Surat Mukker Engineering Leadership & Advisory
Adapting Software Development in the Age of AI

Lesson 2 - Security: Secure as you build

Two dependencies I lean on were compromised in the same week, days before I meant to call the build ready. I had deferred the hardening until the app was done, which is the plan that had just failed. Filing security under later does not work any more.

July 14, 2026 · Lesson 3 of 6 in the series · Discuss on dev.to

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

Security First

Assessment

Before I changed a thing, I worked out whether it had actually reached me.

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.

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.

Manual Levers

The Lane

Keep reading

What actually changes when you build software with AI in the loop. One practice area per lesson.