The five-minute SBOM sniff test earns its keep

Every hardened image ships with a promise. The vendor scanned it. Nothing red. Move along.

That promise is doing a lot of work. Christian Dupuis, writing this week in The New Stack, argues you should stop taking it on faith and instead run what he calls a five-minute sniff test on the SBOM before you let the image anywhere near your pipeline. His piece leans on CISA's updated 2025 guidance for what an SBOM should actually contain, and treats the sniff test as the missing habit between a zero-CVE badge and the reality of what you just pulled.

The verdict up front: he is right, and if you are skipping this you are outsourcing your threat model to whoever built the image.

Why "zero red" does not mean "safe"

A CVE scanner shows you known problems. It cannot show you what is missing from the bill of materials, whether the components inside were pulled from a source you would recognize, or whether the maintainer of the third-largest library shipped their last commit from a laptop that has since been sold on eBay. Hardened images collapse a fleet of upstream projects into a single "trust us" surface. Convenient. Also a nice place to hide a stowaway.

A sniff test is not a security program. It is what you do while you drink your coffee, before you decide whether the security program is going to have a bad week.

What five minutes actually buys you

You are not auditing the image. You look at the SBOM the way you look at ingredients on a cereal box. The point is to spot what does not belong. In hardened-image territory, that usually means asking a handful of tired questions.

Is the SBOM there at all, and does it actually describe the layer you just pulled? A stale attestation carried over from a previous tag is not a bug the vendor thinks about first. Are the listed components the ones you expect for a base image of this class, or has some helpful build script quietly bundled a language runtime you thought you had left behind? Does every component have a version and a source, or are half of them anonymous packages listed by name only? Does the digest in the attestation match the image you actually pulled, byte for byte?

If any of those answers is "not really", you have found in five minutes what the scanner was never going to flag.

The honest upside

Give hardened-image vendors this. They do more than the average build. Fewer packages. No shell. Pinned versions. Signed provenance, sometimes with attestations you can actually verify against a public ledger. That is a real improvement over a generic base image dragging an entire distribution and half of npm along for the ride.

The trap is treating the improvement as a finish line. A minimal image with signed provenance and zero CVEs, whose SBOM you never open, is still an object of pure faith. Faith is not a control.

Wire it into the boring part of the pipeline

Do the sniff test where it belongs: in a pre-merge check, not in a quarterly compliance report nobody reads. A build step that fails when the SBOM is missing or when the attested digest (sha256:<digest>) does not match the image you pulled. A tiny script that diffs today's component list against yesterday's and posts the delta to the channel where your on-caller already lives. A rule that any new top-level package added to a base image has to be approved by a human in a pull request.

Nothing exotic. That is the point.

The kicker

The five-minute sniff test does not make you secure. It makes you slightly harder to fool. In supply-chain work that is often the whole game. Spend five minutes with the SBOM now, or spend a very long afternoon with an incident channel later. Pick one.