Description
Your code works, it deploys, it returns 200, and you have no idea whether it is secure. That is the problem, because “it works” and “it cannot be broken into” are two different things, and nobody taught you to see the second one. The AI agent wrote you an endpoint that fetches a note by id without checking it is yours, and you approved it because it returned the right note in the demo; in production, anyone asks for note 42 while claiming to own note 41 and walks off with the whole database. It left the API key in an environment variable that ended up in the repo, and by the time a bot finds it your cloud account is already drained. It built a query by pasting user input into the SQL string, and one quote blows it open. It stood up a container running as root with a shell inside, left the database listening on the public internet, and wrote the password it just received into the log, in full. None of this throws an error. The demo works, the happy-path tests pass, and the system is quietly one move away from a breach with your name on the commit. And it is not that you are a bad engineer: reviewing the security of a system is a skill apart from building it, most people never learn it, and that is exactly why it is the scarcest and best-paid skill in the field. The day an attacker finds the hole, they do not ask whether you knew. They just walk in.
This book is about the skill that decides whether what you build holds up against someone who genuinely wants in: reviewing the security of a system and seeing the hole before the attacker does. It starts where you are today. An AI agent writes more and more of your code and your infra, and it writes it in a way that compiles, deploys, and passes the happy path, and fails in the most expensive way there is: leaving a door open. Your job stopped being to type the security and became to see it, and this book trains you for that. You will learn to think like the attacker, to look at your own system and see first what an adversary sees: where you get in, what you reach from there, and what you carry off if you do. You will learn to ask every piece the same three questions, who can reach it, what they can do once inside, and how far the damage spreads if one credential leaks, so no surface slips past you. From there you walk, one by one, through the concrete ways a real system opens up. The secret that ended up in the repo and how it is actually handled. The authentication that trusts anyone who asks. The access control that lets someone read another user’s note just by asking for it. The injection that turns one quote, or one message, into control of your database. The dependency with a known flaw you dragged in without looking. The container running as root and the bloated image with a shell inside. The unencrypted data and the log that prints the password. The network that leaves the database open to the whole internet. And when something goes wrong anyway, how to see it, contain it, and survive it with a record that tells you what they touched. Each chapter opens on a concrete breach in Quill, the notes app that runs through the book, teaches you to see it before it gets seen from outside, and leaves the review made instead of the problem open. It closes on the engineer you become when this comes out on its own: the one trusted to sign off on what ships to production, because when you approve something, people know you looked at where it breaks. For the engineer who ships systems and wants to stop praying that nobody looks closely, and become the one who looks first.
Who this was written for
This book is for: the engineer who already lets an AI agent write the app, the infra, the authentication, the queries, and the cloud config (vibe coding), and is now left with the part the agent cannot do: looking at all of it and knowing whether someone can break in before they do. The one who ships a service that works, returns 200, and passes the happy path, with no way to see that it is one request away from leaking every user’s data. The one who knows “security matters” but never learned to see the attack surface of what they built.
The method behind it
The 3 Keys to Becoming the Engineer Trusted to Sign Off on What Ships to Production. The method for reviewing the security of a system and seeing the hole before the attacker does. Instead of trusting that “it works” means “it is secure,” you ask every piece three questions: who can reach it, what they can do once inside, and how far the damage spreads if a credential leaks. With those three you run the whole attack surface, the secret in the repo, the authentication that trusts anyone, the broken access control, the injection, the dependency with a flaw, the container as root, the unencrypted data, the open network, and you see what breaks before it gets broken from outside. You go from the engineer who ships and prays to the one trusted to sign off on what ships to production, because when you approve something, they know you looked at where it gives.
Everything inside
- Chapter 1: The pentester typed whoami and got root. I had approved that deploy
- Chapter 2: Before I fix anything, what does someone trying to break into Quill see first?
- Chapter 3: The agent left the API key in the repo. How much damage does it do before I rotate it?
- Chapter 4: The login the agent left open: anyone says they’re Martin and Quill believes them
- Chapter 5: I asked for note 42, which isn’t mine, and Quill handed it over without blinking
- Chapter 6: One quote in a note title, and suddenly I’m reading the whole database
- Chapter 7: The agent added a library with a known flaw. How many more came in without me looking?
- Chapter 8: I opened Quill’s image and inside was a whole system running as root
- Chapter 9: I found a user’s password printed, in plain text, in Quill’s log
- Chapter 10: Quill’s database was listening to the whole internet and nobody noticed
- Chapter 11: It happened anyway. How do I know what they touched and get them out without blowing everything up?
- Chapter 12: The day the sign-off on what ships to production became mine
