Safeguard's documentation describes continuous scanning as three triggers: a change in vulnerability feeds, a Safeguard zero-day advisory, and a change to an asset such as a new commit or image tag. That is event driven, not a fixed calendar. A fixed schedule is a backstop, not the main mechanism.
Why not just scan every night?
A nightly scan tells you the state of your software once a day. A dependency you shipped on Monday can become vulnerable on Thursday when an advisory is published, and a scan that ran Wednesday night will not know. The Safeguard docs make the same point: scanning at build time describes an artifact at the moment it was built, and the gap after that is what continuous scanning is meant to close.
Event driven rescans also avoid waste. When a new advisory lands, only assets that contain the affected component need rescoring. The docs describe components stored in a knowledge graph and matched to advisories by package URL, version range and CPE, so unaffected assets are not traversed again.
What are the three triggers?
Feed changes. A new CVE, GitHub advisory, OSV entry, addition to CISA's Known Exploited Vulnerabilities catalog or a shift in EPSS scoring that affects a component you use.
Zero-day advisories. When Safeguard's research team publishes an advisory, assets that include the component are re-evaluated.
Asset changes. A new commit in a repository, a new image tag in a registry or a new vendor SBOM upload.
Per the docs, source repositories are also pulled on a schedule to catch missed webhooks. Treat the exact intervals and latency numbers in the docs as targets that can change, and confirm current behavior in your own tenant before you write them into a policy.
What belongs in the web app chat?
The web app is chat first, so you can ask about the state of a project instead of hunting for a page. Useful questions are which projects were rescanned after a given advisory, which findings are new since last week, and which new findings are reachable from your code. Use the chat to read and review. Do not treat an answer as the audit record, since the evidence is the dated finding itself.
We have not confirmed a chat flow for creating custom cron style schedules, so this post does not describe one. If your process needs a specific cadence, check the settings for the project and agree it with your account team.
Where do alerts go?
The docs list routing by owner, severity, exploitation status and environment, with delivery to Slack, Teams or Discord, ticket creation in tools such as Jira and Linear, email digests and a generic webhook. Decide who owns each route before you turn on alerts, because noisy routes teach people to ignore them.
What are the limits?
Rescans depend on the data feeds. A flaw that is not in any feed cannot trigger anything. Continuous scanning also tells you about known issues in components Safeguard can see, so connect the repositories and registries that matter, or they remain blind spots.
Finally, more alerts are not more security. Pair rescans with prioritization, such as reachability and exploitation signals, so people see the findings worth acting on first.
What to do
- Connect your repositories, container registries and vendor SBOM sources.
- Confirm in your tenant how each asset type is rescanned.
- Define alert routes by owner and severity, and assign a person to each.
- Set a rule for how fast a reachable, exploited finding must be handled.
- Use chat to review what changed each week, and keep the dated findings as your record.
- Review the setup every quarter or after major changes.
Quick check
Does continuous scanning replace scans in CI?
No. A build-time scan gates a release. Continuous scanning watches what you already shipped. You want both.
Can I set a daily or weekly scan?
Check the settings for your project and plan. This post only describes the event triggers listed in the docs.
Sources
- Safeguard docs: Continuous Scanning, fetched 18 October 2026
- Safeguard docs: Web Application, fetched 18 October 2026
Last reviewed: 18 October 2026.
