When updates slip, check the support status of your language runtime before anything else. A library that lags is a risk, but a runtime past end of life stops receiving fixes entirely. Python and Node.js both publish support status per release, so the check takes minutes and gives you a hard date to plan against.
Why runtimes first
Libraries can often be replaced or patched by you. A runtime sits under everything. When a release reaches end of life, new vulnerabilities in it are not fixed on that line, and some libraries stop supporting it. It is the one deadline in your stack set by someone else.
What Python publishes
The Python developer guide lists each release with a status: feature, bugfix, security, or end of life. It describes support of about five years from release, with a bugfix phase first and a security only phase afterward. Dates shown in italics on the page are scheduled and can change. At the time of this review, the page listed Python 3.10 as end of life on 1 October 2026 and 3.9 on 31 October 2025, so a service still on either has no remaining upstream fixes. Check the page itself for current dates.
What Node.js publishes
The Node.js releases page states that major versions enter Current status for six months, that even numbered releases historically move to Active LTS, and that LTS typically guarantees critical bug fixes for a total of 30 months. It also says production applications should only use Active LTS or Maintenance LTS releases. Its table marks older lines as end of life. At review time, versions including 18 and 20 were labeled end of life there. Again, read the live page.
A tracking table you can copy
| Runtime | Version in use | Status today | End of life date | Owner | Action by |
|---|---|---|---|---|---|
| Python | fill in | fill in | from official page | team | date |
| Node.js | fill in | fill in | from official page | team | date |
| Other | fill in | fill in | from vendor | team | date |
How to keep it current
- Put each end of life date on a shared calendar with a six month warning.
- Re-check the official pages quarterly, since scheduled dates can move.
- Add the runtime version to your inventory, not just the libraries.
- Include base images and build images, which often carry their own runtime.
What to do if you are already past the date
- Treat it as an incident, with an owner and a date, not as backlog.
- Check whether you can move to the nearest supported release without a major library change.
- Reduce exposure meanwhile: restrict network access and watch for advisories.
- Ask whether commercial support exists for your line, if you truly cannot move.
Related dates people forget
Operating systems, databases and frameworks all have lifecycles. Add them to the same table so the whole stack is visible at once.
Safeguard's SBOM and dependency scanning lists direct and transitive packages with their versions, and reachability analysis shows which outdated or vulnerable ones your code actually calls. Autonomous remediation can open fix pull requests; it is off by default and every category starts on Manual. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look for the runtime and OS versions inside an image and consider their support dates.
Quick check
How early should we plan a runtime upgrade?
Start at least six months before end of life for large systems. Smaller services can move faster, but surprises are common.
Is an LTS release always safe to run?
It is supported for a defined period, not forever. Track its end date like any other.
Sources
Last reviewed: 19 October 2026.
