Base image or your layers? Finding which Dockerfile step introduced a CVE
Short answer
Each image layer is a build step. Mapping every vulnerable package to the first layer that contains its files shows whether it came from the base image (rebuild on a newer base) or from your own RUN / COPY instructions (edit your Dockerfile).
| Layer | Build step | Owner | Fix |
|---|---|---|---|
| 1 | FROM debian:trixie | base publisher | newer base tag |
| 2 | apt-get install … build tools | base publisher | a -slim variant |
| 5 | RUN pip install -r requirements.txt | you | bump the dependency |
| 6 | COPY app/ | you | rebuild |
Measured on python:latest: 81 of its 109 findings rated low or above come from one
apt-get install step in the base image.
Two fix plans
- 01Base layersrebuild on a newer or slimmer base
- 02Your layerschange the Dockerfile step
83 % of security leaders name outdated base images as the root cause of their latest container vulnerabilities. Knowing the split ends the argument over who fixes what.
See where your CVEs come from →
Questions
How is the base image detected?
By matching the image's first layers to the longest known chain of layers of another public image.
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
- "No fix available": what to do about unfixable container CVEs
- EU Cyber Resilience Act for container images: SBOM, VEX and 24-hour reporting