Debian's security team can stop supporting a package inside a release, and then it tags the package as end-of-life or removed in its tracker. No new fixes are tracked for it, so a scanner that depends on that data has nothing to report. A clean scan can mean the package is unsupported, not that it is safe.
What the tracker says
The Debian Security Tracker documentation describes the states a vulnerability entry can have. Several are relevant here.
- An issue can be marked unfixed, meaning no fix exists yet.
- An issue can be marked not-affected, with a note, when the package is not vulnerable.
- Some issues fall in a no-dsa state, which the documentation describes as issues that do not warrant a security advisory on their own, usually because severity is minor. It says these are not kept unfixed in general, but can still be fixed through a point update or alongside a fix for a more severe issue. Two sub-states exist, ignored and postponed.
- A state called unimportant covers problems that do not affect the Debian binary package, and, the documentation says, vulnerabilities in packages that are not covered by security support.
- And there is the end-of-life section.
On end-of-life, the documentation says that in rare cases, such as web browsers, security support for packages needs to be stopped before the end of the regular security maintenance life cycle. Packages that are no longer supported by the security team in an old or stable release are marked with an end-of-life tag. It shows an example of the marking, along with a removed marker for a package that has been taken out of the release.
Why this matters to image scanning
Scanners match installed packages against vulnerability data. For Debian, that data comes mainly from the tracker and from advisories. If a package is tagged end-of-life for your release, the team is no longer tracking its vulnerabilities for that release. New issues that affect it may never be recorded as fixed or unfixed, so they may never appear in your scan.
The result is a quiet failure. The report looks good, and the package may be the most exposed thing in the image. Web browser engines and similar large packages are the examples the documentation itself uses, and they are the kind of software that attracts frequent vulnerability reports.
How to check your image
- List the installed packages in the image.
- For each package that is large, network-facing or parses untrusted input, such as a browser engine or media library, look it up in the Debian Security Tracker for your release.
- Read the source package page and check for end-of-life, removed or no-dsa notes.
- Compare with your scanner's output for the same package.
- If the tracker shows an end-of-life tag, treat the package as unsupported regardless of scan results.
You can do this for the five or ten riskiest packages in an afternoon. You do not need to check every package.
What to do about an unsupported package
| Option | When it fits |
|---|---|
| Remove it from the image | Nothing needs it. This is the cleanest result |
| Replace it with a supported alternative | The function is needed and an alternative exists |
| Move to a newer release where it is supported | The base can be upgraded |
| Isolate it and limit exposure | You must keep it. Restrict the network and privileges |
| Record an exception with an expiry | Only as a time boxed bridge, with a named owner |
A multi-stage build or a minimal base often removes such packages without effort, because they came in with a general purpose image and are not needed at run time.
A worked example
A team runs an image built from a general purpose Debian base, with a media processing tool installed for an old feature. The scan shows no critical findings in the tool. A manual check of the tracker for that release shows the source package carries an end-of-life note. The team realizes the clean result reflects missing tracking. They find that the feature is used by one internal job, move that job to a separate small image that is not exposed, and remove the tool from the main image. The next scan is just as clean, but this time the result is true.
Questions for a vendor
- Does your report flag packages tagged end-of-life, removed or unsupported by the distribution?
- Do you surface the distribution's own notes, such as no-dsa and not-affected reasons?
- How do you tell me that a clean result may reflect lack of tracking?
- Can I get a list of installed packages with the distribution's support status?
A tool that can say "this package is unsupported in this release" is giving you something much more useful than a clean list.
Common mistakes
- Reading a clean report as a safe package.
- Checking only the base image's end-of-life date, not individual packages.
- Keeping a general purpose base for a service that needs ten packages.
- Letting an exception for an unsupported package run without an end date.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for where a finding carries context beyond severity. A support status is the kind of context a package needs before you trust a clean result.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning plus policies, which you can use to record exceptions with an expiry and review them. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Does a clean scan prove a Debian package is safe?
No. If the package has no security support in your release, new issues may not be tracked, so the scan has nothing to show.
What does the end-of-life tag mean in the Debian tracker?
It marks a package that the security team no longer supports in an old or stable release, usually because support had to stop early, as with web browsers.
What is the cleanest fix for an unsupported package in an image?
Remove it if nothing needs it. If you need the function, replace it with a supported alternative or move to a release where it is supported.
Sources
Last reviewed: 19 October 2026.
