A VEX (Vulnerability Exploitability eXchange) statement lets you tell Declara that your own assessment already covers a match — so it doesn't need to interrupt anyone as a new alert.
Which statuses suppress
not_affected— suppresses.fixed— suppresses.affected— does not suppress. You've confirmed exploitability; the match should alert.under_investigation— does not suppress. An assessment in progress can't be used to quiet a clock before it's finished.
Before you start
You need sbom.upload-adjacent access to submit VEX documents for a product (the
same permission tier as uploading an SBOM), and the statement needs to name the
advisory and either the specific component or the whole product.
Steps
- Prepare a VEX document — either an OpenVEX document or a CycloneDX BOM carrying
a
vulnerabilitiesarray with analysis blocks. Both are accepted. - Upload it against the relevant product.
- Declara reads the statement's status, justification, and detail, and matches it to the advisory and component (or whole-product scope) it names.
- On the next match run, any
not_affectedorfixedstatement suppresses the corresponding match before an alert is raised.
What you should see
A suppressed match shows in your inventory as suppressed by VEX, with the statement's justification attached — it never reaches your Alerts list, and nobody is notified.
A VEX statement arriving after an alert is already open does nothing
If a match has already raised an alert, a VEX statement that arrives afterward —
even not_affected or fixed — does not retroactively close it. This is
deliberate, not a bug: once an alert is open, somebody is presumably already
assessing it, and a document that silently retracts an open alert is exactly how a
real finding could disappear unnoticed. See
Why VEX suppresses a match but never an open alert
for the full reasoning.
If you filed a VEX statement expecting it to close an existing alert and it didn't, see Troubleshooting — the fix is to close the alert through triage, not to resubmit the VEX statement.