Why 'Ticket Closed' Doesn't Mean 'Fixed'

A quarter of vulnerabilities your dashboard reports as “remediated” aren’t fixed. A developer marks a Jira ticket Done, security moves it to Resolved, the CISO reports to the board that the critical finding has been remediated. Six weeks later a pen tester finds the exact same exploit in production. The ticket says fixed. Reality disagrees.

The Uncomfortable Data

Edgescan’s 2024 report found that roughly one in four “remediated” vulnerabilities remained exploitable on re-test. That number is an aggregate. Some environments are worse:

• Partial fixes account for a large share: a team updates the direct dependency but misses the transitive path that still pulls in the vulnerable code
• Configuration drift means the fix lands in staging but never reaches every production instance, every auto-scaling group, every container image
• No verification step at all: Edgescan found that many organizations close tickets based on the developer’s word, with no independent re-scan before marking a finding resolved

These aren’t edge cases. They’re the baseline for how most vulnerability management programs actually operate.

Why Remediation Fails Silently

The Handoff Problem

Vulnerability management is a coordination challenge. A security team identifies a finding, creates a ticket, and hands it to engineering. An engineer interprets the ticket, implements what they believe addresses it, and marks it done, but the scanner finding described a technical condition, the ticket translated it into an engineering task, and the engineer interpreted the task through their own context, so by the time the fix ships, the original finding has passed through three translations, each one lossy, each one an opportunity for the actual vulnerability to survive while the ticket doesn’t. That trust is the gap.

Not because engineers are careless, but because the information degrades at every handoff.

Partial Fixes

Consider a common scenario: a scanner identifies an outdated library with a known CVE. The engineering team updates the library. Ticket closed. But the application also has a second dependency that pulls in the same vulnerable code through a transitive path. The direct dependency is updated; the transitive one isn’t. The vulnerability persists.

Partial fixes are especially common with:

• Configuration vulnerabilities where the fix lands in one environment but not others
• Dependency chains where direct updates don’t resolve transitive vulnerabilities
• Infrastructure findings where the fix applies to one instance but isn’t replicated across auto-scaling groups or container images
• Application vulnerabilities where the fix addresses one endpoint but the same pattern exists in other code paths

The Reintroduction Problem

Even when a vulnerability is genuinely fixed, a code merge can overwrite the patch, a new deployment can roll back the configuration change, and an infrastructure rebuild can restore an outdated template. The vulnerability returns to production, the ticket still says “Resolved,” and without continuous verification nobody notices until the next pen test or, worse, the next incident. The fix existed. Past tense.

Human Nature

There’s also a psychological dimension. When someone has spent hours working on a remediation, they’re inclined to mark it complete. The ticket has been open too long. The SLA is about to breach. The standup meeting is tomorrow. These pressures, however subtle, create incentives to close tickets before verification is complete.

What the gap costs

Your risk dashboard is lying

If 25% of your “remediated” vulnerabilities aren’t actually fixed, your risk dashboard is lying to you. The board is making resource allocation decisions based on a risk posture that doesn’t reflect reality. When an auditor asks how you verified remediation and the answer is “the engineer closed the ticket,” that’s not a process gap. It’s a governance failure.

Compliance Exposure

Frameworks like PCI DSS 4.0, SOC 2, and ISO 27001 require evidence that vulnerabilities are actually remediated, not that tickets were closed. A remediation ticket is evidence of intent. Verification is evidence of outcome. Auditors have caught on to the difference.

Compounding Technical Debt

Every unverified “fix” that didn’t work is a vulnerability that stays in production, accumulating risk. Over months and years, the delta between your reported risk posture and your actual risk posture widens, the backlog of silently unfixed findings compounds, and the remediation team’s credibility erodes with every pen test that rediscovers “resolved” vulnerabilities. Eventually the gap becomes visible during the worst possible moment: an incident. Most organizations discover the difference during an incident.

Eroded Trust

When penetration testers or red teams repeatedly find “fixed” vulnerabilities, it erodes trust between security and engineering. Security starts assuming fixes didn’t work. Engineering starts resenting the implication. This adversarial dynamic makes the underlying coordination problem worse.

Verification isn’t re-scanning

Genuine verification isn’t the same as re-scanning. It requires a deliberate process that confirms the specific vulnerability is no longer exploitable in the specific context where it was found.

Someone else checks

The person or system verifying the fix should be independent of the person who implemented it. This is the same principle behind separation of duties in financial controls. The developer who wrote the patch shouldn’t be the sole authority on whether it worked.

Context-Aware Testing

Verification must test the actual condition, not a proxy for it. Confirming that a package version was updated isn’t the same as confirming the vulnerability is no longer exploitable. The verification method should match the finding type.

Speed matters

Verification that happens weeks after remediation is less valuable than verification that happens immediately. The longer the delay, the more likely reintroductions or environmental drift will invalidate the results.

Evidence Generation

Verification should produce a record: what was tested, when, by what method, and what the result was. That record is what an auditor asks for. It’s also what your team needs to trust the process.

Where to start

Organizations that want to close the verification gap should consider these practical steps:

1. Measure the gap first. Re-scan a sample of recently “fixed” vulnerabilities. The results will make the case for investment.
2. Define verification criteria by finding type. A configuration vulnerability requires different verification than a code vulnerability. Document what “verified” means for each category.
3. Automate where possible. Automated re-scanning, configuration checks, and dependency analysis can verify a large percentage of findings without manual effort.
4. Separate the roles. The team that verifies should be distinct from the team that remediates, even if both report to the same leader.
5. Track verification metrics. First-pass fix rate, mean time to verify, and verification failure rate are leading indicators of remediation program health.

Hope isn’t a remediation strategy

Most vulnerability management programs operate on assumption. They issue remediation instructions and hope the instructions were followed. Verification-driven systems confirm the outcome and feed that evidence back into the process.

Every organization has a verification gap. The only variables are its size and whether you find it before an attacker does.

For the practical guide to building the closed-loop program that solves this, see Building a Closed-Loop Remediation Program.

---

If you suspect a verification gap, book a remediation workflow review.