Security Remediation and Vulnerability Retesting

Finding a vulnerability is usually the easy part. The harder work is making the fix specific, checking it, and stopping the same pattern from returning.

Why good findings still get stuck

Findings get stuck for practical reasons. Engineers may care about the issue, but the finding often does not contain enough information to move the work forward.

The finding is written for a security reader

“Broken access control” does not tell an engineer which code path is affected or what correct behaviour should look like.

No one owns it end to end

Security owns the report, engineering owns the code, and the actual outcome falls between the two.

“Done” is undefined

If nobody decides how to check the fix, moving the ticket to Done becomes the definition of fixed.

The fix is local

One endpoint is patched while the same pattern remains in the rest of the product.

There is no retest

Nobody checks that the change removed the risk or that it did not break a neighbouring flow.

Volume sets the order

Findings arrive faster than the team can triage them, so age starts deciding priority instead of exposure.

What lets an engineer close a finding

A finding becomes useful when the person picking it up can tell what is affected, what to change, and how the result will be checked. These are the details I look for first.

The property at risk

Which security property is threatened, stated in plain language.

The affected path

The specific endpoint or flow where the issue lives.

The required behaviour

What correct looks like, so the fix has a target.

An owner

A named engineer or team, not a shared queue.

A verification criterion

The test or check that will demonstrate the risk is gone.

A due date tied to risk

Priority reflects actual exposure, not the order findings arrived.

Retesting is not re-scanning

A re-scan runs the same automated checks again. Useful, but limited: it only finds what the scanner can see, and a clean scan is not evidence that a specific issue is fixed.

Retesting is targeted. It reproduces the original issue, confirms the control now behaves correctly, and checks that the fix did not introduce or leave a related problem.

The distinction matters most for access control and business-logic issues, where scanners are weakest and enterprise customers are most concerned.

How to check that the fix held

Decide how the fix will be checked before the ticket is closed. A workable sequence is:

1 Reproduce the original issue against the current build.
2 Confirm the specific control now behaves as required.
3 Check that the fix did not break adjacent behaviour.
4 Confirm other instances of the same pattern were addressed.
5 Record the evidence so it can be reused for customers and auditors.
6 Add a regression check so the issue cannot silently return.

What good remediation looks like

Good remediation is quiet. A ticket closes because the risk is gone, and the same issue does not return in the next release. The team can spend its security time on new problems instead of reopening old ones.

The verification record also helps with customer reviews. The work used to close the issue answers part of the next questionnaire instead of creating another task.

Common questions

How quickly should critical findings be fixed?

It depends on exposure, not on a universal number. What matters is having a risk-based timeline that is agreed in advance, so priority is a decision the organisation has already made rather than a debate on every finding.

Do we need to retest every finding?

Every finding where the risk is not self-evidently removed should have a verification criterion. For low-risk issues that can be a lightweight check; for access control and business logic it should be a real retest.

Who should do the retesting?

Not the person who wrote the fix, where possible. A second engineer, a QA engineer or an external assessor can verify independently. The important thing is that the retest follows the pre-defined criterion.

How do we stop the same issues returning?

Add a regression check for the specific case, and generalise the fix so the pattern is handled consistently. Over time, tests and review checklists encode the lessons so new code inherits them.

Start with the Product Security Assessment

One week at a fixed fee, and a clear picture of where your Product Security effort is fragmented and what deserves investment next.

Discuss an assessment See what the assessment covers