(2 votes, average: 5.00 out of 5)Technical debt, an Agile term coined by the software developer Ward Cunningham, can cost organizations serious dollars. Want an example? In the U.S. back in 2022, technical debt reached nearly $1.52 trillion.
The same year, a staggering 86% of senior executives interviewed by Foundry admitted their companies had to deal with outages and several limitations, all due to technical debt. And that’s only the tip of the iceberg. Technical debt is so critical that could easily sink an organization for good.
But what is technical debt, exactly? And how can it affect the security of your products, business, and customers so badly to make you risk going out of business? Read on to find out.
Simply put, technical debt is the consequence of prioritizing speed over quality and security. It’s the difference between what’s promised and what is delivered. Moreover, it’s the cost of pushing problems to the future by kicking the proverbial can down the road.
It’s like when you take a loan to pay for that brand-new sports car you always wanted. Yes, you’ll be able to drive it immediately. However, you’ll still have to pay it off in full later. And that payment will end up being much higher due to interest rates.
Now, let’s apply this concept to software development and security. How many times did you have to cut corners developing software to meet a tight deadline? Been there, done that, got the t-shirt. Organizations expect developer teams to deliver more and faster, and bosses demand the products to be released ‘yesterday.’
To make things more difficult, a survey by SoftwareOne shows that 83% of IT leaders will have to achieve more in 2023 with less. Time is money, as uncle Scrooge said. And the faster and the greater number of products you publish, the more money your company makes.
But there’s a catch. No matter how good you are, all the trade-offs, quick fixes, and shortcuts you’ll take to deliver your software on time will pile up. Eventually, they’ll have to be addressed (i.e., paid off) by investing additional time, money, and resources. This is what technical debt is.
So, is tech debt bad for your organization? It depends. Well-managed, low tech debt isn’t a bad thing. But when it starts to inflate as a balloon and corrupt the overall security of your products, then, “Houston we have a problem.”
But we’ll talk more about this in a minute. Before we do that, let’s briefly have a look at the most common causes of tech debt.
At one of the companies that I worked for, a high tech debt was the norm. We had a very small development team and a huge list of projects to complete, all with tight deadlines of course. Fulfilling management’s expectations wasn’t easy. And when the days with only one developer in the office became increasingly frequent, during our status meetings, you could often hear phrases like, “No worries, we’ll fix it in the next release.”
Frankly, you’ll likely hear similar phrases at many other companies, too. Unfortunately, it’s becoming increasingly common. In fact, the latest Invicti research shows that nearly three-quarters (74%) of organizations are used to knowingly publishing vulnerable software.
Why? There are so many issues that could cause this behavior that we could dedicate a whole article to it. And we will, in our next article of the series. Right now, to give you an idea, we’ll list three reasons why I’ve personally encountered technical debt during my professional career.
What would you do if you were at college and you just had two days left to write your essay about Mary Shelley’s “Frankenstein” because you spent the whole week playing the latest online game? You’d take a shortcut (e.g., watch the movie or read the book summary) and hope for the best.
What do you think we did when we had our boss breathing down our necks, pressuring us to release yet another application? We knowingly left select features and patches out (i.e., intentional debt) to keep him happy. Ka-ching! More tech debt was added to our account.
How often do you test your code before releasing it? Is security the Cinderella of your software development life cycle? Do you still stick to devops instead of implementing devsecops or, even better, secdevops to bake security in your software development process? If you answered yes to even only one of these questions, you’re probably not testing your software enough.
Security tests were as rare as unicorns in some development teams I worked with. Why? These processes weren’t automated or baked into the development process like they are when the secure software development life cycle (SSDLC) is implemented. As a result, testing was often skipped as it was considered too complex and time-consuming. Et voila’ — another layer of tech debt was added to our collection.
How many times did you view security as an afterthought when writing your code? You’re not alone. According to Mend’s research, only 58% of developers consider security as a top priority and follow secure coding best practices.
From my experience, the teams I worked with that implemented a security-as-code (SAC) approach had a lower technical debt than those that kept security relegated to the last development steps. The latter were constantly fighting with ever-increasing tech debts.
As I said, these are just a few examples of technical debt’s root causes. But, as Michael Ende wrote in “The Neverending Story” book, “That is another story and shall be told another time.” Let’s move on now and dig deeper into technical debt to find out how it can affect your organization financially, and why reducing it is so important, above all for cybersecurity.
Prove Your Software Is Trustworthy
Signing your code shows users that your software and updates can be trusted.
Download our free code signing best practices eBook to learn how to help keep your supply chain secure and your company, customers & end-users safe.
Want to know how much your technical debt will cost your organization? You can do it by comparing the cost of remediation/risk with the benefits you’ll get by fixing each flaw (i.e., tech debt ratio).
You can use a simple formula: divide the remediation costs (i.e., the costs to fix the software) by the development costs (i.e., the cost of developing the software), and then multiply the result by 100.
Technical debt ratio (TDR) = (remediation costs/development costs) x 100
The higher percentage you get (i.e., TDR), the lower is the quality of your software. Thus, the higher will be the costs of your technical debt.
For example, let’s say that I want to calculate the TDR of a project that has 10,000 lines of code. The developer writes one line of code in 0.2 hours. This means that to write the whole code, they’ll need 2,000 hours (i.e., my development costs in time, one of the most common metrics used for this calculation). To fix that code, it’ll take me 100 hours (i.e., my remediation costs).
My TDR will then be equal to: (100/2,000) x 100=5%
There you have it. That was relatively easy, right?
Over the holidays in December 2022, Southwest Airlines got the answer to this question (and it wasn’t pleasant). More than 10,000 flights were canceled in just one week, crews were left on hold, and luggage was lost. The impact on thousands of travelers was humongous. Southwest Airlines was brought to its knees.
The main reason? An old and limited scheduling system for flight routing and staff management. The company simply chose not to update it when it rapidly grew from a small airline to one of the largest in the US. Bad idea. Another example of tech debt disaster.
The consequences?
I bet you wouldn’t like to be in their shoes now, huh? And if you’re a software development company, things could get even worse:
A high technical debt can seriously impact the security of your products, organization, and customers. The cyber security threat of tech debt is so severe that the U.S. Department of Defense (DoD) has even included technical debt in the National Defense Authorization Act of 2022 (section 835). At the same time, Carnegie Mellon University published a study funded and supported by the DoD, exploring 10 years of research in tech debt.
In the paper, the university highlighted how unintentional (i.e., caused by mistakes, wrong decisions, and/or a lack of strategy) and badly managed tech debt can quickly become a security nightmare. How? Let’s find it out.
The latest Check Point report shows that in 2022 organizations were attacked an average of 1,168 times per week. Can you imagine how easy would be for a cybercriminal to hack an application full of unpatched vulnerabilities and get into your network? It would be like stealing candy from a baby.
As you can imagine, the consequences could be disastrous. Malware infection, data breaches, and ransomware attacks — just to name a few of the issues that could result. A small spark could rapidly spread like fire to your whole organization, causing massive security problems that could cost you an arm and a leg to fix. And this takes us to the next point.
Did you suffer a data breach attributable to the technical debt accumulated by your organization? Beware, it could cost you dearly! In October 2022, the fashion company Shein was slapped with a fine of $1.9 million for a massive data breach that affected 39 million accounts worldwide.
The principal factors? They were nearly all related to tech debt. Among them:
Add the costs of
you’ll reach a figure that may easily undermine the very survival of many organizations.
Last but not least, let’s remember the negative effect such an incident had on the company’s reputation. And when your reputation goes down the drain, a big slice of your sales goes with it.
Yup! High, poorly managed tech debt may affect your customers, users, and suppliers, particularly if it results in a cybersecurity incident. Once again, they may become the indirect casualties of malware infection or data breaches. Do you think you’re safe? Maybe, but if it happened to a tech giant like Google, I wouldn’t be so confident that it won’t happen to you.
In February 2023, Google Fi (Google’s mobile network) was the victim of a data breach resulting from the T-Mobile data theft that happened a month before. But what does Google have to do with T-Mobile? Because Google doesn’t have its own mobile infrastructure, it had to rely on T-Mobile. And when T-Mobile got hacked, the attackers also gained access to Google Fi customers’ data.
Such incidents could badly hurt the trust your clients have in your organization and products. How badly? According to Thales, 21% of interviewed consumers stopped doing business with companies impacted by a data breach. Are you prepared to potentially lose one-fifth of your customers? Probably not.
Don’t get me wrong; a bit of technical debt isn’t always bad. As I said, the problems start when it spirals out of control, chipping away at the security of your products bit by bit. For example, when you:
“Later” becomes never, and that’s when things start getting seriously dangerous.
So, what can you do to tame the technical debt beast and keep it under control? Let me give you a few tips to move you in the right direction.
Did you know that a Gartner research forecasts that organizations that’ll manage to reduce their accumulated tech debt in 2023, will have a service delivery time at least 50% faster than other companies?
If you want to speed up your delivery time, then tackle your technical debt now and start reducing it. Here’s how:
| 3 Actions to Help Reduce Your Technical Debt | Example Solutions |
|---|---|
| 1. Do an Inventory of All Your Software Assets and List All Components |
|
| 2. Make Your Tech Debt Visible |
|
| 3. Create a Plan and Execute It. |
|
Strictly speaking, know what you have if you want to protect it. Start with a list of all your organization’s commercial, open-source, and proprietary software. Once done, go deeper and add a software bill of materials (SBOM) to list all software components and dependencies for each asset.
A software composition analysis (SCA) tool will help you:
Et voila — you’re one step closer to escaping the black hole of tech debt.
Do you remember when, at the beginning of this article, we compared tech debt to the loan you make to pay for the sports car of your dreams? When you take out a loan, it’s difficult to forget that it’s there. Every month, you have to pay a sum, and, if you forget it, you immediately get kind (or not so kind, depending on the creditor) reminders.
Technical debt is much less visible as it’s intangible; therefore, it’s much easier to ignore. At least, until you get hacked or a customer complains because you can’t add a feature they need to your application due to the complexity of the code…
To reduce your tech debt, you’ll have to make it visible. Prioritize the vulnerabilities that you’ll need to fix. It’ll enable you to ensure you address the high-value and high-risk items first. How?
Pro tip: Want to take it a step further? Check out the following resources and tools:
Enough with the theory. Now that you know your software and have identified and prioritized its vulnerabilities, it’s time to take action. But before you do that, you need a plan. Like your loan repayment plan? Yup, that’s more or less the idea.
Let’s quickly detour down memory lane again. One organization I previously worked for would reserve one half-day per week for clean-up/tech debt payment activities. During that time, the developer team was in ‘do not disturb’ mode except for critical issues.
All urgent requests were filtered by their team leader, and I must admit that the plan worked pretty well. In a matter of months, the tech debt was reduced to an acceptable level and wasn’t growing anymore.
Want to do the same? Prioritize, plan, pay, and repeat. See? It isn’t too bad when you have a well-defined plan to pay it off.
Pro tip: Include your technical debt plan in your usual sprint planning. It’ll prevent you from forgetting about it and help you respect the deadlines agreed upon.
In today’s software development, where speed of delivery is everything, every organization has some technical debt. The money is often tight, time is short, and resources are limited. This is when cutting corners here and there becomes inevitable. The consequences? Your team’s ‘To-do later list’ will keep on growing while your products will become less and less secure.
We’ve learned that preferring speed over security and code quality isn’t the right solution though. Software delivery is no longer only a matter of releasing an application as fast as possible. With the risk of data breaches, malware infections, and cyberattacks lurking behind every corner, security has become a critical part of every stage of the software development life cycle.
Want to alleviate the detrimental impact of technical debt on your organization and projects? Embed security throughout your SDLC.
Last but not least, don’t forget to thoroughly analyze and understand the possible tech debt determining factors though. It’ll enable you to:
But this is another story that we’ll explore in our next article on the causes of technical debt. Don’t miss it!
Email Us
+1 (727) 291-0611
Chat Now
