A false positive means the scanner is wrong: the issue does not exist. Accepted risk means the issue is real but someone with authority agreed to live with it. Won't fix usually means the issue is real and low value to fix, such as test only code. Track them separately.
Why three statuses beat one
Many teams dump everything into "ignored". Then a report says 400 ignored findings and nobody can tell whether the scanner is noisy or the team is taking on risk. Splitting the statuses answers two different questions: how good is the tool, and how much risk did we choose to hold.
Definitions
| Status | Is the issue real | Who decides | What should be recorded |
|---|---|---|---|
| True positive, open | Yes | Triager | Severity, owner, due date |
| False positive | No | Developer, confirmed by a second person for high severity | Why the scanner is wrong, evidence |
| Accepted risk | Yes | A named risk owner | Impact, compensating control, expiry date |
| Won't fix | Yes, but low value | Team lead | Reason, such as test only code or end of life component |
| Fixed | Was real | Developer | Link to the change |
How code hosts and standards treat it
Dismissal workflows in common code scanning products give a reason list and an optional free text comment. One major code host's documentation says that when an alert is dismissed the reason is recorded, an optional comment appears in the alert timeline, and the alert no longer counts toward current alerts. It gives two example situations: an error in test only code, and a fix whose effort outweighs its benefit.
The SARIF standard separately models whether a suppression request is accepted, under review or rejected, which is a useful reminder that a suppression is a decision with a state, not a switch.
Rules that keep the statuses meaningful
- Require a reason for every status other than open and fixed.
- Give accepted risk an expiry date. It is a loan, not a gift.
- Send false positive counts back to whoever tunes the rules. A rule with many false positives needs a threshold change, not endless dismissals. See why SAST false positives happen and how to cut them.
- Let a different person confirm any false positive on a high severity finding.
- Report the three counts separately to leadership.
A short worked example
A scanner flags a hard coded password in a file under a test fixtures folder. If the value is a dummy used only in unit tests, that is a real pattern in the wrong place for the rule: mark it won't fix or exclude the folder, and note why. If it is a real credential, it is a true positive and also an incident, because it needs rotating regardless of where it sits. Misclassifying the second case as a false positive is how credentials stay live.
One factual note on Safeguard
Safeguard can enforce policies and gates and keep evidence records for compliance. If you want a quick look at your own code, the free scan at gold.safeguard.sh/scan is a no-account place to start.
Quick check
Should accepted risk ever be permanent?
Avoid it. Circumstances change, so give each acceptance an expiry date and a named owner who renews it deliberately.
Is test only code always safe to ignore?
Usually the flaws do not ship, but secrets in test files can be real credentials. Check before dismissing.
Sources
Last reviewed: 19 October 2026.
