Keep an SBOM for every release you have shipped, re-match those inventories against advisory feeds on a schedule, and send each match to the team that owns the product. A scan at build time only tells you about the day you built. New advisories arrive afterwards, so the matching has to keep running.
Why build time scans are not enough
An advisory is published after a package is released. Your lockfile did not change, but the answer to "is this version vulnerable" did. If you only scan in CI, a flaw published next month in a package you shipped last month reaches nobody until the next build.
What you need
| Piece | Job | Notes |
|---|---|---|
| Stored SBOMs per release | Know what each version contains | Keep old releases that are still deployed |
| Advisory source | Know what is vulnerable | OSV offers a query API and a batch endpoint for many package versions |
| Exploited list | Know what is under attack | CISA KEV is published as CSV and JSON |
| Ownership map | Know who must act | Product to team, with an on call contact |
| Notification route | Reach the owner | Ticket, chat message or email, deduplicated |
Setup steps
- Generate and store an SBOM at every release, tagged with product and version.
- Run a scheduled job that sends all stored component versions to the advisory source in batches and records matches.
- Compare to the last run so you alert on new matches only. Repeating the same alert daily trains people to ignore it.
- Add the KEV feed as a second job and mark matches as urgent.
- Filter by what is deployed, so retired versions do not page anyone.
- Attach context to each alert: package, version, fixed version if known, which products are affected.
- Track acknowledgement. An alert nobody opens is not an alert.
Tuning noise
Alert volume decides whether this survives. Start by alerting on critical and high findings, on anything in the exploited list, and on anything that reachability analysis marks as callable from your code. Review the lower tiers weekly in a batch.
Try it yourself
Open the demo and watch how a monitored inventory is re-checked when new advisories appear.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's SBOM and dependency scanning keep inventories and re-check them as advisories change, and policies and gates decide what blocks and what notifies. Start with a free scan.
Quick check
How often should the matching job run?
At least daily for most teams. For critical systems, poll the exploited list more often, since a match there can change your priorities within hours.
Do I need SBOMs for old releases?
Yes, for any version still running somewhere. Customers on an old release are exposed to new advisories too.
Sources
- OSV API documentation, google.github.io/osv.dev/api (query and querybatch).
- CISA Known Exploited Vulnerabilities Catalog (CSV and JSON feed).
Last reviewed: 19 October 2026.
