Verdicts and Justifications
The term "verdict" is used deliberately to distinguish from automated scanner statuses — it reflects a deliberate human judgment about the impact of a vulnerability.
Verdict Values
| Value | Description |
|---|---|
|
The vulnerability impacts this release and remediation is expected. Requires |
|
The vulnerability is present in a dependency but does not impact this release. Requires |
|
The vulnerability impacts this release but the risk has been assessed and accepted without remediation. Requires |
(absent) |
Not yet triaged. The entry is under investigation. |
"Fixed" is not a verdict.
Fixing a vulnerability is a resolution action, not a judgment about impact.
Use verdict: affected with a resolution block to record that a vulnerability was real and subsequently fixed.
Use verdict: not affected with an optional resolution to record that a vulnerability was not relevant but the dependency was updated anyway.
|
affected
The vulnerability is confirmed to impact the project and remediation is expected.
Requires a severity assessment.
Typically paired with a resolution block once the fix is applied.
Once a resolution is recorded, the entry is automatically excluded from generated suppression files — the scanner is expected to stop reporting the finding after the dependency update.
Without a resolution, an explicit suppress block is required to suppress the finding.
verdict: affected
severity: high
resolution:
in: 2.0.1
at: 2026-03-03
note: "Updated image-lib from 3.1.0 to 3.2.0"not affected
The vulnerable dependency is present but does not impact the project.
Requires a justification explaining why the vulnerability is not exploitable in this context.
Because the finding does not reflect a real risk to the project, entries with this verdict are always included in generated suppression files without requiring an explicit suppress block.
verdict: not affected
justification: vulnerable code not in execute path
analysis: >
The vulnerable code path requires SVG input processing.
Our application only accepts PNG and JPEG formats.risk acceptable
The vulnerability is confirmed to impact the project, but a deliberate decision has been made to accept the risk without remediation.
Requires a severity assessment.
Unlike affected, this verdict signals that no fix is planned.
The vulnerable dependency remains in place and represents a live risk, so the scanner continues to report the finding.
Suppressing a live risk must be a deliberate decision separate from the verdict, so an explicit suppress block on the report entry is required.
verdict: risk acceptable
severity: medium
analysis: >
Vulnerability confirmed but only exploitable with
specially crafted input that our validation layer rejects.Severity Values
Required when verdict is affected or risk acceptable.
| Value | Description |
|---|---|
|
Immediate action required. Exploitable with severe impact. |
|
Action required. Significant impact if exploited. |
|
Action recommended. Moderate impact. |
|
Low priority. Minimal impact or difficult to exploit. |
Justification Values
Required when verdict is not affected.
Values align with the OpenVEX justification vocabulary.
| Value | Description |
|---|---|
|
The vulnerable component is not included in the deliverable. |
|
The vulnerable code is present but the specific vulnerable function or code path is not included. |
|
The vulnerable code is present but cannot be reached during execution. |
|
The vulnerable code is reachable but cannot be triggered by an attacker. |
|
The vulnerability is mitigated by existing controls (e.g., WAF, input validation). |