CRA Evidence Desk vs. matching an SBOM to advisories by hand
Reading a CycloneDX export and an OSV advisory list side by side and noting the overlaps is a generic manual habit anyone with the two files already has, not a company or product this could be mistaken for. It works for a handful of components and breaks down well before a real dependency tree's size does.
Where the manual read breaks down
Matching two lists by eye is really computing an exact set intersection, and a person does that slower and less reliably than a matcher that runs the same rule on every entry. Three specific gaps matter more than the general slowness:
| Case | Matching by hand | This tool |
|---|---|---|
Same registry, spelled differently (golang vs. Go, cargo vs. crates.io, Maven namespace/name vs. group:artifact) | A real match reads as no match unless the reviewer already knows every spelling pair and normalizes them while scanning | Folds both spellings onto one form before comparing, using package URLs wherever present |
| Sub-components nested inside a parent in a CycloneDX SBOM | A read that only walks the top-level dependency list never reaches them | Walks nested sub-components the same as top-level ones |
| An advisory stated as a version range rather than an enumerated list | Requires an on-the-spot judgment call about that ecosystem's version ordering to accept or reject | Does not guess a range; lists it under advisories not evaluated rather than silently dropping it |
| A record of what was checked and when | Rarely survives past the review session | Exports a dated JSON record every run |
| Hundreds of components against hundreds of advisories | Attention and consistency both degrade well before the end of the list | Applies the identical exact-match rule to every entry, first to last |
None of this makes the manual read useless -- for two or three components a quick look is often faster than exporting files into a tool. The gap opens as the SBOM and the advisory export grow, which is exactly when a manual reviewer is least likely to notice they have started missing things.
This tool needs no install and no server: it is a static page, the matching runs in your browser (or as a single CLI command), and once loaded it keeps working with the connection off. Nothing you give it is uploaded.
Common questions
Isn't comparing two lists something I can just do by eye?
For a handful of components, yes -- scan the SBOM's package names, scan the advisory list, note the overlaps. It stops being reliable once a CycloneDX export runs to hundreds of nested sub-components and an OSV advisory export runs to hundreds of entries, because the task is not really reading two lists, it is computing an exact set intersection across two large lists that do not always spell the same thing the same way. That is a mechanical task a person does slower and less consistently than a matcher that never gets tired partway through.
What actually goes wrong when someone matches by hand?
The most common miss is an ecosystem-naming mismatch: a CycloneDX SBOM and an OSV advisory can name the same registry two different ways -- golang vs. Go, cargo vs. crates.io -- and a Maven artifact as namespace/name in one export and group:artifact in the other. A component and its advisory that genuinely match will not visibly match on a side-by-side read unless the reviewer already knows every one of those spelling pairs and normalizes them in their head while scanning. The second common miss is nested components: CycloneDX SBOMs can nest sub-components inside a parent, and a manual read that only walks the top-level dependency list never reaches them.
What about an advisory that names a version range instead of a list?
OSV advisories state affected versions two ways: an enumerated list, or a range such as "everything below 1.4.2." A manual reviewer looking at a range has to decide on the spot whether their installed version falls inside it, which means knowing that ecosystem's own version-ordering rules and whether a backport changes the answer -- a judgment call about the product, not a lookup. Treating a range as a quick yes-or-no during a fast manual pass is exactly where a wrong call costs the most, because the advisory that gets waved through is the one that actually matched.
Does a clean manual read leave any record of what was checked?
Usually not one that survives past the meeting. A person who reads through an SBOM and an advisory export and concludes nothing matches rarely writes down which advisories they evaluated, which they skipped because they only stated a range, or the date they looked. Six months later, when a reporting question comes up, nothing says what was actually checked. This tool exports a dated JSON record every time, and lists advisories it could not evaluate by name rather than silently dropping them, so the same question later has an answer instead of a memory.
Does this tool replace judgment about whether a match matters?
No. It only makes exact name, ecosystem, and version matches and tells you which advisories it could not evaluate. It does not resolve aliases, ranges, reachability, or exploitability, and it does not decide whether a legal reporting obligation applies to a given match. What it replaces is the mechanical part -- comparing two lists exactly, the same way, every time -- not the judgment calls that come after a match is found.
Open CRA Evidence Desk to run your own SBOM and advisory export, or see why your SBOM and advisory package names don't match for the ecosystem-spelling gap in more detail, or CRA Evidence Desk vs. OWASP Dependency-Track if you are weighing this against a continuous monitoring platform instead of a manual read.