--- name: eresus-sast-scanner description: > General-purpose Static Application Security Testing (SAST) skill for code vulnerability analysis. Trigger when the user asks to: "analyze code for vulnerabilities", "review code security", "find security bugs", "do a SAST scan", "check for [vulnerability type] in code", "audit source code", or requests a security code review of any language or framework. Covers 34 vulnerability classes across web, API, auth, mobile, and logic layers. metadata: version: "1.3" domain: application-security coverage: 34 vulnerability knowledge bases --- # SAST Vulnerability Analysis ## Purpose Systematically analyze source code for security vulnerabilities using structured Source→Sink taint tracking, pattern matching, and vulnerability-class-specific detection heuristics. Produce actionable findings with severity ratings, affected code locations (file + line number), and remediation guidance. ## Scope This skill covers the following 34 vulnerability classes. Each has a dedicated vulnerability knowledge file loaded on demand: | Category | Vulnerabilities | |----------|----------------| | **Injection** | SQL Injection, XSS, SSTI, NoSQL Injection, GraphQL Injection, XXE, RCE / Command Injection, Expression Language Injection | | **Access Control & Auth** | IDOR, Privilege Escalation, Authentication/JWT, Default Credentials, Brute Force, Business Logic, HTTP Method Tampering, Verification Code Abuse, Session Fixation | | **Data Exposure & Crypto** | Weak Crypto/Hash, Information Disclosure, Insecure Cookie, Trust Boundary | | **Server-Side** | SSRF, Path Traversal/LFI/RFI, Insecure Deserialization, Arbitrary File Upload, JNDI Injection, Race Conditions | | **Protocol & Infrastructure** | CSRF, Open Redirect, HTTP Request Smuggling/Desync, Denial of Service, CVE Patterns | | **Language/Platform** | PHP Security, Mobile Security (Android/iOS) | --- ## Workflow ### Step 1: Understand Scope Determine: - Target: single file, directory, API endpoint, module, or full repo - Language(s) and framework(s) in use - User's goal: quick scan, deep audit, specific vuln class, or full report ### Step 2: Load Relevant Knowledge Files Based on the code being reviewed, load the appropriate vulnerability knowledge files from `references/`: ``` references/sql_injection.md — SQL / ORM injection references/xss.md — Cross-site scripting references/ssrf.md — Server-side request forgery references/rce.md — Remote code execution references/idor.md — Insecure direct object reference references/authentication_jwt.md — Auth flaws, JWT weaknesses references/csrf.md — Cross-site request forgery references/path_traversal_lfi_rfi.md — Path traversal, LFI/RFI references/ssti.md — Server-side template injection references/xxe.md — XML external entity references/insecure_deserialization.md — Insecure deserialization references/arbitrary_file_upload.md — Arbitrary file upload references/privilege_escalation.md — Privilege escalation references/nosql_injection.md — NoSQL injection references/graphql_injection.md — GraphQL injection references/weak_crypto_hash.md — Weak cryptography / hash references/information_disclosure.md — Information disclosure references/insecure_cookie.md — Insecure cookie attributes references/open_redirect.md — Open redirect references/trust_boundary.md — Trust boundary violations references/race_conditions.md — Race conditions / TOCTOU references/brute_force.md — Brute force / credential stuffing references/default_credentials.md — Default / hardcoded credentials references/verification_code_abuse.md — Verification code abuse references/business_logic.md — Business logic flaws references/http_method_tamper.md — HTTP method tampering references/smuggling_desync.md — HTTP request smuggling / desync references/cve_patterns.md — Known CVE patterns references/expression_language_injection.md — Expression language injection (SpEL / OGNL) references/jndi_injection.md — JNDI injection (Log4Shell class) references/denial_of_service.md — Denial of service / resource exhaustion references/php_security.md — PHP-specific security issues references/mobile_security.md — Mobile security (Android / iOS) references/session_fixation.md — Session fixation ``` **Loading strategy:** - For a targeted review (e.g., "check for SQL injection"), load only the relevant knowledge file(s). - For a full audit, load all 34 coverage files and scan systematically. - Always load knowledge files for the top OWASP risks even if not explicitly requested. --- ### Step 3: Analyze Code — Source→Sink Taint Tracking For each loaded vulnerability class, perform taint analysis: 1. **Identify Sources** — User-controlled input entry points: - HTTP params, headers, cookies, request body - File uploads - WebSocket messages - Environment variables - Database reads of user-supplied data, deserialized objects 2. **Trace Data Flow** — Follow the data through: - Variable assignments, function arguments, return values - Framework helpers, ORM calls, template rendering - Cross-module/service boundaries 3. **Check Sinks** — Dangerous operations receiving tainted data: - Query execution (SQL, NoSQL, LDAP, XPath) - Shell/OS command execution - File system operations - HTTP client calls - Template rendering / eval / expression parsing - Serialization/deserialization 4. **Evaluate Sanitization** — Between source and sink, look for: - Input validation (allowlist vs denylist) - Context-appropriate encoding/escaping - Parameterization (prepared statements) - Framework-native protections 5. **Determine Preliminary Verdict**: - **VULN**: Taint reaches sink with no effective sanitization - **LIKELY VULN**: Sanitization present but bypassable per reference heuristics - **SAFE**: Effective sanitization or no taint path --- ### Step 4: Business Logic & Auth Analysis Beyond taint tracking, check for: - Missing authentication/authorization on sensitive endpoints - Insecure state machine transitions - Race conditions in concurrent operations - Improper trust boundaries between components - JWT algorithm confusion, token fixation, session issues - Default/hardcoded credentials - Enumeration via timing or response differences --- ### Step 5: Judge — Validity Re-Verification Before reporting, every preliminary finding (VULN or LIKELY VULN) **must pass a Judge review**. The Judge acts as an adversarial second opinion to eliminate false positives. For each candidate finding, answer all of the following: #### Reachability Check - [ ] Is the source actually user-controlled, or is it internal/trusted data? - [ ] Is the vulnerable code path reachable from an HTTP endpoint / entry point, or is it dead code / internal-only? - [ ] Are there upstream guards (auth middleware, input filters) that block the path before it reaches the sink? #### Sanitization Re-Evaluation - [ ] Is there sanitization that was missed in Step 3? (Check parent functions, middleware, framework internals) - [ ] Is the sanitization method sufficient for this specific sink and context? - [ ] Does the framework provide implicit protection for this pattern? #### Exploitability Check - [ ] Can the tainted value actually reach the sink in a form that triggers the vulnerability? - [ ] Is exploitation conditional on a specific environment, config, or privilege level? - [ ] For logic bugs: is the business impact real, or hypothetical? - [ ] Is the chosen tag the most precise valid label for this finding? #### Judge Verdict | Verdict | Meaning | Action | |---------|---------|--------| | **CONFIRMED** | All reachability/sanitization/exploitability checks pass | Include in report | | **LIKELY** | Most checks pass; one uncertainty remains | Include in report, flag uncertainty | | **NEEDS CONTEXT** | Cannot determine without runtime behavior / config / additional files | Note as "unverifiable without X" | | **FALSE POSITIVE** | A check definitively fails | Drop silently | **Only CONFIRMED and LIKELY findings are reported.** #### Judge Output Format (internal, before reporting) ``` Finding: VULN-NNN — Reachability: PASS / FAIL / UNCERTAIN — Sanitization: PASS / FAIL / UNCERTAIN — Exploitability: PASS / FAIL / UNCERTAIN — Judge Verdict: CONFIRMED / LIKELY / NEEDS CONTEXT / FALSE POSITIVE ``` #### False Positive Guardrails - Do not emit `default_credentials` unless there is a reachable authentication path that accepts a hardcoded, documented, factory, or seeded credential pair. - Do not emit `weak_crypto_hash` when the evidence only shows a vulnerable third-party component or a generic cryptography import. Require direct use of weak hashes, broken password storage, or unsafe signing. - **Tag clarification**: `weak_crypto_hash` is the canonical tag for both weak cryptographic algorithms (DES, RC4, ECB mode) and weak hash functions (MD5, SHA-1 for passwords). Do not use `weak_crypto` as a separate tag unless the benchmark ground truth explicitly requires it; prefer `weak_crypto_hash` to avoid tag fragmentation. - Do not emit generic `rce` when the code shows direct shell/process execution — prefer `command_injection`. - Do not replace `spel_injection` with `command_injection` or `rce` when the exploit primitive is Spring EL expression parsing. - Do not emit `jndi_injection` for component demos unless the JNDI sink itself is the primary exploit path. - Do not emit broad tags (`trust_boundary`, `authentication`, `privilege_escalation`) when a narrower precise tag is supported (`xff_spoofing`, `session_fixation`, `verification_code`). - Do not emit `open_redirect` for infrastructure/parser misconfiguration unless attacker-controlled redirect response is the primary exploit. - Do not emit `denial_of_service` merely because a path lacks size/rate limits — require explicit evidence that resource exhaustion is the primary impact. - Do not emit `brute_force` merely because a login endpoint lacks visible rate limiting — rate limiting may exist at infrastructure level. Require explicit evidence of unlimited attempt processing. - Do not emit `csrf` for stateless APIs using Bearer-token-only authentication with `SessionCreationPolicy.STATELESS`. - Do not emit `insecure_deserialization` when the same sink is already covered by `component_vulnerability` (e.g., Fastjson autoType) unless a separate deserialization path exists. - Do not emit `arbitrary_file_upload` for profile/avatar image upload with type restrictions and non-webroot storage. - Do not emit `session_fixation` when Spring Security default session management is active (migrateSession is the default). - Do not emit `information_disclosure` for database credentials in application config files — these are deployment issues, not application-level disclosure. --- ### Step 6: Report Findings #### Severity Classification | Severity | Criteria | |----------|----------| | **Critical** | Direct RCE, authentication bypass, unauthenticated data exposure | | **High** | SQLi, SSRF, IDOR with sensitive data, stored XSS, privilege escalation | | **Medium** | Reflected XSS, CSRF, path traversal, insecure deserialization | | **Low** | Information disclosure, open redirect, weak crypto, insecure cookie | | **Info** | Missing security headers, verbose errors, defense-in-depth gaps | #### Finding Format ``` [SEVERITY] VULN-NNN — [CONFIRMED | LIKELY] File: : Description: Impact: Evidence: Judge: Remediation: ``` For NEEDS CONTEXT findings: ``` [UNVERIFIABLE] VULN-NNN — File: : Blocked by: ``` #### Report Structure When producing a full report, write to `sast_report.md` (or user-specified path): ```markdown # SAST Security Report — Date: Analyzer: eresus-sast-scanner v1.3 ## Executive Summary <2-3 sentences: total findings by severity, most critical issue> ## Critical Findings ## High Findings ## Medium Findings ## Low Findings ## Informational ## Unverifiable Findings ## Remediation Priority ``` --- ## Key Principles - **Evidence over assertion**: always show the vulnerable code path, not just the pattern name - **Context matters**: a finding is only valid if the sink is reachable with user-controlled data - **Avoid false positives**: if sanitization exists, verify it is bypassable before marking VULN - **Be precise**: include exact file paths and line numbers — never approximate - **Fix > flag**: always provide a concrete remediation, not just a problem statement - **Language-aware**: adapt sink/source patterns to the specific language and framework in use