LLM Sast Scanner

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 reference file loaded on demand:

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 References

Based on the code being reviewed, load the appropriate reference 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 reference(s).
• For a full audit, load all 34 references and scan systematically.
• Always load references for the top OWASP risks even if not explicitly requested.

Step 3: Analyze Code — Bidirectional Taint Tracking

Taint analysis runs in two passes. Pass A is mandatory and runs first.

Pass A — Sink-First Sweep (mandatory, run before Pass B)

Forward tracing from every source does not converge on a real codebase: a mid-size service has hundreds of request parameters but only a handful of dangerous sinks. Enumerate the sinks first, then walk backward. This pass is cheap, bounded, and has far higher recall.

1. Inventory every dangerous sink in scope with a grep sweep. Record the total count — it is usually 5–50 for a whole repo, and every one must be individually accounted for.

2. For each sink, walk backward to every caller until you reach either an entry point (controller/handler/listener/scheduled job) or a hardcoded constant.
3. Account for 100% of sinks. Every sink gets one of: TAINTED (reaches an entry point), CONSTANT (only ever fed literals), or UNREACHED (no caller found — state this explicitly). Never leave a sink unexamined; never sample.

Report the sink inventory in the scan output — total sinks found, and the disposition of each. A scan that does not state its sink count has not completed Pass A.

Pass B — Source-First Tracing

After Pass A, trace forward from sources to catch classes whose sink is diffuse (XSS, IDOR, business logic, authz) and therefore not greppable as a sink list.

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

   Never infer sanitization from a name. A helper called createFileName, sanitize, normalizePath, buildSafeX, or validateY is only a sanitizer if you have read its body and confirmed every branch constrains the value. Open the function. Trace each return path.

   Decoy-sanitizer shape (high-frequency real-world bug): a helper whose safe behaviour lives in the fall-through branch while an early return passes user input through untouched.

   static String createFileName(String fileName, String feature, LocalDateTime t, String ext) {
       if (StringUtils.isNotBlank(fileName)) {
           return fileName + ext;          // ← tainted, zero filtering: the ATTACKER-REACHED branch
       }
       return feature + "_" + format(t) + ext;   // ← the safe branch, only taken when input is absent
   }
   

   Rule: when a helper branches on "did the caller supply a value?", the supplied-value branch is the attacker's branch. Evaluate the sink against that branch, not the default one.

5. Cross-Layer & Async Continuation — a taint path does not end at a layer boundary. Continue tracing through:

   • Controller → Service → Repository/Util hops, including into a different file/package
   • @Async, @Scheduled, CompletableFuture, thread pools, message queues, event listeners. Leaving the request thread does not detoxify data — the value is still attacker-supplied.
   • Re-derived arguments: check what the caller actually passes. A controller may compute a local String fileName = sanitize(param.getFileName()) and then still hand the raw param.getFileName() to the service. Compare the argument expression at the call site against the sanitized local — they are frequently not the same value.
   • Values re-entering a helper a second time downstream (the sink-side call is the one that counts)

6. 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

Only CONFIRMED and LIKELY findings are reported.

FP burden of proof: UNCERTAIN on any check is NOT sufficient to declare FALSE POSITIVE. If a check result is UNCERTAIN after inspecting the sink, its callers, and the framework internals, use NEEDS CONTEXT instead. Only use FALSE POSITIVE when you have found and can cite positive evidence that the path is protected.

Judge Output Format (internal, before reporting)

Finding: VULN-NNN — <class>
Reachability:   PASS / FAIL / UNCERTAIN — <reason>
Sanitization:   PASS / FAIL / UNCERTAIN — <reason>
Exploitability: PASS / FAIL / UNCERTAIN — <reason>
Judge Verdict:  CONFIRMED / LIKELY / NEEDS CONTEXT / FALSE POSITIVE

False Positive Guardrails

Tags

