Not every vulnerable component is a vulnerable product. A flaw in a function you never call, in a dev dependency that never ships, or on an operating system you don’t run on does not affect your users. Triage is how you record that assessment — and VEX (Vulnerability Exploitability eXchange) is the standard format for sharing it with customers and auditors.
Statuses
| Status | Meaning | Required |
|---|---|---|
| Under investigation | You know about it and are looking into it | — |
| Affected | The product is affected and you plan to act | An action statement: what users or you will do |
| Not affected | The vulnerable code can’t be exploited in this product | A justification or an impact statement |
| Fixed | The product contains a fix | — |
Findings without a decision are open.
Justifications for “not affected”
These are the labels defined by OpenVEX. Pick the one that fits and add an impact statement to explain it in your own words.
| Justification | Use when |
|---|---|
| Component not present | The component is listed but not part of the shipped product (e.g. a dev dependency) |
| Vulnerable code not present | The affected code was removed or not compiled in |
| Vulnerable code not in execute path | The code is there but never runs in your product |
| Vulnerable code cannot be controlled by adversary | An attacker can’t reach or influence the vulnerable code |
| Inline mitigations already exist | Your product already blocks exploitation |
Making a decision
Open a finding on the Findings tab. The side sheet shows the advisory, how the component got into your product (direct dependency, or which direct dependency introduces it) and the triage form. Choose a status, fill in the statements and save.
- Every save is recorded with who made it and when; earlier versions of a decision are kept as history.
- If a colleague changed the decision while you were editing, saving is refused and you are asked to reload, so nobody silently overwrites someone else’s assessment.
How long a decision lasts
A decision applies to one vulnerability in one component of one artifact version. It carries over to every new upload and every re-analysis of that artifact version. A new version starts untriaged, because the code — and your assessment — may have changed. See Projects.
Exporting OpenVEX
Export OpenVEX on the Findings tab downloads an OpenVEX v0.2.0 document with all decisions for the selected artifact version:
- one statement per decision, with the vulnerability id, the component’s purl, the status and the statements,
not_affectedstatements carry the justification label; free-text reasons are exported as the impact statement,- the document id changes whenever a decision changes, so a recipient can tell versions apart.
Hand the document to customers together with your SBOM, or feed it into scanners that support VEX to suppress findings you have already assessed.