Reading a finding is the first half. Deciding what it means for this repository, and having that decision survive the next scan, is the second.
Two different states
Every finding carries the scanner's own verdict, described in Verification. Separately, it carries your triage decision. Keeping them apart matters: the scanner saying a path resolves and you saying you accept the risk are different claims, and neither should overwrite the other.
| Triage status | What you are saying |
|---|---|
open | Nothing has been decided yet. This is where every finding starts. |
fixed | The vulnerability is gone. Set by reconciliation when a later scan no longer reproduces it. |
accepted_risk | It is real, and you are choosing to live with it. Recorded as your decision, with a reason. |
false_positive | It is not real. Recorded as your decision, with a reason. |
Dismissing with a reason
A dismissal without a reason is a decision nobody can review later, including you. The note is the point: six months on, the useful record is not that someone dismissed it, but why.
What the next scan does
Findings are tracked across scans by a fingerprint built from the rule, the location, and the enclosing function, so a finding survives the file being reformatted or moved down a few lines. Your triage decision travels with the fingerprint, which is what stops a dismissed finding coming back every time someone runs a formatter.
Reconciliation is also what lets the commit history say what a commit introduced, resolved, or suppressed. That is a record of what actually happened, rather than a diff someone inferred afterwards. See Branches and commits.
In the workspace
Findings is the working queue. The Triage group in the sidebar splits out what you have flagged, what you have dismissed, and what is completed, so the queue stays a queue rather than turning into an archive.
Common questions
A finding I dismissed came back. Why?
Either the code changed enough that its fingerprint changed, which makes it a genuinely new finding, or it was reintroduced somewhere else. Open it and compare the location against the one you dismissed.
Does merging a fix close the finding?
No. Merging changes the code. The next scan of the newer commit is what proves the path no longer resolves, and that is what marks the finding fixed. Rescan after merging, not before.
Can I stop a whole class of finding at once?
Not by rule today. What you can do is turn a check off for the repository, which stops the category entirely from the next scan. See Checks.
Who can triage?
Anyone with access to the workspace the repository is connected to. Triage decisions record who made them and when.
Have a correction or need help?
Email the docs team