A vendor SBOM is a claim. How much of it can you check?

You can’t patch their code, and a document that lists components doesn’t necessarily answer any questions. Drop in the file and the first thing you see is how much of it holds up.

Review an SBOM Or answer one CVE right now

Two real SBOMs from our test set, measured

Looks like an SBOM0%

0 of 10 components could be checked

Package identifiers
Dependency graph
low confidence

Ten components declared, none with a package identifier. None of them can be matched against an advisory, so none of them can be called safe either. The risk is simply unknown.

Actually checkable100%

20 of 20 components could be checked

Package identifiers
Dependency graph
high confidence

Every component is identified and versioned, so all of them can be checked. There’s still no dependency graph, so direct and transitive dependencies can’t be told apart. That’s worth asking the vendor for.

Trust the document before you trust the findings.

A developer tool starts from code it can read. You’re starting from someone else’s description of software you can’t open. That’s a different job, and it needs a different order.

How much of it can be checked
This comes before any count of findings, because it decides whether those counts mean anything: missing package identifiers, unparseable versions, no dependency graph. A component that can’t be matched is never reported as safe.
What is inside, ranked by exploitation
Known-exploited flaws come before merely severe ones. Anything the vendor marked not affected stays visible with the justification they gave, so you can judge the claim yourself instead of inheriting it.
What to put in the ticket
Component, current version, the version that fixes it, and the evidence. “Upgrade X to Y, it’s on CISA’s exploited list” is a request a vendor acts on. “Please fix your CVEs” is one they file away.

Review an SBOM

No account needed. The file is parsed in memory and never written to disk. Only package coordinates are sent on to OSV.dev, never the document itself.

Drop files here, or click to browse

Add several at once, up to 20 MB. No account needed.

CycloneDX JSON
SPDX JSON
package-lock.json
package.json
yarn.lock
pnpm-lock.yaml
requirements.txt
Pipfile.lock
poetry.lock
Cargo.lock
go.mod
composer.lock
Gemfile.lock
packages.lock.json

“Are we affected?”, with a deadline

A CVE broke this morning and someone wants an answer today. Give it the same file and an identifier, and you get affected, no match found, or cannot determine when the document isn’t complete enough for a clean answer. That third answer matters most, because a wrong all-clear in the middle of an incident is the most damaging thing this tool could tell you.

What this tells you about someone else’s software.

You’re reading a description of the product, not the product itself. That limit is real, and it’s worth stating before the findings rather than after.

It can tell you

That a component they declared has a known vulnerability, and whether that flaw is in CISA’s exploited catalogue.
How much of their document could be checked at all, and how much couldn’t.
Which version clears which finding, with the evidence attached.

It can’t

Tell you whether the vulnerable code is reachable in their product. That needs their source.
Verify a “not affected” claim. It shows what they asserted and on what grounds, so you can ask them about it.
See anything they left out. An SBOM is only as honest as whoever generated it.