image-scanning

Image Scanning

A scanner that reports everything is indistinguishable from one that reports nothing — teams stop reading a 400-line CVE list after the first week. The job of scanning is not to find every issue, it's to find the ones worth someone's attention and force a decision on them before the image ships.

A finding without a decision (fix, accept, or block) is just noise with a CVE number attached.

1. Scan at build time, not just at rest

A scan that runs only against images already sitting in the registry catches problems after they've potentially been deployed. Scan in the CI pipeline immediately after build, before push, so a critical finding blocks promotion rather than triggering a retroactive scramble. Also re-scan images already in the registry periodically — a base image with zero known CVEs today can have a new one disclosed next week against the same digest, so freshness at build time is not sufficient on its own.

Done when: every image is scanned before it is pushed to a registry other images pull from.

2. Gate on severity and exploitability, not raw CVE count

Blocking a deploy on every CVE, including ones with no known exploit and no reachable code path, trains engineers to route around the scanner rather than fix things. Set a gate policy by severity (block critical and high with a known fix available, warn on medium, log low) and by whether the vulnerable package is actually reachable at runtime — a CVE in an unused transitive dependency is a different risk than one in your entry point.

Severity	Fix available	Action
Critical/High	Yes	Block the build
Critical/High	No	Warn, track, time-box a decision
Medium/Low	Either	Log, review on a cadence

Done when: the pipeline's block/warn behavior matches a written policy, not an ad hoc threshold someone picked once.

3. Distinguish fixable from noise before triaging

A finding with no available patched version is not actionable today no matter how severe it is — flagging it the same way as a one-line dependency bump wastes triage time. Sort findings by "upgrade available" first; those are cheap wins. For the rest, check whether the vulnerable code path is reachable at all — many scanners can filter to only what's actually imported or invoked, cutting a long CVE list down to the handful that matter. Suppress the remainder with a documented, expiring exception, not a silent ignore rule that nobody revisits.