Container Image Scanning and the SBOM

Software composition analysis for containers answers a deceptively simple question: what is actually inside this image, and which of those components have known vulnerabilities? The image you built from a few lines of Dockerfile contains hundreds of packages — your dependencies, their dependencies, the OS libraries underneath. Scanning enumerates them and cross-references public vulnerability data. The SBOM is the durable record of that enumeration, and it is what lets you answer the next zero-day without rebuilding anything.

An image scanner works by reading the image's layers, identifying installed packages from the OS package database and language manifests (package-lock.json, go.sum, requirements.txt), and matching each against vulnerability feeds — the NVD, distro security trackers, and language advisory databases. Tools like Trivy, Grype, Clair and Docker Scout differ in packaging and integrations but do fundamentally this.

What a scan can and cannot tell you

A scan is a matching exercise, and that shapes its limits. It reports known vulnerabilities in identifiable components. It will miss a vulnerable library vendored under a renamed path, a bug with no CVE yet, and a flaw in your own first-party code. And it over-reports: a CVE in a package that is present but never invoked is still a finding, which is why raw scan counts are a poor metric and reachability context matters.

The SBOM: an ingredients label for software

A Software Bill of Materials is a machine-readable inventory of every component in a build — names, versions, and often licenses and cryptographic hashes. Two formats dominate: SPDX (a Linux Foundation / ISO standard) and CycloneDX (an OWASP project). Either can be generated at build time by tools such as Syft and attached to the image as an attestation.

The SBOM's value is temporal. When a Log4Shell-class vulnerability drops, the question every organisation scrambles to answer is 'are we affected, and where?' If you generated and stored an SBOM for every image, that becomes a query against inventory you already hold — minutes, not a week of frantic grepping through build systems. Without one, you are re-deriving your dependency graph under pressure, for images that may no longer build.

• Scan in CI, and gate on severity. Fail builds on new critical/high findings with a fix available; warn on the rest. A blanket 'zero CVEs' gate just trains teams to disable it.
• Scan the registry continuously, not just at build. An image clean on Monday is vulnerable on Friday when a new CVE lands against a package it already contains. Rescan stored images against fresh feeds.
• Generate and store an SBOM per image. Attach it as an attestation so it travels with the artifact and can be verified later.
• Prioritise with reachability and exploitability. Use EPSS and CISA KEV plus 'is this code path actually invoked' to rank, rather than drowning in CVSS-9 findings nobody can action.
• Track fixables separately. Distinguish CVEs with an available patched version from those without — only the former are truly actionable today.

Making it a system, not a step

Scanning bolted onto one pipeline stage catches yesterday's problems for today's build. The organisations that handle the next zero-day calmly are the ones treating SBOMs as an asset inventory: every image that reaches a registry has a stored bill of materials, indexed and queryable, and every stored image is rescanned as feeds update. The scan finds today's known issues; the SBOM is how you find tomorrow's, in software you already shipped.

All of it depends on knowing which images and workloads you have. A registry of unscanned images, or a cluster running tags nobody catalogued, is a vulnerability surface you cannot query — and you can't assess what you haven't discovered.