A workable VEX publication workflow has seven steps: match the advisory to your SBOM index, triage each hit, draft statements, peer review, approve, sign and publish, then monitor for corrections. Each step has one owner, and nothing goes public without a second person checking any not affected claim.
Roles
| Role | Does | Does not |
|---|---|---|
| Triage engineer | Decides affected or not, writes the justification | Publish |
| Product security reviewer | Checks the reasoning and the product mapping | Triage their own work |
| Approver | Accepts the risk of the public statement | Edit the evidence |
| Publisher | Signs and posts the file | Change the content |
| Customer communications | Sends notices that point to the file | Restate status in their own words |
In a small team one person may hold two roles. The rule that survives is that the author of a not affected claim does not approve it alone.
The seven steps
- Match. Query the component index for the advisory's package and range. The output is a list of products and releases.
- Triage. For each hit, decide one of four statuses: affected, fixed, not affected or under investigation. For not affected, record why, such as the component being absent or the vulnerable code not being reachable.
- Draft. Generate statements from the triage record, not by hand. Use product identifiers customers recognise.
- Review. A second person checks that the justification matches the evidence and the product list is complete.
- Approve. Someone accountable agrees that the statement can be public.
- Sign and publish. Sign the document, post it at the stable location, update the advisory index and send any customer notice.
- Monitor. Watch for new facts. Update, bump the version and republish when status changes.
Rules from the specification
OpenVEX requires the author to be an individual or organisation, and recommends a machine readable identifier cryptographically tied to the signature or exchange mechanism. It also requires that a not affected statement carry a justification or impact statement, and that an affected statement carry an action statement. Build these checks into the draft step so a reviewer never sees an invalid file.
Corrections
You will sometimes be wrong. Treat a correction as a normal event: publish a new version with the changed status, keep the old one reachable, and tell customers who relied on it. The process is described further in VEX statement lifecycle.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a finding moves through states and who it is assigned to.
Quick check
Who should be allowed to mark a finding not affected?
Anyone trained to triage, but with a second person reviewing before it is public.
Do we need a VEX for every scanner finding?
No. Publish for vulnerabilities customers are likely to ask about, such as widely reported ones or those that appear in their scans of your product.
Safeguard's policies, gates and guardrails and compliance evidence automation can record approvals for each step. A free scan shows the findings that feed it.
Sources
Last reviewed: 19 October 2026.
