Scheduling dependency and security scans with cron
Periodic scans of what's actually deployed. They back up CI-time scanning and don't replace it.
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 scans is treating the output as the alert. A scanner that writes a report to a log file nobody reads gives you the same protection as not running it. What matters is whether a new finding 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, and a week of exposure to 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. It flags a run that never happened, and run history is visible across every host. Runs missed while a machine was off are caught up when it reconnects, up to a cap.