• default_credentials: require a reachable auth path that accepts the hardcoded credential.
• weak_crypto_hash: require direct use of weak hash/algo — not just an import or third-party component. Covers both weak algorithms (DES, RC4, ECB) and weak hashes (MD5, SHA-1 for passwords); do not use weak_crypto as a separate tag.
• rce → prefer command_injection for direct shell/process execution. Do not replace spel_injection with rce/command_injection.
• jndi_injection in demos: only if the JNDI sink is the primary exploit path.
• Broad tags (trust_boundary, authentication, privilege_escalation): prefer the narrowest valid tag (xff_spoofing, session_fixation, verification_code).
• open_redirect: only if the attacker-controlled redirect is the primary exploit (not infra/parser misconfiguration).
• csrf: skip for stateless Bearer-token-only APIs (SessionCreationPolicy.STATELESS).
• insecure_deserialization: skip if component_vulnerability covers the same sink.
• arbitrary_file_upload: skip for avatar/profile upload with type restrictions and non-webroot storage.
• session_fixation: skip when Spring Security default session management is active.
• information_disclosure: skip for DB credentials in config files — deployment issue, not app-level.

Scope

• Demo/example code: skip any finding whose ONLY vulnerable path is in examples/, demo/, sample/ (or similar). Report only if the bug is in the library/SDK itself.
• Non-default config: verify the DEFAULT value before reporting. Requires non-default/deprecated → cap Low. Explicitly labeled legacy or deprecated in code/docs → cap Informational.

Trust Boundary

• Operator self-harm: skip findings where the "attacker" input comes from operator-written config files (YAML/JSON/TOML), CLI flags the operator supplies themselves (--file, --url, --chain-id), or commands the operator must explicitly run.
• Trusted admin role: skip privilege_escalation/business_logic for actions behind onlyAdmin/onlyOwner/onlyPoolAdmin when that role is trusted by design. Only report if an unprivileged user can reach the same path.
• Internal-only service: skip authentication and information_disclosure when the entire codebase has zero auth AND references internal infra (VPC vars, EC2_INSTANCE_ID, Eureka, Consul). Auth is at the network layer.
• Code generators: skip injection/path_traversal/rce for codegen tools (protoc, swagger-codegen, etc.) whose input comes from developer-controlled source comments, annotations, or local config.

Protocol & Architecture

