Security debt is the accumulated cost of security shortcuts, deferred patches, and known vulnerabilities that an organization has chosen not to address yet. Like technical debt, it compounds over time. Unlike technical debt, it has a nasty habit of coming due all at once when an attacker finds the weakness you have been meaning to fix.
Every organization has security debt. The ones that manage it well are not the ones with zero debt, they are the ones that know exactly where their debt is, what it costs to carry, and have a plan for paying it down.
Defining Security Debt
Security debt includes:
- Unpatched vulnerabilities with known CVEs in production dependencies.
- Outdated components that are no longer receiving security updates.
- Missing security controls that should exist but were deferred (no rate limiting, no input validation on internal APIs, missing encryption at rest).
- Configuration weaknesses like overly permissive IAM roles, disabled security features, or default credentials.
- Incomplete security processes such as lack of dependency scanning, no secret rotation, or absent security monitoring.
The common thread is that someone decided, explicitly or implicitly, to accept the risk now rather than address it now. The decision was probably reasonable at the time. The problem is that these decisions accumulate.
Quantifying the Debt
You cannot manage what you do not measure. The first step is building a security debt inventory.
Step 1: Catalog Everything
Pull vulnerability data from every source:
- SCA scanner findings across all projects.
- Infrastructure scan results (cloud configuration, network vulnerabilities).
- Penetration test findings that remain open.
- Audit findings awaiting remediation.
- Known gaps in security controls documented during risk assessments.
Consolidate these into a single inventory. I recommend using a structured format:
ID: SD-2023-047
Type: Unpatched Vulnerability
Severity: High
Description: CVE-2023-XXXXX in jackson-databind 2.13.x
Affected Systems: payment-service, user-service
Age: 127 days
Remediation Effort: 4 hours (version upgrade, regression testing)
Risk Owner: Backend Platform Team
SLA Status: Overdue (7-day SLA for high severity)
Step 2: Score by Risk
Not all security debt is equal. A critical vulnerability in an internet-facing payment service is fundamentally different from a medium vulnerability in an internal reporting tool.
Score each item using a combination of:
- Vulnerability severity (CVSS or your internal scoring model).
- Exposure (internet-facing, internal, or air-gapped).
- Data sensitivity (what does the affected system handle?).
- Exploitability (is there a public exploit? active exploitation?).
- Age (older debt is riskier because it has had more time to be discovered by attackers).
Step 3: Calculate the Cost
For each debt item, estimate:
- Remediation effort in developer hours.
- Cost of carry which is the ongoing risk of leaving the debt unresolved.
- Cost of incident if the vulnerability is exploited (breach cost, regulatory fines, reputation damage).
You do not need precise numbers. Order-of-magnitude estimates are sufficient for prioritization.
Prioritization Strategies
The Risk-Effort Matrix
Plot your debt items on two axes: risk (vertical) and remediation effort (horizontal).
- High risk, low effort: Fix these immediately. These are your quick wins, things like version upgrades that take an hour but close critical vulnerabilities.
- High risk, high effort: Plan these into upcoming sprints. They need dedicated time but cannot be deferred indefinitely.
- Low risk, low effort: Batch these into maintenance windows. Fix them opportunistically when developers are in the affected code.
- Low risk, high effort: Accept these formally. Document the risk, set a review date, and revisit quarterly.
The SLA-Based Approach
Assign SLAs based on the risk score and hold teams accountable:
| Risk Score | SLA | Escalation | |-----------|-----|------------| | Critical (9-10) | 48 hours | Auto-escalate to VP if breached | | High (7-8.9) | 7 days | Escalate to team lead if breached | | Medium (4-6.9) | 30 days | Include in sprint planning | | Low (1-3.9) | 90 days | Quarterly maintenance window |
Track SLA compliance as a team-level metric. Teams that consistently breach SLAs need more capacity, better tooling, or different prioritization from their leadership.
Paying Down the Debt
Dedicated Capacity
The most effective approach I have seen is dedicating a fixed percentage of engineering capacity to security debt. Twenty percent is common. This means one day per week or one sprint in five is allocated to security remediation.
This works because it is predictable. Teams know when they will work on security items. Security knows when to expect progress. Leadership knows the investment.
The Boy Scout Rule
Encourage developers to fix security issues they encounter while working on nearby code. If you are modifying a file that imports a deprecated cryptographic library, update the library while you are there.
This incrementally reduces debt without requiring dedicated sprints. It works best for low-effort items.
Focused Sprints
For large debt items that require sustained effort, such as migrating from a deprecated authentication library or upgrading a major framework version, run focused remediation sprints. These are time-boxed efforts where a team concentrates on a single large security improvement.
Automation
Automate everything that can be automated:
- Dependabot or Renovate for automated dependency updates.
- CI/CD gates that prevent new debt from being introduced.
- Scheduled scans that detect new vulnerabilities in existing code.
- Auto-merge for patch-level dependency updates with passing tests.
Automation handles the routine debt (version bumps, known-fix patches) so humans can focus on the complex debt (architecture changes, manual remediation).
Preventing New Debt
Paying down existing debt while accumulating new debt at the same rate is a treadmill. You need gates:
PR-level gates: Block merges that introduce new critical or high vulnerabilities. This is non-negotiable.
Design-level gates: Require security review for new services and major architectural changes. Catch missing controls before code is written.
Dependency gates: Require review for new dependencies. Each new dependency is a potential future debt item.
Exception tracking: When someone accepts a risk to meet a deadline, log it formally with a remediation date. Do not let accepted risks become forgotten risks.
Reporting and Communication
Security debt is a business risk, so report it in business terms.
For engineering leadership: Total debt items by severity, remediation velocity (items closed per sprint), SLA compliance rates, and top-10 riskiest items.
For the CISO and board: Total risk exposure in terms they understand. "We have 12 critical vulnerabilities in internet-facing systems, down from 28 last quarter. Our current remediation rate projects clearing the critical backlog within 6 weeks."
For engineering teams: Their team's specific debt items, upcoming SLA deadlines, and quick-win opportunities. Make it actionable.
How Safeguard.sh Helps
Safeguard.sh gives you a real-time view of your security debt across every project in your portfolio. It automatically catalogs vulnerabilities, scores them by contextual risk, enforces remediation SLAs through policy gates, and tracks remediation progress over time. The platform provides the dashboards your security team needs to report to leadership and the actionable findings your developers need to prioritize their work. Instead of maintaining spreadsheets and stitching together scanner output, Safeguard.sh makes security debt visible, measurable, and manageable.