static-analysis-triage

name

static-analysis-triage

description

Convert output from custom or experimental static analysis tooling into actionable bug fixes. Use when working with novel linters, in-house detectors, or recently-shipped analysis passes whose findings haven't yet been triaged into PRs. Covers detector volume reduction, per-finding source verification, false-positive shape recognition, and end-to-end PR drafting. NOT for established lints (gosec, staticcheck, eslint) where the rules are well-known and the fix is mechanical.

Static Analysis Triage

Candidate counts and bug counts are different numbers; the ratio depends on the detector, the codebase, and appetite for cosmetic fixes.

Workflow

1. Sanity-check volume first. A detector producing 10x its peers usually has: generated code in the set (filter on the // Code generated ... DO NOT EDIT preamble), vendored code (vendor/, third_party/, build/proto-vendor/, local_vendor/ — conventions are project-specific), or a too-loose caller/sink predicate. Under ~20 candidates, skip volume reduction and triage each one — tightening predicates against tiny samples overfits.
2. Triage the smallest-count detector first. It teaches the false-positive shapes cheaply; then scan larger detectors for those shapes instead of reading each finding line-by-line.
3. Per finding, read the source and classify: false positive / real-but-low-impact (correct but not worth reviewer time, e.g. a Ctrl-C delay in a dev-only CLI) / real bug. Judge at the call site — literal durations, surrounding statements, comments — not the signature; the same sink can be an FP in one caller and a bug in another.
4. Write each PR by hand. No template scripts — auto-drafting a fix against a false positive destroys reviewer trust (explicit user constraint). Description specific to this location's bug shape; fix matches surrounding style (variable names, ctx identifier, error handling); reviewer assignment per project convention; one bug shape per PR.