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.

Each vulnerability entry answers up to four questions:

Question Field Values

Does it affect this release?

verdict

absent (under investigation), affected, not affected

How severe is it for us?

severity

low, medium, high, critical

What will we do about it?

disposition

will fix, wont fix (optional)

Was it remediated, and where?

resolution

absent, or a resolution block

Severity and disposition only carry meaning once the verdict is affected. Resolution is independent of the verdict: it records the fact that the dependency was updated or the issue otherwise addressed.

Verdict values

Value Description

affected

The vulnerability impacts this release. Requires severity; an optional disposition states the remediation intent.

not affected

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

(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. 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 included in generated suppression files without requiring an explicit suppress block.

If a resolution is also recorded, the entry is treated as resolved and excluded from generated suppression files; the dependency was updated, so the scanner is expected to stop reporting the finding.

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.

Disposition values

The optional disposition field states what the project intends to do about an affected vulnerability. It is only valid together with verdict: affected and has no default: absence means the intent has not been stated, which is distinct from both values.

Value Description

will fix

The project intends to remediate the vulnerability.

wont fix

The project accepts the risk; no remediation is intended.

Accepting a risk

A deliberate decision to accept a risk is expressed as verdict: affected with disposition: wont fix. 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 triage, so an explicit suppress block on the report entry is required.

verdict: affected
severity: medium
disposition: wont fix
analysis: >
  Vulnerability confirmed but only exploitable with
  specially crafted input that our validation layer rejects.

A risk-accepted vulnerability may still be fixed passively, for example when an unrelated dependency update happens to contain the fix. Record that with a resolution block; the wont fix disposition and the resolution coexist.

Migration from risk acceptable

Earlier versions expressed risk acceptance as a dedicated verdict, risk acceptable. That verdict is deprecated: it combined the applicability judgment with the remediation intent, which are separate questions.

Files carrying the legacy verdict keep parsing until the 1.0 release; the entry behaves exactly like verdict: affected with disposition: wont fix, and vulnlog validate prints a deprecation warning. Writing commands leave the legacy verdict as written; migrating is a deliberate step. Reports never render risk acceptable either. An accepted risk appears as verdict affected, its severity, disposition wont fix, and state accepted, which is exactly what the file records.

See Migrate from the 'risk acceptable' verdict for the migration guide.

Severity values

Required when verdict is affected.

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.
Accepting a critical risk with disposition: wont fix is valid but unusual; vulnlog validate points it out with an info finding.

Justification values

Required when verdict is not affected. Values align with the OpenVEX justification vocabulary.

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