Scan every time your code changes, and also on a regular schedule, at least weekly for important systems. Code changes bring in new packages. Time brings in new discoveries about packages you already use. You need both triggers, because a clean scan today can be out of date tomorrow.
TL;DR
- Two triggers matter: a change in your code, and a new flaw being published.
- Scan on every pull request, and rescan stored software on a schedule.
- Important and internet facing systems deserve the shortest gap.
- More scans do not help unless someone ranks and acts on the results.
Why is one scan never enough?
Imagine checking a food label once. The label does not change, but what scientists know about the ingredients does. A scan works the same way. It compares the software you run against a database of known flaws. Your software can stay identical while the database grows.
A vulnerability is a flaw in software that someone could misuse. A scan is a check of your software against known flaws. A CVE ID is the shared name for one publicly known flaw.
Two clocks run at once.
- Your clock. You add or update packages whenever you change code. Any new package can bring a flaw with it.
- The world's clock. Researchers and vendors publish new flaws continuously. CISA's Known Exploited Vulnerabilities catalog was showing 1748 entries when we reviewed it, and it keeps growing as evidence of exploitation arrives. FIRST publishes an updated EPSS exploit probability for every scored flaw every day.
Because the facts about a flaw can change daily, a result from last month cannot tell you where you stand today.
What triggers should start a scan?
| Trigger | Why it matters | Example |
|---|---|---|
| A pull request | Catches a new flaw before it reaches live software | A developer adds a new package |
| A merge or release | Confirms what you ship | A build for production |
| A schedule | Catches flaws published after you shipped | Nightly or weekly rescan of stored software |
| A new exploited flaw | Tells you quickly if you are affected | A new entry on the CISA catalog matches a package you use |
| A major change in the environment | New systems may be unlisted | A new cloud account or service |
Scan on every pull request
A pull request is a proposed code change waiting for review. Scanning here is cheap and fast, because a problem is easier to fix before the change is merged than after it ships. Many teams set a rule, called a gate, that blocks the change if it adds a flaw above an agreed danger level. See continuous vulnerability management for context.
Rescan stored software on a schedule
Software that no one is changing still ages. A service that has not been touched for six months can pick up several new known flaws with no change on your side. A scheduled rescan catches this. For most teams, nightly or weekly is a fair start. Pick the gap based on how bad a delay would be for that system.
React to new exploited flaws
If a flaw is added to the CISA catalog and you run the affected package, you want to know today, not at the next weekly scan. If you have a list of what you run, checking a new entry takes minutes. If you do not, it can take days. This is another reason to keep an inventory, as covered in how to list your software before scanning.
What rhythm fits each kind of system?
Use a simple tiering. These gaps are suggestions to adapt, not rules from a standards body.
| System type | Scan on change | Scheduled rescan |
|---|---|---|
| Internet facing and important | Every pull request | Daily |
| Internal and important | Every pull request | Weekly |
| Internal and low importance | Every pull request or release | Monthly |
| Retired but still running | Not applicable | Weekly until fully shut down |
The last row is a trap. Retired systems that still run get no code changes, so only scheduled scans will notice them. The sooner you shut them off, the better.
Does scanning more often make you safer?
Only if the results get handled. A scan that nobody reads is paperwork. More frequent scans produce more findings to rank. So match frequency to your ability to respond.
Two guardrails help.
- Deduplicate. The same flaw seen every night should be one finding with an age, not thirty new alerts.
- Rank before you alert. Notify people only about findings that pass your priority rules, such as exploited and reachable.
See how to rank hundreds of vulnerabilities for a method.
A worked example with invented numbers
These numbers are invented to illustrate the effect of scan timing. They are not from a real team.
A team scans only at release, about once a month. On day 3 after a release, a flaw is published in a package they use. It is added to the known exploited list on day 8. Their next scan is on day 30.
| Day | Event | Monthly scanning | Nightly scanning |
|---|---|---|---|
| 3 | Flaw published | Unknown to the team | Found that night |
| 8 | Added to exploited list | Unknown to the team | Priority raised that night |
| 9 | Fix released and applied | Not yet | Fixed and rescanned |
| 30 | Next scheduled scan | Found, 22 days after exploitation evidence | Already closed |
With monthly scanning, the system ran with a known exploited flaw for 22 days after the list update. With nightly scanning, the exposure was about a day. The extra scans did not create extra work. They moved the same fix earlier.
How do you avoid scan fatigue?
- Set clear thresholds for what interrupts a person and what waits for the weekly meeting.
- Auto close findings that a rescan proves are fixed.
- Keep one view of open findings with age, owner and priority.
- Review the rhythm quarterly. If nobody acts on daily alerts, tighten the rules rather than switching scans off.
For a step by step routine that uses these rhythms, read how to start vulnerability management from scratch.
Try it yourself
Click through it at your own pace, or open it full screen. Watch what happens when a new flaw is published after a project has already been scanned clean.
How can Safeguard help?
Safeguard scans dependencies and SBOMs, and you can attach policies and gates so that a pull request is checked automatically. Zero-day discovery and reachability analysis help you decide which new flaws deserve attention first. The Safeguard CLI can run scans from a terminal or a build pipeline, and the current CLI release is available through a curl installer on macOS and Linux and a PowerShell installer on Windows. You can try the free scan at gold.safeguard.sh/scan.
Quick check
Is weekly scanning enough?
For many internal systems, yes. For internet facing or important systems, consider daily, plus a scan on every pull request.
Why scan software that has not changed?
Because knowledge about flaws changes. New flaws and new exploitation evidence appear without any change on your side.
Should every new finding page someone?
No. Page people for findings that pass your priority rules, such as exploited and reachable. Let the rest wait for the weekly review.
Sources
- CISA, Known Exploited Vulnerabilities Catalog
- FIRST, Exploit Prediction Scoring System (EPSS)
- FIRST, EPSS Frequently Asked Questions
Last reviewed: 19 October 2026.
