The lifecycle of a finding
Open, confirmed, fixing, resolved, verified - and what moves a finding between them.
| Status | Meaning |
|---|---|
| OPEN | Raised and not yet dealt with. |
| CONFIRMED | Corroborated by a second signal - typically a runtime observation confirming a code finding. |
| FIXING | Work is in flight: a fix branch, a draft pull request, or a change set that touches it. |
| RESOLVED | The rule that raised it no longer fires on the current state. |
| VERIFIED | Resolved and re-checked by the rule that raised it, on a later scan. |
Re-appearing findings
Findings are identified by fingerprint. If the same problem comes back after being resolved, it re-opens with its history intact rather than arriving as a new item with no context.
When a committed credential is removed, the finding resolves - but whether you rotated the key is something only you can know. The finding says so explicitly rather than implying it is fully handled.
Questions
A finding says resolved but I did not fix it. Why?
The rule no longer fires. That can mean the code changed, or that the thing it examined is no longer reachable. Open the history: it records which scan resolved it and what changed.
How long do resolved findings stay visible?
They stay with the site, so you keep the history of what was found and when. Filters default to open work.
Something here wrong, missing or out of date? Tell us and we will fix the page.