December 15, 2025
•
12 min read
•
Alexandra Costea Ifrim
Anyone who's worked in or for a SOC knows the grind. The constant battle to keep up with alerts. The endless game of patching here, scripting there, automating whatever you can just to stay afloat.
And in this battlefield of duct tape and workarounds, sometimes a hero emerges.
You know the type. That analyst who refuses to accept "this is just how it is." The one who stays up late watching Python tutorials, hunting for ways to automate one more thing so they can finally focus on actual threats instead of drowning in noise. They write a little integration here, a dashboard there, scripts that connect tools that were never meant to talk to each other.
Their colleagues start coming to them when they're stuck. Management knows they're the go-to when decisions need to be made. They've risen from the ranks to become the undisputed SOC hero.
But there's a catch. There's a dark side to this story that nobody talks about.
Shadow IT. Technical debt. And a ticking time bomb that's often more dangerous than the threats the team is supposed to be defending against.
This isn't an isolated problem. It's a pattern that plays out across security operations centers worldwide, regardless of size, industry, or sophistication.
A SOC analyst identifies a gap in their tooling. Maybe alerts from different vendors aren't correlating properly. Maybe there's no single place to see everything happening across the environment. Maybe reporting takes hours of manual work that could be automated.
So they build something. A Python script. A custom dashboard. An integration that pulls data from five different tools and presents it in a way that actually makes sense.
And it works. It saves time. It catches things that would have been missed. It makes the team more effective.
Management loves it. The analyst gets recognition. Maybe even a promotion.
But nobody asks the critical questions:
The answer to most of these questions is usually the same: nobody knows, and nobody's asking.
While enterprise development teams-with code reviews, CI/CD pipelines, and proper processes-see technical debt consume 20-40% of their development time (IDC, December 2025), SOC analysts are writing code with none of those safeguards.
And honestly, can you blame the overworked analyst for not maintaining the code? For not having time because they're too busy writing detection rules? I mean, we've all been there: why change it if it works? This is what too often a SOC's functioning is based on.
And here's the irony that nobody wants to admit: the security team is creating security vulnerabilities.
As one CISO put it: "We're often some of the worst about quickly throwing solutions together, often with zero consideration about how and if they'll need maintaining. The system thrown up during an incident quickly becomes something you are afraid to patch five years later."
Think about what this actually looks like in practice:
Custom scripts with API keys in plain text. Because storing them properly would take an extra 30 minutes, and the incident needs to be resolved now.
Integrations with weak or no authentication. Because the tools weren't designed to talk to each other, and the "quick fix" becomes permanent.
Dependencies that haven't been patched in years. Because nobody wants to risk breaking something that's "working," even if it's running on libraries with known vulnerabilities.
Code that bypasses security controls. Because the analyst needed elevated permissions to make it work, and those permissions never got revoked.
According to recent research, nearly 1 in 2 cyberattacks stem from shadow IT, with an average remediation cost of $4.2 million (UpGuard, October 2025).
Read that again: the tools built to defend against attacks are creating the vulnerabilities attackers exploit.
The scope of the problem is staggering:
And now AI code generation has entered the picture. ChatGPT, Claude, GitHub Copilot-suddenly the hero doesn't even need to learn Python. The AI writes it for them.
Which would be great, except SOC analysts often lack the software development foundation to ask the right questions. And AI doesn't ask clarifying questions about security requirements.
The result? AI-generated code contains vulnerabilities 45% of the time (Veracode, September 2025). The research is sobering:
But here's what makes it worse: AI creates a false sense of security. The code looks professional. It runs without errors. It solves the problem. So why would anyone question it?
OX Security describes this as the "Army of Juniors" problem-AI writes code like a junior developer, but it removes the bottlenecks that would normally catch problems before they reach production. Vulnerable code gets deployed faster than ever before, at scale, with less oversight.
And in a SOC environment, where the "deployment" is often just "start running this script," there's essentially zero quality control.
And then you have the desperate moment when the hero decides to move on. I mean, let's face it-they're ambitious, and everybody knows that the SOC is for many just a tour of duty-do your time, learn the ropes, then move to something better.
That custom dashboard that's been running for three years? Nobody else knows how it works.
The original builder left for a better opportunity six months ago. They took their knowledge with them. Maybe they wrote some documentation-a README file, some inline comments. More likely, they didn't have time.
Now you have a few options, none of them good:
Best case: The system keeps running, but you can't modify it. New vendor? Can't add it. Bug discovered? Can't fix it. You're locked into whatever the hero built, forever.
Worst case: It breaks during a critical incident. Alerts stop flowing. Your correlation logic dies. And you're blind-right when you need visibility the most.
Nightmare case: It becomes your breach point. An attacker discovers those hardcoded credentials in a script that got accidentally committed to a public GitHub repo. Or they exploit the unpatched dependency in your custom dashboard.
Your own automation, built to protect you, becomes the weapon used against you.
Here's what's critical to understand: this is not the analysts' fault.
The hero isn't incompetent. They're not reckless. They're not ignoring best practices out of laziness.
They're drowning in a tooling environment that doesn't serve their needs, and they're doing the best they can with the resources available.
Consider what a typical SOC analyst faces:
Tool sprawl: I've worked with SOCs managing everything from 8 tools to over 20-SIEM, EDR, firewall manager, email security, threat intelligence platform, SOAR, ticketing system, vulnerability scanner. Each one needs configuration, maintenance, and expertise.
Budget constraints with impossible expectations. The organization won't pay for another tool, won't upgrade to the tier with needed features, won't hire a developer to build it properly. But they still expect the job to get done.
Time pressure that kills quality. Incidents don't wait. When alerts are flooding in at 2am, "build it right" loses to "make it work" every single time.
Skill mismatch. SOC analysts are trained in threat hunting, incident response, and security analysis. They're not software engineers. But we expect them to become both when the situation demands it.
The real problem is that we've built a security operations model that requires heroics to function. We've created an environment where custom code and shadow IT aren't aberrations-they're survival mechanisms.
The solution isn't to stop SOC analysts from writing code. The solution isn't more training on secure development practices, though that wouldn't hurt.
The solution is multifaceted: tooling, process, and culture need to change together.
Better platforms: Security operations needs platforms that actually integrate-not "we have an API" integration, but real correlation without custom code. Tools that work out of the box and scale with the team.
Real governance: If analysts write code, treat it like real development. Version control for everything. Code review before production. Documentation as a requirement, not a nicety. Testing and staging, even for emergency fixes. Ownership and succession planning for every piece of custom code.
Cultural shift: Stop rewarding heroics, start valuing sustainability. Celebrate boring, reliable systems over clever hacks. Make time for maintenance. Speed up procurement so analysts don't need workarounds. Consider a platform engineering team to handle integrations, freeing analysts to focus on threats.
The reality: You can't buy your way out of this problem, but you can't process your way out either. It takes both. The goal isn't to eliminate all custom code-it's to eliminate the conditions that make unmaintainable code necessary for survival.
The security industry needs to have an honest conversation about what we're asking of SOC teams.
We're asking them to defend against nation-state adversaries using tools that don't talk to each other. We're asking them to maintain 24/7 visibility using systems held together with custom scripts. We're asking them to be security analysts, software engineers, system administrators, and integration specialists-all at once, usually understaffed, always under pressure.
And then we're surprised when the hero code they write to survive becomes the weakness that brings the organization down.
This has to change. Not just the tools. The entire system.
The next generation of security operations needs:
Because the SOC hero isn't the problem. The SOC hero is a symptom of a broken system.
And fixing symptoms while ignoring root causes has never worked in security-or anywhere else.
What's your organization doing to address this? Are you building better processes, investing in better tools, or both?
Want to dive deeper? Read the full analysis on Medium.
Sound familiar?
We're building SOCmate with early partner teams. If this resonates with your challenges, let's talk.
Get in touch