Scheduling dependency and security scans with cron
Periodic scans of what's actually deployed — a backstop, not a replacement for CI-time scanning.
The problem
CI-integrated tools (Dependabot, Renovate, `npm audit`/`pip-audit` in your pipeline) catch vulnerable dependencies at commit and PR time — that's the primary defense and where most of this work should happen, because it blocks the bad dependency before it ships. A cron job on a running host is a backstop for what CI can't see: a vulnerability disclosed after deployment for a package already running in production, or drift on long-lived servers that don't get redeployed often.
The failure mode specific to this use case is treating scan output as the alert. A scanner that just writes a report to a log file that nobody reads on a schedule nobody checks provides exactly the same protection as not running it — the value is entirely in whether a new finding actually reaches a person.
CI-time scanning is the primary defense; cron is a backstop for already-deployed hosts.
If you don't already have Dependabot/Renovate or an audit step in CI, add that first — it catches the problem before it ships, which a cron job on a live host never can. Use the cron version specifically to catch newly disclosed CVEs affecting packages already deployed on long-lived hosts.
Recommended schedule
0 5 * * 1
Weekly, Monday morning, is enough for a backstop scan — new CVEs don't need same-day detection on a host that isn't rebuilt daily, but a week of silent exposure on a known vulnerability is a reasonable outer bound.
Check any expression at the cron parser, or browse more at the cron guide.
Example crontab entry
# norc: security-scan Weekly dependency vulnerability scan
0 5 * * 1 cd /opt/myapp && /usr/local/bin/npm audit --omit=dev --json > /var/log/npm-audit.json 2>&1 || /opt/scripts/alert.sh "audit findings"Failure modes to watch for
- Scan output written only to a log file nobody reads, so a genuine new finding has the same visibility as no finding at all.
- Exit-code handling that treats any nonzero exit (including "vulnerabilities found") the same as a scanner crash, either drowning real findings in noise or masking them entirely.
- Scanning the repo checkout instead of what's actually deployed on that host, missing drift where the running version differs from what's in version control.
- No de-duplication: the same known, accepted-risk finding re-alerts every single week with no way to acknowledge and suppress it.
How norc helps
norc treats a scan job like any other scheduled task — run history and exit codes visible across every host — so "the scanner stopped running three weeks ago" is itself a visible failure, not a silent gap.