Buyers turn security debt into cost: engineering weeks to fix, risk of an incident before fixes land, and customer contract exposure. Sellers who present a sorted backlog with owners, dates and a burn down trend usually face smaller adjustments than those who show a raw scanner export.
What counts as security debt
- Open vulnerabilities in shipped code.
- Unsupported runtimes and frameworks.
- Missing controls that customers or regulators expect.
- Manual processes that should be automated, such as access reviews.
How buyers price it
There is no standard formula. Common approaches:
- Estimate engineering effort for each cluster of work and multiply by loaded cost.
- Add a contingency for items that are poorly understood.
- Weigh contractual obligations, such as customer commitments on patch timelines.
- Decide whether the work is a price reduction, an escrow or a post close budget.
Unknowns raise the contingency. Clarity lowers it.
Present the backlog well
- Deduplicate. A thousand findings often reduce to dozens of fixes.
- Separate reachable from unreachable vulnerabilities, with the reasoning.
- Mark exploited in the wild issues first.
- Show age and trend: opened, closed and remaining per month.
- Give each cluster an owner, estimate and date.
Fix what is cheap and visible
Update dependencies with available fixes, rotate old secrets, enable branch protection and multi factor authentication. These close visible gaps quickly and show the team can move.
Do not hide it
Trimming a report to look better backfires when the buyer runs their own scan. Explain differences rather than deny them.
Agree who fixes what
Contracts can assign pre close fixes to the seller and post close work to the buyer. Write the list into the agreement so both sides agree on scope.
Safeguard's reachability analysis and fix pull requests (off by default, with every category on Manual) can help reduce a backlog before a sale.
Example of a clustered backlog
A raw export lists 2,400 findings. After grouping by root cause, they fall into a few clusters: one outdated framework accounting for hundreds of library findings, one container base image, a set of unreachable test dependencies, and a handful of genuine application flaws.
The buyer's view then changes. Instead of 2,400 problems there are four work items with estimates. The framework upgrade is the big one. The base image update is days. The test dependencies are removed from the shipped build. The application flaws go to the product team.
This clustering is the single most useful thing a seller can do. It reduces the number, shows understanding and lets both sides agree on cost.
Quick check
Does a long findings list sink a deal?
Rarely by itself. Missing process and hidden issues do more damage.
Last reviewed: 19 October 2026.
