Skip to Content
GuidesMark False Positives

Mark False Positives

Not every finding is a real bug. Sometimes the scanner flags sanitized input, intentional design, or untestable dev-only code. Marking these as false positives:

  1. Hides them from gate violations
  2. Drops them from issue counts in dashboards
  3. Feeds FP-rate telemetry back into the scanner (so we can tune rules)
  4. Stays audit-logged

Mark via UI

Mark via API

curl -X POST "https://codestax.co/api/quality/findings/mark-fp" \
  -H "Authorization: Bearer $CODESTAX_JWT" \
  -H "Content-Type: application/json" \
  -d '{
    "issue_id": 98765,
    "is_fp": true,
    "reason": "Sanitized via framework encoder at the boundary"
  }'

Response:

{
  "issue_id": 98765,
  "user_marked_fp": true,
  "fp_marked_at": "2026-04-19T15:00:00Z",
  "fp_reason": "Sanitized via framework encoder at the boundary"
}

Unmark by sending "is_fp": false.

How FP Marks Are Used

Gate evaluation

Findings with user_marked_fp: true are excluded from gate violation counts. The gate sees only findings the user hasn’t waved off.

Issue counts

Dashboards + scan summaries report issues_count as confirmed-only (FP-marked findings are stored but not counted).

FP-rate telemetry

Per-rule FP rate is tracked over time. When rule X gets marked FP > 10% of the time, we surface it for rule-tuning. Coming soon: public rule-level FP rate page (Tier 3 roadmap — see Reproducibility).

Mark FP vs Waiver — Which to Use?

SituationUse
One specific finding is wrong (sanitizer, intentional design)Mark FP on the finding
A whole rule is too noisy for your codebaseWaiver for that rule (scope: org or repo)
A PR has a legit exception that breaks policyWaiver at pr_number scope + expiry
Repo has structural tech debt that won’t clearWaiver at repo scope + expiry tied to remediation
Repo has different standards than org default.codestax/quality_gate.yaml policy-as-code override

Short version: FP = “this specific instance is wrong”, Waiver = “this rule doesn’t apply here”.

What Doesn’t FP Marking Do?

  • Doesn’t tell the scanner to stop finding it — the finding still appears in scan output, just flagged as user-marked-FP. If you want the scanner to never surface the pattern again, use a waiver or ignore rule (see SCA Ignore Rules).
  • Doesn’t share across scans automatically — each scan produces a fresh finding. However, if the fingerprint matches a prior FP-marked finding, the scanner can optionally inherit the FP status (set quality_fp_inherit_on_fingerprint: true in scanner config). Coming soon — today, FP marks are per-finding.
  • Doesn’t prevent other users from seeing the finding — mark is org-scoped, not user-scoped. Any org member sees the FP state.

Audit Trail

Every FP mark stores:

  • user_marked_fp: true|false
  • fp_marked_at: datetime
  • fp_reason: str (up to 500 chars)

Accessible via GET /api/scans/:id/issues (includes these fields per finding). No separate audit log endpoint yet — on roadmap.

Baseline RebuildSet Up PR Reviews