SBOMs are Just a Means to an End | Endor Labs

What it is

An opinion piece by an Endor Labs product manager (CISSP, CIS NGINX benchmark maintainer). It tests the NTIA minimum SBOM elements against one concrete job: take a third-party SBOM and check each dependency for vulnerabilities, outdated releases and abandonment. Its conclusion is that the minimum elements are not enough for that job. The author also reports talking to 50+ practitioners, most of whom use SBOMs only as a procurement signal, not in vulnerability management.

How it works

The argument turns on what identifier a consumer needs to look a package up.

• Checksums don't help. There is no reference database mapping checksums to vulnerabilities across every download location.
• purl is the closest fit, but not a complete one. The example given is pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1. Nothing in it separates Maven Central from a private repository, so consumers must assume "not Central means private". The repository_url qualifier could close that gap, but it is optional and inconsistently implemented.
• No spec requires purl. The required fields in SPDX, CycloneDX and the NTIA minimums are only component name and version. A rust crate and an npm package both named log4j-core 2.12.2 would be indistinguishable from the Maven one.
• Depth is underspecified. NTIA (p. 12) requires top-level dependencies "with enough detail to seek out the transitive dependencies recursively." Without pinned dependencies or a lockfile, many package managers resolve differently depending on build time. The specs define only SBOM creation time, which is an imperfect proxy for build time. The page says a consumer also needs the build system or package manager used.

What to do

The page's advice is aimed at standards bodies, not at consumers. Its asks:

• Define required data per use case, separating required from nice-to-have.
• Prioritize two or three use cases.
• Incentivize vendors beyond "cost of doing business".
• Support less manual VEX so vendors can handle vulnerability questions.
• Let tooling omit data such as licenses when a use case doesn't need it.

For an engineer consuming SBOMs, the page implies some checks, but it doesn't spell them out. Check whether each component has a purl, whether repository qualifiers are present, and whether a lockfile or pinned versions accompany the SBOM. Compare output across generators for the same software version, since the page says purl placement and component definitions vary by tool.

Caveats

• The author declines to name any tools or vendors, so there is no data on which generators behave better.
• The 50-practitioner findings are anecdotal and unquantified.
• The page notes that vendors have a disincentive to ship high-quality SBOMs, because license and component-hygiene questions cost them.
• The author works for a vendor that sells in this space.