OSV-Scanner, SBOMs and the supply chain question customers now ask

The supply chain question has moved from a security team's concern to a line in the procurement questionnaire. Customers ask for a software bill of materials. NIS2 expects supply chain risk management from entities in scope. The US executive order made SBOMs a condition of federal sale and the expectation spread outward from there.

Most organisations respond by generating an SBOM at release time, attaching it to a compliance folder and never looking at it again. That satisfies the questionnaire and provides nothing. The same artefact, used differently, answers the only question that matters on the day a serious library vulnerability is published: are we affected, where, and how fast can we ship the fix?

Generate from the build, not from the repository

An SBOM produced by reading package.json or requirements.txt lists what you asked for. An SBOM produced from the built artefact lists what you got, which is a different and longer list, because transitive dependencies are where the interesting vulnerabilities live.

Generate at build time, from the lockfile and the resulting image:

syft packages dir:. -o spdx-json > sbom-source.json
syft packages myimage@sha256:... -o spdx-json > sbom-image.json

Attach both to the release. SPDX and CycloneDX are both accepted; pick one and be consistent, because the tooling that consumes them differs in its support and mixing formats across repositories makes aggregation painful later.

Scan the lockfiles with OSV-Scanner

OSV-Scanner queries the OSV database, which aggregates advisories across ecosystems with precise affected-version ranges rather than the loose ranges that produce false positives elsewhere.

osv-scanner --lockfile=package-lock.json --lockfile=poetry.lock --lockfile=go.sum .
osv-scanner --sbom=sbom-image.json

It reads lockfiles directly, which means it sees the resolved versions rather than the declared constraints, and it reads SBOMs, which means you can re-scan a release from two years ago without rebuilding it.

The output tends to be smaller and more accurate than a generic scanner's, and that accuracy is what makes the difference between a list people act on and a list people ignore.

Reachability is the filter that matters

A vulnerability in a package present in the dependency tree is not the same as a vulnerability in your application. The library may be a build-time tool, a transitive dependency of a test framework, or present but never imported.

osv-scanner --call-analysis does static call-graph analysis for Go and, increasingly, other ecosystems, marking findings as reachable or not. Where it works it removes most of the list. Where it does not, approximate: does the vulnerable function get called from any of your code paths? Twenty minutes with grep and the advisory's affected-function list answers that better than any severity score.

Record the reasoning. "Not reachable — parseXml is not called; we use the JSON path only" is a defensible position for an auditor and a useful note for the next person who sees the same CVE.

The hour that counts

When the next widely-exploited library bug lands, the work is:

1. Query every stored SBOM for the package. If the SBOMs are in one place and machine-readable, this is one command over a directory, and it covers services nobody is actively developing — which is where the unpatched copy always is.
2. Determine reachability per service.
3. Ship the upgrade to the reachable ones first.
4. Check the logs for exploitation attempts predating the patch.

Step one is the reason to generate SBOMs at all. Organisations that have them answer in an hour. Organisations that do not spend three days asking teams whether they use the library, and get it wrong, because the answer for the service written in 2020 by a team that no longer exists is "yes, transitively".

Signing and provenance, briefly

Once the inventory exists, the next question is whether the artefact is the one your pipeline built. Sigstore and cosign sign images without managing keys, and SLSA provenance attestations record which build produced which digest. Verify at admission in the cluster, so an image that was not built by your pipeline cannot run.

This is a smaller step than it sounds — a signing task in the pipeline and an admission policy — and it closes the gap that scanning cannot: a perfectly clean SBOM for an image that is not the image you are running tells you nothing.

Keep it honest

The failure mode of SBOM programmes is generating documents nobody queries. The test is simple: can you answer, right now, which of your running services include a given package at a given version, without asking a team? If yes, the programme works. If no, you have compliance artefacts, not a supply chain capability — and the difference will show on the day it matters.