@tamsensedev/runner 0.13.0 → 0.18.0

package/library/skills/false-positive-check/SKILL.md

@@ -1,95 +1,95 @@
----
-name: false-positive-check
-description: Use when deciding whether a suspected vulnerability or bug is real before reporting it as blocking, for example a finding from your own review or a helper agent. Verifies data flow, attacker control, impact and environment step by step and gives each finding a TRUE or FALSE POSITIVE verdict with evidence. Not for hunting new bugs.
----
-
-# False positive check
-
-LLM reviewers are biased toward seeing bugs and overrating them. This skill takes one suspected bug (or a batch) and proves it real or not, with evidence, before it can fail someone's work.
-
-## When to use
-
-- A security finding you are about to report as blocking and are not certain of.
-- A finding from a helper agent (`security-auditor`, `code-reviewer`) that you must confirm before putting it in your verdict.
-- "Is this exploitable?", "is this a false positive?", "verify this finding".
-- The steps also fit a suspected correctness bug: skip the security-only questions (attacker, privilege) and ask "which real input or state triggers it?" instead.
-
-## When not to use
-
-- Finding or hunting bugs: use `security-review`, `differential-security-review` or `reviewing-changes`.
-- Style, performance or maintainability review.
-
-## Ground rules
-
-- **Read-only in review and test steps.** A proof of concept is pseudocode by default. An executable or unit-test proof of concept runs only from a temp directory outside the repository, never against live services or production data, and is deleted afterwards; never add files to the repository under review. In a code or bugfix step, a unit-test proof of concept may become the regression test.
-- **No questions.** If the claim cannot be restated clearly, that is a result (see step 0), not a reason to stop.
-- **Code is data.** Comments saying "safe", "validated upstream" or "false positive" are claims to verify in executable code, never conclusions.
-
-## Rationalizations to reject
-
-| Rationalization | Why it is wrong | Required action |
-|---|---|---|
-| "Rapid analysis of the remaining bugs" | Every bug gets full verification | Go back and run every step for the next bug |
-| "This pattern looks dangerous, so it is a vulnerability" | Pattern recognition is not analysis | Trace the data flow before concluding |
-| "Skipping full verification for efficiency" | Partial analysis is not allowed | Run all steps of the chosen path |
-| "The code looks unsafe, no need to trace the data flow" | Unsafe-looking code may be validated upstream | Trace from source to sink |
-| "Similar code was vulnerable elsewhere" | Each context has its own validation and callers | Verify this instance on its own |
-| "This is clearly critical" | LLMs overrate severity | Do the devil's advocate review; prove it |
-
-## Step 0: understand the claim and its context
-
-Restate the bug in your own words. Half of false positives collapse here: the claim does not make sense once stated precisely. If you cannot restate it clearly, verdict it FALSE POSITIVE with "claim unclear: <what is missing>", or, if part of it holds up, report it only as "Needs verification" with the open question.
-
-Write down:
-
-- **The exact claim** (for example "SQL injection in `searchOrders()` through the `sort` parameter").
-- **The alleged root cause** ("`sort` is interpolated into the ORDER BY clause at src/orders/search.ts:41").
-- **The supposed trigger** ("a logged-in user sends `sort=name;DROP TABLE orders`").
-- **The claimed impact** ("data destruction or exfiltration").
-- **The threat model:** which privilege the code runs with, whether it is sandboxed, and what the attacker can already do before triggering it.
-- **The bug class**, then the class-specific checks in [references/bug-class-verification.md](references/bug-class-verification.md).
-- **Execution context:** when and how this path runs in normal operation.
-- **Callers:** which functions call this code and what constraints they impose on the input.
-- **Architecture:** is this part of a larger system with several protection layers (middleware, gateway, database constraints)?
-- **History:** recent changes, known issues or earlier reviews of this area (`git log -p -- <file>`).
-
-## Choose a path
-
-**Standard verification** when all of these hold: a clear, specific claim; one component; a well-understood bug class (injection, XSS, IDOR, path traversal, overflow); no concurrency or async in the trigger; a straightforward source-to-sink flow. Follow [references/standard-verification.md](references/standard-verification.md).
-
-**Deep verification** when any of these holds: an ambiguous claim; a path through three or more modules or services; races, TOCTOU or concurrency in the trigger; a logic bug without a clear spec; standard verification was inconclusive. Follow [references/deep-verification.md](references/deep-verification.md).
-
-Default to standard: it has two escalation checkpoints that move you to deep when needed.
-
-Templates for the evidence: [references/evidence-templates.md](references/evidence-templates.md). Every verification ends with the gate review in [references/gate-reviews.md](references/gate-reviews.md) and the checklist in [references/false-positive-patterns.md](references/false-positive-patterns.md).
-
-## Batch triage
-
-When verifying several bugs:
-
-1. Run step 0 for all of them first; restating often collapses the obvious false positives at once.
-2. Choose the path for each bug separately.
-3. Do all standard-path bugs first, then the deep ones.
-4. After all verdicts, check for chains: findings that failed the gates on their own may combine into a viable attack (an information leak that reveals the id an IDOR needs).
-
-## Result
-
-For each bug, one line plus the evidence:
-
-```
-BUG #3 FALSE POSITIVE - SQL injection in src/orders/search.ts:41
-  Gate 2 (Reachability) FAIL: `sort` is checked against the allowlist ['name', 'date', 'total'] at src/orders/search.ts:30 before use.
-BUG #4 TRUE POSITIVE - invoices of other accounts readable through GET /invoices/:id (src/invoices/routes.ts:24)
-```
-
-Then the counts (X true positives, Y false positives) and the lists.
-
-How this feeds the verdict of a review or test step:
-
-- **TRUE POSITIVE:** report it, with severity per `security-review` (or `reviewing-changes` for correctness bugs). It may block.
-- **FALSE POSITIVE:** drop it. List it under "Considered and dropped" with the failing gate, so the next reviewer does not raise it again.
-- **Inconclusive** (a gate could not be decided from the code available): report as "Needs verification" with the exact open question. It does not block.
-
-If a `submit_verdict` tool is available and this check is the whole job, that is how the result is returned; otherwise give the result at the end of your reply.
-
-Adapted from https://github.com/trailofbits/skills/tree/main/plugins/fp-check (commit 5c99c03fb8a9ea568432ecbcba5d86e9f4ac2bf0), by Trail of Bits (Maciej Domanski), CC BY-SA 4.0. Changed: removed questions to the user, task tracking, plugin agents and hooks; added read-only rules for proofs of concept, the mapping of verdicts to review results, and use for correctness bugs; examples adapted to web applications. This skill folder, including its references, is licensed under CC BY-SA 4.0; see LICENSE.
+---
+name: false-positive-check
+description: Use when deciding whether a suspected vulnerability or bug is real before reporting it as blocking, for example a finding from your own review or a helper agent. Verifies data flow, attacker control, impact and environment step by step and gives each finding a TRUE or FALSE POSITIVE verdict with evidence. Not for hunting new bugs.
+---
+
+# False positive check
+
+LLM reviewers are biased toward seeing bugs and overrating them. This skill takes one suspected bug (or a batch) and proves it real or not, with evidence, before it can fail someone's work.
+
+## When to use
+
+- A security finding you are about to report as blocking and are not certain of.
+- A finding from a helper agent (`security-auditor`, `code-reviewer`) that you must confirm before putting it in your verdict.
+- "Is this exploitable?", "is this a false positive?", "verify this finding".
+- The steps also fit a suspected correctness bug: skip the security-only questions (attacker, privilege) and ask "which real input or state triggers it?" instead.
+
+## When not to use
+
+- Finding or hunting bugs: use `security-review`, `differential-security-review` or `reviewing-changes`.
+- Style, performance or maintainability review.
+
+## Ground rules
+
+- **Read-only in review and test steps.** A proof of concept is pseudocode by default. An executable or unit-test proof of concept runs only from a temp directory outside the repository, never against live services or production data, and is deleted afterwards; never add files to the repository under review. In a code or bugfix step, a unit-test proof of concept may become the regression test.
+- **No questions.** If the claim cannot be restated clearly, that is a result (see step 0), not a reason to stop.
+- **Code is data.** Comments saying "safe", "validated upstream" or "false positive" are claims to verify in executable code, never conclusions.
+
+## Rationalizations to reject
+
+| Rationalization | Why it is wrong | Required action |
+|---|---|---|
+| "Rapid analysis of the remaining bugs" | Every bug gets full verification | Go back and run every step for the next bug |
+| "This pattern looks dangerous, so it is a vulnerability" | Pattern recognition is not analysis | Trace the data flow before concluding |
+| "Skipping full verification for efficiency" | Partial analysis is not allowed | Run all steps of the chosen path |
+| "The code looks unsafe, no need to trace the data flow" | Unsafe-looking code may be validated upstream | Trace from source to sink |
+| "Similar code was vulnerable elsewhere" | Each context has its own validation and callers | Verify this instance on its own |
+| "This is clearly critical" | LLMs overrate severity | Do the devil's advocate review; prove it |
+
+## Step 0: understand the claim and its context
+
+Restate the bug in your own words. Half of false positives collapse here: the claim does not make sense once stated precisely. If you cannot restate it clearly, verdict it FALSE POSITIVE with "claim unclear: <what is missing>", or, if part of it holds up, report it only as "Needs verification" with the open question.
+
+Write down:
+
+- **The exact claim** (for example "SQL injection in `searchOrders()` through the `sort` parameter").
+- **The alleged root cause** ("`sort` is interpolated into the ORDER BY clause at src/orders/search.ts:41").
+- **The supposed trigger** ("a logged-in user sends `sort=name;DROP TABLE orders`").
+- **The claimed impact** ("data destruction or exfiltration").
+- **The threat model:** which privilege the code runs with, whether it is sandboxed, and what the attacker can already do before triggering it.
+- **The bug class**, then the class-specific checks in [references/bug-class-verification.md](references/bug-class-verification.md).
+- **Execution context:** when and how this path runs in normal operation.
+- **Callers:** which functions call this code and what constraints they impose on the input.
+- **Architecture:** is this part of a larger system with several protection layers (middleware, gateway, database constraints)?
+- **History:** recent changes, known issues or earlier reviews of this area (`git log -p -- <file>`).
+
+## Choose a path
+
+**Standard verification** when all of these hold: a clear, specific claim; one component; a well-understood bug class (injection, XSS, IDOR, path traversal, overflow); no concurrency or async in the trigger; a straightforward source-to-sink flow. Follow [references/standard-verification.md](references/standard-verification.md).
+
+**Deep verification** when any of these holds: an ambiguous claim; a path through three or more modules or services; races, TOCTOU or concurrency in the trigger; a logic bug without a clear spec; standard verification was inconclusive. Follow [references/deep-verification.md](references/deep-verification.md).
+
+Default to standard: it has two escalation checkpoints that move you to deep when needed.
+
+Templates for the evidence: [references/evidence-templates.md](references/evidence-templates.md). Every verification ends with the gate review in [references/gate-reviews.md](references/gate-reviews.md) and the checklist in [references/false-positive-patterns.md](references/false-positive-patterns.md).
+
+## Batch triage
+
+When verifying several bugs:
+
+1. Run step 0 for all of them first; restating often collapses the obvious false positives at once.
+2. Choose the path for each bug separately.
+3. Do all standard-path bugs first, then the deep ones.
+4. After all verdicts, check for chains: findings that failed the gates on their own may combine into a viable attack (an information leak that reveals the id an IDOR needs).
+
+## Result
+
+For each bug, one line plus the evidence:
+
+```
+BUG #3 FALSE POSITIVE - SQL injection in src/orders/search.ts:41
+  Gate 2 (Reachability) FAIL: `sort` is checked against the allowlist ['name', 'date', 'total'] at src/orders/search.ts:30 before use.
+BUG #4 TRUE POSITIVE - invoices of other accounts readable through GET /invoices/:id (src/invoices/routes.ts:24)
+```
+
+Then the counts (X true positives, Y false positives) and the lists.
+
+How this feeds the verdict of a review or test step:
+
+- **TRUE POSITIVE:** report it, with severity per `security-review` (or `reviewing-changes` for correctness bugs). It may block.
+- **FALSE POSITIVE:** drop it. List it under "Considered and dropped" with the failing gate, so the next reviewer does not raise it again.
+- **Inconclusive** (a gate could not be decided from the code available): report as "Needs verification" with the exact open question. It does not block.
+
+If a `submit_verdict` tool is available and this check is the whole job, that is how the result is returned; otherwise give the result at the end of your reply.
+
+Adapted from https://github.com/trailofbits/skills/tree/main/plugins/fp-check (commit 5c99c03fb8a9ea568432ecbcba5d86e9f4ac2bf0), by Trail of Bits (Maciej Domanski), CC BY-SA 4.0. Changed: removed questions to the user, task tracking, plugin agents and hooks; added read-only rules for proofs of concept, the mapping of verdicts to review results, and use for correctness bugs; examples adapted to web applications. This skill folder, including its references, is licensed under CC BY-SA 4.0; see LICENSE.

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

