The mental models. Everything else in this book is an application of one of these.
Security operations goes wrong in predictable ways, and most of them are conceptual rather than technical. A team with excellent tooling and a bad model of what a vulnerability is will generate 1,200 alerts, triage none of them, and get breached by the one that mattered. A team with mediocre tooling and a clear model of blast radius will rotate the right six credentials in an hour.
The spine¶
Build time asks "should this artifact exist?" Run time asks "is what's running still okay?"
Hold onto this. It's the sorting hat for every practice in this book.
A build-time gate evaluates something once, at a moment, against what was known then. It produces a yes or a no and then it is finished. Signature verification, license checks, npm ci against a lock file, an SBOM being generated — all gates.
A runtime monitor evaluates the same artifact continuously, and its answer changes without anyone touching the code. The container you built in March is byte-identical in August. Whether it's safe to run is not.
Teams routinely build the gate, watch it go green, and believe they've done security. The gate is the cheaper half and the one with a clear finish line, which is exactly why it gets built first and mistaken for the whole job.
Available now¶
- Build Time vs Run Time — the chapter the rest of the book applies. Includes the one-question test for sorting your own controls, why CI vulnerability scanning is a gate wearing a monitor's clothes, and the half-life idea: every gate's answer decays, and you should know how fast
Planned chapters¶
| Chapter | The question it answers |
|---|---|
| The Vulnerability Lifecycle | What actually happens between "a researcher finds something" and "your scanner tells you" — embargo, CVE assignment, NVD enrichment lag, and why your scanner's silence is not evidence |
| Blast Radius | The only question that matters during an incident: what does this credential, host, or token actually reach? How to know before you need to know |
| Detection Is Not Remediation | The gap where most incidents actually live. A quarantined package doesn't un-exfiltrate a credential |
| Risk That Expires | Accepted risk is a legitimate engineering decision and a terrible permanent state. Why every acceptance needs a date on it |
| Signal and Noise | Alert fatigue is not a personal failing, it's a design failure. Tuning as a first-class security control |
| Time as an Axis | Detection takes hours, propagation takes minutes, and remediation takes weeks. Most security decisions are really scheduling decisions |
Why concepts first
I've watched a lot of teams buy tools to fix problems they hadn't defined. The tool arrives, produces output nobody can act on, and becomes another dashboard nobody looks at — which is worse than nothing, because now there's a green checkmark next to the thing you aren't doing.
The chapters here are short on purpose. They exist so that when you get to Operations and Runbooks, you already know which question each procedure is answering.