Security debt represents the accumulation of various vulnerabilities in the internal structure of your software. This leaves your solution open to potential breaches, hacks and exploits. It also greatly increases the risk of your data and system architecture becoming compromised or hijacked. So, how do you get rid of security debt? To answer that, we first need to understand what causes it and this leads us to the concept of technical debt.
What is technical debt?
Over a decade ago, a programmer named Ward Cunningham defined the term “technical debt“. He used it to describe the long-term impact of programmers taking shortcuts while developing their code. In a nutshell: if you cut corners in the beginning of your development cycle, this will likely haunt you later on. The problem is that everybody uses shortcuts in their work, but some shortcuts come with a heavy future cost. Granted, some of these issues could be miniscule at first, but their compounding over time inevitably leads to so-called “cruft”. Cruft is the buildup of deficiencies in your software’s internal quality, which makes future modifications and upscaling difficult. You can also think of it as a house whose foundation was not laid down properly. Building up is going to be a major struggle, and expanding sideways will require a huge amount of work.
Now, if you take the essence of this problem and apply it to your software’s security, you get “security debt”. Let’s take a look at what it entails and how to fix it.
What is security debt and what causes it?
Security debt represents the sum of different vulnerabilities in your software which make data and system protection increasingly difficult. Since security debt is a direct subset of technical debt, this means that the root cause is the same. One of the leading reasons why security debt occurs in the first place is the way we create software today.
When it comes to modern software development lifecycles, developers rarely build their products from scratch. The reason is quite simple – there’s a host of functional, pre-made elements available in open source repositories. Developers use these existing blocks of code to save time, but they often do so without thoroughly analyzing the security aspects of that code. If the code works, they will tweak it to suit their purpose and implement it in their development. Now, if they happen to notice security vulnerabilities during this process, they’re faced with two options:
- Perform an in-depth analysis of the code’s integrity and security on a fundamental level, or
- Write or copy a quick workaround on top of the code to bridge this issue
Take into consideration the fact that time to market plays a crucial role in an enterprise’s ability to succeed in the market. This is how a security risk is born, and the consequences then simply propagate into each subsequent development step. Another particular problem occurs when developers change. Instead of just building the product further, new developers must spend extra time figuring out how the old code functions.
The cost of security debt
Pushing for “quick and dirty” design choices in the inception phase will limit your development options down the road. Not only that, but it will also greatly increase your costs and security risks. From the client’s perspective, having robust security and data protection within a scalable and modular design is a major consideration. Since data leaks or breaches can cause huge financial and reputational damages, your clients need to be completely sure that this does not happen. If it does, the solution provider might even be held liable. Furthermore, from your perspective as a software company, every hour your developers spend ironing out old vulnerabilities costs you money.
Try to visualize the lifetime of your software for a particular client and its version upgrades and maintenance. Software can easily last for years, if not decades. Now, imagine having to patch new security breaches after each update because someone took the easy way out years ago. What’s also frightening is that many companies are still hoping to achieve “security by obscurity”. This means they’re keeping the architecture secret or they’re hoping bad actors will not exploit a long-standing vulnerability in their software because no one remembers it exists, both hackers and their developers. This is a mistake in reasoning that you should avoid at all cost.
The good news is that these types of errors can definitely be avoided if the development team pays close attention early on in the SDLS.
Getting rid of security debt
The philosophy behind avoiding the accumulation of security debt and financial debt is essentially the same – good and responsible planning. However, actually getting there isn’t as easy as it seems. Why? Because this requires motivating your developers to confront and reject some embedded habits and work against prevalent industry trends.
You can leverage some existing methods to help this transition in the beginning, such as using VPNs to boost online anonymity, or utilizing zero-knowledge cloud services. Unfortunately, this will not fix deeper systemic problems.
The only proper way to address this is through a paradigm shift in the minds of developers. They should be required to inspect their code for security vulnerabilities not only during development, but also after the deployment. If you manage to implement the principle which requires all technology teams in your enterprise to be responsible for product security, congratulations – you’ve successfully transitioned towards DecSevOps. This methodology will definitely pay dividends in the long run. It will allow you to deploy your software not only quickly, but also securely.
Additionally, a couple of useful starting tips that can help protect your software are:
- Hash your passwords instead of encrypting them
- Avoid installing “secret” backdoors
- Require authentication on every page
Keep in mind that just because a developer doesn’t expect that a user might undertake a certain (illogical) action; this doesn’t mean the user will not attempt to do it. Therefore, the only viable approach is to invest more time in the beginning in order to avoid paying the burdensome security interest in the long run.
