A finding is a control that failed, or an alert the repository host reported. Findings are the work list: each one names the control or the alert, the requirements it affects, where the problem is, and the fix.
Two kinds of finding
- Failed control
- A control a signal tested and found false. Every requirement it satisfies is unmet until it is fixed and re-tested. It carries its inherited tier, the requirement identifiers, and a remediation prompt for your coding tool or, where the control is a document, a generator.
- Host alert
- A dependency vulnerability or a leaked secret reported by your repository host. It carries the severity word the host reports, the vulnerability identifier where there is one, its age, and a remediation window.
Remediation windows for host alerts
- Critical
- 7 days from the day the host opened the alert.
- High
- 14 days.
- Medium
- 30 days.
- Low
- No window.
The window is your due date, keyed on the host’s own severity word. VibeLock assigns no severity of its own. A leaked secret has no window because the only remedy is to rotate it now; the old value is compromised the moment it was committed.
Closing a finding
A failed control is closed by re-testing it. Apply the fix, run the signal again, and the control moves to verified at the new commit. There is no button that marks a finding fixed; only fresh evidence does.
A host alert is closed when the host closes it: the dependency updated, or the secret rotated and the alert resolved. The repository signal picks that up on its next run.
Every failed control in the coding-tool signal comes with a remediation prompt written for that control. Hand it to the same tool that found the problem, review the change, commit, and re-test.