Security debt, a horrid side effect of Business/Technical debt
Storm in a tea cup!
Technical debt is a techie problem, the business should not pay for it. If you have some technical debt, it’s because you hired some bad staff. The good ones get everything right.
I have heard this way too often from both CEO and COO who do not really get it. And that’s because technical debt is not a technical problem, yet by calling it technical, we create a barrier to understanding that it is a business problem. Let’s look at a tiny aspect of it, that of security…
Of course, no one seems to want to improve their security nowadays: ship fast, break things, and let the next person worry about it, right?
One person who does care is the hacker. They are going to make thousands from you as you lose millions in the process. Or worse, they’re just going to get kudos from their l337 h4ck3r1 friends.
The Security Debt Problem
Applications continue to ship with known weaknesses even as development workflows speed up. A new Datadog State of DevSecOps 2026 report examines how dependency management and pipeline practices are influencing exposure across cloud native environments.
Across the environments studied, 87% of organizations run at least one exploitable vulnerability in production services, affecting 40% of those services. This condition points to a persistent accumulation of security debt inside deployed software stacks. Your dependencies are 278 days out of date and your pipelines aren’t protected.
What happens next? You get hacked. Your customer data is stolen and leaked on the dark web. Your customers curse you and leave in droves. Your name is in the news as the weekly company that treated security as an after thought. And everyone laughs behind your back.
How do you fix it?
We know it is possible as is shown here: UK reduces cyberattack fix times from two months to eight days. But, how?
First, patching is critical. You need to have a rolling update of all your dependencies. It costs resources and is not glamorous but it is needed. How it works is simple:
- Week 1: Patch all dependencies in development and fix all the new issues it causes.
- Week 2: The patches get into the testing environment and are explicitly tested.
- Week 3: The patches get into the staging environment and are monitored for failures.
- Week 4: The patches are deployed into production.
If you really want to be efficient, this means that every week your developers patch their dependencies.
Second, there are plenty of open sourced and free security scanners. There are, of course, many pay for tools as well — for example…. Running one of these in your CI/CD pipeline is a sure way to find out which need to be updated as a priority. Of course, this is only as good as those tools are good. Still, having multiple ones is not hard to set up and is a good way to catch those elusive vulnerabilities. One problem here is that of false positives: you must review it all which can lead to alert fatigue.
Finally, and most importantly, as technical leadership we need to make sure that the business at large understands that this is not a cost. It is protecting your revenue stream. It is the equivalent of locking your car and taking the keys with you, not leaving the key in the ignition in the car park. You need to set resources (technical, monetary, and time) to protect your revenue stream. How much is often dictated by your company’s risk appetite: How much would a breach cost you?
Conclusion
This is just a tiny aspect of the problem. It is an opportunity to change minds, to educate senior leadership who, for entirely understandable reasons, do not understand this aspect. This is what I have done many time in the past, and I can do again for you.
Imagine, if you will, a day when all the drama is removed from your software production: no panic, no crisis, just smooth software releases that exceed your customer’s expectations. This is what we have done in the past and can do for you.
How about getting in touch to see how we can help you?