Base-image CVE you can only fix by bumping the base in CI
When a scanner reports CVEs in OS packages (libssl, zlib, glibc), the fix lives in the base image, not your requirements or package.json. Rebuilding on a newer base tag, or moving to a slimmer base with fewer packages, is what clears them.
What this error means
The scan lists CVEs in system libraries you never installed directly, and no application dependency bump changes the result; only rebuilding on a patched base does.
myimage:latest (debian 12.4)
Total: 9 (HIGH: 6, CRITICAL: 3)
| libssl3 | CVE-2024-XXXX | CRITICAL | 3.0.11-1 | 3.0.13-1 |
| zlib1g | CVE-2023-YYYY | HIGH | 1.2.13 | 1.2.13-1 |
# all in the base OS layerCommon causes
CVEs originate in the base OS packages
The vulnerable packages come from the base image (debian, alpine, ubuntu), so remediation is a base change, not an application dependency change.
The base tag is pinned to an old patch level
A base pinned to debian:12.4 misses fixes shipped in 12.6; the scanner reports the older, vulnerable versions.
How to fix it
Bump to a patched base tag and rebuild
- Update the
FROMline to a newer patched tag. - Rebuild and rescan to confirm the OS CVEs clear.
- Where practical, run the base updater during the build too.
# Dockerfile - move to a patched base
FROM debian:12.6-slim
# ... or add an update layer
RUN apt-get update && apt-get upgrade -y && rm -rf /var/lib/apt/lists/*Switch to a slimmer base with fewer packages
A minimal or distroless base ships fewer OS packages, which shrinks the CVE surface you have to track.
FROM gcr.io/distroless/static-debian12How to prevent it
- Pin base images to patched tags and bump them regularly.
- Prefer slim/distroless bases to reduce the package surface.
- Automate base updates so OS CVEs do not accumulate.