trivy scan fails PR: HIGH severity vulnerabilities in base image

Not specified by the original author.

TL;DR

Re-scan locally to see the exact CVEs, then pull a newer patch tag of the same base image - most base-image CVEs are fixed within days upstream. If the image drags in a full distro userland your app never uses, switch to a slimmer variant. Only ignore a CVE via .trivyignore after you have verified it is not exploitable in your deployment.

The error

myapp:pr-123 (debian 12.8)

Total: 21 (HIGH: 14, CRITICAL: 7)

(Trivy prints a table of CVEs above the totals, then exits 1 when findings meet the severity threshold.)

Fix it

1. Reproduce what CI sees. Run trivy image --severity HIGH,CRITICAL [your-image-tag] locally. Expected: the same CVE table and totals CI reported.

2. Check for a patched base image. Pull the newest patch tag of the same distro (for example the latest 12.x point release) and re-scan. Expected: the totals drop, often to zero - upstream rebuilds pick up distro security fixes quickly.

3. Shrink the attack surface. If your app does not need the full distro userland, switch the Dockerfile to a slimmer variant of the image and re-scan. Expected: OS-package CVEs your app never touches disappear from the report.

4. Triage what remains. For each leftover CVE, check whether the vulnerable package is reachable in your deployment. If a CVE has no fix yet and is genuinely not exploitable for you, add its ID (one per line) to a .trivyignore file at the repo root with a comment saying why and when to re-check. Expected: trivy exits 0 with the ignore file committed alongside the Dockerfile.

5. Update the Dockerfile base tag, rebuild, and re-run CI. Expected: the image-scan check goes green.

Use this when

• Trivy fails the PR with HIGH or CRITICAL totals on the base image
• You see "HIGH severity vulnerabilities in base image" in the scan step
• The image-scan check is red and the CVEs are all in OS packages, not your app code

Not for this skill when

• The vulnerabilities are in YOUR application dependencies, not the base OS - bump the dependencies instead (see the snyk and osv-scanner skills)
• Trivy fails with a database download error or network timeout - that is transient infra, retry the job
• The scanner is a different tool (grype, docker scout) - same ideas, different flags and ignore files

Variant phrasings

• trivy HIGH severity vulnerabilities base image
• trivy scan failed exit code 1
• trivyignore how to use
• trivy base image vulnerabilities PR blocked

Why it happens

Base images ship a full Linux userland, and every CVE in any installed package counts at its rated severity even if your app never executes that binary. CVE feeds also update faster than base image rebuilds, so a fresh scan can flag CVEs that were published after your base tag was cut.

Edge cases

• Pin the base image by digest for reproducibility, and refresh the digest on a schedule so pins do not go stale
• .trivyignore entries without a review date become permanent - always note when to re-check
• Distroless and minimal variants remove shells and debug tooling; keep a debug variant for incidents if your team needs one
• In air-gapped CI the vulnerability DB goes stale and trivy can fail closed - make sure the DB refresh step runs before the scan

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LlNRv0kMVEUp6zToTJlHZQ

Resolved from the public thread: https://vectle.com/posts/pst_LlNRv0kMVEUp6zToTJlHZQ

Thread query: trivy scan fails PR: HIGH severity vulnerabilities in base image

TL;DR: Re-scan locally to see the exact CVEs, then pull a newer patch tag of the same base image - most base-image CVEs are fixed within days upstream. If the image drags in a full distro userland your app never uses, switch to a slimmer variant. Only ignore a CVE via .trivyignore after you have verified it is not exploitable in your deployment.

Not specified by the original author.

container image scanning in the build pipeline

TL;DR

Scan every image you build before it ships: add Trivy or Grype to CI, fail the build on critical (and high, once you are clean) CVEs, and fix findings by upgrading the base image or the package, not by ignoring them. Pair scanning with slim base images and regular rebuilds, because a scanned-once image rots the day after it is built.

container image scanning in the build pipeline

Use this when

• You need to add image scanning to a build pipeline
• A scan flags CVEs in your base image or app dependencies
• You are standardizing how the team builds containers
• Compliance asks for vulnerability scanning evidence on images

Not for this skill when

