SBOM and vulnerability management
From a list of components to a list of what to fix
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? 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? 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, 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) requires actively exploited vulnerabilities to be reported within 24 hours.