Two things are true of every system you're responsible for. It's running, which means the question of whether it's safe never closes. And you're doing this on empty — fewer hours than systems, no dedicated security team, and a list of things you know you should be monitoring and aren't.
This book is written for that condition rather than around it.
There are three questions you ask about a piece of software, and they belong to three different disciplines.
May I use this? is a licensing question. It's answered once, at the beginning, and the answer is stable for years. That's the Open Source Licensing Guide.
Should I depend on this, and how do I ship it safely? is a supply chain question. It's answered when you choose, and re-answered whenever you upgrade. That's The Weight of Your Dependencies.
Is what's running still okay, and what do I do when it isn't? is this book.
Why this is a separate book¶
The artifact you shipped does not change. Everything around it does.
The CVE database gets a new entry. A researcher publishes a proof of concept. A vendor you depend on gets breached and your credentials were in the blast radius. A certificate expires. A base image you pinned — correctly, deliberately — turns out to have been carrying a vulnerable library the whole time, and nobody knew until Tuesday.
None of that is a dependency selection problem. You can do the supply chain work perfectly and still wake up to it.
Here is the moment that made this book necessary. In March 2026, an attacker compromised the Trivy vulnerability scanner, used it to harvest publishing tokens from LiteLLM's CI, and published two malicious versions of litellm to PyPI. They were live for forty minutes.
The supply chain guide has plenty to say about that: pin your dependencies, use a lock file, run cooldowns, and note that everyone running the pinned container image was untouched. All true, all useful, all preventive.
But if you were exposed, none of it helps. What you needed at that point was to sweep a fleet for indicators, reason about what one leaked Kubernetes service account token can actually reach, audit a cluster for pods you didn't create, review logs from a specific date, and decide whether "we upgraded in April" closes the incident. (It doesn't. Rotation closes it.)
That's a different discipline with different tools, different reflexes, and a different relationship to time. Supply chain security is about making good decisions. Security operations is about the fact that you will sometimes have made bad ones, or good ones that expired.
The honest version
Most security writing is preventive, because prevention is the part you can sell. The response side is unglamorous — rotation spreadsheets, alert triage, arguing about severity scores, and the specific misery of discovering that a credential you rotated in April was also in a config file nobody grepped.
This book is mostly about that part. It's written from a real environment — a sprawling homelab and an institutional HPC estate — rather than from a vendor's reference architecture, which means it includes the coverage gaps too. There's a whole section admitting what isn't monitored and why.
The spine¶
One distinction runs through every chapter:
Build time asks "should this artifact exist?" Run time asks "is what's running still okay?"
The artifact doesn't change. The vulnerability database does. A gate answers a question once, at a moment, and then it's done. A monitor answers the same question continuously, forever, and its answer changes without anyone touching the code.
Most teams have built the gate and called it security. The gate is the easy half.
That distinction gets a chapter of its own — Build Time vs Run Time — because everything else here is an application of it. It carries the one-question test for sorting your own controls, and the sentence the book keeps coming back to: a scan that passed is not evidence, it's a timestamp.
What's here¶
-
The mental models. Build time vs run time, the vulnerability lifecycle, blast radius, why detection is not remediation, and risk that expires.
-
The standing discipline. Continuous scanning, SBOMs as living inventory, patching and the backport problem, secrets, rotation, monitoring.
-
What you do when the answer is no. The first hour, scoping blast radius, rotation under fire, evidence, disclosure, and writing the postmortem.
-
Executable procedures, not prose. CVE triage, the accepted-risk register, IoC sweeps, emergency rotation.
-
A real environment, named: the tools actually deployed, what they cover, and — the useful part — what they don't.
-
Case studies read from the response side. Not how they got in, but how the response went, and where it went badly.
Who this is for¶
People who operate things. Not a SOC with twelve analysts and a SIEM budget — a person, or a small team, responsible for more systems than they can hold in their head, who need to know what to check first and what can wait until Monday.
If you're looking for the prevention side, start with The Weight of Your Dependencies and come back here.
This book is being written
It's a skeleton with load-bearing walls, not a finished building. Sections carry roadmaps of what belongs in them. Where a chapter doesn't exist yet, the index says so rather than pretending otherwise.