Module 05 · Lesson 04
Image Vulnerability Scanning
Scan with Trivy, and decide what a CVE list actually obliges you to do.
- Scan an image and filter the result to something actionable.
- Explain why a CVE list is not a decision.
- Say why scanning at build time alone is insufficient.
Scanning
The unfiltered report for any non-trivial image is long, and most of it is low and medium
findings nobody will block a release over. Filtering to critical and high is what turns a
list into a decision. --exit-code 1 is what turns that decision into a pipeline
gate.
A CVE list is not a risk assessment
A finding means a vulnerable package version is present. It does not tell you whether your application ever calls the affected code path, whether the vulnerability is reachable in your configuration, or whether a fix exists yet.
| The report says | The question to ask |
|---|---|
| CRITICAL in a library | Does anything in this image actually call it? |
| No fix available | Can we mitigate around it, or do we accept and track it? |
| Hundreds of findings in the base | Should we be on a smaller base image instead? |
When a base image contributes three hundred findings, triaging them monthly is the expensive option. Moving to a distroless or minimal base removes most of them permanently, which is why footprint and scanning are the same conversation.
Scanning at build time is not enough
An image scanned clean in January and running in June has not been assessed against anything disclosed since. Continuous re-scanning of what is actually running is what closes that gap, and it is the part most pipelines leave out because the build-time scan feels like it covered it.
A scan reports 240 findings, 3 of them CRITICAL. What is the most useful first action?
Blocking on everything means the gate gets disabled within a month. Filtering makes it actionable, and the base image question addresses the volume at its source.
Your image scanned clean at build time four months ago and is still running. What is its vulnerability status?
The image is unchanged and the world is not. This is why registries and platforms re-scan continuously rather than trusting the build-time result.
Why is "CRITICAL finding present" not the same as "we are exploitable"?
Presence is not reachability. That is not a reason to ignore findings, it is the reason triage exists rather than a rule that any critical blocks everything.
Filter scans to critical and high and gate the pipeline with an exit code. Presence of a CVE is not proof of exposure, so triage rather than react. The cheapest fix for a long report is usually a smaller base image, and build-time scanning has to be paired with continuous re-scanning of what is running. Next: production notes.