@tamsensedev/runner 0.13.0 → 0.19.0

package/library/skills/false-positive-check/references/false-positive-patterns.md

@@ -1,122 +1,122 @@
-# False Positive Patterns: Lessons Learned
-
-Apply ALL items in this checklist to EACH potential bug during verification.
-
-Contents:
-
-- [Checklist](#checklist): 13 items to apply to every bug (trace validation, confirm data paths, bounds logic, TOCTOU, trust boundaries, real vs theoretical impact, defense-in-depth)
-- [Red Flags for False Positives](#red-flags-for-false-positives): recurring failure patterns (pattern-based, context-blind, math/bounds, API-contract)
-
-## Checklist
-
-### 1. Trace Full Validation Chain
-
-Don't analyze isolated code snippets. Trace backwards to find ALL validation that precedes potentially dangerous operations. Network packet size operations may look dangerous but often have bounds validation earlier in the function.
-
-### 1a. Map Complete Conditional Logic Flow
-
-Vulnerable-looking code may be unreachable due to conditional logic that creates mathematical guarantees. Example: array access `buffer[length-4]` appears unsafe when `length < 4`, but if the code is only reachable when `length > 12` due to earlier validation, the vulnerability is impossible.
-
-**Verify:**
-
-- What conditions must be met for execution to reach the alleged vulnerability?
-- Do those conditions mathematically prevent the vulnerability scenario?
-- Are there minimum size/length requirements that guarantee safe access?
-- Does the conditional flow create impossible-to-violate bounds?
-
-### 2. Identify Defensive Programming Patterns
-
-Distinguish between actual vulnerabilities and defensive assertions/validations. `ASSERT(size == expected_size)` followed by size-controlled operations is defensive, not vulnerable. Verify that checks actually prevent the alleged vulnerability.
-
-### 3. Confirm Exploitable Data Paths
-
-Only report vulnerabilities with CONFIRMED exploitable data flow paths. Don't assume network-controlled data reaches dangerous functions without tracing the actual path step by step.
-
-### 4. Understand Data Source Context
-
-Distinguish between data sources and their trust levels. API return values, compile-time constants, and network data have different risk profiles. Determine the actual source and whether it is attacker-controlled.
-
-### 5. Analyze Bounds Validation Logic
-
-Look for mathematical relationships between validation checks and subsequent operations. If `packet_size >= MIN_SIZE` is checked and `MIN_SIZE >= sizeof(header)`, then `packet_size - sizeof(header)` cannot underflow.
-
-### 6. Verify TOCTOU Claims
-
-Time-of-check-time-of-use issues require proof that the checked value can change between check and use. If a size is checked and immediately used in the same function with no external modification possible, there is no TOCTOU.
-
-### 7. Understand API Contract and Trust Boundaries
-
-Always understand API contracts before claiming buffer overflows. Some APIs have built-in bounds protection and cannot write beyond the buffer regardless of input parameters.
-
-### 8. Distinguish Internal Storage from External Input
-
-Internal storage systems (configuration stores, registries) are controlled by trusted components, not attackers. Values set during installation by trusted components are not attacker-controlled.
-
-### 9. Don't Confuse Pattern Recognition with Vulnerability Analysis
-
-Code patterns that "look vulnerable" may be safely implemented due to context and API contracts. Size parameters being modified doesn't mean buffer overflow if the API prevents writing beyond bounds.
-
-### 10. Verify Concurrent Access is Actually Possible
-
-Don't assume race conditions exist without proving concurrent access patterns. Single-threaded initialization contexts cannot have race conditions. Verify the threading model and synchronization mechanisms.
-
-### 11. Assess Real vs Theoretical Security Impact
-
-Focus on vulnerabilities with actual security impact. Storage failure for non-critical data is an operational issue, not a security vulnerability. Ask: would this lead to code execution, privilege escalation, or information disclosure?
-
-### 12. Understand Defense-in-Depth vs Primary Controls
-
-Failure of defense-in-depth mechanisms is not always a vulnerability if primary protections exist. Token cleanup failure is not critical if tokens are single-use by design at the server.
-
-### 13. Apply the Checklist Rigorously, Not Superficially
-
-Having a checklist doesn't prevent false positives if it isn't applied systematically. For EVERY potential vulnerability, work through ALL checklist items before concluding.
-
----
-
-## Red Flags for False Positives
-
-### Pattern-Based False Positives
-
-- Reporting vulnerabilities in validation/bounds-checking code itself
-- Claiming TOCTOU without proving the value can change
-- Ignoring preceding validation logic
-- Assuming network data reaches operations without tracing the path
-- Confusing defensive programming (assertions/checks) with vulnerabilities
-- Analyzing vulnerable-looking patterns without tracing conditional logic that controls reachability
-- Reporting "vulnerabilities" in error handling or cleanup code
-- Flagging size calculations without understanding mathematical constraints
-- Identifying "dangerous" functions without checking if inputs are bounded
-- Claiming buffer overflows in fixed-size operations with compile-time bounds
-- Reporting race conditions in single-threaded or synchronized contexts
-
-### Context-Blind Analysis False Positives
-
-- Analyzing code snippets without understanding broader system design
-- Ignoring architectural guarantees (single-writer, trusted input sources)
-- Missing that "vulnerable" code is unreachable due to earlier validation
-- Confusing debug/development code paths with production paths
-- Reporting issues in code that only runs during trusted installation/setup
-- Flagging theoretical issues that cannot occur due to system architecture
-- Missing that alleged vulnerabilities are prevented by framework or language guarantees
-- Reporting issues in test-only or debug-only code paths as production vulnerabilities
-
-### Mathematical/Bounds Analysis False Positives
-
-- Reporting integer underflow without proving the mathematical condition can occur
-- Claiming buffer overflow when bounds are mathematically guaranteed by validation
-- Missing that conditional logic creates mathematical impossibility of vulnerable conditions
-- Reporting off-by-one errors without checking if loop bounds prevent the condition
-- Claiming memory corruption when allocation sizes are verified sufficient
-- Reporting arithmetic overflow without checking if input ranges prevent the condition
-
-### API Contract Misunderstanding False Positives
-
-- Claiming buffer overflows when APIs have built-in bounds checking
-- Reporting memory corruption for APIs that manage their own memory safely
-- Missing that return values are already validated by the API contract
-- Confusing API parameter modification with vulnerability when API prevents unsafe modification
-- Reporting issues explicitly handled by the API's safety guarantees
-- Missing that seemingly dangerous operations are safe due to API implementation details
-
-Part of the `false-positive-check` skill, adapted from https://github.com/trailofbits/skills/tree/main/plugins/fp-check (commit 5c99c03fb8a9ea568432ecbcba5d86e9f4ac2bf0), CC BY-SA 4.0. Changed: punctuation and small wording changes for read-only runs.
+# False Positive Patterns: Lessons Learned
+
+Apply ALL items in this checklist to EACH potential bug during verification.
+
+Contents:
+
+- [Checklist](#checklist): 13 items to apply to every bug (trace validation, confirm data paths, bounds logic, TOCTOU, trust boundaries, real vs theoretical impact, defense-in-depth)
+- [Red Flags for False Positives](#red-flags-for-false-positives): recurring failure patterns (pattern-based, context-blind, math/bounds, API-contract)
+
+## Checklist
+
+### 1. Trace Full Validation Chain
+
+Don't analyze isolated code snippets. Trace backwards to find ALL validation that precedes potentially dangerous operations. Network packet size operations may look dangerous but often have bounds validation earlier in the function.
+
+### 1a. Map Complete Conditional Logic Flow
+
+Vulnerable-looking code may be unreachable due to conditional logic that creates mathematical guarantees. Example: array access `buffer[length-4]` appears unsafe when `length < 4`, but if the code is only reachable when `length > 12` due to earlier validation, the vulnerability is impossible.
+
+**Verify:**
+
+- What conditions must be met for execution to reach the alleged vulnerability?
+- Do those conditions mathematically prevent the vulnerability scenario?
+- Are there minimum size/length requirements that guarantee safe access?
+- Does the conditional flow create impossible-to-violate bounds?
+
+### 2. Identify Defensive Programming Patterns
+
+Distinguish between actual vulnerabilities and defensive assertions/validations. `ASSERT(size == expected_size)` followed by size-controlled operations is defensive, not vulnerable. Verify that checks actually prevent the alleged vulnerability.
+
+### 3. Confirm Exploitable Data Paths
+
+Only report vulnerabilities with CONFIRMED exploitable data flow paths. Don't assume network-controlled data reaches dangerous functions without tracing the actual path step by step.
+
+### 4. Understand Data Source Context
+
+Distinguish between data sources and their trust levels. API return values, compile-time constants, and network data have different risk profiles. Determine the actual source and whether it is attacker-controlled.
+
+### 5. Analyze Bounds Validation Logic
+
+Look for mathematical relationships between validation checks and subsequent operations. If `packet_size >= MIN_SIZE` is checked and `MIN_SIZE >= sizeof(header)`, then `packet_size - sizeof(header)` cannot underflow.
+
+### 6. Verify TOCTOU Claims
+
+Time-of-check-time-of-use issues require proof that the checked value can change between check and use. If a size is checked and immediately used in the same function with no external modification possible, there is no TOCTOU.
+
+### 7. Understand API Contract and Trust Boundaries
+
+Always understand API contracts before claiming buffer overflows. Some APIs have built-in bounds protection and cannot write beyond the buffer regardless of input parameters.
+
+### 8. Distinguish Internal Storage from External Input
+
+Internal storage systems (configuration stores, registries) are controlled by trusted components, not attackers. Values set during installation by trusted components are not attacker-controlled.
+
+### 9. Don't Confuse Pattern Recognition with Vulnerability Analysis
+
+Code patterns that "look vulnerable" may be safely implemented due to context and API contracts. Size parameters being modified doesn't mean buffer overflow if the API prevents writing beyond bounds.
+
+### 10. Verify Concurrent Access is Actually Possible
+
+Don't assume race conditions exist without proving concurrent access patterns. Single-threaded initialization contexts cannot have race conditions. Verify the threading model and synchronization mechanisms.
+
+### 11. Assess Real vs Theoretical Security Impact
+
+Focus on vulnerabilities with actual security impact. Storage failure for non-critical data is an operational issue, not a security vulnerability. Ask: would this lead to code execution, privilege escalation, or information disclosure?
+
+### 12. Understand Defense-in-Depth vs Primary Controls
+
+Failure of defense-in-depth mechanisms is not always a vulnerability if primary protections exist. Token cleanup failure is not critical if tokens are single-use by design at the server.
+
+### 13. Apply the Checklist Rigorously, Not Superficially
+
+Having a checklist doesn't prevent false positives if it isn't applied systematically. For EVERY potential vulnerability, work through ALL checklist items before concluding.
+
+---
+
+## Red Flags for False Positives
+
+### Pattern-Based False Positives
+
+- Reporting vulnerabilities in validation/bounds-checking code itself
+- Claiming TOCTOU without proving the value can change
+- Ignoring preceding validation logic
+- Assuming network data reaches operations without tracing the path
+- Confusing defensive programming (assertions/checks) with vulnerabilities
+- Analyzing vulnerable-looking patterns without tracing conditional logic that controls reachability
+- Reporting "vulnerabilities" in error handling or cleanup code
+- Flagging size calculations without understanding mathematical constraints
+- Identifying "dangerous" functions without checking if inputs are bounded
+- Claiming buffer overflows in fixed-size operations with compile-time bounds
+- Reporting race conditions in single-threaded or synchronized contexts
+
+### Context-Blind Analysis False Positives
+
+- Analyzing code snippets without understanding broader system design
+- Ignoring architectural guarantees (single-writer, trusted input sources)
+- Missing that "vulnerable" code is unreachable due to earlier validation
+- Confusing debug/development code paths with production paths
+- Reporting issues in code that only runs during trusted installation/setup
+- Flagging theoretical issues that cannot occur due to system architecture
+- Missing that alleged vulnerabilities are prevented by framework or language guarantees
+- Reporting issues in test-only or debug-only code paths as production vulnerabilities
+
+### Mathematical/Bounds Analysis False Positives
+
+- Reporting integer underflow without proving the mathematical condition can occur
+- Claiming buffer overflow when bounds are mathematically guaranteed by validation
+- Missing that conditional logic creates mathematical impossibility of vulnerable conditions
+- Reporting off-by-one errors without checking if loop bounds prevent the condition
+- Claiming memory corruption when allocation sizes are verified sufficient
+- Reporting arithmetic overflow without checking if input ranges prevent the condition
+
+### API Contract Misunderstanding False Positives
+
+- Claiming buffer overflows when APIs have built-in bounds checking
+- Reporting memory corruption for APIs that manage their own memory safely
+- Missing that return values are already validated by the API contract
+- Confusing API parameter modification with vulnerability when API prevents unsafe modification
+- Reporting issues explicitly handled by the API's safety guarantees
+- Missing that seemingly dangerous operations are safe due to API implementation details
+
+Part of the `false-positive-check` skill, adapted from https://github.com/trailofbits/skills/tree/main/plugins/fp-check (commit 5c99c03fb8a9ea568432ecbcba5d86e9f4ac2bf0), CC BY-SA 4.0. Changed: punctuation and small wording changes for read-only runs.

package/library/skills/false-positive-check/references/gate-reviews.md

@@ -1,36 +1,36 @@
-# Gate Reviews and Verdicts
-
-Before reporting ANY bug as a vulnerability, all six gate reviews must pass. Evaluate them at the end, after all phases are complete:
-
-| Gate | Criterion | Pass | Fail |
-|------|-----------|------|------|
-| **1. Process** | All phases completed with documented evidence | Evidence exists for every phase | Phases lack concrete evidence |
-| **2. Reachability** | Attacker can reach and control data at the vulnerability | Clear evidence of attacker-controlled path + PoC confirms | Cannot demonstrate attacker control or reachability |
-| **3. Real Impact** | Exploitation leads to code execution, privilege escalation, information disclosure, unauthorized changes to data, or loss of money | Direct impact with concrete scenarios | Only operational robustness issue |
-| **4. PoC Validation** | PoC (pseudocode, executable, or unit test) demonstrates the attack path | Shows attacker control, trigger, and impact | PoC fails to show attack path or impact |
-| **5. Math Bounds** | Mathematical analysis confirms vulnerable condition is possible (N/A, counted as pass, when the bug is not about bounds or arithmetic) | Algebraic proof shows condition is possible | Math proves validation prevents it |
-| **6. Environment** | No environmental protections entirely prevent exploitation | Protections do not eliminate vulnerability | Environmental protections block it entirely |
-
-For a suspected correctness bug rather than a vulnerability: gate 2 asks whether a realistic input or state reaches the faulty code, and gate 3 whether the outcome is a wrong result, lost or corrupted data, or a crash that users hit.
-
-## Verdict Format
-
-- **TRUE POSITIVE**: All gate reviews pass → `BUG #N TRUE POSITIVE - [brief vulnerability description]`
-- **FALSE POSITIVE**: Any gate review fails → `BUG #N FALSE POSITIVE - [brief reason for rejection]`
-- **INCONCLUSIVE**: A gate cannot be decided from the code available (the caller is in another repository, the configuration is not in the repo) → `BUG #N NEEDS VERIFICATION - [the exact open question]`. Reported as a note, never as blocking.
-
-If any phase fails verification, document the failure with evidence and continue all remaining phases. Issue the FALSE POSITIVE verdict only after all phases are complete.
-
-## Example Verdict
-
-```
-BUG #3 FALSE POSITIVE - Integer underflow in packet_handler.c:142
-  Gate 5 (Math Bounds) FAIL: validation at line 98 ensures packet_size >= 16,
-  making (packet_size - header_size) >= 8. Underflow is mathematically impossible.
-
-BUG #5 FALSE POSITIVE - IDOR in src/api/files.ts:19
-  Gate 2 (Reachability) FAIL: the route is mounted under accountRouter (src/app.ts:52),
-  whose middleware loads the file with the session's account id; other accounts' files return 404.
-```
-
-Part of the `false-positive-check` skill, adapted from https://github.com/trailofbits/skills/tree/main/plugins/fp-check (commit 5c99c03fb8a9ea568432ecbcba5d86e9f4ac2bf0), CC BY-SA 4.0. Changed: wider impact list for web applications, N/A rule for gate 5, correctness-bug reading of gates 2 and 3, inconclusive verdict, second example.
+# Gate Reviews and Verdicts
+
+Before reporting ANY bug as a vulnerability, all six gate reviews must pass. Evaluate them at the end, after all phases are complete:
+
+| Gate | Criterion | Pass | Fail |
+|------|-----------|------|------|
+| **1. Process** | All phases completed with documented evidence | Evidence exists for every phase | Phases lack concrete evidence |
+| **2. Reachability** | Attacker can reach and control data at the vulnerability | Clear evidence of attacker-controlled path + PoC confirms | Cannot demonstrate attacker control or reachability |
+| **3. Real Impact** | Exploitation leads to code execution, privilege escalation, information disclosure, unauthorized changes to data, or loss of money | Direct impact with concrete scenarios | Only operational robustness issue |
+| **4. PoC Validation** | PoC (pseudocode, executable, or unit test) demonstrates the attack path | Shows attacker control, trigger, and impact | PoC fails to show attack path or impact |
+| **5. Math Bounds** | Mathematical analysis confirms vulnerable condition is possible (N/A, counted as pass, when the bug is not about bounds or arithmetic) | Algebraic proof shows condition is possible | Math proves validation prevents it |
+| **6. Environment** | No environmental protections entirely prevent exploitation | Protections do not eliminate vulnerability | Environmental protections block it entirely |
+
+For a suspected correctness bug rather than a vulnerability: gate 2 asks whether a realistic input or state reaches the faulty code, and gate 3 whether the outcome is a wrong result, lost or corrupted data, or a crash that users hit.
+
+## Verdict Format
+
+- **TRUE POSITIVE**: All gate reviews pass → `BUG #N TRUE POSITIVE - [brief vulnerability description]`
+- **FALSE POSITIVE**: Any gate review fails → `BUG #N FALSE POSITIVE - [brief reason for rejection]`
+- **INCONCLUSIVE**: A gate cannot be decided from the code available (the caller is in another repository, the configuration is not in the repo) → `BUG #N NEEDS VERIFICATION - [the exact open question]`. Reported as a note, never as blocking.
+
+If any phase fails verification, document the failure with evidence and continue all remaining phases. Issue the FALSE POSITIVE verdict only after all phases are complete.
+
+## Example Verdict
+
+```
+BUG #3 FALSE POSITIVE - Integer underflow in packet_handler.c:142
+  Gate 5 (Math Bounds) FAIL: validation at line 98 ensures packet_size >= 16,
+  making (packet_size - header_size) >= 8. Underflow is mathematically impossible.
+
+BUG #5 FALSE POSITIVE - IDOR in src/api/files.ts:19
+  Gate 2 (Reachability) FAIL: the route is mounted under accountRouter (src/app.ts:52),
+  whose middleware loads the file with the session's account id; other accounts' files return 404.
+```
+
+Part of the `false-positive-check` skill, adapted from https://github.com/trailofbits/skills/tree/main/plugins/fp-check (commit 5c99c03fb8a9ea568432ecbcba5d86e9f4ac2bf0), CC BY-SA 4.0. Changed: wider impact list for web applications, N/A rule for gate 5, correctness-bug reading of gates 2 and 3, inconclusive verdict, second example.

package/library/skills/false-positive-check/references/standard-verification.md

@@ -1,80 +1,80 @@
-# Standard Verification
-
-Linear single-pass checklist for straightforward bugs. No task tracking: work through each step sequentially and document findings inline.
-
-## Escalation Checkpoints
-
-Two points in this checklist may trigger escalation to [deep-verification.md](deep-verification.md):
-
-1. **After Step 1 (Data Flow)**: Escalate if 3+ trust boundaries, callbacks/async control flow, or ambiguous validation chain
-2. **After Step 5 (Devil's Advocate)**: Escalate if any question produces genuine uncertainty you cannot resolve
-
-When escalating, hand off all evidence gathered so far: deep verification will continue from where you left off.
-
-## Checklist
-
-### Step 1: Data Flow
-
-Trace data from source to the alleged vulnerability sink.
-
-- Map trust boundaries crossed (internal/trusted vs external/untrusted)
-- Identify all validation and sanitization between source and sink
-- Check API contracts: many APIs have built-in bounds protection that prevents the alleged issue
-- Check for environmental protections (compiler, runtime, OS, framework) that prevent exploitation entirely (not just raise the bar)
-- Apply class-specific checks from [bug-class-verification.md](bug-class-verification.md)
-
-**Key pitfall**: Analyzing the vulnerable code in isolation. Conditional logic upstream may make the vulnerability mathematically unreachable. Trace the full validation chain.
-
-**Escalation check**: If you found 3+ trust boundaries, callbacks or async control flow in the path, or an ambiguous validation chain: escalate to deep verification.
-
-### Step 2: Exploitability
-
-Prove the attacker can trigger the vulnerability.
-
-- **Attacker control**: Prove the attacker controls data reaching the vulnerable operation. Internal storage set by trusted components is not attacker-controlled.
-- **Bounds proof**: For integer/bounds issues, create an explicit algebraic proof using the template in [evidence-templates.md](evidence-templates.md). Verify: IF validation_check_passes THEN bounds_guarantee_holds.
-- **Race feasibility**: For race conditions, prove concurrent access is actually possible. Single-threaded initialization and synchronized contexts cannot have races.
-
-### Step 3: Impact
-
-Determine whether exploitation has real security consequences.
-
-- Distinguish real security impact (RCE, privesc, info disclosure) from operational robustness issues (crash recovery, cleanup failure)
-- Distinguish primary security controls from defense-in-depth. Failure of a defense-in-depth measure is not a vulnerability if primary protections remain intact.
-
-### Step 4: PoC Sketch
-
-Create a pseudocode PoC showing the attack path. Executable and unit test PoCs are optional for standard verification; in review and test steps they run only from a temp directory outside the repository and never against live services (see the ground rules in SKILL.md).
-
-```
-Data Flow: [Source] → [Validation?] → [Transform?] → [Vulnerable Op] → [Impact]
-Attacker controls: [what input, how]
-Trigger: [pseudocode showing the exploit path]
-```
-
-See [evidence-templates.md](evidence-templates.md) for the full PoC template.
-
-### Step 5: Devil's Advocate Spot-Check
-
-Answer these 7 questions. If any produces genuine uncertainty, escalate to deep verification.
-
-**Against the vulnerability:**
-
-1. Am I seeing a vulnerability because the pattern "looks dangerous" rather than because it actually is? (pattern-matching bias)
-2. Am I incorrectly assuming attacker control over trusted data? (trust boundary confusion)
-3. Have I rigorously proven the mathematical condition for vulnerability can occur? (proof rigor)
-4. Am I confusing defense-in-depth failure with a primary security vulnerability? (defense-in-depth confusion)
-5. Am I hallucinating this vulnerability? LLMs are biased toward seeing bugs everywhere: is this actually real or am I pattern-matching on scary-looking code? (LLM self-check)
-
-**For the vulnerability (always ask: false-negative protection):**
-
-6. Am I dismissing a real vulnerability because the exploit seems complex or unlikely?
-7. Am I inventing mitigations or validation logic that I haven't verified in the actual source code? Re-read the code after reaching a conclusion.
-
-**Escalation check**: If any question above produces genuine uncertainty you cannot resolve with the evidence at hand: escalate to deep verification.
-
-### Step 6: Gate Review
-
-Apply all six gates from [gate-reviews.md](gate-reviews.md) and all 13 items from [false-positive-patterns.md](false-positive-patterns.md) to reach a verdict.
-
-Part of the `false-positive-check` skill, adapted from https://github.com/trailofbits/skills/tree/main/plugins/fp-check (commit 5c99c03fb8a9ea568432ecbcba5d86e9f4ac2bf0), CC BY-SA 4.0. Changed: read-only rule for proofs of concept, punctuation.
+# Standard Verification
+
+Linear single-pass checklist for straightforward bugs. No task tracking: work through each step sequentially and document findings inline.
+
+## Escalation Checkpoints
+
+Two points in this checklist may trigger escalation to [deep-verification.md](deep-verification.md):
+
+1. **After Step 1 (Data Flow)**: Escalate if 3+ trust boundaries, callbacks/async control flow, or ambiguous validation chain
+2. **After Step 5 (Devil's Advocate)**: Escalate if any question produces genuine uncertainty you cannot resolve
+
+When escalating, hand off all evidence gathered so far: deep verification will continue from where you left off.
+
+## Checklist
+
+### Step 1: Data Flow
+
+Trace data from source to the alleged vulnerability sink.
+
+- Map trust boundaries crossed (internal/trusted vs external/untrusted)
+- Identify all validation and sanitization between source and sink
+- Check API contracts: many APIs have built-in bounds protection that prevents the alleged issue
+- Check for environmental protections (compiler, runtime, OS, framework) that prevent exploitation entirely (not just raise the bar)
+- Apply class-specific checks from [bug-class-verification.md](bug-class-verification.md)
+
+**Key pitfall**: Analyzing the vulnerable code in isolation. Conditional logic upstream may make the vulnerability mathematically unreachable. Trace the full validation chain.
+
+**Escalation check**: If you found 3+ trust boundaries, callbacks or async control flow in the path, or an ambiguous validation chain: escalate to deep verification.
+
+### Step 2: Exploitability
+
+Prove the attacker can trigger the vulnerability.
+
+- **Attacker control**: Prove the attacker controls data reaching the vulnerable operation. Internal storage set by trusted components is not attacker-controlled.
+- **Bounds proof**: For integer/bounds issues, create an explicit algebraic proof using the template in [evidence-templates.md](evidence-templates.md). Verify: IF validation_check_passes THEN bounds_guarantee_holds.
+- **Race feasibility**: For race conditions, prove concurrent access is actually possible. Single-threaded initialization and synchronized contexts cannot have races.
+
+### Step 3: Impact
+
+Determine whether exploitation has real security consequences.
+
+- Distinguish real security impact (RCE, privesc, info disclosure) from operational robustness issues (crash recovery, cleanup failure)
+- Distinguish primary security controls from defense-in-depth. Failure of a defense-in-depth measure is not a vulnerability if primary protections remain intact.
+
+### Step 4: PoC Sketch
+
+Create a pseudocode PoC showing the attack path. Executable and unit test PoCs are optional for standard verification; in review and test steps they run only from a temp directory outside the repository and never against live services (see the ground rules in SKILL.md).
+
+```
+Data Flow: [Source] → [Validation?] → [Transform?] → [Vulnerable Op] → [Impact]
+Attacker controls: [what input, how]
+Trigger: [pseudocode showing the exploit path]
+```
+
+See [evidence-templates.md](evidence-templates.md) for the full PoC template.
+
+### Step 5: Devil's Advocate Spot-Check
+
+Answer these 7 questions. If any produces genuine uncertainty, escalate to deep verification.
+
+**Against the vulnerability:**
+
+1. Am I seeing a vulnerability because the pattern "looks dangerous" rather than because it actually is? (pattern-matching bias)
+2. Am I incorrectly assuming attacker control over trusted data? (trust boundary confusion)
+3. Have I rigorously proven the mathematical condition for vulnerability can occur? (proof rigor)
+4. Am I confusing defense-in-depth failure with a primary security vulnerability? (defense-in-depth confusion)
+5. Am I hallucinating this vulnerability? LLMs are biased toward seeing bugs everywhere: is this actually real or am I pattern-matching on scary-looking code? (LLM self-check)
+
+**For the vulnerability (always ask: false-negative protection):**
+
+6. Am I dismissing a real vulnerability because the exploit seems complex or unlikely?
+7. Am I inventing mitigations or validation logic that I haven't verified in the actual source code? Re-read the code after reaching a conclusion.
+
+**Escalation check**: If any question above produces genuine uncertainty you cannot resolve with the evidence at hand: escalate to deep verification.
+
+### Step 6: Gate Review
+
+Apply all six gates from [gate-reviews.md](gate-reviews.md) and all 13 items from [false-positive-patterns.md](false-positive-patterns.md) to reach a verdict.
+
+Part of the `false-positive-check` skill, adapted from https://github.com/trailofbits/skills/tree/main/plugins/fp-check (commit 5c99c03fb8a9ea568432ecbcba5d86e9f4ac2bf0), CC BY-SA 4.0. Changed: read-only rule for proofs of concept, punctuation.