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

Value	Description
`affected`	The vulnerability impacts this release and remediation is expected. Requires `severity`.
`not affected`	The vulnerability is present in a dependency but does not impact this release. Requires `justification`.
`risk acceptable`	The vulnerability impacts this release but the risk has been assessed and accepted without remediation. Requires `severity`.
(absent)	Not yet triaged. The entry is under investigation.

affected

The vulnerability impacts this release and remediation is expected. Requires severity.

not affected

The vulnerability is present in a dependency but does not impact this release. Requires justification.

risk acceptable

The vulnerability impacts this release but the risk has been assessed and accepted without remediation. Requires severity.

(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.

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, so the scanner continues to report the finding. An explicit suppress block on the report entry is required to suppress the finding.

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

Value	Description
`critical`	Immediate action required. Exploitable with severe impact.
`high`	Action required. Significant impact if exploited.
`medium`	Action recommended. Moderate impact.
`low`	Low priority. Minimal impact or difficult to exploit.

critical

Immediate action required. Exploitable with severe impact.

high

Action required. Significant impact if exploited.

medium

Action recommended. Moderate impact.

low

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

Value	Description
`component not present`	The vulnerable component is not included in the deliverable.
`vulnerable code not present`	The vulnerable code is present but the specific vulnerable function or code path is not included.
`vulnerable code not in execute path`	The vulnerable code is present but cannot be reached during execution.
`vulnerable code cannot be controlled by adversary`	The vulnerable code is reachable but cannot be triggered by an attacker.
`inline mitigations already exist`	The vulnerability is mitigated by existing controls (e.g., WAF, input validation).

component not present

The vulnerable component is not included in the deliverable.

vulnerable code not present

The vulnerable code is present but the specific vulnerable function or code path is not included.

vulnerable code not in execute path

The vulnerable code is present but cannot be reached during execution.

vulnerable code cannot be controlled by adversary

The vulnerable code is reachable but cannot be triggered by an attacker.

inline mitigations already exist

The vulnerability is mitigated by existing controls (e.g., WAF, input validation).