Continuous Scanning

Scanning at build time tells you the state of an artifact the moment it was built. That's not enough. A dependency you shipped on Monday can become vulnerable on Thursday when a new CVE is published. Continuous scanning closes that gap.

Safeguard re-evaluates every asset in your inventory — SBOMs, container images, AI models, source repositories, vendor SBOMs — every time the world changes.

What "Continuous" Means in Safeguard

Three signals drive rescans:

1. Vulnerability feed updates — when a new CVE, GHSA, OSV entry, CISA KEV addition, or EPSS score change affects a component you use.
2. Safeguard zero-day publication — when the research team publishes an SG-YYYY-NNNNN advisory.
3. Asset change — when a repository gets a new commit, a registry gets a new image tag, or a vendor uploads a new SBOM.

Rescan latency is measured in seconds to minutes, not hours:

What Gets Scanned, Continuously

Feed-Driven Re-Scoring

The expensive part of scanning is not extraction — it's comparing every component to every known advisory. Safeguard inverts this:

• Components are stored as searchable nodes in the Safeguard knowledge graph.
• New advisories are matched to components via purl, version range, and CPE resolution.
• Only affected assets get rescored; unaffected assets are never re-traversed.

This lets Safeguard rescan a fleet of 50,000 SBOMs in seconds when a new advisory lands, instead of minutes or hours.

Notifications

When a continuous scan produces a new or escalated finding, Safeguard routes the alert by:

• Owner (from CODEOWNERS, container labels, or manual assignment).
• Severity band (critical / high / medium / low).
• Exploitation status (KEV-listed, EPSS > 0.7, PoC available).
• Environment (production flows differently than dev sandboxes).

Configure routes in Settings → Notifications:

• Slack / Teams / Discord channels.
• Jira / Linear / Azure Boards ticket creation.
• Email digests (per-user, daily or weekly).
• PagerDuty / OpsGenie on-call pages for critical-KEV findings in production.
• Generic webhook for custom integrations.

Runtime Continuous Scanning

In addition to SBOM-level scanning, the runtime collector (DaemonSet or host agent) continuously observes:

• Loaded shared libraries and running processes.
• Image digests of running containers.
• Open network ports and egress destinations.
• Anomalous behavior scored by Eagle (see AI Models).

Runtime scans catch components that aren't in any SBOM — for example, a debug tool that got baked into a production image by mistake.

Air-Gapped Continuous Scanning

For air-gapped environments, continuous scanning uses signed, incremental vulnerability database snapshots:

• Snapshots ship on a schedule (hourly, daily, weekly — you pick) as signed tarballs.
• A helper downloads snapshots and applies deltas to the on-prem instance.
• Rescans run locally the moment the delta is applied.

See the air-gapped deployment guide for details.

Rescan History and Diffs

Every asset shows a Timeline of scans:

• When each scan ran and what triggered it.
• The diff of findings from the previous scan (added, resolved, changed severity).
• Griffin-narrated summaries: "3 new high-severity findings since last scan; 2 are in production-reachable code paths."

This makes postmortems straightforward — you can see exactly when a finding entered or left the system.

Tuning Scan Frequency

Most teams should leave defaults on. For specialized needs:

• Sensitive production workloads — set scan.interval: 5m on the asset label criticality:sensitive.
• Dev / sandbox environments — set scan.interval: 24h to reduce noise.
• Vendor SBOMs with SLA windows — set SLA-driven rescans in TPRM.

Settings are in Policies → Scan Policies or via the safeguard policy CLI.

Performance Impact

Continuous scanning is designed to be invisible to your systems:

• Agentless scans pull metadata from registries and Git providers; no compute runs on your side.
• The runtime collector uses eBPF where possible (Linux hosts, Kubernetes) — ~1% CPU overhead at p99.
• Feed-driven rescoring runs in Safeguard cloud; no customer-side work.

API

Trigger an on-demand scan:

safeguard scan --asset <asset-id>
safeguard scan --project <project> --all

Subscribe to scan events via webhook:

POST /v1/webhooks
{
  "event": "scan.finding.created",
  "url": "https://your-endpoint/webhook",
  "filter": { "severity": ["critical", "high"], "env": "production" }
}

Related

• Vulnerability Prioritization (Reachability) — how findings get scored after they're detected.
• Asset Discovery — what gets scanned in the first place.
• Zero-Day Discovery — how Safeguard's own research feeds into scans.
• Guardrails & Enforcement — how scan results drive policy.