Every time you install a piece of software, you are trusting hundreds of authors you have never heard of. A modern web app can pull in 1,200 dependencies before you write a single line of your own code, and most developers could not name more than a dozen of them. That gap between what you install and what you actually understand is where supply-chain attacks live.
The good news is that there is now a standard document designed to close that gap: the Software Bill of Materials, or SBOM. Think of it as the ingredients label on a box of cereal, except for code. The 2021 US Executive Order 14028 pushed SBOMs from a niche security curiosity into a near-mandatory artifact for anyone selling software to serious buyers. Sonatype's 2023 State of the Software Supply Chain report counted more than 245,000 malicious open-source packages published that year, roughly double the total of all previous years combined. An SBOM is one of the few tools that lets you spot the risky ones before they touch your machine.
In this article you will learn exactly how to read an SBOM, which fields actually matter, how to cross-reference components against known vulnerabilities, and a repeatable checklist you can run in under fifteen minutes before any install. We will use real formats, real tools, and a worked example with real numbers.
Key Takeaways
- An SBOM lists every component in a piece of software, including transitive dependencies you never chose directly.
- The two dominant formats are SPDX and CycloneDX; both are machine-readable JSON or XML you can parse in seconds.
- Focus first on four fields: component name, version, supplier, and hash. These catch the majority of tampering and typosquatting.
- Cross-reference component versions against the NVD and OSV databases to find known CVEs before you install.
- A missing, stale, or unsigned SBOM is itself a red flag, treat it as a reason to slow down.
- Automate the boring parts with tools like Grype, Trivy, or Dependency-Track so you review the exceptions, not the whole file.
What an SBOM Actually Is (and What It Is Not)
An SBOM is a formal, structured inventory of the components that make up a piece of software. At minimum it records the name, version, and supplier of each component, plus the relationships between them. The best SBOMs also include cryptographic hashes, license identifiers, and unique package URLs.
What it is not: a guarantee of safety. An SBOM tells you what is inside, not whether each piece is trustworthy. It is a map, not a verdict. The skill you are building is reading that map well enough to spot the parts of town you should avoid.
There are three concepts worth pinning down before you open your first file:
- Direct dependencies are components the author chose on purpose, like a specific logging library.
- Transitive dependencies are the components those libraries pull in. This is where most surprises hide, and often where 80% of your total component count comes from.
- Provenance is the evidence of where a component came from and who built it. Strong provenance means you can trace a component back to a signed, verifiable source.
The Two SBOM Formats You Will Actually See
You do not need to memorize a dozen standards. In practice, two formats cover almost everything you will encounter.
SPDX
SPDX (Software Package Data Exchange) is a Linux Foundation standard, now an ISO standard as of 2021. It leans toward licensing and compliance use cases and is common in enterprise and open-source projects. Files usually end in .spdx.json or .spdx.
CycloneDX
CycloneDX is an OWASP project built with security in mind. It handles vulnerabilities, dependency graphs, and component pedigree cleanly. Files usually end in .cdx.json or .bom.json. If your goal is catching supply-chain risk specifically, CycloneDX tends to give you more security-relevant fields out of the box.
| Criteria | SPDX | CycloneDX | Plain manifest (e.g. package-lock.json) |
|---|---|---|---|
| Primary focus | Licensing & compliance | Security & vulnerabilities | Build reproducibility |
| Transitive deps | Yes | Yes | Yes |
| Component hashes | Yes | Yes | Partial |
| Built-in vuln fields | Limited | Yes (VEX support) | No |
| Tooling maturity | High | High | Ecosystem-specific |
| Best for | Legal review | Risk hunting | Developers only |
A plain lockfile is not an SBOM, but it is a useful stand-in when a vendor does not provide one. If you are choosing between open-source tools where only lockfiles exist, our guide on how to vet an open-source app before replacing your default software pairs well with this piece.
How to Read an SBOM: The Fields That Matter Most
Open any CycloneDX JSON file and you will see a components array. Each entry looks roughly like this:
nameandversion— the identity of the component. Together with the package URL, this is your lookup key for vulnerability databases.purl(package URL) — a standardized string likepkg:npm/lodash@4.17.21. This is the single most useful field for automated scanning because it encodes ecosystem, name, and version in one place.hashes— cryptographic digests (SHA-256 is common). This is how you verify the component you install matches the one in the SBOM.supplierorauthor— who published it. Watch for missing or suspicious values.licenses— legal obligations, and sometimes a signal of abandonment.externalReferences— links to source repos, issue trackers, and distribution points.
When you first look at a large SBOM, resist the urge to read every line. Sort or filter for four things: components with no supplier, components with no hash, components pinned to unusually old versions, and components whose names look almost-but-not-quite like popular packages.
The typosquatting check
Typosquatting is when an attacker publishes a package named reqeusts hoping you meant requests, or colour instead of color. Scan the name column for near-misses of packages you recognize. A single transposed letter in a dependency you did not choose directly is one of the highest-signal red flags in the whole document.
A Worked Example: Auditing a 312-Component SBOM
Say you download a self-hosted analytics dashboard and it ships with a CycloneDX SBOM listing 312 components. Here is how a fifteen-minute review actually goes.
- Count and categorize. You run a quick script and find 41 direct dependencies and 271 transitive ones. Immediately you know that 87% of your risk surface comes from code the author never explicitly picked.
- Extract every purl. You pipe the SBOM into Grype:
grype sbom:analytics.cdx.json. In about eight seconds it reports 6 high-severity and 2 critical vulnerabilities. - Investigate the criticals. One critical is
log4j-core@2.14.1, which is vulnerable to CVE-2021-44228 (Log4Shell), CVSS 10.0. The fixed version is 2.17.1. This alone is a stop sign. - Check supplier gaps. Filtering for empty supplier fields surfaces 14 components. Twelve are harmless internal utility packages. Two have no repository link and version
0.0.1, published within the last month. You flag these for manual review. - Verify one hash. You pick the most sensitive dependency, download it directly from the official registry, run
sha256sum, and confirm it matches the SBOM. It does. Good. - Decide. The Log4Shell finding and the two orphan packages mean you either wait for a patched build or reject the software. You email the vendor with the exact CVE and version.
Total time: about twelve minutes. Compare that to the alternative, which is installing a component with a CVSS 10.0 vulnerability directly onto a server. This is the entire value proposition of learning to read an SBOM.
Cross-Referencing Components Against Vulnerability Databases
An SBOM by itself is static. Its power comes from matching component versions against live vulnerability data. Three sources cover most needs:
- NVD (National Vulnerability Database) — the canonical source for CVEs and CVSS scores, run by NIST.
- OSV.dev — Google's open-source vulnerability database, excellent for language ecosystems like npm, PyPI, and Go, and it takes purls directly.
- GitHub Advisory Database — well-curated, with clear affected-version ranges.
You rarely query these by hand. Instead, feed your SBOM to a scanner that does the matching for you:
- Grype (Anchore) — fast, works directly on SBOM files.
- Trivy (Aqua Security) — scans images, filesystems, and SBOMs.
- OWASP Dependency-Track — a server you feed SBOMs into continuously, so you get alerted when a new CVE affects something you already installed.
That last point matters more than people realize. A component that was clean the day you installed it can become critical overnight when a new CVE drops. Dependency-Track re-evaluates your existing SBOMs against fresh advisories automatically, which turns a one-time check into ongoing monitoring. This is the same defense-in-depth mindset behind hardening tools like SiteGuard Pro and eDarpan WordPress Protection, where the threat model assumes yesterday's safe code can become today's liability.
Red Flags That Should Stop an Install
Not every warning is a dealbreaker. But some patterns should make you pause regardless of how much you want the software.
