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:

Hides them from gate violations
Drops them from issue counts in dashboards
Feeds FP-rate telemetry back into the scanner (so we can tune rules)
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

False-positive actions remain attached to the finding and its stable fingerprint for audit and rule-tuning evidence. The dashboard does not currently expose a public per-rule false-positive-rate report.

Mark FP vs Waiver - Which to Use?

Situation	Use
One specific finding is wrong (sanitizer, intentional design)	Mark FP on the finding
A whole rule is too noisy for your codebase	Waiver for that rule (scope: org or repo)
A PR has a legit exception that breaks policy	Waiver at `pr_number` scope + expiry
Repo has structural tech debt that won’t clear	Waiver 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 its own finding state. Do not assume a false-positive decision will be inherited by a later scan solely because the fingerprint matches.
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)

Retrieve scan findings with GET /api/scans/{scan_id}/issues. Customer-visible audit events are available through GET /api/audit-logs/my-org.

Manage Waivers - rule-level exemptions across PRs/repos
Set Up Quality Gates
Quality Gate API - POST /quality/findings/mark-fp