Home / Knowledge hub / Security debt
Knowledge hub
Security debt
The pile of known weaknesses a team has put off fixing.
What it means
Security debt is the collection of known security weaknesses your team has chosen, or drifted into, leaving unfixed for now. It is borrowed from the idea of technical debt: a shortcut taken now that you pay back later, usually with interest, and the interest is risk.
The items are things you know about, not hidden ones. An outdated library with a published fix, an admin page without a second factor, a finding from last year's pentest marked low and forgotten. Each one is small on its own. Together they form the backlog an attacker would choose from.
Why it matters
Debt does not stay still. Old issues interact with new code, staff who understood them move on, and fixes get harder as more depends on the weak part. Something that took an hour to correct in week one can need a project by year two.
It shows up in sales and audits too. A buyer's security questionnaire asks how quickly you fix problems, and an old list of open items answers badly. A breach through a known, unfixed flaw is also the hardest to explain afterwards.
How it shows up
You meet it as a long vulnerability backlog, scanner results nobody opens, and exceptions that never expire. The causes repeat: fixes lose out to features, nobody owns the old systems, and findings arrive with no clear owner or deadline, so they sit until someone has a reason to look.
Make it visible first. Count open items by severity and age. Agree fix times, as in a remediation SLA. Where you decide not to fix something, record it as a risk acceptance with an owner and an end date. Then reserve a steady share of each sprint for paying it down, so the work does not wait for a quiet month.
Questions people ask
Security debt, answered
Is security debt the same as technical debt?
It is a close cousin. Technical debt covers any shortcut that makes code harder to change. Security debt is the part that leaves the system open to abuse. Some technical debt carries no security risk at all.
How do we measure security debt?
Count open known issues, grouped by severity, and track their age. A simple chart of how many were opened and closed each month shows whether the pile is growing or shrinking.
Should we fix everything before we release?
Rarely possible. Fix what is serious and easy to exploit first, and set dates for the rest. Releasing with known gaps is acceptable only when someone has decided so on purpose and written it down.
Can we ignore low-severity findings?
Not forever. A low item on its own may be harmless, but flaws can be combined. Keep them on the list with an owner, and look again when the system around them changes.
How do we stop security debt from coming back?
Fix the cause as well as the symptom. Add automated checks, review sensitive changes, and add a regression test for each fixed flaw, so the same issue cannot quietly return.
Sources
Where this comes from
Related
Terms that sit next to this one
Vulnerability backlog
The growing list of known flaws a team has yet to fix.
Remediation SLA
The agreed time within which a finding of each severity must be fixed.
Risk acceptance
Deciding, on the record, to live with a known issue rather than fix it.
Vulnerability ageing
How long known findings have sat open, as a measure of fix speed.
Security regression test
An automated test that fails if a fixed vulnerability ever returns.
How old is your oldest open finding?
A backlog is easier to clear when each item is proven, ranked and tied to a line of code. Our findings keep severity and confidence apart, and a fix is closed only after we re-run the exact exploit. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.