Tools for Tracking End-of-Life Software Across an Organization

The short answer

To identify unsupported software across an organization you need three things: an inventory of what runs, from SBOMs, a CMDB or cloud APIs; a source of lifecycle dates, such as endoflife.date, which tracks 481 products through a free API, or vendor lifecycle pages; and something that matches the two and alerts. xeol matches SBOMs and images against end-of-life data. Trivy and Grype flag end-of-life operating system distributions in container images. AWS sends planned lifecycle events for managed services such as EKS. For infrastructure software, OSSeva's EOL tracker lists end-of-life dates and patch status by version.

No one tool covers every layer. Vulnerability scanners mostly report CVEs, not support status, and the components most often left behind, such as databases, brokers and language runtimes, are the ones they are least likely to flag.

What each tool actually reports

Checked against each project's documentation or source on 6 October 2026. "End-of-life detection" means the tool itself reports that a component is past end of life, not that it can store data you add.

Lifecycle data: endoflife.date and the EOL tracker

endoflife.date is a community-maintained, MIT-licensed collection of lifecycle dates with a JSON API. Version 1 of the API returns one release cycle per call:

curl -s https://endoflife.date/api/v1/products/postgresql/releases/13 \
  | jq '.result | {name, isEol, eolFrom, latest: .latest.name}'
# {"name": "13", "isEol": true, "eolFrom": "2025-11-13", "latest": "13.23"}

Other endpoints return a whole product (/api/v1/products/{product}), its latest release, or products by category or tag. The usual pattern is a scheduled job that reads your inventory, looks up each product and version, and opens a ticket when isEol is true or eolFrom is less than six months away.

Two cautions. endoflife.date records the upstream project's dates, and extended support sold by vendors or cloud providers is a separate question. And not every product is there, so record a source for anything you add by hand. OSSeva's end-of-life charts are built on the same API for the open source infrastructure we support, with dates we have checked against the vendor where the feed disagreed. The EOL tracker adds which lines OSSeva still patches, and each version page, such as PostgreSQL 14 end of life, gives the date, its source and the upgrade path.

Scanners that flag end-of-life components

xeol

xeol is the only tool in this list built specifically to find end-of-life software. It scans container images, directories and SBOMs in Syft, SPDX or CycloneDX format, matches packages against its own end-of-life database, and can fail a pipeline:

syft registry.example.com/app:1.4 -o cyclonedx-json > sbom.json
xeol sbom:./sbom.json --fail-on-eol-found

Its README says the database is not a complete list of end-of-life packages and that it matches standard end dates only, not extended support. The project's most recent release was v0.10.8 in March 2025. By default xeol refuses to run on a local database more than five days old, so confirm in a test run that its database is still being refreshed before you depend on it.

Trivy

Trivy knows the end-of-life dates of the operating system distributions it scans. When an image is built on one past end of life, it prints a warning that the OS version is no longer supported by the distribution, marks EOSL in its JSON output, and with --exit-on-eol fails the scan:

trivy image --exit-on-eol 1 registry.example.com/app:1.4

This matters because an end-of-life base image can scan clean simply because no one publishes advisories for it any more. Trivy does not report end-of-life language runtimes or application packages.

Grype and Syft

Since v0.106.0, released in January 2026, Grype warns when packages come from an end-of-life distribution and adds a distro-eol alert to its JSON output. The warning is on by default (alerts.enable-eol-distro-warnings), but --fail-on accepts only severities, so failing a build on it needs a check on the JSON. Syft generates SBOMs and is usually the inventory step in front of Grype or xeol.

Dependency-Track

OWASP Dependency-Track is a good home for a portfolio of SBOMs and their vulnerabilities, but it has no built-in end-of-life detection in version 4 or in 5.0, which became generally available in June 2026. Adding end-of-life and end-of-support data is an open feature request on the 5.x milestone. Until then, run end-of-life checks alongside it and record the results with the same component identities.

Cloud provider notices

For services the cloud provider runs, the provider is the authoritative source. On AWS:

• AWS Health planned lifecycle events cover changes such as Amazon EKS Kubernetes version end of support and Amazon RDS for MySQL engine version end of support. AWS aims for at least 180 days' notice for major versions and 90 for minor, where possible, and lists affected resources as pending until they are resolved. Reading these through the AWS Health API needs a Business Support+, Enterprise Support or Unified Operations plan.
• Amazon EKS keeps each Kubernetes version in standard support for 14 months and extended support for 12 more, posts a notice in the AWS Health Dashboard about 12 months after release, and its cluster upgrade insights, refreshed every 24 hours, flag issues that would block an upgrade.
• Amazon RDS enrols a database in RDS Extended Support automatically when its engine version passes the end of standard support, for up to three years and at an extra charge. The RDS Extended Support cost breakdown covers the PostgreSQL dates.

