In the world of software development, “tech debt” refers to accrued costs and long-term consequences of prioritizing speed over software quality. This can involve taking shortcuts by using poor coding techniques, ignoring outdated modules, or using software architecture that doesn’t meet industry standards. This, however, creates additional work later on (maintaining the software, upgrading the modules and the architecture) that costs you and accrues “interest” over time. Security tech debt for that matter is technical debt that results from prioritizing speed over security.
In this article, we take a deep dive into both technical debt in general and more specifically security debt, the causes, how to avoid it, and what to do if you’ve already accrued debt.
In order to better understand security debt, we will lay the groundwork by first exploring general technical debt and building on this to learn about security debt.
Types of technical debt
Martin Fowler classifies technical debt into four categories:
- Reckless and deliberate
- Reckless and inadvertent
- Prudent and deliberate
- Prudent and inadvertent
Prudent
This form of technical debt is deliberate and is used to gain speed and market advantage. Companies may release an MVP, prioritizing speed over perfection, but then release frequent updates to manage the debt. Being the first to go to market gives them the competitive edge, but this requires good and experienced management, as it can easily cause technical debt to accrue.
Inadvertent
Software architectures should be adaptable to future industry standards—since no design is perfect. But when developers build applications that are not modular and adaptable due to lack of knowledge or experience, the company can inadvertently incur major technical debt.
Reckless
This type of tech debt can happen due to consistent incremental changes and customizations to a legacy system while deliberately ignoring the need to upgrade such systems to modern standards.
Causes of technical debt
Company culture is a key factor when it comes to technical debt. It often occurs in companies where junior developers are poorly mentored, resources are not spent on hiring professional in-house developers, and software development relies heavily on outsourcing. In all such cases, the project would eventually end up in the hands of poorly skilled or uninformed in-house developers who are ill-equipped to maintain the application.
The cost of any buggy code or vulnerability introduced by these poorly prepared developers represents a technical debt that must be paid.
Here are some ways technical debt can pile up:
- Ignorance: When company leaders or software developers are oblivious to the concept of technical debt, they can make decisions that cause technical debt to accrue without even realizing it.
- Tightly coupled components: When the software architecture is not modular, the software cannot be adapted to future business needs.
- Failure to align with industry standards: When features, frameworks, or technologies are not upgraded on time, upgrades can become expensive. When legacy applications are being maintained and customized, while refactors are delayed and upgrades deferred, technical debt grows over time and may eventually require a complete overhaul.
- Lack of collaboration & poor leadership: How your team leaders set up your engineering teams and the software development cycle (SDLC) is a key factor in whether technical debt will be accrued. When junior developers are not properly mentored or software development is done in isolation across multiple branches, this creates silos. Team leaders must also know how to balance speed, scalability, and quality; and prioritize which features to release at a given time.
- Time pressure & constant change: Changes or project requirements that come late in the SDLC, without the time or budget to properly implement and document them can lead to technical debt. Moreover, companies need to adapt quickly and provide excellent user experiences or become obsolete. But if you cannot evolve rapidly due to poor quality code and IT infrastructure, this can be detrimental.
Indications of tech debt
Tracking your company’s tech debt is key, as it dictates future capital allocation requirements and is an indication of company culture, long-term vision, and just how fragile your business model may be. It presents a holistic view of your company’s intangible assets and liability.
There are several indications that can reveal the level of a company’s technical debt, including:
- Product release cycle frequency: Companies that can iterate and release updates frequently are generally more flexible and product focused.
- System uptime: A 99.9% system uptime indicates a system with a solid architecture and efficient development lifecycle.
- Engineer turnover: Paying tech debt can burn out developers, causing many to seek out greener pastures, where they can innovate.
Security debt: The new tech debt
Security debt is a variation of technical debt that results from the accumulation of vulnerabilities in a company’s system or application. Just like technical debt, this can occur because the company prioritizes speed over product security. And like financial debt, it also accrues interest.
Security technical debt can also occur when a company fails to keep its IT system patched or deliberately ignores the rapidly evolving security threats.
A company may delay patch releases because of:
- The time it would take to implement the patch
- The effect of the patch on the system
- Short-term financial pressures
This can cause vulnerabilities to pile up and put you at risk for severe breaches.
While technical debt is bad, security tech debt is one of the worst variants of technical debt. Aside from its high cost, it can put you out of business quickly.
Causes of security debt
Technical debt—which may be intentional or unintentional—occurs when companies build software without planning for the future, using expedient shortcuts to get to market early. Over time, technology evolves—since, of course, no architecture is perfect—and delayed modernization or refactoring of legacy applications can lead to security tech debt.
Failure to address known vulnerabilities, as previously noted, can also lead companies to accrue security debt, which may have severe financial consequences.
Delayed testing or failure to integrate testing into your SDLC is another cause of security debt. When applications are built by inexperienced developers who prioritize speed over security, the entire development life cycle may be completed without any testing at all; or testing may only be carried out at the end of the SDLC.
Novice developers may simply lack the knowledge about the testing tools they should be integrating into their workflow.
How to get out of security debt
There are a number of steps you can take to avoid or address security tech debt.
1. Proper testing
Performing static code analysis is one way to build quality software while reducing security debt. Static code analysis, also referred to as source code analysis, involves debugging code by testing it against a set of coding rules to catch bugs that can lead to vulnerabilities. Because it is performed before the code is executed, early on in the SDLC, it can improve overall software quality.
This can be achieved using static analysis tools such as Sonarqube, Coverity, DeepSource, or Closure Compiler. Such tools generally offer multi-language support, perform security analysis, track bugs, and enhance code reviews. While some static analysis tools can run on a pull request (e.g., DeepSource), others offer CI/CD integration (e.g., Sonarqube).
Automating your testing—static analysis included—is also recommended.
2. Adopt a DevSecOps culture
DevSecOps brings development, security, and operations together and automates the integration of security into your SDLC. The DevSecOps culture prioritizes security without compromising on the speed of software development. It accomplishes this by integrating security checks in every stage of the SDLC. Embedding security checks early on in your workflow increases efficiency and helps to ensure potential vulnerabilities and threats are dealt with during development.
This allows you to maintain rapid development without compromising on product quality or application security.
Key to taking full advantage of the DevSecOps culture is the Integration of tools that provide automated risk detection and remediation to both find and fix vulnerabilities. Tools that only expose vulnerabilities can actually work against you, since the sheer amount of vulnerabilities or threats exposed in your application can overwhelm your security team and discourage them from paying off security debt. In addition, attempts to remediate exposed threats are often very costly.
You should therefore opt for tools that provide automated risk remediation.
3. Effective patch management system
Setting up a reliable patch management system is another way to effectively manage and even eliminate security debt, and is one of the most important tasks in any IT organization. It involves continuously maintaining software by regularly deploying small units of code to add new features, fix bugs, or patch vulnerabilities.
A good patch management system is critical to the success of your software on the market. Once a security update is released, any unpatched software or system is potentially vulnerable to attacks from hackers looking to exploit these known vulnerabilities. For this reason, software patches should not be delayed, and the process should be automated using tools like Pulseway.
Reducing security tech debt is a key part of a robust cyber risk management program, but there’s plenty more to address. Get started by booking a demo with Vulcan Cyber.
In the next blog, we’ll go into what to do once you’ve paid your security debt.
