A cadence runbook is a one page table that lists every scan trigger, who owns it, how deep it goes, what it alerts on and what record it leaves. If a trigger is not in the table, it is not a commitment. Writing it down also makes gaps visible.
Why write it down
Cadence tends to live in people's heads and in scattered CI files. Then someone leaves and a nightly job quietly stops, or an auditor asks how often you scan and the answers differ. A runbook gives one source of truth and a thing to review.
The template
| Trigger | Owner | Depth | Alert rule | Evidence kept |
|---|---|---|---|---|
| Pull request | Each dev team | Quick, changed manifests | Block on agreed findings | Check result on the PR |
| Merge to default | Platform team | Full | Notify on new critical | Stored scan result |
| Release or tag | Release manager | Full plus inventory | Gate on policy | SBOM and report per version |
| Deploy | Platform team | Running image digest | Alert on new findings | Result on deploy record |
| Nightly | Security | Rescan stored inventories | New, worsened, reopened only | Run log and findings diff |
| Advisory signal | Security on call | Targeted match | Page on exploited and present | Timeline of action |
| Weekly | Team leads | Digest review | Owner assigned for open items | Meeting notes |
| Quarterly | Security | Coverage and rule review | Gaps become tickets | Review record |
Steps to fill it in
- Inventory your triggers. Read your CI files and scheduler lists. Add what you find, not what you wish.
- Name an owner as a team. A named person leaves. A team persists. Add a backup.
- State depth. Quick or full, and which ecosystems and artifacts are in scope.
- Write the alert rule in one sentence. If you cannot, the rule is unclear.
- Say what evidence is stored and for how long. This is what you will show to a customer or auditor.
- Add a health check for each scheduled row. See how to detect a silently failing scan.
- Review it every quarter. Compare the table to reality and fix whichever is wrong.
Common gaps the table exposes
- A scheduled job with no owner.
- No row for release branches that customers still run.
- Alert rules that page for everything.
- No evidence retention, so past scans cannot be shown.
- No row for container images or infrastructure files.
A short test
Ask three people on different teams how often your code is scanned and by what. If the answers differ from each other or from the table, update the table or fix the practice.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning, policies and gates, and compliance evidence automation. You can try a free scan at gold.safeguard.sh/scan.
Quick check
How long should the runbook be?
One page. If it grows beyond that, link out to detail, but keep the table.
Who approves changes?
The security owner, with the platform team consulted, since most triggers live in their CI.
Last reviewed: 19 October 2026.
