Fp Check

False Positive Gate Review

Adapted from Trail of Bits' fp-check skill. Every security finding must pass through this gate — no exceptions. Untriaged findings are worse than no findings, because they train the team to ignore alerts.

Why This Exists

Security scanners produce noise. When the noise-to-signal ratio gets too high, teams start ignoring findings entirely. The fp-check gate ensures every finding is classified, justified, and documented. The result is a security findings list where everything on it is real, and everything not on it was explicitly triaged and justified.

Hard Exclusion Rules

Before manual triage, automatically exclude findings matching these patterns. These are categories with near-zero signal in practice:

Precedents (context-dependent keeps):

• Logging secrets/passwords/PII in plaintext → keep (real vulnerability)
• React/Angular XSS → exclude unless using dangerouslySetInnerHTML or bypassSecurityTrustHtml
• Subtle web vulns (tabnabbing, XS-Leaks, prototype pollution) → exclude unless extremely high confidence
• Notebook (.ipynb) vulns → exclude unless concrete untrusted-input path

Any finding that matches a hard exclusion gets classified as FP — Auto-Excluded with the matching rule number as justification. No manual triage needed.

Confidence Gate

Every finding that survives hard exclusions must receive a confidence score (1-10):

• 1-3: Low confidence, likely false positive → auto-classify as FP
• 4-6: Medium confidence, needs investigation → manual triage required
• 7: Suspicious but conditional → include only if concrete exploit path documented
• 8-10: High confidence, likely true vulnerability → proceed to classification

Hard threshold: findings with confidence < 8 do not enter the triage backlog. They are logged for audit but not actioned.

Triage Protocol

For each finding that passes hard exclusions AND the confidence gate:

Step 1: Reproduce

Can you demonstrate the vulnerability? Try to exploit it:

• For injection: can you craft input that triggers the flaw?
• For credential exposure: is this a real secret or a placeholder?
• For configuration: does this setting actually apply in the relevant environment?

Step 2: Classify

True Positive (TP) — The finding is real and exploitable.

• Action: Fix it. Create a test that captures the security requirement. Enter TDD cycle.
• Priority: Based on severity and exploitability.

False Positive (FP) — The finding is not a real vulnerability in this context.

• Action: Document WHY it's a false positive. Add to allowlist with justification.
• Example justification: "This eval() call only receives output from our internal compiler, never user input. Input validation is enforced at [file:line]."
• Bad justification: "We don't think this is a problem." (Not specific enough.)

Accepted Risk (AR) — The finding is real but the business has decided to accept it.

• Action: Document the risk, the business justification, the mitigation (if any), and who approved it.
• Example: "This endpoint is rate-limited but not authenticated. Accepted because it serves public data, and adding auth would break existing integrations. Mitigated by rate limiting and monitoring. Approved by [name] on [date]."
• Requires: Explicit sign-off. Cannot be self-approved by the person who wrote the code.

Step 3: Document

Every finding produces a triage record:

{
  "finding_id": "layer1-insecure-defaults-001",
  "file": "src/auth/middleware.ts",
  "line": 47,
  "scanner": "insecure-defaults",
  "classification": "FP",
  "justification": "The catch block defaults to authenticated=false (deny), not true. Scanner misread the negation logic.",
  "triaged_by": "agent",
  "date": "2026-03-20",
  "added_to_allowlist": true
}

Step 4: Update Allowlist

False positives go into .nomark/security/allowlist.json so they don't get re-flagged:

{
  "allowlist": [
    {
      "pattern": "eval() in src/compiler/transform.ts",
      "reason": "Internal compiler output only — no user input path exists",
      "added": "2026-03-20",
      "review_by": "2026-06-20"
    }
  ]
}

Every allowlist entry has a review_by date. False positives don't stay on the allowlist forever — they get re-verified periodically because code changes and today's false positive might become tomorrow's real vulnerability.

Output Format

FP-CHECK TRIAGE — [timestamp]
Findings reviewed: [count]

TP  — [1] findings confirmed real → fix required
FP  — [2] findings classified as false positive → allowlisted
AR  — [0] findings accepted as risk
OPEN — [0] findings still need triage

Triage complete: YES | NO (if NO, merge is blocked)