Technical debt poses a cybersecurity risk

Looking for a layperson’s explanation of “technical debt” and why it matters? Terumi Laskowsky, an instructor at DevelopIntelligence, a Pluralsight company, walks through the basics in this brief interview and discusses the implications for business leaders.

TL: Let me start with the original definition, and then I’ll segue into how people are using the term today.

Ward Cunningham, the Agile Manifesto co-author who conceived the term “technical debt,” explained it with a financial metaphor: Moving forward to develop a new software application is like getting a loan (debt). 

Imagine building a product using a brand new technology. You’re facing many unknowns and there’s some trial-and-error. You do the best you can with what you know now, proceeding forward in the face of uncertainty. As you discover what’s working well and what isn’t, you use this knowledge to improve the code. Making the code better as you learn from experience is similar to paying back the loan. This is an empowering concept, right?

In recent years, however, the definition of technical debt has morphed from Cunningham’s original concept. Today, most organizations think of technical debt as code with known shortcomings and inefficiencies. If you leave that subpar code in place, you’re allowing tech debt to grow.

TL: Focusing on rapid, frequent releases often results in cutting corners with code quality. The mindset: “If it’s not perfect, we can fix it on the next release. Let’s just get it out the door.” 

Technical debt (by today’s definition) can build in this way. Since developers need to complete new features and enhancements, they may not have time in their schedules to fix code from earlier releases. Unless a customer complains about the software or it outright doesn’t work, a team may choose to leave imperfections in place, rather than “lose” time on fixes.

If an organization doesn’t make time to write clean code in the first place, why would they take time to do it later? 

If you never go back to improve the code, you allow the debt to persist and grow. You’re paying interest on it. That “interest” could take many forms—for example, dissatisfied customers or poor market share because your product is subpar against competitors’ offerings.

TL: To meet speed goals, organizations often release code with glaring security vulnerabilities. 

A vulnerability is any weakness that could lead to compromised data, systems, brand reputation and so forth. An IT security risk refers to the potential consequences a business could face if an attacker successfully exploits these vulnerabilities. 

Developers and businesses must balance the quest for speed against the factors of functionality, usability and security. Unfortunately, these priorities conflict. 

What if security features make a product harder to use? Who wins? Functionality, usability or security? If you are in government or a highly regulated industry, security is more likely to win. But for everyone else, functionality and usability too often win at the expense of security. 

And if a company doesn’t prioritize security at the outset, what happens when there’s a culture of “got to move fast, so let’s put that in later”? Just as with cars, speed kills. 

Here’s another important note: An organization can write clean code and still be taking shortcuts on security. You need both clean code and a security focus.

TL: Security is still an afterthought for many software development teams. They may view it as someone else’s responsibility and/or something that happens later in the software development life cycle. A typical programmer’s job is to create new things. That person often is not a security expert. In order to write code with security in mind, software developers need training in secure coding principles. 

Additionally, every software development team should be referring to a requirements document as they build the product. This document sets forth the specifics of what the software needs to be able to do (functional requirements), as well as other parameters that are vital but may not be directly visible to the user (non-functional requirements such as security). 

Many organizations do not train their programmers with this knowledge or define comprehensive security requirements at the outset of the project, even though an early failure in security can cause a significant risk to the business.

TL: The most common problems involve security controls in the code or system. The National Institute of Standards and Technology (NIST) defines a security control as “a safeguard or countermeasure prescribed for an information system or an organization to protect the confidentiality, integrity and availability of its information.”

Security controls are there to mitigate potential risk. If these controls are missing or poorly implemented because of a "we'll do it better later" attitude, then the company could be liable for lack of due diligence and governance to protect the data and systems of their stakeholders.

IT professionals talk about the distinction between “built in” and “bolt on” security. Security is not something you can bolt on to the end of a product. It needs to be built in from the start. The more you ignore or delay focusing on security, the harder it is to get it right later. 

If code has vulnerabilities, the way to make the code secure is to refactor (redo) it to correct the vulnerabilities. Otherwise, security issues will persist. Tacking something on to the top as a “fix” is similar to applying a bandage to a bad wound. The bandage may buy you time to get to a doctor, but it doesn’t fix the injury.

Your focus on speed can end up costing more than whatever advantage you thought you gained—if you have to go back to refactor.

TL: Because more and more business risk is tied to technology risk, it’s important for all business leaders to have a correct understanding of technical debt—what it is, what causes it and the potential security implications—so that you feel empowered to ask questions about it. 

If your organization prizes automation and speed, you’re likely acquiring technical debt. So, you want to make sure it is acceptable debt. 

The right kind of technical debt increases the speed and agility of your business. The wrong kind of technical debt will needlessly expose your organization to increased security risk. Talk about this distinction as a leadership team. The business priorities you emphasize drive the behaviors that keep technical debt under control, or conversely, cause it to mushroom.

The C-suite needs to support the CISO in making sure that developers and others involved in software projects have the best current knowledge about security. Have you trained your programmers to do secure coding? Are you striving to include as much automated security testing as possible in your CI/CD process to enforce security best practices?

Leadership—the C-suite—needs to set the right tone for developers regarding the importance of IT security. Developers will do what leaders reward. If you are rewarding speed over security and code quality, you may be increasing your organization’s cybersecurity risk.

As a leader, you can influence your organization to do the right thing.