Use three triggers together. Scan on every change, so new problems are caught before merge. Scan on a schedule, because code that does not change still ages as new advisories appear. And re-check stored inventories whenever a new advisory lands. One trigger alone leaves a gap.
Why one trigger is not enough
A scan on commit answers "did this change add risk". It says nothing about a service nobody has touched for six months. New vulnerabilities are published against old code every day. EPSS, for example, publishes updated exploit probability scores daily for every CVE, so the risk picture changes even when your code does not.
A scheduled scan alone has the reverse flaw: it finds problems after merge, and the delay is as long as your schedule.
The three triggers
| Trigger | Catches | Cost |
|---|---|---|
| Pull request or commit | New risk from a change | Pipeline time on each change |
| Schedule, such as nightly or weekly | Aging code and new advisories | Compute on idle services |
| Advisory driven re-check | A fresh CVE against what you already have | Cheap if you store SBOMs |
The third is the efficient one at scale. If you keep an SBOM per service build, a new advisory is a query, not a scan of hundreds of repos.
Setting the schedule by tier
Do not scan everything at the same rhythm.
- Internet facing production services: daily.
- Internal production services: weekly.
- Libraries and tooling: weekly or on release.
- Deprecated and experimental: monthly, with a retirement date.
Adjust by what your pipeline can bear, and stagger start times so scans do not all hit at midnight. Use a scheduled run for the stragglers and keep the pull request gate light.
Keep pull request scans fast
Developers will route around a slow gate. Scan only changed manifests where you can, fail only on new high severity findings, and send everything else to a report. A gate that blocks on old findings the developer did not introduce becomes a source of friction, not safety.
Watch the signals
- Services with no scan in the last cycle.
- Scan durations trending up.
- Jobs failing quietly.
A scan that did not run looks the same as a clean scan unless you track it. Alert on missing runs.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how findings change over time without new commits.
Quick check
Is a nightly scan enough?
It covers aging code but not new changes before merge. Pair it with a pull request check.
What if scans take too long?
Scan changed paths on pull requests, stagger scheduled runs, and use stored SBOMs for advisory driven checks.
Safeguard offers continuous monitoring and SBOM and dependency scanning, and a free scan lets you try it on one repo.
Sources
Last reviewed: 19 October 2026.
