Container Security Scanning

The plain-language idea

An image scanner (Trivy, Grype, Docker Scout, or a cloud registry's built-in scanner like ECR's) inspects an image's layers and produces a list of every OS package and language dependency it contains, then cross-references that list against public vulnerability databases (the CVE — Common Vulnerabilities and Exposures — feed and similar sources). The output is a report: which packages have known, disclosed vulnerabilities, and how severe each one is.

The most common way this gets used is as a CI gate: a build step runs the scan and fails the pipeline if anything at or above a chosen severity threshold (critical, or critical + high) turns up. This catches a real, common category of risk before it ever reaches production — a base image with an outdated OpenSSL, a language dependency with a known remote-code-execution bug — without requiring anyone to manually track disclosures themselves.

The part that's easy to miss: a scan result is a snapshot of the vulnerability databases at the moment the scan ran, not a permanent property of the image. An image that passed a clean scan on Monday can fail the identical scan on Friday, with the exact same bytes, the exact same layers, zero code changes — because a new CVE affecting one of its packages got disclosed on Wednesday. The image didn't get worse. The world's knowledge of it did.

See it in a real thing: a scan-gated CI step

trivy image --severity CRITICAL,HIGH --exit-code 1 myapp:latest

--exit-code 1 is what turns this from an informational report into an actual gate — a nonzero exit fails the CI job, blocking the build from being pushed or deployed. This is the same shape as any other CI quality gate (tests, lint, type-check): a command that either passes silently or fails loudly enough to stop the pipeline.

What people usually miss

Watch out

• A clean scan today is not a permanent guarantee. New CVEs are disclosed constantly against existing, unchanged software — scheduled re-scanning of already-built (even already-deployed) images is what a push-only CI gate misses entirely.
• Severity thresholds are a real tradeoff, not a formality. Gating on every single finding (including low-severity, often-unexploitable ones) tends to produce so much noise that teams start ignoring the scanner altogether — a threshold tuned to critical/high, with a documented process for triaging the rest, is usually the more sustainable policy than an all-or-nothing gate.
• A "no fix available" finding is a different problem than a "fix available, just not applied" finding. The first needs a mitigation or risk acceptance decision; the second is usually just an outdated base image or dependency pin, and rebuilding against a newer version resolves it directly — scanners typically distinguish these, and treating them the same wastes effort.
• Scanning the final image misses build-time-only exposure. A vulnerable tool used only during the build (and not present in a properly multi-staged final image, from the earlier lesson in this track) won't show up in a scan of the shipped image at all — which is one more reason a lean, multi-stage final image is a security property, not just a size optimization.

Why this matters in interviews

"How do you make sure known vulnerabilities don't reach production?" is a standard security-process question, and the strong answer covers both halves: a CI gate on push (catching new vulnerabilities in new code), and scheduled re-scanning of what's already deployed (catching newly-disclosed vulnerabilities in code that hasn't changed at all). Naming only the first half is the most common gap — it sounds complete but leaves every already-deployed image permanently unmonitored.