Usually not by default. A dependency scanner reads manifests and lockfiles, which list libraries, not the interpreter or JDK that runs them. The runtime appears only if the scanner also reads a container image, an installed environment or a pinned version file. Check this explicitly, because a clean report can still sit on an unsupported runtime.
Why the runtime falls outside a manifest scan
A package.json or requirements.txt names the libraries you chose. Nothing in those files says which Node, Python or Java build will execute them, except an optional engines field or a version file. A scanner that only parses those files has no input about the runtime, so it cannot report on it.
This creates a quiet false negative. Your library list can be spotless while the runtime itself has reached end of life and no longer receives fixes.
Where the runtime version actually lives
| Place | What it tells you | Scanner needs to read |
|---|---|---|
| Dockerfile FROM line | Base image and tag | Image or Dockerfile |
| CI config | Version used to build | Pipeline files |
| Version pin file such as .nvmrc or .python-version | Developer intent | That file |
| Running host or container | What really executes | Image or host inventory |
These four can disagree. Developers may pin one version while production runs another. The one that matters for risk is the last row.
How to check support status
Support windows are published by the projects. The Node.js releases page explains that production applications should only use Active LTS or Maintenance LTS releases, and it lists which versions are in which phase. The Python Developer's Guide has a status of Python versions page that shows which branches still get security fixes. Use those pages as the source of truth rather than a scanner's silence.
A short routine
- List every runtime your services use: Node, Python, JDK, Ruby, PHP, .NET.
- Record the exact version actually running in production, from the image or host, not from a pin file.
- Compare each against the project's published support page.
- Put any runtime past its support window on the same remediation list as a vulnerable library.
- Ask your scanner vendor or review the docs to confirm whether runtimes inside images are reported.
If a runtime is inside a container image, an image scan is the usual place it shows up, because the interpreter is installed as a package or binary in the image. For related reading, see does the scanner cover containers and base images and a clean scan usually means the scanner did not look.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which items are libraries and notice that none of them is the interpreter.
Safeguard offers SBOM and dependency scanning, plus a free scan at gold.safeguard.sh/scan. Whatever tool you use, confirm in a test what it reports about runtimes.
Quick check
Is an end of life runtime a vulnerability?
It is a risk rather than a single vulnerability. Once a runtime stops receiving fixes, newly found flaws stay open, so treat it as a finding to schedule.
Does pinning a version in a file prove what runs in production?
No. A pin file shows intent. Read the version from the built image or running host to know what executes.
Sources
Last reviewed: 19 October 2026.
