Does an SBOM Show End-of-Life Software?
Not on its own. A software bill of materials (SBOM) lists the components in a piece of software with their versions and identifiers. It does not, by default, record whether each component is still supported or when its support ends. An SBOM is an inventory; end of life is a fact about the vendor's calendar. To find end-of-life components, the SBOM has to be joined to lifecycle data from outside.
What the two SBOM formats can carry
| CycloneDX 1.6 | SPDX 3.0 | |
|---|---|---|
| Component name, version, supplier | Yes | Yes |
| Identifiers (package URL, CPE) | Yes | Yes |
| Dedicated end-of-life or support field on a component | No. The component definition has no such field | Yes, optional: supportLevel (values include endOfSupport, limitedSupport, noSupport) and validUntilTime for the date |
| Something that looks like it but is not | lifecycles in the metadata describes the stage at which the BOM was produced (design, build, operations and so on), not a component's support status | None |
| Where lifecycle facts can be added | The general-purpose properties list on each component | The two properties above, or an annotation on the package |
| Filled in by SBOM generators in practice | Rarely. A build tool knows what it packaged. It does not know the vendor's support dates | |
Sources: the CycloneDX 1.6 JSON schema and the SPDX 3.0.1 model pages for Artifact and SupportType.
Why the gap exists
An SBOM is produced from what a build or a scan can see: files, manifests, package metadata. End-of-life dates are not in any of those. They are published by vendors and projects on their own lifecycle pages, change over time, and differ by release line. A component entry for a framework at a given version is complete and correct as an SBOM entry even when that release line stopped receiving security fixes years ago. Nothing in the document marks the difference.
How to find end-of-life components in an SBOM
- Match by package URL, not by name. Names collide across ecosystems. A package URL (purl) says which ecosystem and which package, so the match is exact.
- Resolve the version to its release line. Lifecycle dates attach to a line such as 3.2 or 18, not to a patch build.
- Look up that line's dates and record them against the component: end-of-life date, status, and where the date came from.
- Report what could not be matched as not tracked. A guess in a compliance document is worse than a gap.
- Repeat on a schedule. An SBOM is a snapshot. A component that is supported on the day the SBOM is generated passes end of life later without the document changing.
Our SBOM end-of-life audit guide walks through this on real SBOMs. The endoflife.ai API accepts a CycloneDX or SPDX document and returns each component's lifecycle status; in enrich mode it writes the facts back into the document, as endoflife: properties on CycloneDX components or as annotations on SPDX packages, and leaves everything else untouched. The field list is published at sbom-enrichment.json, and the package URL map is at purl-map.json.
Frequently Asked Questions
Does an SBOM show end-of-life software?
Not on its own. An SBOM lists the components in a piece of software with their versions and identifiers. It does not, by default, record whether each component is still supported or when its support ends. That information has to be joined to the SBOM from a lifecycle data source.
Does CycloneDX have an end-of-life field?
No. The CycloneDX 1.6 component definition has no field for end of life, end of support or support status. The lifecycles entry in CycloneDX metadata describes the stage at which the BOM itself was produced, not the support status of a component. Lifecycle facts can be added to a component through the general-purpose properties list.
Does SPDX have an end-of-support field?
SPDX 3.0 has two optional properties on every artifact: supportLevel, whose values include endOfSupport, limitedSupport and noSupport, and validUntilTime, which carries the date. They are optional, and in practice SBOM generators rarely fill them, because a build tool does not know a vendor's support dates.
How do I find end-of-life components in an SBOM?
Join the SBOM to lifecycle data. Match each component by its package URL where it has one, resolve the version to its release line, and look up that line's end-of-life date. Components that cannot be matched should be reported as not tracked, not guessed.