Security findings need more than a debt label

What the label does not tell you

In the backlog they sit side by side: “Refactor the order module” and “Missing input validation in the customer API”. Both tagged technical debt. Both deprioritized, sprint after sprint, for the same good reasons.

But the label says nothing about who can reach the customer API, what missing validation makes possible, or which data is at stake. When both items are treated as ordinary maintenance, that assessment can be missed.

What the debt metaphor does and doesn’t tell us

The metaphor “technical debt” helps us talk about the cost of deferring work. Messy code can make every change more expensive, and the team has to decide when cleanup is worthwhile. We can make that trade-off visible, as I wrote in Technical debt as a team phenomenon (in Norwegian).

Ward Cunningham used the metaphor in a 1992 experience report. He described how a little debt can speed development if it is repaid promptly, and how working with code that is not quite right costs interest. He also warned that unpaid debt can bring an entire engineering organization to a standstill. The metaphor does not promise that deferral is harmless.

Security holes add another uncertainty: someone outside the team may choose to exploit them.

A vulnerability may remain without visible incidents, or be exploited before the next planned upgrade. The impact depends on what the attacker can reach and do. The absence of an alarm does not tell us it is safe to wait.

A weakness can be both technical debt and a security risk. The point is that the debt label must not replace the risk assessment. We decide when we do the work. We do not decide when someone tries to exploit the weakness.

Language sets the priority

Consider how the issue might be presented in a prioritization meeting:

“We have technical debt in authentication” says little about what is at stake. It is easy to treat it as maintenance that can wait.

“We have a known vulnerability in authentication, and we don’t know whether it has been exploited” raises a different question: which systems are affected, what can an attacker do, and what do we need to investigate or contain now?

As with debt that has to be made visible to decision-makers (in Norwegian), the translation is part of the tech lead’s job. Describe exposure and impact as concretely as you can. If five years of customer data may be accessible, say so, and explain what the assessment rests on. If you do not know whether the weakness can be reached, someone needs responsibility for finding out.

Rules for security findings

The practical consequence:

Give security findings their own rules. A separate list or a clear view within the same backlog can do the job. Findings assessed as critical in your environment get an owner and a deadline for a fix or mitigation. If the deadline cannot be met, escalate to whoever has authority to accept the risk. A new feature request cannot quietly push the issue back another sprint. This is a boundary the team should know in advance, as I wrote in Standards in practice (in Norwegian).

Let the assessment decide what can be planned. Security findings assessed as lower risk can be handled alongside ordinary maintenance. Record why waiting is reasonable, who will follow up, and when the assessment should be revisited. Refactorings and modernization still need deliberate trade-offs; not every issue becomes urgent because it sits next to a security finding.

An assessment that survives the next sprint

The next time you prioritize, pick one security finding that has been moved back several times. Do you know what is exposed, and why it can wait?

It is fine to plan the work. The reason for waiting needs to be visible.

Finish the assessment with an owner, a deadline and an agreement on how you will check that the risk has actually been reduced.