# SBOM and vulnerability management

From a list of components to a list of what to fix

> An SBOM makes it possible to answer which products are affected by a vulnerability. This page goes through the workflow: match against vulnerability data, prioritise with CVSS, EPSS and KEV, and filter out what does not affect you with VEX.

Updated: 5 October 2026  
URL: https://sbom.se/en/vulnerabilities/vulnerability-management

When a serious vulnerability becomes known in a library that many use, as with Log4j in December 2021, the first question is which of your own systems contain it. With an SBOM for every system, that is a search. Without SBOMs, it is an inventory carried out under time pressure.

## The workflow

### 1. Collect the SBOMs

Store an SBOM for every version of every product that is in use or has been delivered. That applies to software built in-house and to software from suppliers.

### 2. Match against vulnerability data

The components in the SBOM are compared against databases of known vulnerabilities:

* **NVD**, the US National Vulnerability Database
* **EUVD**, the EU vulnerability database operated by ENISA
* **OSV** and the **GitHub Advisory Database**, which cover open-source ecosystems

Matching depends on the components having correct versions and unique identifiers. [Why is SBOM quality important?](https://sbom.se/en/guides/sbom-quality) describes what happens otherwise.

### 3. Prioritise

A match often returns more findings than can be fixed at once. Three measures are used to prioritise:

| Measure | What it says                                                                    |
| ------- | ------------------------------------------------------------------------------- |
| CVSS    | How severe the vulnerability is if exploited, on a scale from 0 to 10           |
| EPSS    | The probability that the vulnerability is exploited within 30 days              |
| KEV     | Whether the vulnerability is on a list of vulnerabilities known to be exploited |

A vulnerability with a medium CVSS score that is on a KEV list is usually more urgent than a critical one that nobody is exploiting. [What is a vulnerability?](https://sbom.se/en/vulnerabilities/what-is-a-vulnerability) describes the measures in more detail.

### 4. Filter out what does not affect you

Not every vulnerability in a component can be exploited in the product. The supplier's assessment is delivered as [VEX](https://sbom.se/en/vulnerabilities/what-is-vex), and vulnerabilities with the status Not Affected can be set aside.

### 5. Fix and follow up

Update the component, or add another protection if no update exists. A new version of the product gets a new SBOM, and the old one is kept for as long as the old version is in use.

## Continuous monitoring

The SBOM for a version does not change, but the vulnerability databases change every day. Matching therefore has to be done continuously, against all versions that are still in use.

For manufacturers this is also a legal requirement. The [Cyber Resilience Act (CRA)](https://sbom.se/en/cra/vulnerability-reporting) requires actively exploited vulnerabilities to be reported within 24 hours.