To trigger a scan on a new advisory, poll an advisory source on a short interval, compare new entries against the package list you already store, and rescan only the projects that contain a match. You rarely need to rebuild anything. The stored inventory is the input.
Why not just scan everything every hour
A full rescan of every repository on a tight loop wastes compute and floods people with alerts. Most new advisories affect a small number of packages, and most of your projects contain none of them. Matching first, scanning second, keeps the work small.
The pieces you need
| Piece | What it does | Example source |
|---|---|---|
| Advisory feed | Tells you something new exists | OSV, the GitHub Advisory Database, the CISA KEV files |
| Inventory store | Lists packages and versions per project | SBOMs saved at release |
| Matcher | Finds projects containing the affected package and range | A small script or your platform |
| Notifier | Opens a ticket or pings an owner | Chat, issue tracker, email |
Steps
- Store an inventory for every released artifact. Without it, the only option is to rebuild, which is slow.
- Pick a source. The OSV project documents a query endpoint, a batch endpoint and a lookup by vulnerability ID, and its documentation states there are currently no limits on the API (OSV API docs). The batch endpoint suits checking many package versions at once.
- Poll on a schedule. For NVD, the developer pages suggest pausing about six seconds between requests and using the last modified start date so you fetch only records changed since your last sync (NVD developer page). Record your last sync time and pass it on each run.
- Match. For each new record, check ecosystem, package name and affected version range against your inventory.
- Trigger. For each match, start a targeted scan or open a finding directly. GitHub lets you start a workflow from outside with the repository dispatch event (GitHub events reference).
- Deduplicate. Key your findings on advisory ID plus project plus package version so a second poll does not raise the same alert again.
Limits to know
No feed is complete or instant. GitHub's own documentation notes that new vulnerabilities may take time to appear in its Advisory Database, so alerts can lag (GitHub Dependabot alerts). Using two sources narrows the gap, at the cost of deduplication work.
Also decide what counts as urgent before the alert arrives. A known-exploited entry deserves a page. A low severity advisory on a package you only use in tests can wait for the weekly review.
Try it yourself
In the demo, watch how a newly disclosed issue is surfaced against components already in an inventory. Look for how the affected list is built without any new build.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard includes SBOM and dependency scanning plus zero-day discovery, and you can check a manifest for free at gold.safeguard.sh/scan.
Quick check
Do I need to rebuild my code when an advisory lands?
Not to find out whether you are affected. Match the advisory against a stored SBOM. Rebuild only when you are ready to fix.
How often should I poll?
Often enough to meet your response target. Every 15 to 60 minutes is common for urgent sources, and daily is fine for general ones. Check each source's published guidance.
Sources
- OSV API documentation
- NVD vulnerabilities API developer page
- GitHub events that trigger workflows
- About Dependabot alerts
Last reviewed: 19 October 2026.
