Debt isn’t always a bad thing. Borrowing can grease the wheels of both business and personal growth and prosperity—as long as the debt doesn’t get beyond your ability to pay it back.
The same isn’t true of technical and security debt. Even a little technical debt puts an organization at risk. And while there are different levels of severity—bad, worse, much worse, and catastrophic—no expert claims there is a “good” level of security debt.
Why is that? Good question. We’re here to help you understand what technical and security debt are, how to evaluate the risks, and how to “pay it off.” Being debt free is a good thing, especially in the digital world.
What is technical debt?
Technical debt refers to the long-term burden software development organizations create when they take shortcuts. Technical debt includes the buildup of “cruft,” which are deficiencies in internal quality that make it harder to modify and extend a system further.
The term comes from programmer Ward Cunningham, developer of the first wiki. Cunningham, who coined the phrase more than a decade ago, said the failure to address problems during software development was like “borrowing money thinking you never had to pay it back.”
“Of course, if you do that—say with your credit card—eventually all your income goes to interest and your purchasing power goes to zero,” he said.
Dave Smith, an agile software development coach, describes technical debt as “those internal things (in the planning or execution of a software project) that you choose not to do now, but which will impede future development if left undone.”
He offers a few examples of the thinking behind technical debt:
- “It’s too late in the life cycle to upgrade to the new release of the compiler. We’ll do it next time.”
- “We’re not completely conforming to the user interface guidelines. We’ll get to it next time.”
Or as Martin Fowler, chief scientist at ThoughtWorks, describes it, “Doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. The technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.”
What is security debt?
Security debt is a subset of technical debt. Specifically, security debt refers to the accumulation of vulnerabilities in your software that make it harder or even impossible to defend your data and systems from attack.
In some ways, security and technical debt are similar: If you don’t pay the debt off, you’ll end up paying just interest without getting to the principal. But security debt doesn’t just “impede future development” of a project. Instead, an accumulating pile of vulnerabilities puts your organization at a much greater risk of malicious cyber exploits.
One of the most notorious examples is Equifax, the credit reporting giant breached in 2017 because it had failed to patch a known vulnerability in Apache Struts, a popular open source web application framework. The patch had been available for months. The breach compromised crucial personal data of more than 147 million people.
Yet, more than a year later, the Synopsys Open Source Security and Risk Analysis (OSSRA) report showed that of analyzed codebases containing Apache Struts, a third still had the same vulnerability that impacted Equifax.
The message of this and other examples is the same: If you let software vulnerabilities accumulate in your applications, networks, and systems, hoping that attackers will ignore them because they’re “old,” it’s just as if you were ignoring old weaknesses in a roof. At some point, it’s going to fall in on you.
What causes security debt?
Security debt is caused by a failure to “build security in” to software from the start to the finish of the software development life cycle (SDLC).
Security debt accumulates when a development organization releases software without addressing its weaknesses and vulnerabilities. Sometimes the organization fails to test software thoroughly throughout the SDLC. Sometimes it decides that the pressure to finish a project is so great that it makes more sense to release now and fix vulnerabilities later. Later is better than never, but when “later” never arrives, existing security debt becomes worse.
Utsav Sanghani, staff product manager at Synopsys, said many organizations are carrying a potentially catastrophic level of security debt. “The percentage of security improvements needed in a typical technical debt bucket ranges from 40% to 50%,” he said.
Is security debt bad?
Yes, yes, a thousand times yes. But that declaration, while true, lacks some nuance.
First, while it’s all bad, a little security debt is better than a lot of security debt. Organizations that set up a system to chip away at their security debt are doing themselves an enormous favor, even if it takes them a long time. Heading in the right direction is better than doing nothing (which is essentially heading in the wrong direction).
Second, not all vulnerabilities are equally dangerous. The Common Vulnerabilities and Exposures (CVE) list maintained by MITRE contains descriptions of publicly known vulnerabilities. It feeds the National Vulnerability Database (NVD), a U.S. government repository of standards-based vulnerability management data that provides additional data about CVEs, including their severity and risk. Some security product vendors provide their own vulnerability information feeds as well, enhanced with information such as versions affected and remediation information.
Another excellent resource is the OWASP Top 10, published by the Open Web Application Security Project. The OWASP Top 10 “represents a broad consensus about the most critical security risks to web applications.”
How do I get rid of security debt?
You can reduce security debt, but it will take time and money. The cost will be greater than if you had fixed the vulnerabilities before release rather than waiting for debt to pile up. But the cost of reducing security debt is far less than the potential cost of a data breach in terms of incident response, fines, loss of customer and investor trust, and possibly litigation. Consider it an investment.
The best way to start addressing security debt is to create a thorough inventory of all your software assets—proprietary, commercial, and open source. You also need a software bill of materials, or a list of software components, for each asset you maintain. In short, you can’t protect what you don’t know you have.
While the NVD and CVE don’t cover every vulnerability out there, they can help you practice risk management. Eliminate the biggest risks first and then work your way down to those that still matter but aren’t as dangerous.
The same is true for the OWASP Top 10. While it doesn’t list specific vulnerabilities, it tells you which software weaknesses are most likely to lead to vulnerabilities. This list is particularly useful while a project is still in development. If you can keep weaknesses out of your codebase, you can prevent them from becoming vulnerabilities after release.
What tools and services can I use?
A software composition analysis (SCA) tool will help you discover the open source components you’re using so you can mitigate any vulnerabilities they contain and address potential licensing problems.
Smith also recommends you keep a technical debt list. “Group deferred tasks into workable units, note the consequences of leaving each unit unattended. Make sure that marketing knows that the list exists and repeat the mantra, ‘If we don't schedule time to pay off technical debt, you might not get all of the new features that you want.’”
And once you’re out of debt, you should work to stay out of debt. Consider each of these software security testing tools and services for your toolkit:
- ARA (architecture risk analysis) flags possible structural flaws in a program during the design stage.
- SAST (static application security testing) uncovers security and quality defects in code during development and build stages.
- IAST (interactive application security testing) detects vulnerabilities as a program is interacting with external input during testing and QA stages.
- DAST (dynamic application security testing) continuous web application security testing in production.
- Fuzz testing “attacks” systems, apps, and services with random, malformed inputs to test their robustness, safety, and security.
- Penetration testing generally occurs at the end of the SDLC, where white hat hackers see if they can exploit any remaining weaknesses in a program.
Continue Reading
Solving telecom network security challenges with Defensics
Apr 15, 2024 / 3 min read
SANS report: Securing the shifting landscape of application development
Apr 03, 2024 / 2 min read