• Protocol-designed SSRF: skip ssrf when fetching a peer-supplied URL is required by spec (LNURL, UMA, OAuth discovery, WebFinger, OIDC discovery). Only report if the impl allows schemes the protocol does not require (e.g., file://) or skips required domain validation.
• Blind SSRF: downgrade to Informational when all three hold: (a) response never reaches the attacker, (b) no meaningful side effect on the target, (c) no error oracle.
• Bounded DoS: skip denial_of_service unless the upper bound of the iterated/allocated data is attacker-controllable and unbounded. Naturally bounded data (blockchain validator set, gas limits, etcd/request-body size caps) → not a finding.
• Brute force: skip brute_force only if rate limiting is visible in code, framework config, or referenced middleware in the repo. Do not assume infrastructure-level rate limiting.
• Idempotent replay: skip replay/business_logic when the operation is idempotent AND parameters are cryptographically signed (no tampering possible).
• Library dead path: if no real caller in the codebase triggers the vulnerable parameter combination AND the code has a warning log for that path → NEEDS CONTEXT, not a finding.

Platform

• Android app-private storage: skip insecure_storage/information_disclosure for SharedPreferences/DataStore in app-private storage without android:allowBackup="true" in a production manifest.
• Terraform state: skip information_disclosure for providers writing secrets to state when attributes are marked Sensitive: true.
• Intra-org CI/CD: skip supply_chain for mutable action tags (e.g., @v3) when the action org matches the repo org. Only report third-party org actions.
• Local dev tools: skip authentication for README-described local dev tools with no production docs. Exception: report (reduced severity) if the tool does not bind to localhost, exposes tokens in API responses, or allows destructive ops.

Under-Reporting Guardrails

The guardrails above suppress. These override them — a suppression rule must never fire on the cases below. Every rule here exists because a real vulnerability was previously missed.

Authority-escalation overrides the trusted-role rules. The Trusted admin role and Operator self-harm rules apply only to the authority the role legitimately holds. They do not apply when the input crosses from application-data authority into host, filesystem, network, or process authority.

A CMS admin is authorized to export a CSV. A CMS admin is not authorized to choose where on the server's disk that CSV lands. That is a trust-boundary crossing, and it is a finding at full severity regardless of the authentication in front of it.

Do not suppress on constrained impact. A finding stands even when the primitive is partial:

• Extension is forced (.csv, .png) → still arbitrary-path write. Report it.
• Attacker cannot read back what was written → still a write primitive. Report it.
• Overwrite only, no new-file creation (or vice versa) → still a finding.
• No obvious escalation to RCE → impact is still overwrite / disk exhaustion / web-root drop. Absence of an RCE chain is not absence of a vulnerability.

Do not suppress because a parameter's name sounds benign. fileName, name, title, label, id, key, type, format are routinely passed straight to dangerous sinks. Dual-use parameters are the classic miss: the same fileName may be used safely in a Content-Disposition header in one method and unsafely in new File() in another. Seeing the safe use first does not clear the parameter. Evaluate every sink it reaches, independently.

Severity Downgrade Rule does not apply to authority escalation. Requiring authentication downgrades a finding only when the authenticated role was already entitled to the outcome. When authentication merely gates access to an escalated-authority primitive (table above), do not downgrade — and never let a downgrade drop a finding out of the report entirely. Downgrading changes the severity label; it never changes whether the finding is reported.

Sink accounting is not optional. If Pass A found N sinks and the report explains fewer than N, the scan is incomplete — not clean. Re-run the unexplained sinks before reporting.

Pre-Report Checklist

• Public-facing service, or internal-by-design (zero auth everywhere + internal infra refs)?
• Production code, or demo/example/sample directory?
• Attacker is genuinely untrusted, not an admin/operator within their own trust boundary?
• Verify DEFAULT config value — does the attack work with defaults?
• SSRF required by protocol spec?
• SSRF response reachable by attacker (readable / side effect / error oracle)?
• Sensitive storage protected by OS sandbox (Android app-private)?
• Replay: is the operation idempotent with signature-bound parameters?
• Library: does any real caller trigger the vulnerable path?
• Terraform state with Sensitive: true — by design?
• DoS: is the upper bound attacker-controllable and unbounded?
• CI/CD mutable tags: same org or third-party?
• Admin action within the admin's designed trust boundary — or does it reach host/filesystem/process authority the role was never granted?
• Pass A sink inventory: is every sink found accounted for as TAINTED / CONSTANT / UNREACHED?
• Did any "sanitizer" get credited on its name alone, without reading every return path?
• Did any trace stop at an @Async / queue / thread-pool boundary instead of continuing?
• At each call site, is the argument passed the sanitized local — or the raw source re-read?
• Was a finding dropped only because impact was constrained (fixed extension, no read-back, no RCE chain)?

Step 6: Report Findings

Severity Classification

Severity Downgrade Rule: When exploitation requires authentication, specific non-default configuration, chained prerequisites, or is only reachable through an internal/admin-only path, downgrade severity by one level from the class default; LIKELY-verdict findings whose exploitability is marked UNCERTAIN must be capped at one level below the class default regardless of vulnerability type.

Finding Format

[SEVERITY] VULN-NNN — <Vulnerability Class>  [CONFIRMED | LIKELY]
File: <path>:<line_number>
Description: <one sentence — what the vulnerability is>
Impact: <what an attacker can achieve>
Evidence:
  <relevant code snippet>
Judge: <one sentence — why this passed re-verification>
Remediation: <specific fix — not generic advice>
Reference: references/<vuln>.md

For NEEDS CONTEXT findings:

[UNVERIFIABLE] VULN-NNN — <Vulnerability Class>
File: <path>:<line_number>
Blocked by: <what additional context is needed>

Report Structure

When producing a full report, write to sast_report.md (or user-specified path):

# SAST Security Report — <target>
Date: <date>
Analyzer: llm-sast-scanner v1.4

## Executive Summary
<2-3 sentences: total findings by severity, most critical issue>

## Coverage — Sink Inventory (Pass A)
<Total sinks found per class, and the disposition of each: TAINTED / CONSTANT / UNREACHED.
A report without this section is incomplete, not clean.>

| Sink | File:Line | Disposition | Traced to |
|------|-----------|-------------|-----------|

## Critical Findings
## High Findings
## Medium Findings
## Low Findings
## Informational
## Unverifiable Findings

## Remediation Priority
<ordered fix list>

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