Image and dependency scanning

Two scanners, one inventory problem

A container image is a stack of two software supply chains, and you have to scan both. The OS layer is whatever your base image ships — glibc, openssl, zlib, hundreds of Debian or Alpine packages, most of which you never invoke. The application layer is your direct and transitive dependencies: the package-lock.json, go.sum, or requirements.txt that pulls in code you actually call. Both are scanned the same way and it’s worth being precise about how, because the mechanism explains the noise.

A scanner does not analyze your code for bugs. It builds a bill of materials — every package and exact version present — then joins that list against a vulnerability database (the NVD plus distro-specific feeds like Debian Security Tracker, GitHub Advisories, and the language ecosystems). The output is set arithmetic: installed_packages ∩ known_vulnerable_versions. That join is why a fresh node:20 image reports dozens of CVEs on day one — you installed an OS with known-vulnerable packages, and the scanner is reporting a fact, not a judgment. This is what OWASP’s DevSecOps guideline calls Software Composition Analysis (SCA), and it’s the cheapest high-value control you can add to a pipeline. It’s also why turning it on feels like being buried.

Why the wall of red is mostly noise

The set-arithmetic that makes scanning cheap is exactly what makes it noisy. A CVE in installed_packages ∩ known_vulnerable_versions tells you the vulnerable code is present. It does not tell you that the code is loaded, called, or reachable with attacker-controlled input. That gap is the source of nearly all the noise, and it has three distinct shapes a senior learns to recognize.

The three shapes of noise:

• Unreachable code. A CVE in glibc’s NIS resolver, in a font-parsing path of an image library you only use for thumbnails, or in a CLI subcommand your service never invokes. The vulnerable bytes are on disk; the vulnerable path is dead. Reachability analysis — does any call chain from your entrypoint reach the vulnerable function? — is the single biggest noise reducer, and the newest scanners (and tools like the VEX standard, Vulnerability Exploitability eXchange) exist specifically to record “present but not affected.”
• No fix yet (or a won't-fix). Distros routinely mark low-severity CVEs won't-fix because the fix isn’t worth the regression risk. Failing your build on a CVE with no upstream patch just means the build can never go green — you’ve built a ratchet that only tightens.
• Severity ≠ exploitability in context. A CVSS 9.8 in a dev-only dependency that’s tree-shaken out of the production bundle is not a 9.8 for you. CVSS scores the vulnerability in the abstract; only you know whether it’s exposed.

Where the gate goes, and what it gates on

Knowing the noise shapes lets you place the gate correctly. The wrong design — the one everyone reaches for first — is “fail the build if any CRITICAL exists.” It produces three failure modes in week one: builds that can’t go green (CVEs with no fix), alert fatigue (so the one real RCE scrolls past with the 40 unreachable ones), and the inevitable --exit-code 0 that silently disables the whole control. A scanner that’s been quietly neutered is worse than no scanner, because it lets you believe you’re covered.

The senior gate composes three predicates: severity AND fix-available AND not-suppressed. Fail the build only on a fixable, high-or-critical, unsuppressed finding — because that’s the set where the build failing actually changes someone’s behavior (bump the version). Everything else gets a different workflow: track it, suppress it with a recorded reason, or accept it. The goal is a gate where a red build always means “do this specific thing,” never “go acknowledge 40 things you can’t act on.”

Cutting the input, not just filtering the output

The cheapest way to win the triage game is to have less to triage. Two structural moves shrink the input before any filtering:

• Minimal base images. A node:20 image is ~1.1 GB and carries the entire Debian userland — a shell, apt, dozens of libraries your app never touches, each a potential CVE. A distroless or alpine image carries only the runtime. Swapping node:20 for gcr.io/distroless/nodejs20 routinely drops OS-layer findings from ~150 to single digits, because you deleted the packages, not just suppressed their CVEs. Fewer packages is the only fix that removes the vulnerable code itself rather than arguing about its reachability.
• Pin and update deliberately. Lockfiles make scans reproducible (you scan exactly what ships), and a steady dependency-update cadence (Dependabot/Renovate) means you’re applying small patches continuously instead of facing a 200-CVE cliff at the next forced major upgrade.