Two kinds of recurring work matter in a security program. One is the report that tells people where things stand. The other is the rescan that keeps those numbers honest between builds. Safeguard documents both, and the pieces fit together if you set them up on purpose.
Scheduled reports
The analytics docs describe email scheduled reports driven by any dashboard, with three cadences:
- A daily digest at 09:00 local time.
- A weekly executive summary on Mondays.
- A monthly board pack with trend charts.
Reports ship as PDF with embedded charts, plus a structured JSON payload that reporting tools can ingest. The docs do not list recipient settings, naming rules or limits. The platform also has actions to create, list, update and delete report schedules, so a schedule is something you manage, not a fixed feature. The Third Party Risk Manager docs have their own Scheduled Reports section for vendor monitoring.
The dashboards behind them include Program Overview with total assets, SBOM coverage and ownership coverage, open critical and high findings by environment, KEV listed production findings, and time to remediate over 30 and 90 days.
Continuous scanning
The continuous scanning docs say Safeguard re-evaluates every asset against new vulnerabilities, new malware signatures and new policy rules. Three signals trigger a rescan: feed updates (CVEs, GHSAs, KEV and EPSS changes), Safeguard zero day advisories, and asset changes such as new commits, image tags or vendor SBOMs.
The documented schedules by asset type are below.
| Asset | Rescan |
|---|---|
| Source repositories | On every push, plus an hourly pull to catch missed webhooks |
| Container images | On push, plus every 4 hours for running images |
| Packaged artifacts | On publish and on vulnerability feed changes |
| AI models | On publish, plus weekly re-validation |
| SBOMs, yours and vendors | On upload, plus hourly feed driven rescoring |
| Kubernetes workloads | On admission, plus runtime reconciliation every 15 minutes |
| Vendors | On SBOM upload and at SLA expiry, which is configurable |
The docs give latency figures from trigger to scored findings, and they call them medians, not guarantees. Air-gapped deployments apply signed, incremental vulnerability snapshots on a schedule you choose: hourly, daily or weekly.
Tuning the interval
The docs show scan.interval: 5m for assets labeled criticality:sensitive and scan.interval: 24h for dev and sandbox environments. Scan settings live under Policies, in Scan Policies. A tighter interval costs more compute, so spend it on the assets where a slow answer hurts.
Automation settings are a separate area. The platform has actions to read and change them, so check what your tenant has enabled before you assume a behavior.
Where alerts go
Continuous scanning alerts can be routed by owner, severity band, exploitation status and environment, under Settings, then Notifications. Listed destinations include Slack, Teams, Discord, Jira, Linear, Azure Boards, email digests, PagerDuty or OpsGenie for critical KEV findings in production, and generic webhooks. Google Chat is not named in the docs I read.
Two cautions. The ChatOps docs say routing is not configurable yet, and that each chat integration sends everything to one default channel. And the continuous scanning docs say the version one REST endpoints, including the webhook example, are not yet available. Test one alert end to end before you rely on routing.
How to use it
- Pick the three dashboards your managers actually read, and schedule the weekly summary first.
- Review the default rescan schedule for each asset class and tighten it only where needed.
- For scans of private code, register a local runner rather than scripting the CLI. The CLI docs recommend this for platform scheduled scans.
- Send alerts to a channel with an owner, and mute the rest.
- Once a month, open an asset Timeline and check the scan history and the diff from the last scan.
Why it matters
A report schedule without a rescan schedule shows stale truth quickly. A rescan schedule without a reader produces findings nobody opens. Treat the two as one loop: scan, report, decide, fix.
Quick check
How often are source repositories rescanned besides on push?
Hourly, to catch missed webhooks.
Do the docs give a numeric limit for reports?
No. Recipients, naming and limits are not described.
What is the documented interval for sensitive assets?
The example is scan.interval: 5m on assets labeled criticality:sensitive.
