Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
How do you find end-of-life dependencies before they bite?
Updated
An end-of-life (EOL) dependency is a runtime, library, or OS package that no longer receives security fixes, whether or not a CVE has been published against it yet. Find them by checking your inventory against vendor lifecycle pages, using endoflife.date as a fast community-maintained index. Best-practice guidance, not legal advice.
Last verified 10 September 2026 against the endoflife.date API and product pages (a community-maintained, crowdsourced catalog, not a vendor or statutory authority), the Node.js release-schedule repository maintained by the Node.js project, CIS Critical Security Controls v8.1 Control 2, and NIST SP 800-40 Revision 4. Not legal advice. It does not scan YOUR dependency tree or determine whether any specific component is currently supported.
This is a workflow, not a scan of YOUR estate
Audience: an engineer or eng lead who has just realized a service is running a Node.js version, a language runtime, or a library that stopped receiving updates months ago, with no CVE yet on record for it. This page is not legal advice. It does not check YOUR dependency tree, and it does not determine whether any specific version in your environment is currently supported — that is a per-component, per-date fact you verify against the vendor's own lifecycle page.
'End of life' means the maintainer has stopped shipping security fixes for that version, full stop. It does not mean the software stopped working, and it very often means no CVE has been filed against it — because nobody is looking for new ones in software the maintainer already abandoned, and even if one is found, no patch is coming. Treating 'no known CVE' as 'no risk' for an EOL component inverts the actual risk: a scanner that reports zero findings against an EOL runtime is reporting the absence of a patch pipeline, not the absence of vulnerabilities.
- The what-is-an-SBOM guide on this site covers building the component inventory this workflow starts from. The detect-vulnerable-open-source-packages guide on this site covers matching that inventory against active advisory feeds — a separate, complementary check from the EOL check on this page. The accepted-risk guide on this site covers formally documenting a decision to keep running something EOL for a defined period.
- The vulnerability management pillar on this site is not published yet; naming it here is not a link.
endoflife.date is a community catalog, not a statute
endoflife.date is a community-maintained project that aggregates lifecycle data — release dates, active-support end dates, security-support end dates, and extended/commercial-support availability — across hundreds of products, exposed through a stable, documented v1 API (at endoflife.date/api/v1/) and per-product web pages. It is not a vendor, not a standards body, and not a legal or regulatory authority; it is a crowdsourced index of dates vendors and projects have themselves published elsewhere. Treat any single entry as a pointer to check, not as the authoritative record.
The authoritative source for any given component's lifecycle is the vendor or project itself — for example, the Node.js project's own release-schedule repository, which documents exactly when each major version enters Active LTS, moves to Maintenance LTS, and reaches end-of-life, and explicitly notes that 'dates are subject to change.' When endoflife.date and a vendor's own page disagree, or when a date is approaching, check the vendor's page directly before making a decision.
| Source | What it is | How to use it |
|---|---|---|
| endoflife.date (community catalog) | A crowdsourced, actively maintained aggregator with a documented v1 API and per-product pages, covering release, active-support, security-support, and extended-support dates for hundreds of products. | Fast, broad first pass across a mixed inventory (runtimes, OS distributions, frameworks, databases) in one query pattern. Not authoritative on its own for a decision that matters. |
| Vendor or project lifecycle page (e.g., the Node.js release-schedule repository) | The authoritative, primary source for that specific component's support dates, maintained by the people who actually decide the dates. | The source to confirm against before a go/no-go decision, and the source to cite in an accepted-risk record or an audit trail. |
Example workflow: finding EOL runtimes and libraries
This is an illustrative sequence, not a script for YOUR specific tooling. Adapt it to your inventory sources and CI pipeline.
- 1. Build or pull a current component inventory — an SBOM, a lockfile-derived dependency list, or an infrastructure inventory covering runtimes and OS base images. The what-is-an-SBOM guide on this site covers this step.
- 2. Cross-check each distinct runtime, language, and major library version against endoflife.date (via its API for automation, or its per-product page for a quick manual check) to get a fast first read on active-support and security-support end dates.
- 3. For anything already past, or within a defined warning window of, its security-support end date, confirm the exact date against the vendor's own lifecycle page — for Node.js, that is the project's release-schedule repository, not a mirror.
- 4. Classify each finding: still supported (no action needed beyond normal patch cadence); approaching EOL within your warning window (schedule an upgrade); already EOL (requires a decision — upgrade, or a documented, time-boxed risk acceptance, not silence).
- 5. Feed EOL findings into the same triage and ownership process as CVE-based findings, even when no CVE exists yet for the specific EOL version — an EOL runtime is a standing risk regardless of whether a scanner currently has anything to report against it.
- 6. Re-run the check on a defined cadence (for example, tied to your normal dependency-review or release cycle), because a component that was supported at last check can cross its EOL date silently between checks.
'No CVE yet' is not 'safe' — and 'unsupported' is a decision, not a status
Two distinct honest-reporting failures show up repeatedly in EOL tracking, and this page names both so neither gets waved away as pedantry.
| What gets said | Why it is wrong | What is actually true |
|---|---|---|
| 'It's fine, there's no CVE against this version.' | Absence of a published CVE against an abandoned component is frequently absence of anyone looking, not absence of flaws. Security researchers and maintainers alike deprioritize hunting for and disclosing issues in software nobody is patching. | 'No CVE yet' describes the state of public disclosure, not the state of the component's actual security. Treat an EOL component as elevated risk regardless of its current CVE count. |
| 'We're on an unsupported version, but it hasn't caused problems.' | Running unsupported software is not a neutral, no-decision default state. It is an accepted-risk position, whether or not anyone wrote it down. | If a component is past its security-support end date and still in production, that is a risk-acceptance decision that should have an owner, a justification, compensating controls if any, and a review or expiry date — the same governance a formally accepted CVE-based finding would get. The accepted-risk guide on this site covers building that exception record. |
Commercial extended support is a stopgap, not a reset of the clock
For some end-of-life runtimes, third-party vendors sell commercial extended-support contracts that continue shipping security patches after the original maintainer has stopped — for example, endoflife.date's own Node.js page notes that commercial support for some deprecated Node.js LTS lines is available through initiatives such as HeroDevs' Never-Ending Support and TuxCare's Endless Lifecycle Support. That is a legitimate stopgap for a component that cannot be upgraded immediately, but it does not change the underlying fact that the original vendor considers the version unsupported.
Treat a commercial extended-support contract as a documented, time-boxed compensating control inside an accepted-risk record — who is paying for it, what it covers, and when the plan is to actually upgrade — rather than as a reason to close the EOL finding as resolved. The accepted-risk guide on this site covers building that kind of exception record.
Legal requirement vs framework guidance vs vendor fact
Do not treat any of these as a legal mandate to upgrade by a specific date; none of them is one on its own. Last verified 10 September 2026. Not legal advice.
| Text or catalog | What it is | Who it binds |
|---|---|---|
| A vendor's own lifecycle page (e.g., Node.js release schedule) | A factual statement of when that vendor stops shipping security fixes for a given version. Not a regulation. | No one by force of law. It is simply the fact of what support the vendor is committing to provide, and after the stated date, will not provide. |
| endoflife.date | A community-maintained aggregation of vendor-published lifecycle facts. | No one. A convenience index to check, not an authority to cite in place of the vendor's own page. |
| CIS Critical Security Controls v8.1, Control 2 | Framework guidance: maintain a software inventory (Safeguard 2.1) and ensure only currently supported software is designated as authorized, reviewed at least monthly, with unsupported-but-necessary software requiring a documented exception (Safeguard 2.2). | No one by force of law directly. Widely adopted voluntarily, and referenced by other frameworks and by some regulatory guidance as a baseline control set. |
| NIST SP 800-40 Revision 4 | Planning guidance for enterprise patch management, including the expectation that unsupported software be identified and handled deliberately rather than left running by default. | No one by force of law directly. A reference framework, not a mandate with a specific day-count. |
Checklist
Not legal advice; this page does not run any of these steps for you.
- Do you have a current, queryable inventory of runtimes, languages, major libraries, and OS base images across every service — not just the ones someone remembers to check?
- Have you cross-checked that inventory against endoflife.date (or an equivalent) for a fast first read on security-support end dates?
- For anything flagged as approaching or past EOL, have you confirmed the exact date against the vendor's own lifecycle page, per CIS Control 2 Safeguard 2.2's expectation to verify authorized-software support status at least monthly?
- For anything already past its security-support end date, is there a documented decision — upgrade scheduled, or a formal, time-boxed risk acceptance with an owner and a review date — rather than silence?
- Is 'no CVE published against this version' explicitly not being treated as 'this version is safe' in your triage process?
- Is the EOL check re-run on a defined cadence, so a component crossing its EOL date between audits does not go unnoticed until the next annual review?
Common blind spots this workflow catches
The workflow above is generic on purpose. These are the specific places EOL components most often hide, based on how inventories typically get built.
- OS base images and container layers: a Dockerfile pinned to an old base-image tag can carry an EOL OS release long after the application code itself has moved on. Base-image scanning is a separate check from application-dependency scanning, and teams that only run the latter miss this entirely.
- Transitive runtime dependencies: a language runtime itself (not just its packages) can go EOL — for example, a specific Node.js major version reaching its security-support end date — while the application layer on top of it looks perfectly current.
- Forked or vendored code: a copy-pasted or vendored library, rather than a declared dependency, will not show up in a manifest- or lockfile-derived inventory at all, so an SBOM built purely from package manager metadata can miss it.
- Infrastructure and platform components: databases, message queues, load balancers, and CI/CD tooling versions are frequently tracked separately from application dependencies, if at all, and are a common place an EOL check never reaches.
- Long-lived branches and rarely deployed services: an internal tool or a rarely touched service can drift past its runtime's EOL date silently, because no active development work would otherwise surface the version in normal day-to-day work.
What to do now
This page does not scan YOUR estate. The list below is the practical sequence to start from.
- Pull or build a current inventory covering runtimes, languages, and major libraries, not just application-level dependencies — OS base images and container base layers are common blind spots.
- Run that inventory against endoflife.date for a fast, broad first pass, then confirm anything flagged against the vendor's own lifecycle page before acting on it.
- For each EOL finding, make an explicit decision and record it — upgrade, or a formal, time-boxed risk acceptance with a named owner — rather than letting 'we haven't gotten to it' stand in as the decision.
- Do not let 'no CVE yet' close out an EOL finding in your tracker; the absence of a published CVE against abandoned software is not evidence it is safe.
- Set a recurring cadence for this check, tied to your normal release or dependency-review cycle, so EOL dates crossed between audits get caught promptly.
Where this shows up in ShipReady Metrics
Signed-in app → Security → Findings ingests dependency data from connectors such as Dependabot, alongside code-scanning and first-party findings, giving the organization one inventory surface to spot stale or aging components. This product does not itself query endoflife.date or a vendor's lifecycle page, does not classify a specific version as EOL, and does not upgrade anything. A named human on the team confirms EOL status against the vendor's own source and owns the upgrade-or-accept decision.
This page does not document a public product demo path.
Primary sources (last verified 10 September 2026)
endoflife.date, a community-maintained lifecycle-data catalog and its documented v1 API (not a vendor or statutory authority). The Node.js project's own release-schedule repository (nodejs/Release on GitHub), the authoritative source for Node.js LTS and end-of-life dates. CIS Critical Security Controls v8.1, Control 2 (Inventory and Control of Software Assets), Safeguards 2.1 and 2.2. NIST Special Publication 800-40 Revision 4 (April 2022). Not legal advice. These are not a complete list of every component's own vendor lifecycle source, which this page cannot substitute for on a per-component basis.
The what-is-an-SBOM guide, the detect-vulnerable-open-source-packages guide, and the accepted-risk guide on this site are the closest related pages.
Frequently asked questions
Is this legal advice?
No. It is a best-practice checklist and workflow for finding end-of-life dependencies using endoflife.date as a community index and vendor lifecycle pages as the authoritative source, distilled against CIS Control 2 and NIST SP 800-40r4. It does not determine whether any specific component in your environment is currently supported. Confirm against the vendor's own page.
Is endoflife.date an authoritative or legal source?
No. It is a community-maintained catalog that aggregates lifecycle dates vendors and projects publish elsewhere. It is fast and broad for a first pass, but the vendor's own lifecycle page (for example, the Node.js project's release-schedule repository) is the authoritative source for that component's actual support dates, and is what to cite or confirm against before a decision that matters.
If there is no CVE against our unsupported version, are we safe?
No. Absence of a published CVE against an end-of-life component usually reflects that nobody is actively hunting for or disclosing issues in software the maintainer has stopped patching, not that the component has no flaws. Treat 'no CVE yet' as a statement about disclosure activity, not about actual risk.
Is running unsupported software automatically a compliance failure?
It depends on which framework and contract apply to you, which this page does not determine. But running unsupported software without a documented decision is treated, in practice, the same way an unmanaged accepted risk is treated: as a gap. CIS Control 2 Safeguard 2.2 expects unsupported-but-necessary software to carry a documented exception with mitigating controls, not silence.
How often should we re-check for EOL dependencies?
This page does not set a mandated cadence, because none of the cited sources states a universal one. Tying the check to your normal release or dependency-review cycle, at minimum, is common practice — a component that was supported last quarter can cross its EOL date silently before the next scheduled review.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.