# Lesson 2 - Security: Secure as you build > Source: > Published: 2026-07-14 19:09:11+00:00 **Filing security under later does not work**. For most of my career, when a vulnerability got disclosed, attackers needed days, often weeks, to turn it into a weapon. Defenders had a head start, and it's not the case anymore. A few days from calling the build ready, one of the packages I lean on got poisoned. A release of a core dependency, one that sat deep in my stack, went up on the package index carrying a deliberate compromise. Not a bug. A rigged version built to harvest secrets: the keys, tokens, and passwords a developer has lying around. It got caught and pulled fast, but that doesn't help when it's already sitting in your own dependency tree. I froze for a few moments, then got to work. It hit hard because I already knew AI was making the challenge of securing what we build worse. I'd read about it and nodded along, then deferred the library hardening until the app was built and production-ready. The warning had been in front of me for months, filed under later. ### Exposures - And it wasn't a one-off. That same week, a second dependency I relied on was hijacked in a similar way, a remote-access trojan slipped into its latest version. Two compromises, two packages I used, seven days. - That is the pace now. Poisoned code goes live and lands in thousands of dependency trees before the advisory is even written. The same speed that lets us build lets them attack. ### Security First - I threw out the ship-it-then-secure-it plan. I stopped what I was doing and dealt with security first. **In the AI era, security is not a phase after the build but a part of it.** ### Assessment Before I changed a thing, I worked out whether it had actually reached me. - Was it ever pulled into a production build? No. I hadn't built for prod during the exposure window, so the rigged version never got there. - Locally? I'd been in active development with hot-reload on, so I never triggered the full rebuild that would have freshly installed it. Most likely clear, not certain. - What could it have reached? This package sat deep in my stack, close to my environment and my secrets, and the compromised code was built to hunt for exactly that. So I stopped guessing and treated every key and token as already compromised. ### Mitigation Once I knew roughly where I stood, I hardened past the incident, not just against it. **Every dependency you add is someone else's attack surface borrowed into yours.** - Rotated every token. - Properly segregated staging and production. They'd been sharing more than they should, a cache instance and some credentials I'd waved off as low-risk. Not anymore. - Pinned every dependency, frontend and backend, to exact versions by hash. Nothing floating, no silent updates. - Stood up a dependency-review framework so new bumps get looked at instead of auto-trusted. - Changed when I reach for a library at all. When the second one got hit, I didn't wait for a clean version. It was small enough that I pulled it out and wrote the few lines I actually needed myself. ### Gap The dependency scare wasn't the only place I'd gone loose. Around the same time, I ran a proper security review and found something closer to home. - Once I'd stopped reading every line, the agent had quietly dropped an authorization check. The scoping that should have kept one tenant's data walled off from another was just gone. - It hadn't caused a breach; the identifiers weren't guessable, but the gate was standing open. - That is now a standing rule: a security review runs as a gate inside the build loop, not a pass tacked on at the end. When AI is writing this much of the code, you pull every review left, security included, or the code rots as fast as you build it. ### Manual Levers - Not all of it is automated, and that's deliberate. Service tokens rotate on their own now. Password rotation is streamlined, but I still choose to run it myself. ### The Lane **The most important lane in software right now is AI-native security: prevention, threat assessment, and mitigation built for a world where attackers move at machine speed.** - You don't bolt this on at the end. It decides whether everything else is even safe to ship. - That week took away the last illusion that there was time to prepare. Getting the edge back means defending as fast as they now attack. - It's a good time to be in this lane. If you're building here, or thinking seriously about it, I'd love to compare notes.