SkillHub

Skills trailofbits skills

fp-check

Use it when:
A scanner, reviewer or another agent flagged a bug and you need to know if it's real and exploitable, not hunt for new ones.
It does:
Restates each claim, traces source to sink, proves attacker control and impact, sketches a proof of concept, argues against itself, then applies six gates.
You get:
A TRUE POSITIVE or FALSE POSITIVE verdict per bug with documented evidence, then the counts and both lists.
Two paths:
A linear checklist for clear single-component bugs; deep, task-tracked verification with subagents for races, cross-component or ambiguous claims.

Deep verification delegates to the fp-check plugin's data-flow-analyzer, exploitability-verifier and poc-builder agents, which come with the Claude Code plugin rather than the skill alone.

TL;DR

From Trail of Bits. It starts by restating each claim precisely, with the exact bug, root cause, trigger, impact, threat model and bug class, because many false positives fall apart there. The standard path then traces data from source to sink across trust boundaries and validation, checks API contracts and compiler, runtime or OS protections, proves the attacker controls the input (with algebraic proofs for bounds bugs), separates real security impact from robustness issues and sketches a pseudocode proof of concept. A devil's-advocate step asks whether the code only looks dangerous, and also whether a real bug is being dismissed. Unresolved doubt escalates to deep verification, which splits each phase into dependent tasks, hands data-flow, exploitability and proof-of-concept work to the plugin's agents, running each phase's independent sub-steps in parallel, and builds executable or unit-test proofs of concept when feasible. With several bugs it restates them all first, then checks whether rejected findings chain into a viable attack. It rejects shortcuts such as rushing the remaining bugs or calling a pattern a vulnerability without tracing it.

Summarizes the skill at e4dd0bb.

npx skills add https://github.com/trailofbits/skills --skill fp-check

skills.sh pageSource on GitHubAll skills from trailofbits/skills

Total Downloads
7,500 on skills.sh, Nov 9, 2026
Repo stars
8,081 trailofbits/skills
First seen
Mar 3, 2026 on skills.sh
Weekly Downloads
262
+85% over the 8 weeks to Nov 9
Weekly values
Week toInstalls
Sep 21142
Sep 28134
Oct 5163
Oct 12169
Oct 19195
Oct 26221
Nov 2269
Nov 9262
Category
category:securitycategory:debuggingcategory:software-engineering

Compliance, guardrails, skill vetting and browser fingerprinting.

Find root causes, review code and test what you built.

Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills.
Type
type:workflow

A multi-step process the agent follows: interview, debug, run a TDD loop, review.
Effect
effect:local

Its own steps create or change files, git state or local tools.
Needs
needs:subagents

Relies on the agent being able to spawn subagents.
Publisher
by:official

A verified publisher on skills.sh, or the company or maintainer behind the product the skill operates.
Topics
securityverificationdebugging

SKILL.md

From trailofbits/skills at e4dd0bb. Checked daily, last changed Nov 6, 2026.

Frontmatter
name: fp-check
description: "Systematically verifies suspected security bugs to eliminate false positives, producing a TRUE POSITIVE or FALSE POSITIVE verdict with documented evidence for each. Use when asked whether a specific finding is real, exploitable, or a false positive, or to verify or validate a suspected vulnerability — not for hunting or discovering new bugs."
allowed-tools: Read Grep Glob LSP Bash Task Write Edit AskUserQuestion TaskCreate TaskUpdate TaskList TaskGet

False Positive Check

When to Use

  • "Is this bug real?" or "is this a true positive?"
  • "Is this a false positive?" or "verify this finding"
  • "Check if this vulnerability is exploitable"
  • Any request to verify or validate a specific suspected bug

When NOT to Use

  • Finding or hunting for bugs ("find bugs", "security analysis", "audit code")
  • General code review for style, performance, or maintainability
  • Feature development, refactoring, or non-security tasks
  • When the user explicitly asks for a quick scan without verification

Rationalizations to Reject

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

Step 0: Understand the Claim and Context

Before any analysis, restate the bug in your own words. If you cannot do this clearly, ask the user for clarification. Half of false positives collapse at this step — the claim doesn't make coherent sense when restated precisely.

Document:

  • What is the exact vulnerability claim? (e.g., "heap buffer overflow in parse_header() when content_length exceeds 4096")
  • What is the alleged root cause? (e.g., "missing bounds check before memcpy at line 142")
  • What is the supposed trigger? (e.g., "attacker sends HTTP request with oversized Content-Length header")
  • What is the claimed impact? (e.g., "remote code execution via controlled heap corruption")
  • What is the threat model? What privilege level does this code run at? Is it sandboxed? What can the attacker already do before triggering this bug? (e.g., "unauthenticated remote attacker vs privileged local user"; "runs inside Chrome renderer sandbox" vs "runs as root with no sandbox")
  • What is the bug class? Classify the bug and consult bug-class-verification.md for class-specific verification requirements that supplement the generic phases below.
  • Execution context: When and how is this code path reached during normal execution?
  • Caller analysis: What functions call this code and what input constraints do they impose?
  • Architectural context: Is this part of a larger security system with multiple protection layers?
  • Historical context: Any recent changes, known issues, or previous security reviews of this code area?

Route: Standard vs Deep Verification

After Step 0, choose a verification path.

Standard Verification

Use when ALL of these hold:

  • Clear, specific vulnerability claim (not vague or ambiguous)
  • Single component — no cross-component interaction in the bug path
  • Well-understood bug class (buffer overflow, SQL injection, XSS, integer overflow, etc.)
  • No concurrency or async involved in the trigger
  • Straightforward data flow from source to sink

Follow standard-verification.md. No task tracking — work through the linear checklist sequentially, documenting findings inline.

Deep Verification

Use when ANY of these hold:

  • Ambiguous claim that could be interpreted multiple ways
  • Cross-component bug path (data flows through 3+ modules or services)
  • Race conditions, TOCTOU, or concurrency in the trigger mechanism
  • Logic bugs without a clear spec to verify against
  • Standard verification was inconclusive or escalated
  • User explicitly requests full verification

Follow deep-verification.md. Track each phase as a task with explicit dependencies, and execute the phases using the plugin's analysis agents.

Default

Start with standard. Standard verification has two built-in escalation checkpoints that route to deep when complexity exceeds the linear checklist.

Batch Triage

When verifying multiple bugs at once:

  1. Run Step 0 for all bugs first — restating each claim often collapses obvious false positives immediately
  2. Route each bug independently (some may be standard, others deep)
  3. Process all standard-routed bugs first, then deep-routed bugs
  4. After all bugs are verified, check for exploit chains — findings that individually failed gate review may combine to form a viable attack

Final Summary

After processing ALL suspected bugs, provide:

  1. Counts: X TRUE POSITIVES, Y FALSE POSITIVES
  2. TRUE POSITIVE list: Each with brief vulnerability description
  3. FALSE POSITIVE list: Each with brief reason for rejection

References

  • Standard Verification — Linear single-pass checklist for straightforward bugs
  • Deep Verification — Full task-based orchestration for complex bugs
  • Gate Reviews — Six mandatory gates and verdict format
  • Bug-Class Verification — Class-specific verification requirements for memory corruption, logic bugs, race conditions, integer issues, crypto, injection, info disclosure, DoS, and deserialization
  • False Positive Patterns — 13-item checklist and red flags for common false positive patterns
  • Evidence Templates — Documentation templates for data flow, mathematical proofs, attacker control, and devil's advocate reviews