Blocking Vulnerable Images Before They Ship

Scanning after you ship is scanning too late

A lot of teams run vulnerability scans on a schedule: a nightly job emails a report, someone skims it, and known-bad images keep running until the next maintenance window. The scan is real, but it happens after the vulnerable image is already in production. By then the fix is an incident, not a code review comment.

The better place to catch a vulnerable dependency is at the moment you deploy, before the container starts taking traffic.

Scanning the image you are about to run

InfraPilot scans container images with Trivy, which checks OS packages and application dependencies against known CVE databases. The scan runs against the exact image a deploy produced, so you are looking at what will actually run, not an approximation from a manifest.

On its own, a scan is just information. What turns it into a control is a gate.

Deploy gates that block a bad build

A deploy gate runs during the build and can stop the deploy. You can run two kinds together:

• CVE gate. Fail the deploy if the image contains vulnerabilities at or above a severity you choose.
• SAST gate. Run static analysis on the code and fail on findings that cross your threshold.

A failing gate blocks the deploy the same way a failing test would. The vulnerable image never reaches production, and the person deploying finds out in the build output instead of in an alert three weeks later.

Picking a threshold you can live with

Set the bar too high and every deploy fails on some low-severity issue in a base image nobody can fix today. Set it too low and the gate is decorative. A practical starting point is to block on critical and high severity, and to record but not block medium and low. As you clean up your base images, you can tighten it. The goal is a gate that fails only when a human should genuinely stop and look.

SBOM and accepted risk

Two things make the gate livable in the real world. First, an SBOM: InfraPilot can produce a software bill of materials (SPDX or CycloneDX) for an image, so when a new CVE lands you can answer whether you are affected by searching, not by rebuilding everything. Second, an accepted-risk path: sometimes a flagged CVE is not exploitable in your context, or the fix is not available yet. Being able to acknowledge a specific finding, with a note and an audit record, keeps the gate meaningful instead of teaching everyone to ignore it. A gate that is always red gets bypassed; a gate that is red only when it matters gets respected.