Vulnerability Analysis

Every vulnerability you miss is a vulnerability an attacker can find. Systematic analysis traces untrusted data from source to sink, evaluates filters for bypass, and questions every trust boundary assumption.

When to Apply

Apply this analysis when:

• Reviewing any code for security vulnerabilities
• Auditing authentication, authorization, or session logic
• Evaluating input handling and output encoding
• Assessing cryptographic implementations
• Reviewing file operations, command execution, or deserialization
• Checking for race conditions in concurrent code
• Analyzing dependency security and supply chain risks
• Hardening web APIs, reverse proxies, or infrastructure code

Core Methodology

Taint Analysis: Mark untrusted data at its origin (source) and track propagation to dangerous operations (sink). Assess whether adequate sanitization exists along each path.

Source-Forward: Start from data entry points, trace every path through the codebase to sinks. Comprehensive but time-consuming.

Sink-Backward: Start from dangerous operations (eval, exec, SQL, innerHTML), trace backward to potential sources. Faster and targeted.

Hybrid Approach: Use sink-backward for rapid high-risk identification, then source-forward for complete coverage of the attack surface.

Rule Categories by Priority

Audit Protocol

1. Reconnaissance: Identify language, frameworks, trust boundaries, sensitive data, and high-value targets. Establish the threat model — what attacker capabilities are assumed?
2. Attack Surface Enumeration: Map all entry points — HTTP endpoints, CLI args, file inputs, IPC, deserialization points
3. Systematic Analysis: Apply hybrid taint analysis across all source-sink paths
4. False Positive Reduction: For every finding, verify: (a) trace validation chains upstream — is the value bounded before reaching the sink? (b) confirm reachability — can an attacker actually trigger this path from external input? (c) evaluate against the project's threat model — does exploitation require capabilities the attacker isn't assumed to have? (d) check for established patterns — is this a recognized safe idiom in the domain (e.g., volatile+fences in VMMs, privileged setup phases in sandboxes)?
5. Exploitability Gate: Before reporting ANY finding, answer all three questions affirmatively: (a) Are you certain this isn't the expected functionality? (b) Is this a valid vulnerability worth reporting? (c) Is it actually exploitable to users with this deployed in production? If any answer is "no" or uncertain, investigate further — read the actual code paths and verify before claiming exploitability.
6. Findings: Document CWE, severity, root cause, exploitation scenario, and remediation. Rate severity based on actual exploitability after the Exploitability Gate, not pattern-match severity.
7. Variant Hunting: Generalize each finding into a pattern and search for variants

How to Use

Read individual reference files for detailed vulnerability patterns and code examples:

references/taint-source-sink-analysis.md
references/injection-sql.md
references/injection-command.md
references/auth-bypass.md
references/crypto-weak-algorithms.md
references/_sections.md

Each reference file contains:

• Explanation of the vulnerability class and why it matters
• Vulnerable code example with exploitation scenario
• Secure code example with explanation
• Language-specific patterns and edge cases

False Positive Discipline

A finding without confirmed exploitability is noise. Before reporting any vulnerability:

• Trace the full validation chain: Follow the value backward from sink to source. If it's bounded, cast, or validated upstream, the overflow/injection may be impossible regardless of the sink pattern.
• Verify attacker reachability: Can external input actually reach this code path? Internal invariant assertions (.unwrap() after bounds checks) are not guest/user-triggerable vulnerabilities.
• Respect the threat model: A jailer running as root needs root. A snapshot loaded from a chroot is trusted by design. Flag design-level concerns separately from exploitable vulnerabilities.
• Recognize domain idioms: volatile + memory fences is the standard virtio/VMM pattern, not a race condition. Privileged setup before exec() is the standard sandbox pattern, not a privilege escalation.
• Separate severity from pattern: An unchecked_mul on a value bounded to 256 is not CRITICAL. Rate by actual exploitability, not by the CWE description.

Security Review Checklist

After reviewing code, verify:

• All user inputs are validated server-side with allowlists
• Database queries use parameterized statements exclusively
• Command execution avoids shell interpretation
• Output encoding matches the rendering context (HTML, JS, CSS, URL)
• Authentication checks exist on every sensitive endpoint
• Authorization verifies ownership, not just authentication
• Cryptographic operations use modern algorithms with proper key management
• Session tokens have sufficient entropy with Secure, HttpOnly, SameSite attributes
• File operations validate paths against traversal attacks
• Deserialization never operates on untrusted data without safe loaders
• Race conditions are mitigated with atomic operations or proper locking
• Dependencies are pinned, audited, and free of known CVEs