Stats
Actions
Tags
From prodsec-skills
Systematically verifies suspected security bugs to eliminate false positives. Produces TRUE POSITIVE or FALSE POSITIVE verdicts with documented evidence for each bug.
How this skill is triggered — by the user, by Claude, or both
Slash command
/prodsec-skills:fp-checkThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
- "Is this bug real?" or "is this a true positive?"
If you catch yourself thinking any of these, STOP.
| Rationalization | Why It's Wrong | Required Action |
|---|---|---|
| "Rapid analysis of remaining bugs" | Every bug gets full verification | Return to task list, verify next bug through all phases |
| "This pattern looks dangerous, so it's a vulnerability" | Pattern recognition is not analysis | Complete data flow tracing before any conclusion |
| "Skipping full verification for efficiency" | No partial analysis allowed | Execute all steps per the chosen verification path |
| "The code looks unsafe, reporting without tracing data flow" | Unsafe-looking code may have upstream validation | Trace the complete path from source to sink |
| "Similar code was vulnerable elsewhere" | Each context has different validation, callers, and protections | Verify this specific instance independently |
| "This is clearly critical" | LLMs are biased toward seeing bugs and overrating severity | Complete devil's advocate review; prove it with evidence |
Before any analysis, restate the bug in your own words. If you cannot do this clearly, ask the user for clarification by asking the user clarifying questions. Half of false positives collapse at this step — the claim doesn't make coherent sense when restated precisely.
Document:
parse_header() when content_length exceeds 4096")memcpy at line 142")After Step 0, choose a verification path.
Use when ALL of these hold:
Follow ## Inlined: Standard Verification below. No separate task tracker required — work through the linear checklist, documenting findings inline.
Use when ANY of these hold:
Follow ## Inlined: Deep Verification below. Track phases with explicit tasks or a checklist and execute them in dependency order (parallelize independent work when practical).
Start with standard. Standard verification has two built-in escalation checkpoints that route to deep when complexity exceeds the linear checklist.
When verifying multiple bugs at once:
After processing ALL suspected bugs, provide:
(See upstream Trail of Bits prodsec-skills fp-check plugin for companion agents and automation.)
Linear single-pass checklist for straightforward bugs. No task creation — work through each step sequentially and document findings inline.
Two points in this checklist may trigger escalation to deep-verification.md:
When escalating, hand off all evidence gathered so far — deep verification will continue from where you left off.
Trace data from source to the alleged vulnerability sink.
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.
Prove the attacker can trigger the vulnerability.
Determine whether exploitation has real security consequences.
Create a pseudocode PoC showing the attack path. Executable and unit test PoCs are optional for standard verification.
Data Flow: [Source] → [Validation?] → [Transform?] → [Vulnerable Op] → [Impact]
Attacker controls: [what input, how]
Trigger: [pseudocode showing the exploit path]
See evidence-templates.md for the full PoC template.
Answer these 7 questions. If any produces genuine uncertainty, escalate to deep verification.
Against the vulnerability:
For the vulnerability (always ask — false-negative protection):
Escalation check: If any question above produces genuine uncertainty you cannot resolve with the evidence at hand — escalate to deep verification.
Apply all six gates from gate-reviews.md and all 13 items from false-positive-patterns.md to reach a verdict.
Full task-based verification for complex bugs. Use when routing from SKILL.md selects the deep path, or when standard verification escalates.
When a bug escalates from standard verification:
For each bug (Bug #N), define tasks with the dependency structure below. Record task IDs and dependencies in your tracker (spreadsheet, issue system, or checklist) so nothing starts before its prerequisites complete.
── Phase 1: Data Flow Analysis ──────────────────────────────────
"BUG #N - Phase 1.1: Map trust boundaries and trace data flow"
Then in parallel (each blocked by 1.1):
"BUG #N - Phase 1.2: Research API contracts and safety guarantees"
"BUG #N - Phase 1.3: Environment protection analysis"
"BUG #N - Phase 1.4: Cross-reference analysis"
── Phase 2: Exploitability Verification (blocked by Phase 1) ───
In parallel:
"BUG #N - Phase 2.1: Confirm attacker controls input data"
"BUG #N - Phase 2.2: Mathematical bounds verification"
"BUG #N - Phase 2.3: Race condition feasibility proof"
Then (blocked by 2.1, 2.2, 2.3):
"BUG #N - Phase 2.4: Adversarial analysis"
── Phase 3: Impact Assessment (blocked by Phase 2) ─────────────
In parallel:
"BUG #N - Phase 3.1: Demonstrate real security impact"
"BUG #N - Phase 3.2: Primary control vs defense-in-depth"
── Phase 4: PoC Creation (blocked by Phase 3) ──────────────────
"BUG #N - Phase 4.1: Create pseudocode PoC with data flow diagrams"
Then in parallel (each blocked by 4.1):
"BUG #N - Phase 4.2: Create executable PoC if feasible"
"BUG #N - Phase 4.3: Create unit test PoC if feasible"
"BUG #N - Phase 4.4: Negative PoC — show exploit preconditions"
Then (blocked by 4.2, 4.3, 4.4):
"BUG #N - Phase 4.5: Verify PoC demonstrates the vulnerability"
── Phase 5: Devil's Advocate (blocked by Phase 4) ──────────────
"BUG #N - Phase 5.1: Devil's advocate review"
── Gate Review (blocked by Phase 5) ────────────────────────────
"BUG #N - GATE REVIEW: Evaluate all six gates before verdict"
You may assign phase work to specialized reviewers or separate focused sessions:
| Focus | Phases | Purpose |
|---|---|---|
| Data-flow pass | 1.1–1.4 | Trace data flow, map trust boundaries, check API contracts and environment protections |
| Exploitability pass | 2.1–2.4 | Prove attacker control, mathematical bounds, race condition feasibility |
| PoC pass | 4.1–4.5 | Pseudocode, executable, unit test, and negative PoCs |
Phases 3 (Impact Assessment), 5 (Devil's Advocate), and the Gate Review should be synthesized in one place — do not split accountability for the final verdict.
(See upstream Trail of Bits prodsec-skills for named agents that mirror these phases.)
The task list above names every phase. Below are the key pitfalls and decision criteria for each — focus on what you might get wrong.
1.1: Map trust boundaries (internal/trusted vs external/untrusted) and trace data from source to alleged vulnerability. Apply class-specific verification from bug-class-verification.md. Key pitfall: Analyzing code in isolation without tracing the full validation chain. Conditional logic upstream may make the vulnerable code mathematically unreachable (see false-positive-patterns.md items 1 and 1a).
1.2: Check API contracts before claiming overflows — many APIs have built-in bounds protection that prevents the alleged issue regardless of inputs.
1.3: Before concluding vulnerability, verify that no compiler, runtime, OS, or framework protections prevent exploitation. Note: mitigations like ASLR and stack canaries raise the exploitation bar but do not eliminate the vulnerability itself. Distinguish "prevents exploitation entirely" (e.g., Rust's safe type system) from "makes exploitation harder" (e.g., ASLR).
1.4: Check if similar code patterns exist elsewhere and are handled safely. Review test coverage, code review history, and design documentation for this area.
2.1: Prove attacker controls the data reaching the vulnerability. Key pitfall: Assuming network/external data reaches the operation without tracing the actual path — internal storage set by trusted components is not attacker-controlled.
2.2: Create explicit algebraic proofs for bounds-related issues. Use the template in evidence-templates.md. Verify: IF validation_check_passes THEN bounds_guarantee_holds.
2.3: For race conditions, prove concurrent access is actually possible. Key pitfall: Assuming race conditions in single-threaded initialization or synchronized contexts.
2.4: Assess full attack surface: input control, validation bypass paths, timing dependencies, and state manipulation.
3.1: Distinguish real security impact (RCE, privesc, info disclosure) from operational robustness issues.
3.2: Distinguish primary security controls from defense-in-depth. Failure of a defense-in-depth measure is not a vulnerability if primary protections remain intact.
Always create a pseudocode PoC. Additionally, create executable and/or unit test PoCs when feasible:
See evidence-templates.md for PoC templates.
Negative PoC (Phase 4.4): Demonstrate the gap between normal operation and the exploit path — what preconditions must hold for the vulnerability to trigger, and why they don't hold under normal conditions.
Before final verdict, systematically challenge the vulnerability claim. Assume you are biased toward finding bugs and rating them as critical — actively work against that bias.
Challenges arguing AGAINST the vulnerability:
Challenges arguing FOR the vulnerability (false-negative protection):
See evidence-templates.md for the devil's advocate documentation template.
Apply the six gates from gate-reviews.md to reach a verdict.
Before reporting ANY bug as a vulnerability, all six gate reviews must pass. Evaluate these during the GATE REVIEW task 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 RCE, privesc, or info disclosure | 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 | 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 |
BUG #N TRUE POSITIVE — [brief vulnerability description]BUG #N FALSE POSITIVE — [brief reason for rejection]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.
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.
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.
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:
Authentication bypass, access control errors, incorrect state transitions, confused deputy, privilege escalation through API misuse.
Verify:
TOCTOU, data races, signal handling races, concurrent state modification.
Verify:
Overflow, underflow, truncation, signedness errors, wraparound.
Verify:
-Wconversion, -Wsign-compare) flag this.Weak algorithms, bad parameters, nonce reuse, padding oracle, insufficient randomness, timing side channels.
Verify:
/dev/urandom, CryptGenRandom)?SQL injection, XSS, command injection, server-side template injection, path traversal, LDAP injection.
Verify:
../ or null bytes bypass validation?Uninitialized memory reads, error message leaks, timing side channels, padding oracles.
Verify:
Algorithmic complexity, resource exhaustion, crash bugs, infinite loops, memory bombs.
Verify:
Unsafe deserialization, object injection, gadget chain exploitation.
Verify:
ObjectInputStream, Python pickle, PHP unserialize, .NET BinaryFormatter each have different exploitation characteristics.Apply ALL items in this checklist to EACH potential bug during verification.
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.
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:
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.
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.
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.
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.
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.
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.
Internal storage systems (configuration stores, registries) are controlled by trusted components, not attackers. Values set during installation by trusted components are not attacker-controlled.
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.
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.
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?
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.
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.
Use these templates when documenting verification evidence for each bug.
Bug #N Data Flow Analysis
Source: [exact location] — Trust Level: [trusted/untrusted]
Path: Source → Validation1[file:line] → Transform[file:line] → Vulnerability[file:line]
Validation Points:
- Check1: [condition] at [file:line] — [passes/fails/bypassed]
- Check2: [condition] at [file:line] — [passes/fails/bypassed]
Bug #N Mathematical Analysis
Claim: Operation X is vulnerable to [overflow/underflow/bounds violation]
Given Constraints: [list all validation conditions]
Algebraic Proof:
1. [first constraint from validation]
2. [constant or known value]
3. [derived inequality]
...
N. Therefore: [vulnerability confirmed/debunked] (Q.E.D.)
Conclusion: [vulnerability is/is not mathematically possible]
Example:
Given: validation ensures (input_size >= MIN_SIZE)
Given: MIN_SIZE = 16, header_size = 8
Prove: (input_size - header_size) cannot underflow
1. input_size >= MIN_SIZE (from validation)
2. MIN_SIZE = 16 (constant)
3. header_size = 8 (constant)
4. input_size >= 16 (substitution of 1,2)
5. input_size - 8 >= 16 - 8 (subtract header_size from both sides)
6. input_size - header_size >= 8 (simplification)
7. Therefore: underflow impossible (Q.E.D.)
Bug #N Attacker Control Analysis
Input Vector: [how attacker provides input]
Control Level: [full/partial/none]
Constraints: [what limits exist on attacker input]
Reachability: [can attacker-controlled data reach vulnerable operation?]
PoC for Bug #N: [Brief Description]
Data Flow Diagram:
[External Input] → [Validation Point] → [Processing] → [Vulnerable Operation]
| | | |
Attacker (May be bypassed) (Transforms data) (Unsafe operation)
Controlled | | |
| v v v
[Malicious Data] → [Insufficient Check] → [Processed Data] → [Impact]
PSEUDOCODE:
function vulnerable_operation(user_data):
validation_result = weak_validation(user_data) // Explain why this fails
processed_data = transform_data(user_data) // Show transformation
unsafe_operation(processed_data) // Show vulnerability trigger
Bug #N Devil's Advocate Review
Vulnerability Claim: [brief description]
For each of the 13 questions from the devil's advocate review, document your answer:
1-11. [Challenges arguing AGAINST the vulnerability]
12-13. [Challenges arguing FOR the vulnerability — false-negative protection]
Final Assessment: [Vulnerability confirmed/debunked with reasoning]
npx claudepluginhub redhatproductsecurity/prodsec-skills --plugin prodsec-skillsVerifies suspected security bugs by restating claims, tracing data flows, and checking mitigations to issue TRUE POSITIVE or FALSE POSITIVE verdicts with evidence.
Verifies suspected security bugs as true or false positives with documented evidence. Useful when validating a specific vulnerability claim.
Verifies suspected security bugs systematically to eliminate false positives, producing TRUE POSITIVE or FALSE POSITIVE verdicts with documented evidence.