Why Your SBOM Is Rotting

An SBOM is a snapshot. It captures the state of your software supply chain at a specific point in time. But reality changes daily — and your SBOM ages with every hour that passes.

What happens after creation? #

On the day of creation, an SBOM is accurate. After that, decay begins:

New vulnerabilities are discovered in existing components — new CVEs are added daily, plus Silent Fixes that appear in no database
Dependencies change. Developers update libraries, add new ones, or replace existing ones. The SBOM knows nothing about this.
Projects become orphaned. A maintainer stops, a project is archived, the last activity was months ago. Your SBOM still shows the component as "present" — but not as "unmaintained".
Licences change. A project switches from a permissive to a restrictive licence. Your SBOM contains the old licence information.
Maintainers change. A new maintainer takes over a project — with unknown trustworthiness. Supply chain attacks often begin precisely here.

Why is this a problem? #

EU legislation does not require a one-time inventory. It requires a continuous process:

DORA Art. 8(6): Regular updating of the inventory "following any material change"
DORA Art. 8(7): Assessment of legacy ICT systems at least annually, before and after connecting new systems
NIS2 Art. 21(2)(d): Supply chain security — requires current knowledge of all components
CRA Annex I Part II No. 1: Ongoing identification of vulnerabilities and components
ISO 18974 (4.3.1): SBOM creation and maintenance as a continuous, lifecycle-spanning process
ISO 18974 (4.1.5 No. 5): Post-release monitoring for new vulnerabilities in existing components

An auditor will not ask whether you have an SBOM. They will ask when it was last updated and what changes have occurred since. If your answer is "six months ago", you have a problem.

How quickly does an SBOM become outdated? #

For a typical enterprise product with hundreds of open source dependencies, the following happens within a few weeks:

Dozens of components receive updates
Several new vulnerabilities become known in existing versions
At least one project changes its maintenance status
Transitive dependencies shift without you noticing

After a few weeks, your SBOM no longer describes reality. After months, it is a historical document.

The problem doesn't start with you #

Outdated dependencies are not a problem that only affects end users. The open source projects themselves have the same problem — and it cascades through the entire supply chain:

90% of examined codebases contain components that are more than four years outdated
71.6% of dependencies in open source projects are outdated
95% of all vulnerabilities are found in transitive dependencies — packages that developers did not choose themselves but that are pulled in indirectly
A critical vulnerability remains on average over one year in an open source project before it is fixed

When Project A uses an outdated version of Project B, and Project B uses an outdated version of Project C — the risk cascades through the entire chain without you as the end user even knowing about any of these dependencies. Your SBOM shows you Project A. What lies beneath, you only see if someone actively looks.

What does this mean for you? #

An SBOM is the necessary beginning, but it rots without continuous maintenance. The laws do not require a stocktake but a living inventory. If your SBOM is not regularly updated, matched against current threats, and accompanied by risk assessments, it meets neither the regulatory requirements — nor does it protect you.