A Cybersecurity Tale Told in 3 Parts

Ali Naqvi

Part 1 – Your Resident Frustrated Developer...A Story of Passion

Ever had one of those days? You know, the one where you’re deep in the code, knee-deep in brilliance, crafting the product that’s going to take your company from a startup in a garage to a tech giant with its own rocket ship division. And then....BOOM! 

An email. From. The.  Security. Team. 

Subject: URGENT: Critical Vulnerabilities Detected. Action Required! 

Of course, it’s urgent. It’s always urgent. The world is apparently on fire every Tuesday at 8:30am aaannnddd Friday at 5:30pm aaannnddd...you get the point.  So, I hesitatingly open the email, hoping it’s just a false alarm, but nope it’s not.  What greets me is a 3-page PDF riddled with vulnerabilities, red alerts (so many alerts!), and enough technical jargon to make a cryptographer cry. 

Look, I get it. Hackers, bad guys, black hats—oh my!  But let’s be real, I’m busy. Not "mildly occupied" busy. I’m "haven’t-showered-in-three-days-because-I’m-building-the-next-big-thing" busy. And here comes Security like, “Hey, remember that obscure library you imported in 2018 for a feature no one even uses anymore? Yeah, it’s got vulnerabilities.  Better drop everything and fix it.  Today.”  Guys, I’m trying to build something new here. A revolutionary product—the kind of thing that makes Elon want to tweet that you took his great idea before he thought it up. But apparently, that’s less important than the 0.01% chance some hacker from the dark web might exploit a vulnerability in a package I don’t even use. 

Ah, the dumpster fire that is the dependency package. The unsung heroes, initially, that slowly become the creepy clowns of my nightmares. You know the ones—those handy little packages you import thinking they’ll make your life easier? Yeah, they’re more like exercise equipment you buy that turn into places to hang clothes on until you start accidentally stubbing your toes and want to set it on fire.  At first, everything’s great, “Oh look, this library handles all my authentication needs!”  Fast forward two years, that same library is now a ticking time bomb, “allegedly” threatening to bring down my entire system. Now, Security wants me to update this thing because, apparently, hackers might exploit it if they learn ancient Sumerian to solve a riddle and steal John Wick’s stuffed dog and escape alive.  But here’s the real kick in the marbles: I’m not even calling the vulnerable piece of the code! 

So, what happens next?  I’m forced to drop everything and get further behind. We don’t schedule time for fixing ancient code, but now I’m in the appliance repair business for older appliances they don’t stock parts for anymore.  And it’s not just a quick fix, my friends. Refactoring code is like playing Jenga...on a boat...in a storm. One wrong move and you are back to square one.  Updating one library means testing, re-testing, re-re-testing, while breaking things that shouldn’t have been breakable. Time?! Time has no meaning here. I’ve lost entire seasons of productivity (and my dating life!) because I had to upgrade a library that I used once... for logging. LOGGING! No one even reads the logs! They’re like subtitles during a football game. 

I can already hear the security team shaking their heads. “But vulnerabilities are serious!” they cry, clutching their compliance checklists. Let’s not forget the forward momentum part of this. While I’m refactoring, my backlog grows longer than the waitlist for Taylor Swift concert tickets, my deadlines are cooked and my hopes of getting through one sprint without constant distractions. All because I had to update a library that could only be exploited by someone who starred in the Multiverse of Madness. And here’s the thing: by the time I finish refactoring, the next batch of security vulnerabilities will already be waiting in my inbox. “Hello Darkness, my old friend...” 

So here I am, doing battle with dependency demons (like a coding Constantine) while the rest of the team wonders why code isn’t done yet.  They just want the product shipped.  Have I already mentioned that we don’t schedule time for fixing code?  Until next time, I’ll be here, refactoring away, slowly losing my will to live. 

Well readers, stay tuned for our next part, where someone from the Security team will opine on their miseries in the battle to remediate code!