These notices stop at the managed service boundary. PostgreSQL on an EC2 instance, a broker in a Kubernetes pod or a runtime inside your image gets no lifecycle notice from AWS.

Inventory: CMDB and asset management tools

A CMDB, IT asset management platform or endpoint management tool is usually the inventory for servers, desktops and commercial software, and many such products include lifecycle data for operating systems and major vendor software. Check three things before you rely on one for open source: whether it records the version line of software inside containers and Kubernetes clusters, not only hosts; whether its lifecycle catalogue includes the open source components you run, such as RabbitMQ, Kafka or Spring; and whether it can export end-of-life findings with dates and sources. Where it cannot, feed it from SBOMs and endoflife.date rather than maintaining a second spreadsheet.

A workable setup

1. Generate SBOMs for every image and build with Syft or your build tooling, and keep them per release.
2. Scan for end-of-life components in CI: trivy image --exit-on-eol 1 for base images, xeol or a script against endoflife.date for packages and runtimes.
3. Check infrastructure by hand once a quarter against the EOL tracker or the vendor's own lifecycle page: databases, brokers, coordination services and runtimes are where SBOM matching is weakest.
4. Subscribe to provider notices for managed services, through AWS Health and its equivalents.
5. Record a decision for every finding: upgrade by a date, buy extended support, or accept the risk with compensating controls and a named owner.

Our SBOM and end-of-life components article explains why inventories miss the runtime layer, and the EOL exposure research shows what accumulates on versions left unpatched.

Evidence for auditors

Auditors rarely ask which tool you use. They ask for a list of components past upstream end of life, how you found them, and what you decided for each one. End-of-life reporting that survives an audit usually contains:

• An end-of-life inventory with product, version, location, the end-of-life date and the source of that date, dated when it was produced.
• The method: which SBOMs, scanners and data sources produced it, and how often it runs, so the auditor can see it is repeatable.
• A decision per item: an upgrade with a target date, an extended support contract that names the versions covered, or a risk acceptance with compensating controls.
• Proof the decision held: change records for upgrades, and for supported end-of-life versions, the patch releases applied since end of life.

The open source audit evidence checklist maps these artefacts to PCI DSS, NIST SP 800-53, ISO/IEC 27001 and SOC 2 clauses, and SOC 2 findings on end-of-life software covers how auditors treat them. Where a version cannot move yet, extended support turns an open finding into a supported component with a patch record.

Frequently asked questions

What are the best tools for tracking unsupported software?

A combination: endoflife.date for lifecycle dates, Syft or your build system for SBOMs, xeol for matching packages to end-of-life data, Trivy or Grype for end-of-life base images, and your cloud provider's lifecycle notices for managed services. OSSeva's EOL tracker covers infrastructure software such as brokers, databases and Spring.

How do I identify unsupported software across an organization?

Build an inventory from SBOMs, a CMDB and cloud APIs; match each product and version against lifecycle data from endoflife.date or the vendor; and check databases, brokers and runtimes by hand, because SBOM-based matching misses them most often. Re-run the match on a schedule, since a version that is supported today can reach end of life next month.

Which software inventory tools have end-of-life alerts?

Among open source tools, xeol reports end-of-life packages and can fail a build, Trivy can fail a scan on an end-of-life OS, and Grype warns about end-of-life distributions. Dependency-Track does not detect end of life yet. Many commercial CMDB and asset tools include lifecycle data; check that it covers the open source components you run.

Where can I track end-of-life dates for open source infrastructure?

endoflife.date for a broad catalogue with an API, each project's own release policy page, and OSSeva's EOL charts and EOL tracker for RabbitMQ, Kafka, PostgreSQL, Spring, Tomcat, Node.js, .NET and other infrastructure software, with sources cited for every date.

What should end-of-life software reporting for auditors include?

A dated list of components past end of life with the source of each date, the method used to produce it, a decision for each item with an owner and a date, and evidence that the decision was carried out. The audit evidence checklist covers each artefact.

Do vulnerability scanners detect end-of-life software?

Mostly not. Trivy and Grype flag end-of-life operating system distributions, but not end-of-life databases, brokers or language runtimes. A clean scan of an end-of-life component can simply mean no one publishes advisories for it any more.