Answer a vulnerability inquiry

A customer, a downstream user, or an auditor asks about a specific vulnerability in your product. This guide turns the recorded triage decision into a reliable answer, and covers the cases where the lookup is not straightforward.

Prerequisites

  • Read access to the Vulnlog file of the release line the inquiry concerns.

  • The identifier the inquirer reports, and ideally their product version.

Find the entry

Search the file for the identifier with your editor, GitHub search, or grep:

grep -n "CVE-2026-1234" vulnlog.yaml
60:  - id: CVE-2026-1234

When the direct search misses, work through these in order before concluding the finding is untracked:

Aliases

Scanners name the same vulnerability differently. Known alternative identifiers are recorded in the entry’s aliases field, so search for the reported identifier as a whole; it may match an alias of an entry with a different primary id.

Scanner-specific identifiers

Report entries can carry scanner-native identifiers in vuln_ids (for example SNYK-…​ identifiers on a Snyk report).

The affected package

Search for the package name from the inquirer’s scanner output; the entry’s packages field lists affected Package URLs.

Another release line

With one file per release line, the decision for the inquirer’s version lives in that line’s file, and verdicts can legitimately differ between lines.

Build the answer

Three fields carry the position; quote them rather than paraphrasing from memory:

  • verdict: the decision (not affected, affected, risk acceptable).

  • justification: for not affected, the machine-readable reason from the VEX vocabulary.

  • analysis: the reasoning, written to be quoted.

Add the timeline from reports[].at and analyzed_at, and the fix release from resolution.in when one is recorded. Confirm the inquirer’s version is covered: their release must appear in the entry’s releases list.

For an affected entry, the honest answer includes the fix release and whether it shipped. For risk acceptable, the analysis and comment carry the accepted-risk rationale.

Share evidence

When the inquiry warrants more than a written answer, share the generated report; it contains the verdict, justification, and analysis for every entry (see Generate reports). For auditors, the git history of the Vulnlog file shows when each decision was made and by whom.

If there is no entry

The finding is untriaged. Record it now so triage starts (see Triage a new scanner finding), and answer with "under investigation" plus a date for the verdict. An invented answer costs more trust than an honest open state.

Verify

Every statement in your answer should trace to a field in the entry or to the git history; if you had to reason beyond the file, the entry’s analysis is incomplete: improve it while the reasoning is fresh.

Related