VEX assessments
A bill of materials says your product contains OpenSSL 3.0.11; a source says that version has a published vulnerability. It does not follow that the product is vulnerable: the component may be unreachable, the faulty function may never be used, a mitigation may already be in place. VEX is the document in which you say which of the two is true, and take that statement on yourself. CRAnotify brings you the match; the assessment stays yours.
Where it lives
The Vulnerabilities tab of a product's page (/prodotto?id=…&tab=vulnerabilita). Each row is an observed match: the vulnerability, the matched component, the source that saw it, and next to it the human assessment — or its absence, stated in words.
Four steps, and they stay four
- A source observes a match between a component in the bill of materials and a published vulnerability.
- A person assesses it: picks a status and gives the reason. That produces a draft.
- A person approves the draft. It is a separate gesture, with its own name and date.
- From then on the statement is what the company says it knows about its product, and only then does it reach the documents that go out.
There are four steps on purpose. Compressing them into a single button would mean that a source update, overnight, changes what you state you know about your product. The assessor and the approver may be two people, and in an organisation that cares about its defensibility they are.
A match is not an assessment
The opened row shows two layers, side by side and distinct: on the left the source data (source, component, PURL, release, reference, when it was recorded), on the right the human assessment. The source layer states that CRAnotify has determined no legal applicability: this is a signal.
If nobody has assessed it yet, the human column does not show a dash — it says "Not assessed — human review required". A dash, or an empty cell, reads as "nothing to report", which is the opposite of what is true.
The four statuses of the standard
They are the CSAF/OpenVEX ones. We add none and rename none: whoever consumes a VEX expects these, and invented semantics would make the document unreadable to exactly the people who should read it.
| Status | What it states |
|---|---|
under_investigation | You are still looking: nothing is stated about the product. |
not_affected | It tells the reader not to worry. A justification is required. |
affected | The product is affected. |
fixed | A remediation is available. Saying which one, in the justification, is what makes it useful. |
"Affected" starts no deadline. It is the condition from which, together with active exploitation, an Art. 14 obligation may follow — but whether an obligation exists is established by the engine, on a case, after an awareness confirmed in triage. Recording a VEX status opens no deadline and issues no verdict.
Recording an assessment
From the panel on the row: choose the status and write the justification. The vulnerability and the component are the ones from the match and are not typed in — that keeps the statement attached to what was observed. The assessor's identity comes from the session: there is no form field it could come from, which is why no automated path can produce a draft.
Approving is the second gesture
Under a draft you will find Approve this assessment, with the notice that the assessment is recorded but not approved. Approval records who gave it and when, and only applies to a statement belonging to that product: the application checks this on the server, so a hand-built form cannot approve, from one product's page, the statement of another.
Approving twice is not an error: the second time nothing changes.
Where approved statements end up
Only approved statements are cited in the technical documentation file, and they are what can be shown to a third party. A draft is an opinion in progress, and publishing it would amount to stating something nobody has signed.
Every assessment and every approval leaves a row in the activity registry, with the vulnerability, the status, the component, who assessed and who approved.
If there is no match at all
The tab says so in words: no source has matched a published vulnerability to a component of this product. That is not a statement about the product: it depends on which bills of materials have arrived and which sources are connected. A product with no bill of materials produces no matches, and silence is not good news.
Review work still to be done also appears in the action queue, filterable by product.