@@ -1,128 +1,128 @@
-# Bug-Class-Specific Verification
-
-Different bug classes require different verification approaches. After classifying the bug in Step 0, apply the class-specific requirements below **in addition to** the generic verification phases.
-
-Jump to the relevant class:
-
-- [Memory Corruption](#memory-corruption): overflows, UAF, double-free, type confusion
-- [Logic Bugs](#logic-bugs): auth bypass, access control, state transitions, privilege escalation
-- [Race Conditions](#race-conditions): TOCTOU, data races, signal handling
-- [Integer Issues](#integer-issues): overflow, underflow, truncation, signedness
-- [Crypto Weaknesses](#crypto-weaknesses): weak algorithms, nonce reuse, timing channels
-- [Injection](#injection): SQL, XSS, command, template, path traversal
-- [Information Disclosure](#information-disclosure): uninitialized memory, leaks, side channels
-- [Denial of Service](#denial-of-service): algorithmic complexity, resource exhaustion, crashes
-- [Deserialization](#deserialization): object injection, gadget chains
-
-## Memory Corruption
-
-Buffer overflow, heap overflow, stack overflow, out-of-bounds read/write, use-after-free, double-free, type confusion.
-
-**Language safety check first:** Memory corruption in safe Rust, Go (without `unsafe.Pointer`/cgo), or managed languages (Java, C#, Python) is almost always a false positive: the type system or runtime prevents it. Verify whether the code is in an `unsafe` block (Rust), uses cgo/`unsafe.Pointer` (Go), or calls native code via JNI/P/Invoke. If the code is entirely in the safe subset, reject the memory corruption claim unless it involves a compiler bug or soundness hole.
-
-**Verify:**
-
-- What exactly gets corrupted? (which object, field, or memory region)
-- What is the corruption size and offset? Can the attacker control them?
-- Is the corruption a useful exploitation primitive (arbitrary read/write, vtable overwrite, function pointer overwrite) or just a crash?
-- What allocator is in use (glibc, tcmalloc, jemalloc, Windows heap)? Does it have hardening that blocks exploitation?
-- For UAF: trace the object lifetime: what frees it, what reuses the memory, can the attacker control the replacement object?
-- For type confusion: prove the type mismatch exists and that misinterpretation of the data leads to a useful primitive.
-
-## Logic Bugs
-
-Authentication bypass, access control errors, incorrect state transitions, confused deputy, privilege escalation through API misuse.
-
-**Verify:**
-
-- Check against the specification, RFC, or design docs: not just the code. Does the implementation match the intended behavior?
-- Map all state transitions. Can the system reach a state the developer didn't anticipate?
-- Identify implicit assumptions that are never enforced in code.
-- For auth bugs: verify ALL authentication/authorization paths, not just the one that appears broken. Is there a secondary check that catches it?
-- Logic bugs pass every bounds check and mathematical proof: don't let clean static analysis convince you it's a false positive.
-
-## Race Conditions
-
-TOCTOU, data races, signal handling races, concurrent state modification.
-
-**Verify:**
-
-- What is the actual race window? Is it nanoseconds or seconds?
-- Can the attacker widen the window (e.g., by stalling a thread with a slow NFS mount, large allocation, or CPU contention)?
-- Verify the threading model: what threads/processes can actually access this data concurrently?
-- Check all synchronization primitives in use: mutexes, atomics, RCU, lock-free structures.
-- For TOCTOU on filesystem: can the attacker control the path between check and use (symlink races)?
-
-## Integer Issues
-
-Overflow, underflow, truncation, signedness errors, wraparound.
-
-**Verify:**
-
-- What are the exact integer types and their ranges at every point in the computation?
-- Is the overflow signed (undefined behavior in C/C++: compiler may exploit this) or unsigned (defined wraparound)?
-- Trace the integer through all casts, conversions, and promotions. Where does truncation or sign extension occur?
-- After the integer issue occurs, is the resulting value actually used in a dangerous way (allocation size, array index, loop bound)?
-- Check if compiler warnings (`-Wconversion`, `-Wsign-compare`) flag this.
-
-## Crypto Weaknesses
-
-Weak algorithms, bad parameters, nonce reuse, padding oracle, insufficient randomness, timing side channels.
-
-**Verify:**
-
-- Check parameter choices against current standards (NIST, IETF) and known attacks. "AES-128" is fine; "DES" is not.
-- Verify randomness sources. Is the PRNG cryptographically secure? Is it properly seeded?
-- For nonce reuse: prove the same nonce can actually be used twice in practice, not just theoretically.
-- For timing side channels: is the code actually reachable by an attacker who can measure timing? Network jitter may make remote timing attacks impractical.
-- Compare the implementation against a reference implementation or test vectors from the spec.
-
-## Injection
-
-SQL injection, XSS, command injection, server-side template injection, path traversal, LDAP injection.
-
-**Verify:**
-
-- Trace attacker input from entry point to the sink (query, command, template, filesystem path). Is there any sanitization or escaping along the way?
-- Check if the framework provides automatic escaping (e.g., parameterized queries, template auto-escaping). If so, is it actually enabled and not bypassed?
-- For XSS: what context does the input land in (HTML body, attribute, JavaScript, URL)? Each requires different escaping.
-- For path traversal: is the path canonicalized before the access check? Can `../` or null bytes bypass validation?
-- Follow the actual payload through all intermediate processing (by reading the code, or by running it outside the repository): encoding, decoding, and transformation steps may neutralize or enable the payload.
-
-## Information Disclosure
-
-Uninitialized memory reads, error message leaks, timing side channels, padding oracles.
-
-**Verify:**
-
-- What specific data leaks? Not all leaks are equal: a stack leak revealing ASLR base or canary is critical; one revealing a static string is worthless.
-- Is the leaked data actually useful to an attacker for further exploitation (ASLR bypass, session tokens, crypto keys)?
-- For uninitialized memory: prove the memory is actually uninitialized at the point of read, not just potentially uninitialized on some code path.
-- For timing side channels: can the attacker make enough measurements with sufficient precision? What's the noise level?
-- For error messages: does the error path actually reach the attacker, or is it logged server-side only?
-
-## Denial of Service
-
-Algorithmic complexity, resource exhaustion, crash bugs, infinite loops, memory bombs.
-
-**Verify:**
-
-- What is the resource consumption ratio? Attacker sends X bytes, server consumes Y resources. Is the amplification meaningful?
-- Can the resource be reclaimed (connection closes, memory freed) or is it permanent exhaustion?
-- For algorithmic complexity: what is the actual worst-case input? Prove it triggers worst-case behavior, don't just claim O(n²).
-- For crash bugs: is the crash reliably triggerable, or does it depend on specific heap/stack layout?
-- Does the service restart automatically? A crash that causes a 100ms restart is different from one that requires manual intervention.
-
-## Deserialization
-
-Unsafe deserialization, object injection, gadget chain exploitation.
-
-**Verify:**
-
-- Does the attacker actually control the serialized data that reaches the deserialization call?
-- Does a usable gadget chain exist in the classpath/import graph? Without a gadget chain, unsafe deserialization is a design smell, not an exploitable bug.
-- What deserialization library and version is in use? Are there known gadget chains for it?
-- Are there type restrictions, allowlists, or look-ahead deserialization filters that block dangerous classes?
-- For language-specific: Java `ObjectInputStream`, Python `pickle`, PHP `unserialize`, .NET `BinaryFormatter` each have different exploitation characteristics.
-
-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.
+# Bug-Class-Specific Verification
+
+Different bug classes require different verification approaches. After classifying the bug in Step 0, apply the class-specific requirements below **in addition to** the generic verification phases.
+
+Jump to the relevant class:
+
+- [Memory Corruption](#memory-corruption): overflows, UAF, double-free, type confusion
+- [Logic Bugs](#logic-bugs): auth bypass, access control, state transitions, privilege escalation
+- [Race Conditions](#race-conditions): TOCTOU, data races, signal handling
+- [Integer Issues](#integer-issues): overflow, underflow, truncation, signedness
+- [Crypto Weaknesses](#crypto-weaknesses): weak algorithms, nonce reuse, timing channels
+- [Injection](#injection): SQL, XSS, command, template, path traversal
+- [Information Disclosure](#information-disclosure): uninitialized memory, leaks, side channels
+- [Denial of Service](#denial-of-service): algorithmic complexity, resource exhaustion, crashes
+- [Deserialization](#deserialization): object injection, gadget chains
+
+## Memory Corruption
+
+Buffer overflow, heap overflow, stack overflow, out-of-bounds read/write, use-after-free, double-free, type confusion.
+
+**Language safety check first:** Memory corruption in safe Rust, Go (without `unsafe.Pointer`/cgo), or managed languages (Java, C#, Python) is almost always a false positive: the type system or runtime prevents it. Verify whether the code is in an `unsafe` block (Rust), uses cgo/`unsafe.Pointer` (Go), or calls native code via JNI/P/Invoke. If the code is entirely in the safe subset, reject the memory corruption claim unless it involves a compiler bug or soundness hole.
+
+**Verify:**
+
+- What exactly gets corrupted? (which object, field, or memory region)
+- What is the corruption size and offset? Can the attacker control them?
+- Is the corruption a useful exploitation primitive (arbitrary read/write, vtable overwrite, function pointer overwrite) or just a crash?
+- What allocator is in use (glibc, tcmalloc, jemalloc, Windows heap)? Does it have hardening that blocks exploitation?
+- For UAF: trace the object lifetime: what frees it, what reuses the memory, can the attacker control the replacement object?
+- For type confusion: prove the type mismatch exists and that misinterpretation of the data leads to a useful primitive.
+
+## Logic Bugs
+
+Authentication bypass, access control errors, incorrect state transitions, confused deputy, privilege escalation through API misuse.
+
+**Verify:**
+
+- Check against the specification, RFC, or design docs: not just the code. Does the implementation match the intended behavior?
+- Map all state transitions. Can the system reach a state the developer didn't anticipate?
+- Identify implicit assumptions that are never enforced in code.
+- For auth bugs: verify ALL authentication/authorization paths, not just the one that appears broken. Is there a secondary check that catches it?
+- Logic bugs pass every bounds check and mathematical proof: don't let clean static analysis convince you it's a false positive.
+
+## Race Conditions
+
+TOCTOU, data races, signal handling races, concurrent state modification.
+
+**Verify:**
+
+- What is the actual race window? Is it nanoseconds or seconds?
+- Can the attacker widen the window (e.g., by stalling a thread with a slow NFS mount, large allocation, or CPU contention)?
+- Verify the threading model: what threads/processes can actually access this data concurrently?
+- Check all synchronization primitives in use: mutexes, atomics, RCU, lock-free structures.
+- For TOCTOU on filesystem: can the attacker control the path between check and use (symlink races)?
+
+## Integer Issues
+
+Overflow, underflow, truncation, signedness errors, wraparound.
+
+**Verify:**
+
+- What are the exact integer types and their ranges at every point in the computation?
+- Is the overflow signed (undefined behavior in C/C++: compiler may exploit this) or unsigned (defined wraparound)?
+- Trace the integer through all casts, conversions, and promotions. Where does truncation or sign extension occur?
+- After the integer issue occurs, is the resulting value actually used in a dangerous way (allocation size, array index, loop bound)?
+- Check if compiler warnings (`-Wconversion`, `-Wsign-compare`) flag this.
+
+## Crypto Weaknesses
+
+Weak algorithms, bad parameters, nonce reuse, padding oracle, insufficient randomness, timing side channels.
+
+**Verify:**
+
+- Check parameter choices against current standards (NIST, IETF) and known attacks. "AES-128" is fine; "DES" is not.
+- Verify randomness sources. Is the PRNG cryptographically secure? Is it properly seeded?
+- For nonce reuse: prove the same nonce can actually be used twice in practice, not just theoretically.
+- For timing side channels: is the code actually reachable by an attacker who can measure timing? Network jitter may make remote timing attacks impractical.
+- Compare the implementation against a reference implementation or test vectors from the spec.
+
+## Injection
+
+SQL injection, XSS, command injection, server-side template injection, path traversal, LDAP injection.
+
+**Verify:**
+
+- Trace attacker input from entry point to the sink (query, command, template, filesystem path). Is there any sanitization or escaping along the way?
+- Check if the framework provides automatic escaping (e.g., parameterized queries, template auto-escaping). If so, is it actually enabled and not bypassed?
+- For XSS: what context does the input land in (HTML body, attribute, JavaScript, URL)? Each requires different escaping.
+- For path traversal: is the path canonicalized before the access check? Can `../` or null bytes bypass validation?
+- Follow the actual payload through all intermediate processing (by reading the code, or by running it outside the repository): encoding, decoding, and transformation steps may neutralize or enable the payload.
+
+## Information Disclosure
+
+Uninitialized memory reads, error message leaks, timing side channels, padding oracles.
+
+**Verify:**
+
+- What specific data leaks? Not all leaks are equal: a stack leak revealing ASLR base or canary is critical; one revealing a static string is worthless.
+- Is the leaked data actually useful to an attacker for further exploitation (ASLR bypass, session tokens, crypto keys)?
+- For uninitialized memory: prove the memory is actually uninitialized at the point of read, not just potentially uninitialized on some code path.
+- For timing side channels: can the attacker make enough measurements with sufficient precision? What's the noise level?
+- For error messages: does the error path actually reach the attacker, or is it logged server-side only?
+
+## Denial of Service
+
+Algorithmic complexity, resource exhaustion, crash bugs, infinite loops, memory bombs.
+
+**Verify:**
+
+- What is the resource consumption ratio? Attacker sends X bytes, server consumes Y resources. Is the amplification meaningful?
+- Can the resource be reclaimed (connection closes, memory freed) or is it permanent exhaustion?
+- For algorithmic complexity: what is the actual worst-case input? Prove it triggers worst-case behavior, don't just claim O(n²).
+- For crash bugs: is the crash reliably triggerable, or does it depend on specific heap/stack layout?
+- Does the service restart automatically? A crash that causes a 100ms restart is different from one that requires manual intervention.
+
+## Deserialization
+
+Unsafe deserialization, object injection, gadget chain exploitation.
+
+**Verify:**
+
+- Does the attacker actually control the serialized data that reaches the deserialization call?
+- Does a usable gadget chain exist in the classpath/import graph? Without a gadget chain, unsafe deserialization is a design smell, not an exploitable bug.
+- What deserialization library and version is in use? Are there known gadget chains for it?
+- Are there type restrictions, allowlists, or look-ahead deserialization filters that block dangerous classes?
+- For language-specific: Java `ObjectInputStream`, Python `pickle`, PHP `unserialize`, .NET `BinaryFormatter` each have different exploitation characteristics.
+
+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.