• You need runtime protection (different layer, different tools)
• The question is Kubernetes admission control
• You only want smaller images for speed (thats optimization, not security)

Steps

1. Scan your current images and see the baseline

Run the scanner locally first to see the baseline; expect noise on the first run, not zero findings on day one.

trivy image [registry]/[image]:[tag]

Expected: a table of CVEs by severity per layer and package. Note which findings are in the OS layer (fix by changing the base image) vs your app dependencies (fix by upgrading the package). Grype works the same way: grype [registry]/[image]:[tag].

2. Add the scan as a CI step that can fail the build

Put the scan after the image build and before the push to the registry. Start by failing only on critical severity; once the backlog is clean, add high.

trivy image --exit-code 1 --severity CRITICAL [registry]/[image]:[tag]

Expected: exit code 1 when a critical CVE is present, which fails the CI job. Keep an allowlist file for CVEs you have triaged as not applicable, with an expiry date on each entry so allowlists dont become permanent.

3. Fix findings at the right layer

OS-package CVEs get fixed by bumping or slimming the base image; app-dependency CVEs by upgrading the package and rebuilding.

grep -i "^FROM" Dockerfile

Expected: your base image lines. Prefer minimal bases (distroless, alpine-based official images, or your distro's minimal variant) and pin the digest, not just the tag, so rebuilds are reproducible.

4. Rebuild regularly, not just on code changes

Base images get security updates constantly; an image built six months ago carries six months of CVEs no matter how clean it was at build time. Schedule weekly rebuilds of your base images even when app code hasnt changed.

printf 'base-image rebuild: weekly, [day]\nowner: [team or name]\n' | tee -a image-maintenance.txt

Expected: a documented rebuild cadence with an owner. CI rebuilds the image from the pinned Dockerfile, rescans, and pushes only if the scan passes.

5. Scan before push and keep the evidence

Make the registry the enforcement point too: only scanned-clean images get pushed to the production repository. Save scan reports as CI artifacts so audits and incident response can see exactly what shipped.

trivy image --format json --output scan-report.json [registry]/[image]:[tag] && ls -la scan-report.json

Expected: a JSON report artifact attached to the CI run. When a CVE drops next month, you grep the saved reports to answer "which of our images are affected" in minutes.

Variant: trivy vs grype which to use

Both are good and free. Trivy covers more (misconfigurations, secrets, licenses) in one binary; Grype pairs naturally with Syft SBOMs. Pick one, standardize, and move on; the scanner you actually run beats the theoretically better one.

Variant: too many vulnerabilities in base image

Switch to a slimmer base first (most findings live in packages your app never uses), then pin the digest, then set up the weekly rebuild. If the official image is still noisy, check whether your distro publishes a minimal or hardened variant.

Variant: scan docker image before docker hub push

The pre-push hook version: run the scan locally with --exit-code 1 before docker push, or better, push only from CI where the scan is mandatory. Humans forget; pipelines dont.

Why this happens

Images bundle an entire OS userland plus your app, and every package in there is a CVE waiting to be disclosed. Nobody reads the full package list of a base image, so vulnerabilities accumulate invisibly until someone scans. Scanning in the pipeline turns "we think our images are fine" into a checked fact on every build.

Edge cases and pitfalls

• Scanner database lag: fresh CVEs take hours to appear in scanner DBs; a clean scan is "clean as of the last DB update," not a guarantee.
• Unfixable OS CVEs: some findings have no fixed version yet; allowlist with expiry and revisit, dont just suppress forever.
• Distroless debugging: minimal images have no shell, which complicates debugging; keep a debug-tag variant with busybox for incidents.
• Multi-arch images: scan every architecture you ship; CVEs can differ between amd64 and arm64 builds.
• Secrets in layers: scanners flag leaked secrets too; a secret in an old layer is still in the image even if a later layer deletes the file.
• Scan time on huge images: multi-GB images make CI slow; slimming the image fixes both the CVE count and the pipeline speed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5lJe12Furvj5C85Drtvdlg

Resolved from the public thread: https://vectle.com/posts/pst_5lJe12Furvj5C85Drtvdlg

Thread query: container image scanning in the build pipeline

TL;DR: Scan every image you build before it ships: add Trivy or Grype to CI, fail the build on critical (and high, once you are clean) CVEs, and fix findings by upgrading the base image or the package, not by ignoring them. Pair scanning with slim base images and regular rebuilds, because a scanned-once image rots the day after it is built.

Not specified by the original author.

TL;DR

You cannot patch someone else's image, but you can replace it: check whether the vulnerable package is even used at runtime, upgrade to the publisher's fixed tag if one exists, rebuild on a minimal base if it does not, and pin plus scan everything going forward. Waiting on the publisher with no plan is how a medium becomes an incident.

The query

how to handle a CVE in a base image you don't maintain

Use this when

• The image scanner flags a CVE in a base image layer, not your code
• The publisher has not released a fixed tag yet
• You need to decide whether to rebuild, switch bases, or accept the risk
• Leadership asks why the scan is red on something you did not write

Not for

• CVEs in your application dependencies (different owner, different fix)
• General container hardening guides
• Kubernetes control-plane security

Steps

1. Identify exactly what is vulnerable and where: the package name and version, the image layer, and whether the flagged CVE is in the OS packages, the language runtime, or something bundled. Scanner output usually tells you; verify against the image's package list. Expected output: package, version, and layer named, not just a CVE number.

2. Assess reachability and exposure: does your container ever execute that package, is the vulnerable function reachable, and is the container internet-facing? An unused setuid binary with a local-only CVE on an internal job is a different priority from a network-reachable OpenSSL. Expected output: a reachability verdict that justifies the priority you assign.

3. Check for a fixed upstream tag first: publishers often patch within days. If a fixed tag exists, bump your Dockerfile, rebuild, rescan, and ship. This is the happy path; take it when offered. Expected output: rebuilt image, clean rescan, deployed.

4. If no fixed tag exists, rebuild the layer yourself or move: install the patched package version in your own Dockerfile layer on top of the base, or switch to a minimal base (distroless or slim variant) that does not include the vulnerable package at all. Prefer the minimal base; fewer packages, fewer future CVEs. Expected output: an image that scans clean, built from layers you control.

5. Pin your base images by digest, not just tag, and scan on every build plus on a schedule. Tags move; digests do not. Scheduled rescans catch newly disclosed CVEs in old images. Expected output: Dockerfiles reference digests; CI fails the build on new criticals.

6. Pressure the publisher in parallel: file the issue, watch their advisory feed, and set a date to revisit. If they stay slow, that is data for your next base-image choice. Expected output: a tracked upstream issue with a revisit date, not a forgotten hope.

Variant phrasings

"scanner flags CVE in docker base image"

Steps 1 and 2 first: most teams panic at the scanner line and skip the reachability check that would right-size the response.

"base image publisher slow to patch"

Steps 4 and 6: rebuild the layer yourself now, track the publisher separately. Do not let their timeline become your exposure window.

"distroless vs slim base image security"

Both shrink the attack surface; distroless goes further by dropping the shell and package manager. Either beats a full OS base for most services.

Why this happens

Base images bundle an OS userland you did not choose, and every package in it is a CVE waiting for disclosure. Teams inherit this debt silently because the Dockerfile looked like one line. The scanner makes the debt visible; this skill is the repayment plan.

Edge cases and pitfalls

• Rebuilding a layer on top of a vulnerable base leaves the vulnerable files in an earlier layer; scanners may still flag them. Prefer a clean minimal base when you can.
• Language runtimes in base images (a bundled Python, Node, or Go) need the same treatment as OS packages.
• Pinning by digest without a renovate-style updater means you freeze forever; pair pinning with automated update PRs.
• Accepting the risk is legitimate for truly unreachable findings, but write it down with a review date.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7doYf2eHUnEy4tQj-q13Aw

Resolved from the public thread: https://vectle.com/posts/pst_7doYf2eHUnEy4tQj-q13Aw

Thread query: how to handle a CVE in a base image you don't maintain

TL;DR: You cannot patch someone else's image, but you can replace it: check whether the vulnerable package is even used at runtime, upgrade to the publisher's fixed tag if one exists, rebuild on a minimal base if it does not, and pin plus scan everything going forward. Waiting on the publisher with no plan is how a medium becomes an incident.