Run both. A scan on every commit or pull request catches vulnerabilities you introduce. A scheduled scan catches vulnerabilities that become known after you shipped. They answer different questions, and one cannot replace the other. Pick the schedule by how fast your team can act on results, not by how fast the scanner runs.
Two triggers, two questions
| Trigger | Question it answers | What changes between runs |
|---|---|---|
| Pull request or commit | Did this change add a known problem? | Your code and dependencies |
| Schedule | Did the world learn something new about what we already have? | The advisory data |
GitHub's documentation describes this split for Dependabot: it creates alerts in two cases, when a new vulnerability is added to the advisory database and when the dependency graph changes. Both triggers exist because both kinds of change happen.
What happens if you pick only one
Only commit scans: a repository that nobody touches for six months never gets checked, yet new advisories keep landing against its dependencies. Quiet repositories become the blind spot.
Only scheduled scans: a risky package can be merged on Monday and sit in the main branch until the next run. You find the problem after it is already in the build.
Choosing a schedule
The right interval depends on how fast you can act, not on how fast you can scan. A daily scan that produces findings nobody reads is worse than a weekly scan that is triaged the same day.
- Start daily for internet facing services and anything shipped to customers.
- Weekly is often enough for internal tools and archived branches.
- Add an event trigger for emergencies, so a high profile disclosure can start a scan on demand.
- Stagger start times. GitHub notes that scheduled runs can be delayed at the start of each hour, and suggests choosing a different minute.
What to scan on each trigger
Keep pull request checks fast and focused on what changed. Save the heavy work for the schedule: full dependency tree matching, container images in the registry, and old release branches. If the pull request check takes too long, developers will route around it.
Do the two share results?
They should. A finding from the nightly run should show up in the same queue as one from a pull request, with the same owner rules and the same suppression decisions. Two queues means two sets of ignored alerts.
For the related question of whether built in alerts replace scheduled scans, read do Dependabot alerts replace scheduled scans.
Where Safeguard fits
Safeguard's gates act on pull requests, and its SBOM and dependency scanning covers the stored inventory for the scheduled side. A free scan gives a first look.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice what a pull request gate can stop, and what it cannot see about code already merged.
Quick check
Is a nightly scan overkill for a small team?
Not if it is cheap and triaged. If you cannot act daily, weekly is fine. Pick the rhythm you will keep.
Can the pull request scan alone cover old code?
No. It sees only changes. Old code needs a scheduled or event driven scan.
Sources
Last reviewed: 19 October 2026.
