SBOMs Find Your EOL Components. They Do Not Fix Them.

The gap between knowing and fixing

SBOM adoption has moved quickly, and for good reason. Executive Order 14028 pushed it into federal procurement, Section 524B of the FD&C Act made it a condition of medical device submissions, and the EU Cyber Resilience Act is pulling in the same direction. The tooling matured alongside: generating a conformant CycloneDX or SPDX document from a build is now routine.

What none of that addresses is the thing the document tends to reveal. An SBOM is an inventory. Inventories are useful because they are honest, and the honest result for most enterprise estates includes a row for a component whose upstream project stopped publishing fixes some time ago.

At that point the SBOM has done its job completely and helped you not at all. You now have a precise, machine-readable, auditable record of a problem you did not previously have to name.

Why that row is usually a middleware component

There is a pattern to which components turn up unmaintained, and it is not random.

Application dependencies get updated because they are in the developers' path. A library with a vulnerability produces a failing scan in CI, someone bumps the version, the test suite runs, it merges. The feedback loop is short and the change is cheap.

Infrastructure components sit outside that loop. The message broker, the database, the coordination service, the servlet container, the language runtime — these are provisioned once, configured carefully, and then left alone precisely because they are working. Nobody bumps a broker version in a pull request. Upgrading one is a change window, a migration plan and a rollback procedure, which means it competes against feature work and loses, quarter after quarter.

So the components most likely to be years behind are the ones the whole estate depends on, and the ones where a vulnerability is least contained.

What an SBOM does not tell you

Three things, each of which matters more than the inventory itself.

Whether anyone is still fixing it

An SBOM records that you run version X. It does not record whether version X is still receiving security fixes. Those are different facts and only the second one is actionable. This is why an SBOM paired with a vulnerability feed produces a list of findings and no remediation path: the feed tells you what is wrong, the SBOM tells you where it is, and neither tells you that the fix does not exist for your branch.

What is underneath the thing it names

SBOM generators walk the dependency graph of an application. They are considerably less reliable about the platform the application executes on. A container image SBOM will usually catch OS packages. It frequently will not represent the language runtime, the JVM, or the Erlang/OTP release under a broker as first-class entries with their own version and their own advisory history.

That omission is not cosmetic. In our exposure study, Erlang/OTP 24 had accumulated twenty-two CVE records since its end-of-life date, nine of them CVSS 7.0 or above, while RabbitMQ itself had accumulated none. An SBOM that lists the broker and not the runtime reports the clean layer and omits the exposed one.

Whether the version string is even true

Backported builds, vendor-repackaged distributions and container images carrying patches that upstream never released all produce version strings that do not map cleanly onto upstream release history. A scanner matching on version alone will produce both false positives and false negatives against those artifacts.

What to do with the row you cannot fix

When the SBOM names an EOL component, there are four honest responses. The wrong move is to leave the finding open and hope the next audit does not ask.

1. Upgrade. Correct where it is feasible. Cost it properly — for infrastructure components the work is rarely the upgrade itself, it is the validation and the cutover window.
2. Get the version patched. Extended support exists because the arithmetic between component lifecycles and system lifecycles does not work. A backported fix keeps the version string, the API and the behaviour, which means it does not trigger the re-validation an upgrade would.
3. Replace the component. Sometimes the right answer, particularly where the upstream project has genuinely stopped rather than merely moved on.
4. Accept the risk, explicitly. Legitimate in some contexts, but it has to be written down, owned by someone with authority to own it, and reviewed. An undocumented acceptance is not a decision, it is a finding waiting to be written by somebody else.

What an auditor actually wants is evidence that a decision was made. The SBOM proves you knew. What follows it proves you acted.

Making the inventory useful

Three things turn an SBOM from a compliance artifact into an operational one:

• Join it to lifecycle data. Each component needs its end-of-life date next to its version, so the report distinguishes “old” from “unmaintained”. Those are different risks and conflating them wastes effort on the wrong rows. Our EOL tracker carries dates for the technologies we cover, with sources.
• Include the runtime layer deliberately. If your generator does not emit the JVM, the language runtime or the broker's runtime as entries, add them by hand. It is a short list and it is where the advisories are.
• Record a remediation owner per unmaintained component. Not a status — an owner. “Upstream” is not an owner when upstream has stopped.

Related reading

• FDA, off-the-shelf software, and the EOL component problem — where an SBOM becomes a submission requirement with refusal attached.
• EOL Exposure Study 2026 — the data behind the runtime-layer point.
• EOL tracker — lifecycle dates to join your inventory against.