Continuous matching means you store a component list, usually an SBOM, for each build and compare it with advisory data every time that data changes. It finds new problems in old software without rescanning source code, but only as accurately as the stored list.
Definitions
An SBOM, or software bill of materials, is a structured list of the components in a piece of software, with names and versions. Matching is the act of comparing that list with a database of known vulnerabilities. Continuous matching repeats the comparison automatically when the database changes, not when you run a scan.
Why separate the two halves
A normal scan does both jobs at once: it reads your code or image and compares it with advisories. But the reading step is slow and its result only changes when your software changes. The comparison step is fast and its result changes whenever advisories change. Splitting them lets you pay the slow cost once per build and the fast cost as often as you like.
What you need
- A generated SBOM for every release, stored with the build identifier or image digest.
- A standard format, so any tool can read it later.
- Package identifiers that match advisory data, such as package URLs. Mismatched names are the main cause of missed findings.
- A trigger: a schedule at minimum, new data events ideally.
- A place to record results and owners.
OSV's documentation lists the ecosystems and sources it covers and describes ways to fetch modified records, with files sorted so a client can stop at a timestamp it has already processed. That design suits a matcher that only needs the changes since its last run.
Where it falls short
| Limit | Why |
|---|---|
| SBOM is wrong or partial | Matching cannot find what the list omits |
| Vendored or copied code | May not appear as a component |
| Unmapped advisories | NVD says some CVEs are not scheduled for enrichment, so product data may be absent |
| Runtime behaviour | A list says what is present, not what is called |
Treat the SBOM as a claim to be checked. Spot check a few releases by comparing the list against what is actually in the artifact.
Add reachability to cut noise
A match says a vulnerable version is present. It does not say your code uses the vulnerable function. Combine matching with call path analysis, and you can sort findings into those worth acting on now and those to schedule. The post dependency review on pull requests covers the earlier stage.
Where Safeguard fits
Safeguard's SBOM and dependency scanning builds and stores the inventory, and reachability analysis helps rank matches. A free scan generates a first component list for a project.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how components are listed with versions, since that list is what gets matched later.
Quick check
Is an SBOM the same as a scan result?
No. An SBOM lists what is inside. A scan result lists known vulnerabilities matched to it.
How often should stored SBOMs be rematched?
At least daily for production releases if you can act on results, otherwise weekly.
Sources
Last reviewed: 19 October 2026.
