Most teams need both. A pull request scan answers "is this change safe to merge today?" A scheduled scan answers "did something we already shipped become unsafe since then?" They look at different moments in time, so one cannot stand in for the other.
Two different questions
The pull request scan looks at a diff or a branch at a single point. It is fast and tied to an author who can act on it.
The scheduled scan looks at the whole repository or the deployed software on a timer. Its job is to catch the thing that did not change in your code but changed in the world: a newly published advisory against a package you already use.
If you only scan on pull requests, a quiet repository never gets rescanned. If you only scan on a schedule, bad changes reach the main branch before anyone sees them.
What each stage is good at
| Question | Pull request scan | Scheduled scan |
|---|---|---|
| Did this change add a risky dependency? | Yes | Eventually |
| Did a new advisory hit something already shipped? | No | Yes |
| Can it block a merge? | Yes | No, it opens tickets |
| Who acts on a finding? | The author | An owner or rotation |
| How fast must it be? | Minutes | Can be slower |
Setting the schedule
There is no universal interval. Choose by how fast you can respond. If your team cannot act on a finding within a day, a daily scan produces tickets nobody reads. Daily or weekly is common for active repositories. Releases that stay in production for a long time may deserve a more frequent look than the code still being developed.
Also decide where findings go. A scheduled finding needs an owner and a due time, or it becomes a growing list. Many teams route them to the team that owns the service, with a short triage window.
Avoid duplicate noise
The same finding will appear in both stages. Deduplicate by identifying the vulnerable package and the affected service, so the pull request check does not re-flag old debt and the scheduled scan does not re-open a ticket that is already tracked.
A simple rule works: the pull request check fails only on findings introduced by the change. The scheduled scan owns everything else.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for the point where a finding appears on software that did not change, since that is what a scheduled rescan exists to catch.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning, continuous monitoring of what you have already shipped, and pull request gates, so both questions are covered by one set of policies. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Is a nightly scan overkill for a small team?
Not if it is cheap to run and has an owner. Weekly may be enough. What matters is that someone is assigned to look at the result.
Can a scheduled scan block releases?
It can, if you add a release gate that checks the latest result. Otherwise it informs and opens tickets.
Last reviewed: 19 October 2026.
