Web applications change continuously. Packages are updated, configurations are modified, new endpoints are added, and cloud infrastructure is reconfigured - often by different people on different teams. A security scan you ran last month reflects the state of your application last month, not today.
Scheduled scanning solves this by running automatically at set intervals and alerting you only when something changes. This post explains how to set it up and what to watch for.
The problem with one-off scans
Most developers who run security scans do it once - before a launch, before a compliance review, or after a breach. This creates long gaps during which vulnerabilities can be introduced and go undetected.
Common scenarios that introduce new vulnerabilities between scans:
- A dependency update that ships with a known CVE
- A misconfigured environment variable that exposes debug mode in production
- An S3 bucket policy change that accidentally enables public listing
- A new API endpoint deployed without authentication
- A server config change that removes an HSTS or CSP header
None of these require an attacker - they are ordinary development mistakes that scheduled scanning catches automatically.
How delta alerts reduce noise
The biggest problem with alerting on every completed scan is alert fatigue. If your application has 12 known findings and your scanner emails you about all 12 every week, you will start ignoring the emails - including the one that contains a new CRITICAL finding.
Shieldome uses delta alerts: it compares each scheduled scan to the previous scan of the same target and only sends an email when the results differ. Specifically:
- A new finding appears that was not present in the last scan → email with new finding details
- No change between scans → no email
This means the alert is always a signal, not noise. When you receive a scheduled scan email, something actually changed.
Setting up a scheduled scan
In the Shieldome dashboard:
- Go to Scan History → Scheduled Scans tab
- Click + New Schedule
- Enter your target URL and choose a frequency (daily, weekly, or monthly)
- Set the hour - choose a low-traffic time like 03:00 UTC to avoid TTFB noise in performance metrics
- Save
The schedule fires at the next configured slot. All results appear in Scan History alongside manually triggered scans, marked with a calendar icon.
Choosing a frequency
| Frequency | Good for |
|---|---|
| Daily | Production applications with continuous deployment, e-commerce, SaaS products |
| Weekly | Staging environments, applications updated weekly, lower-traffic sites |
| Monthly | Static sites, compliance evidence generation, infrequently updated infrastructure |
When in doubt, weekly is a practical starting point. It catches most post-deploy regressions without generating excessive scan data.
Using scheduled scans for compliance evidence
Security frameworks like ISO 27001, SOC 2, and PCI DSS require evidence of regular vulnerability assessments. Monthly scheduled scans generate a reproducible audit trail: timestamped scan records in your history, downloadable PDF reports, and a consistent methodology across all runs.
The Scan History filter lets you export all scans for a specific domain and date range - a five-minute task when your auditor asks for the last 12 months of assessments.
Combining scheduled scans with CI/CD
Scheduled scans and CI/CD scanning are complementary, not alternatives. CI/CD scans catch vulnerabilities introduced by code changes before they reach production. Scheduled scans catch changes that happen outside the code - infrastructure updates, third-party configuration changes, cloud policy drift.
A practical setup: CI/CD scan on every PR merge (using the GitHub Actions integration), plus a weekly scheduled scan on the production URL to catch everything else.
Tracking improvement over time
Scheduled scans build a security history for each target. The Trends chart in Scan History plots risk score and finding counts across your last 30 scans for a given URL. Over time this shows whether your security posture is improving, stable, or degrading - and when specific events (deploy, config change, dependency update) correlated with finding changes.
Set up your first scheduled scan - the weekly schedule is available on all plans, no credit card required to start.