These terms describe one pipeline. An SBOM lists what is in your software. SCA matches that list to known vulnerabilities, which are named by identifiers such as a CVE. KEV flags the ones attackers are using. VEX records whether a given vulnerability actually affects your product.
The terms
- SBOM, software bill of materials. A list of the components in a piece of software, in a standard format such as CycloneDX or SPDX.
- SCA, software composition analysis. Scanning your dependencies, direct and transitive, to find components with known vulnerabilities or licence issues.
- CVE. A public identifier for a specific vulnerability, so that everyone can refer to the same flaw.
- OSV. An open format and database for vulnerability data about open source packages. Entries record affected ranges and fixed versions, and an API lets you query by package and version.
- KEV. CISA's Known Exploited Vulnerabilities catalog, a list of flaws exploited in the wild, published as CSV and JSON.
- VEX. A statement about whether a vulnerability affects a product, such as not affected, affected or fixed. CycloneDX can carry VEX information alongside a BOM.
Which question each one answers
| Term | Question | Typical owner |
|---|---|---|
| SBOM | What is in this software? | Build and release team |
| SCA | Which components have known flaws? | AppSec and developers |
| CVE | What is this flaw called? | Anyone referring to it |
| OSV | Which versions are affected and fixed? | Scanners and tooling |
| KEV | Is anyone exploiting it? | Security operations |
| VEX | Does it affect us, and why or why not? | Product security |
How they connect
- Build produces an SBOM.
- SCA compares SBOM components with vulnerability data such as OSV and assigns identifiers.
- Findings are prioritised, with KEV membership as a strong signal.
- For each finding you decide: fix, mitigate, accept or mark not affected.
- VEX communicates the not affected decisions, with reasons, to customers and auditors.
Common mix ups
- An SBOM is not a vulnerability report. It lists components. Vulnerabilities come from matching.
- A CVE is not a score. Scores such as CVSS are separate.
- KEV is short. A flaw missing from it is not therefore safe.
- VEX is not an alternative to scanning. It records decisions about scan results.
Quick check
Do I need all six?
You need the first four to find and fix problems. KEV improves prioritisation. VEX matters once customers or regulators ask you to explain findings that do not apply.
Can one tool do all of it?
Often, yes. What matters is that the pieces share one inventory, so a finding, a decision and its evidence stay connected.
Where Safeguard fits
Safeguard's SBOM and dependency scanning covers the first two steps and its reachability analysis and policies help with the decision step. Try the free scan.
Sources
- CycloneDX specification overview, cyclonedx.org (BOM types and VEX use).
- OSV API documentation and OSV schema, google.github.io/osv.dev and ossf.github.io/osv-schema.
- CISA Known Exploited Vulnerabilities Catalog (CSV and JSON feeds).
Last reviewed: 19 October 2026.
