Vulnerability States
Every vulnerability entry has a state that reflects where it sits in the triage lifecycle. State is not written into the YAML directly — it is derived from which fields are present on the entry each time a report is generated.
The three states
| State | Derivation | Meaning |
|---|---|---|
|
|
The finding has been registered but triage has not started. |
|
|
Triage is complete and a verdict has been reached. The entry awaits closure. |
|
|
The maintainer’s triage work on the entry is complete. |
Perspective
State describes the maintainer’s view: has the triage team finished its work on this entry? It does not describe whether a currently running release contains the fix.
An entry can be resolved while the release carrying the fix is still unpublished.
Release-scoped questions are answered by other means:
-
Use the
--releasefilter onvulnlog reportto list vulnerabilities present in a specific release. -
See the
Fixed Incolumn (the entry’sresolution.infield) for the release that contains the fix.
Typical progression
State derivation depends only on the analysis and resolution fields.
The verdict is independent of state and is retained as the entry moves through the lifecycle.
-
New entry. No
analysis, noverdict. State isunder investigation. -
Triage complete.
analysisrecorded andverdictset. State isopen. All verdict values are valid at this stage. -
Closure.
resolutionrecorded. State isresolved. The verdict is retained.
State in the HTML report
The HTML report produced by vulnlog report is the project owners view (the view from and for the project maintainer team) of the triage backlog across all tracked releases.
Entries in every state appear in the same table so the maintainer can see the complete picture.
| Column | Content |
|---|---|
|
|
|
Releases in which the vulnerability was reported. |
|
Release in which the resolution was applied. Empty for entries that are not |
See vulnlog report for command usage and filters.