"No fix available": what to do about unfixable container CVEs
Short answer
When a scanner shows CVEs with no fix, the distribution has not shipped a patched package (often marked no-dsa, postponed or ignored). Upgrading cannot help. Switch to a slimmer or hardened base that does not contain those packages, watch the image so it is rebuilt when fixes land, and document non-exploitable ones with VEX.
python:latest483
3.12-slim32
Three ways out
- 01Rebaseslimmer base, measured
- 02Watchrebuilt when fixes ship
- 03VEXnot loaded → not affected
Where the CVEs come from
OCImend traces each vulnerable package to the layer and build step that installed it. In python:latest
most findings come from a single apt-get install of build tools in the base image, not from Python itself,
which is why the -slim variant drops them.
Questions
What does Debian no-dsa mean?
The Debian security team judged the issue minor enough not to issue a security advisory; it may be fixed in a point release, or never.
Can I ignore unfixable CVEs?
Record why: packages not loaded by the app can be marked not affected in an OpenVEX document, which scanners and auditors can read.
Sources
More guides
- How to build FIPS-enabled containers (FIPS 140-3)
- OCImend FIPS containers: what you get and how they are verified
- How to fix container image CVEs automatically
- A container vulnerability pipeline that ends in a fix, not a report
- Base image or your layers? Finding which Dockerfile step introduced a CVE
- EU Cyber Resilience Act for container images: SBOM, VEX and 24-hour reporting