To find end-of-life components in an SBOM, list each component and version, map each to a product and release cycle, then compare that cycle to a support calendar and flag any past its end date. An SBOM gives you the inventory. The calendar comes from a separate source.
What an SBOM does and does not hold
An SBOM, in formats such as CycloneDX and SPDX, is an inventory of software components with their versions and relationships. CycloneDX describes it as covering first party and third party libraries with versions and hierarchy.
It does not carry lifecycle dates. Whether node 20.11.0 is supported depends on facts that live outside the file. So you join two datasets: your components and a calendar.
Step by step
- Generate an SBOM that includes runtimes and operating system packages, not just application libraries. Scan the built artifact or image.
- Normalise names. A component may appear as
node,nodejsor a purl such aspkg:generic/node. Pick one name per product. - Reduce versions to the release cycle that vendors use.
3.9.25becomes cycle3.9.20.20.2becomes20. - Look up the end date for each cycle. The endoflife.date site provides a free JSON API with one document per product.
- Flag items with an end date in the past, and a second group within 90 days.
- Add the owner and the service name, so each flag has someone to act on it.
A short script outline
curl -s https://endoflife.date/api/python.json |
python3 -c "import sys,json; [print(r['cycle'], r['eol']) for r in json.load(sys.stdin)[:8]]"
That prints each Python cycle with its end date. Repeat per product, then compare against dates from your SBOM. Keep the lookup output in a file so reviews are repeatable.
Where this approach falls short
| Gap | Why it happens | What to do |
|---|---|---|
| Libraries with no formal calendar | Most packages have no EOL date | Check maintenance signals instead |
| Vendor patched builds | A distro may backport fixes to an older version | Check the vendor's advisory page |
| Bundled copies | A jar or binary may embed another component | Scan inside archives |
| Wrong cycle mapping | Names and versions vary | Review the unmatched list by hand |
Treat the calendar as a pointer, not proof. Third party summaries can differ from vendor pages. When we compared the Node.js release page with a summary site, the exact day for Node.js 20 differed. Both marked it ended. Confirm the date on the vendor page for anything you will escalate.
Try it yourself
Open the demo and look at how each component and its version appears in the inventory, since that is the list you would compare against a calendar.
Click through it at your own pace, or open it full screen.
Quick check
Can I get EOL data from the SBOM file itself?
No. Lifecycle dates are not part of standard SBOM fields. You join the SBOM to a calendar.
How often should I rerun the check?
On every build for new findings, and on a schedule such as weekly, since support dates are revised.
Where Safeguard fits
Safeguard's SBOM and dependency scanning produces the component inventory, and you can run the free scan to see the list for one repository.
Sources
Last reviewed: 19 October 2026.
