Security debt is all the shortcuts and fixes you put off until tomorrow, which end up piling up until they cost a lot. A postponed update, a configuration left too permissive, an ignored alert: each deferral looks harmless, but together they silently weaken the system. Like a loan, this debt accrues interest. This lesson explains where it comes from, why it is dangerous, and the rule that keeps it from becoming invisible: a detected weakness is fixed right away or recorded in the register, never left aside.
What you will learn
This lesson needs no prerequisite other than the notion of a software update. It prepares vulnerability management, its tooled practice.
- Define security debt and compare it to a financial debt.
- Recognise its sources: deferred fixes, outdated dependencies, lax configurations, ignored alerts.
- Apply the handling rule: fix right away, or record in the register with an owner and a due date.
- Understand why it is paid all at once, at the worst moment.
- Pay back existing debt: inventory, prioritise by risk, fix as part of daily work.
What is security debt?
Security debt covers all the known unfixed flaws, overly permissive settings and technical shortcuts accumulated for lack of handling them right away. It is not a visible outage: it is a set of small weaknesses that grows quietly as long as nothing forces you to deal with it.
Its defining trait is that its cost grows over time. Deferring a fix gives an immediate benefit: the release keeps its date. But the code goes to production, other components rely on it, the author changes teams and the context of the decision is lost. Six months on, the same fix requires understanding a choice nobody owns anymore.
The term is inspired by technical debt, the code written fast that will slow future changes. Security debt is its protection counterpart: it is not changes that become hard, it is the system that becomes vulnerable. A vulnerability is a weakness an attacker can exploit to get in, steal data or disrupt the service.
Where does security debt come from?
Security debt is not born of one big act of negligence, but of a crowd of small decisions made under pressure. Four sources come back almost every time, and they share one trait: the weakness was seen, then left without follow-up.
Deferred fixes are the most frequent source. A vendor publishes an update that closes a flaw, but the team decides to apply it "after the next release". The flaw stays open throughout that delay, and the deferral often repeats until it is forgotten.
Outdated dependencies concern reused building blocks. Modern software relies on dozens of external libraries: when they are no longer updated, they carry their own known flaws, which your system inherits without knowing it.
Lax configurations are settings left too open "to go faster": a default password never changed, admin access granted too broadly, a service exposed on the Internet when it should stay internal. Every overly permissive setting opens one more way in.
Ignored alerts come from monitoring tools. A scanner, a tool that inspects code or servers for flaws, reports problems nobody handles. Alerts pile up, people stop looking at them, and real emergencies drown in the noise.
What should you do with a detected weakness?
A detected weakness has only two legitimate outcomes, and the diagram contrasts them with the third, the one that creates debt. Either you fix it right away, when possible. Or you decide to defer, and then you record it in the debt register, with what it takes to find and handle it. What is forbidden is a weakness seen and then left aside on a "we'll see": neither fixed nor recorded, it becomes invisible debt.
A register entry is only worth something if it lets you act without finding the author of the deferral. The table gives the minimum to record; a ticket in the team's tracking tool is enough, as long as it carries all these fields.
| Field | What it says | Example |
|---|---|---|
| Weakness | What was detected, and where | Critical CVE in the payment library of the orders service |
| Severity in context | The real risk, not the raw score | Exposed on the Internet, public exploit: high |
| Owner | A named person or role | Tech lead of the orders team |
| Due date | The date to fix or review | Within 14 days |
| Interim measure | What reduces the risk meanwhile | Web application firewall rule blocking the vector |
| Acceptance | Who accepts the risk until the due date | Security manager, in writing |
At the due date, the entry does not silently disappear: the weakness is fixed, or the risk is re-accepted explicitly, with a new date. A due date passed with no decision is a warning signal in itself. The same principles apply to suppressing scanner alerts, and a VEX document records that a vulnerability is not exploitable in your context, with evidence.
Why is security debt dangerous?
The real danger of security debt is that it is not paid gradually. It stays invisible as long as nothing happens, then it is settled all at once, the day a flaw is exploited. That day, the bill is far heavier than the avoided fix.
Fixing a flaw upstream, while you still master the context, often takes a few hours or a few days. Fixing the same flaw after an incident (intrusion, data leak, service down) costs weeks: understand what happened, patch in a hurry, notify the people affected and restore trust.
A second trap makes things worse: the normalisation of risk. After living with a flaw without an incident, you end up believing it is harmless. "Not yet exploited" does not mean "not exploitable": an old flaw is precisely an easy target, because everyone has forgotten it exists. This is what the register prevents, by keeping each deferral visible and dated.
How do you pay back existing debt?
The handling rule stops the debt from growing; it does not pay back what already exists. That repayment happens in three steps, without trying to fix everything at once: the goal is to regain control, not to start an endless project.
The first step is to take inventory. You cannot reduce what you do not see: known flaws, outdated software, dubious configurations, forgotten access. Each item found goes into the register, exactly like a newly detected weakness. Making the debt visible is already half the work.
The second step is to prioritise by risk. A flaw that is easy to exploit, exposed on the Internet and giving access to sensitive data comes well before a minor weakness on an internal server. Fix first what combines high likelihood of exploitation and high impact, not what is oldest or most numerous.
The third step is to fix as part of daily work. Debt always comes back if it is treated as an exceptional project. Better to set aside regular time for remediation (the act of fixing a flaw), apply security updates as soon as they come out, and leave the system a little safer than you found it every time you touch it.
Reducing what you install and expose also creates less debt: that is the purpose of minimisation (in French) and of reducing the attack surface. For the flaws that remain anyway, defence in depth limits the damage.
A concrete scenario
A team discovers a serious flaw in a library of its application. The fix is estimated at two days, but a major release is coming: "we'll fix it after". Nobody opens a ticket, nobody sets a date. The flaw is seen, but not recorded.
After the release, the team moves on to another project. The people who knew the subject move on, and the context is lost. Six months on, an attacker exploits the flaw: customer data exposed, service down, three weeks to understand, patch and restore trust.
With the handling rule, the same deferral would have been recorded: owner appointed, due date in two weeks, filtering rule set up meanwhile. At the due date, the ticket would have come back to the table, and the two-day fix would have been applied at the initial price.
Which traps should you avoid?
Even with good intentions, a few reflexes sabotage debt handling. Knowing them helps avoid them, and each has a simple fix.
The first trap is to defer without recording. Each deferral looks reasonable taken alone, but a deferral without an owner or due date is a planned oversight. The fix: no deferral without a register entry.
The second trap is the register graveyard: everything is recorded, but nobody rereads. Due dates passed by the dozen protect nothing. The fix: a regular review of the register, and a passed due date treated as a process incident.
The third trap is to measure only functionality. What is not measured is not handled: without a security indicator (number of open flaws, age of register entries), the debt thrives. Security KPIs provide these indicators.
The fourth trap is to take comfort in flattering numbers. "Fifty flaws fixed this month" means nothing if they are fifty minor weaknesses while a critical flaw has been lingering for six months. What matters is the severity handled, not the volume.
Key points
- Security debt accrues interest. The longer you wait to fix, the bigger the final bill.
- It comes from small repeated deferrals: fixes put off until tomorrow, outdated dependencies, overly permissive configurations and ignored alerts.
- A detected weakness is fixed right away or recorded in the register, with severity, owner, due date and risk acceptance. Never left aside.
- It is paid all at once, at the worst moment: an incident costs weeks where the initial fix cost days.
- "Not exploited" does not mean "not exploitable". The absence of an incident is never proof of security.
- You pay it back by taking inventory, prioritising by risk and fixing daily. A serious, exposed flaw comes before ten minor weaknesses.
- This debt is the dark side of the threat model: the SOCLE threat model (in French) links each weakness to a concrete threat.
Knowledge check
Check that you have the essentials of this guide. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: CINC Auditor: scanning the compliance of your containers
A new full quiz with random questions
Work again only on the questions you missed