Understanding Security Debt

When we think about cybersecurity, technical jargon, such as malware, firewalls, encryption, and so on, often comes to mind. Here’s a new term you should know: security debt. While originating in software development, this concept is not just for tech-savvy professionals. It’s a simple idea with implications for systems, businesses, and society. This post will explore the idea of security debt, why it matters, and how it accumulates in systems.

What is Security Debt?

To get the full picture of security debt, it is essential first to understand the monetary metaphor of technical debt. Simply put, technical debt is used to explain the cost incurred when software quality is compromised. Different software quality attributes (i.e., maintainability, evolvability, reliability, security, etc.) may be compromised, for example, to reduce time-to-market. This can be compared to building a house quickly by skipping some structural reinforcements. It’ll stand for now, and fixing it later may cost more.

Security debt takes the concept of technical debt into the realm of security. Being able to avoid security debt or leveraging it strategically depends on a clear definition of security debt and people sharing a common understanding of what it entails. The proposed security debt definition is as follows:

Security debt is a set of design or implementation solutions that hinder or have the potential to hinder the achievement of a system's security goal.

In short, security debt refers to postponed or insufficient security measures that leave systems more vulnerable to malicious attacks. Unlike technical debt, which primarily affects maintainability and evolvability, security debt relates to increased security risk. Think of it as skipping the lock on the front door of your house. It is an insufficient security measure that should be improved as it increases the security risk.

Why Should You Care About Security Debt?

Our society is becoming more digitalized, where computers are connecting critical infrastructure and functions we rely on as part of our daily lives. Neglecting security debt can lead to real-world consequences as it makes systems more vulnerable to malicious attacks.

Companies might face issues such as data breaches, financial losses, and reputational damage. For individuals, this could mean compromised personal information, among other problems. In a world increasingly dependent on technology, understanding and addressing security debt is crucial for everyone.

Take a simple example: outdated software. Many of us postpone updates for our personal devices, like phones and computers, because we find them inconvenient. But these updates often include security patches. For systems, it is also important to stay updated with the latest versions of protocols, libraries, etc. More about this below!

The different aspects of the security debt definition

A case study was conducted by interviewing professionals from the multinational conglomerate Visma to investigate security debt. The covered areas include what security debt it, its relationship to technical debt and security vulnerabilities, and how security debt accumulates in systems. The key takeaway points are as follows:

1. The definition of security debt explains the gap between the current security measures and the system’s security goal (ideal state). The security goal guides the software practitioners in understanding what qualifies as security debt in the context of the system.
   
   
2. Security debt can be both deliberate and not deliberate. Teams may intentionally accumulate security debt due to, for example, limited time or dependencies that increase the difficulty of repaying (fixing) the security debt. In other cases, security debt accumulates unintentionally, such as when technology changes. An example is when a new version of the Transport Layer Security (TLS) protocol is released: a gap is created and will be reduced by updating the protocol.
   
   
3. Security debt as a type of technical debt: the interviewed software practitioners highlighted similarities between security debt and technical debt, suggesting that security debt is a type of technical debt. Two key similarities include: security debt accumulates in a way that is similar to technical debt. It can be deliberate, not deliberate, and a technology change. Examples provided by the software practitioners to explain their understanding of the debts were used to describe both security and technical debt.
   
   
4. Security debt and security vulnerabilities: Unaddressed security vulnerabilities become security debt when fixes (e.g., patching or refactoring the system to remove the security vulnerability) are postponed. On the other hand, not all security vulnerabilities are considered security debt. A security vulnerability is not security debt if there is no existing solution or fix for it.

Now that we better understand the definition of security debt and the relationship between technical debt and security vulnerabilities, the next step is to understand how security debt accumulates in systems.

Security debt accumulation

To work efficiently with security debt, it is key to understand how it is accumulated. As part of the research, four accumulation patterns were identified:

1. Deliberate security debt accumulation: these intentional security measures are insufficient when it comes to achieving the system’s security goal. While the optimal solutions are not implemented, the security debt exists in the system.
   
   
2. Non-deliberate security debt accumulation: in this case, the software practitioners are unaware of the accumulated security debt. This can, for example, be due to a lack of knowledge or technology change. An example is software practitioners unaware of the security best practices needed to reach the system’s security goal.
   
   
3. Security vulnerabilities accumulated as security debt: security vulnerabilities introduced without available fixes/solutions (e.g., patching or refactoring the system to remove the security vulnerability) are not included in the set of security debt present in the system. However, once a fix/solution is discovered, the security debt gap between the current security measures and the security goal increases.
   
   
4. Accumulation of security debt with potential security risk: security measures that are sufficient today but may fall short in the future. When software practitioners discover potential security risks, they have the opportunity to prevent them from materializing in the system. If this opportunity is not taken, the security debt gap will increase when the security risk materializes in the system.

Practical steps to deal with security debt

What are the practical steps?

• Define the security goal: identify the security goal for the system, as this provides essential guidance on what qualifies as security debt within the context of the system. The security goal should be updated if the system’s context changes.
  
  
• Work continuously with security: once the security goal for the system has been defined, software practitioners must work with security debt in alignment with that goal.
  
  
• Security debt awareness is essential when identifying and preventing security debt accumulation. From the accumulation pattern “Not deliberate security debt accumulation,” we understand that security debt can accumulate due to a lack of knowledge. Equip your team with the knowledge they need to make informed security decisions.
  
  
• Tooling: even though tooling to detect security debt is not included in the definition, it can be used to identify it.

Looking Ahead

We rely on technology in our daily lives, which means we must focus on the importance of addressing security debt. The security debt research shows the need for a structured way to deal with security debt. Understanding the relationship between security debt, security vulnerabilities, and technical debt provides guidance for future research on security debt management.

Organizations must have a clear understanding of the definition of security debt and the accumulation patterns to work efficiently with security debt and the related security risks.

Let’s tackle security debt together. After all, a secure digital world benefits us all. 

This post is based on the article “Defining Security Debt: A Case Study Based on Practice.” Read the entire article as part of the Product-Focused Software Process Improvement (PROFES) 2024 conference proceedings or as a preprint from the Visma website under the header “Scientific articles.”