Case studies read from the response side.
The Weight of Your Dependencies covers a lot of incidents already, and covers them well — how the attacker got in, what the mechanism was, what would have prevented it. This section deliberately does not duplicate that.
These are the same class of events viewed through a different lens: not how it happened, but how the response went. Who found out, how long it took, what got rotated in what order, what the scanner said versus what was true, and where the response itself went wrong.
That's a distinct body of knowledge, and it's much less written about, because "we detected it in four hours and then took eleven weeks to finish rotating" is a less flattering story than the technical teardown.
What belongs here¶
| Kind of case | Example of the question it answers |
|---|---|
| Detection stories | What actually noticed? Was it your tooling, a vendor advisory, or someone on Mastodon? Honest answers here are humbling |
| Rotation postmortems | The gap between "we rotated the credential" and "we rotated every credential that credential could reach" |
| Triage failures | The finding that was in the scanner output for eight months at medium severity |
| False confidence | Green dashboards measuring the wrong thing. A passing pipeline is not a working one |
| Response-time reality | Detection in hours, propagation in minutes, remediation in weeks. Where that asymmetry actually bit |
Cases¶
- The Hole Shaped Exactly Like Good News — a fleet vulnerability scanner that covered two of seven hosts for six weeks while every alert, exporter and dashboard reported healthy. It had not decayed; it had never landed. The rollout succeeded once under a human typing a sudo password, and the two hosts that kept working were the two where it was never needed
Planned cases¶
- LiteLLM / TeamPCP, from the response side — the supply chain writeup covers the attack. The response side is the interesting half: a forty-minute exposure window that nobody could answer for months, an FBI advisory arriving in July about credentials taken in March, and the specific problem of proving a negative across a fleet
- The eight-month medium — how severity scores become a filing system for things you've decided not to think about
- Rotating in the wrong order — the bootstrap problem, told as a story
- When the scanner was right and nobody read it — alert fatigue as a root cause, with the alert count that caused it. Its mirror image is already written up above: the scanner that was silent because it had stopped looking
The unflattering genre
Attack teardowns get written because they make the writer look observant. Response postmortems get written much less often, because they mostly document a period during which the author was confused, tired, and behind.
That's exactly why they're worth writing. The teardown teaches you what an attack looks like. The response postmortem teaches you what you look like during one, which is the part you can actually change.