Use both. Event-driven scans run when your code changes, such as a pull request or a release, and catch problems you introduce. Scheduled scans run on a clock and catch problems that were published after you shipped. Neither one covers the other's gap, so a sound setup pairs them.
Definitions
An event-driven scan starts because something happened: a push, a pull request, a merge, a tag, a deployment or an incoming webhook. A scheduled scan starts because time passed: a nightly cron job, a weekly sweep, a monthly full audit.
The distinction matters because vulnerabilities have two origins. You can add a vulnerable dependency today. Or a dependency you added a year ago can become vulnerable tomorrow, when a researcher publishes an advisory. Your code did not change, so no event fires.
What each trigger catches
| Trigger | Catches | Misses |
|---|---|---|
| Pull request | Vulnerable packages and code you are about to merge | Advisories published after merge |
| Merge to main | Anything that slipped past review, plus the exact released state | Advisories published later |
| Release or tag | A record of what shipped | Everything after the tag |
| Nightly schedule | New advisories against code that has not changed | Nothing about today's edits until the next run |
| New advisory signal | Fast response to a specific disclosure | Anything the signal source lacks |
How to split the work
- Gate on events. Run a fast scan on every pull request and fail the check on the findings you have agreed to block. Keep it quick, because developers wait on it.
- Record on release. Generate an inventory (an SBOM) at release time and store it. That stored file is what your scheduled job re-checks later.
- Sweep on a clock. Once a day, re-match stored inventories against the latest advisory data. This does not need a rebuild, which keeps it cheap.
- React to urgent signals. Add a trigger for the small set of advisories that need action within days, such as entries on a known-exploited list. The CISA Known Exploited Vulnerabilities catalog publishes JSON and CSV files you can poll.
For a deeper take on the nightly sweep, see how often should you scan dependencies.
When to lean one way
A small team with a few repositories can start with pull request scans plus one nightly job and be well covered. A team with hundreds of services needs the signal triggers too, because a nightly sweep across everything can take hours and a response to an urgent advisory should not wait for it.
If you only pick one, pick events. Blocking a bad dependency before it merges is cheaper than finding it in production. But accept that you are then blind to anything published after the merge.
Try it yourself
Open the demo and look at how a monitored inventory changes state without any code change. The point to notice is that a finding appears while nothing in the repository moved.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning, reachability analysis and policy gates for pull requests. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is a nightly scan enough on its own?
No. It tells you about new advisories the next morning, but it does not stop a vulnerable dependency from merging today. Add a pull request check.
Do event-driven scans find new advisories?
Only if the event is an advisory signal. A pull request scan uses the data available at that moment and will not rerun when new data arrives.
Sources
Last reviewed: 19 October 2026.
