What is VEX? Vulnerability Exploitability eXchange explained
VEX is a statement from a supplier about whether a known vulnerability actually affects their product. Learn the four statuses and why they cut noise.
Deep dives, practical guides, and incident analyses from engineers who build Safeguard. No fluff, no vendor FUD — just what you need to ship secure software.
VEX is a statement from a supplier about whether a known vulnerability actually affects their product. Learn the four statuses and why they cut noise.
How a VEX statement moves from under_investigation to affected, fixed or not_affected, and which version and timestamp fields must change along the way.
How to record a reachability result in an OpenVEX statement: the five not_affected justification labels and which one fits code that is never called.
Six common misunderstandings about VEX, checked against the CISA minimum requirements and the OpenVEX spec, from default status to who may write one.
A not_affected VEX statement needs a justification, an impact statement, or both. Here is when each fits and why machines should read the justification.
How VEX document and statement versions, first issued and last updated timestamps must relate, so consumers can trust change tracking in a VEX feed.
Reachability analysis finds whether vulnerable code can be called. VEX records the conclusion. How the evidence feeds vulnerable_code_not_in_execute_path.
What the VEX statuses affected, fixed and under_investigation mean, what each one must contain, and how a consumer should act on them in triage.
Got a CycloneDX or SPDX file from a vendor? Drop it into the free scan for a quick look at known vulnerabilities, then ask the supplier better questions.
Weekly insights on software supply chain security, delivered to your inbox.
Your first fix PR is minutes away.
No sales call required, even your agent can complete the purchase over MCP.