A one page security playbook for a development team lists who owns what, which checks run in the pipeline, how to handle a finding, what to do with a leaked secret, how to report an incident, and where to ask for help. Keep it in the repository, keep it short, and review it each quarter.
Why one page
Long policies are read once, if at all. A single page that lives next to the code gets opened when someone has a real question. NIST's Secure Software Development Framework makes the point that secure practices must be added to whichever development model a team already uses, so the playbook should describe your actual workflow, not an ideal one.
The template
1. Owners and contacts
- Service owner, backup, security champion
- Where to ask: channel name and office hours time
- Who to call out of hours
2. What runs on every pull request
- Secret scan, dependency scan, static analysis, tests
- What blocks a merge and what only warns
- How to read the summary comment
3. How to handle a finding
- Triage weekly, owner decides one of four things: fix, schedule, mitigate, accept
- Target times by risk class
- Where to record the decision
4. Dependencies
- How updates are made, how often, who reviews
- Rules for adding a new library: maintained, licence allowed, no known exploited flaws
5. Secrets
- Where secrets live
- If one leaks: revoke, rotate, check logs, tell the security contact
- Never paste secrets in chat or tickets
6. Exceptions
- Request template link, approver, maximum duration
7. Incidents
- What counts: suspected leak, unexpected access, suspicious dependency change
- Who to tell first, how to preserve evidence, who leads
8. Release checks
- A short list: scans clean for new findings, no open exceptions past expiry, rollback plan ready
A compact version
| Section | One line |
|---|---|
| Owners | Named people, not teams alone |
| Pipeline | What runs and what blocks |
| Findings | Four decisions, with dates |
| Dependencies | Weekly update routine |
| Secrets | Revoke first, ask later |
| Exceptions | Written, approved, expires |
| Incidents | Tell early, preserve evidence |
| Help | A channel and a person |
Keeping it alive
- Store it as a Markdown file in the repository root
- Require a pull request to change it, so history is visible
- Review it at the start of each quarter, and after any incident
- Link to it from the pull request template and new hire guide
Each time someone asks a question the page does not answer, add the answer.
Quick check
Should every team write its own?
Start from a shared template and let teams change the details. Common structure makes help easier, and local details make it useful.
How long should it be?
One page, plus links for detail. If it grows past two screens, move the detail out.
Safeguard offers a free scan at gold.safeguard.sh/scan that a team can run to fill in the pipeline and dependency sections with real data.
Sources
Last reviewed: 19 October 2026.
