But was the issue actually fixed? Often nobody checks. At BreachLine Labs we think that last step deserves its own checklist. Here is the one we would hand to any team.

1. Why "fixed" is not the same as "safe"

Fixes fail in quiet ways. Some common ones:

• The twin endpoint. You patch /api/v2/orders/{id}, but /api/v1/orders/{id} still works and has the same bug.
• The symptom, not the cause. You block one bad input, but a slightly different one gets through.
• The fix that gets undone. A later refactor, a merge, or a config change quietly brings the issue back.

None of these are rare. That is why a fix needs a retest, not just a review.

2. Start from the original proof

Before anything else, find the evidence that showed the issue in the first place. That might be:

• the exact HTTP request and response
• the steps a tester followed
• the test accounts and roles they used

Re-run those steps first, exactly as before. If the original proof no longer works, that is a good start. If it still works, the fix is not done.

Tip: if your tickets do not keep this evidence, start now. A finding without reproduction steps is very hard to retest.

3. Test around the fix, not just on it

Attackers rarely try only the exact thing you patched. Neither should you.

Imagine you fixed an access control bug where user A could read user B's invoice. Now check:

• Similar endpoints. Can user A still read B's receipts, orders or profile?
• Other roles. Does the fix hold for admins, guests and API keys?
• Other encodings. Does the check still apply if the ID is sent in a different format, or in the body instead of the URL?
• Older versions. Is an older API version still live, and does it have the fix?

A short list like this catches most "fixed here, broken there" problems.

4. Quick re-checks for config fixes

Some fixes are not code. They are settings. Security headers, cookie flags, TLS settings and CORS rules are common examples.

These are easy to get right in a pull request and wrong in production. A proxy, a CDN or a different environment can change what users actually receive.

So check them live, after deploy:

• Are the security headers you added actually being sent?
• Do session cookies have Secure, HttpOnly and a sensible SameSite value?
• Is the CORS policy as tight in production as it was in review?

For header fixes, a quick live check helps. A free security headers check shows what your site actually sends after deploy.

When the fix is a dependency upgrade

Some fixes are just a version bump. A library had a known flaw, and you upgraded it. That sounds simple, but it is worth a quick check.

• Did the new version actually ship? Look at the lockfile and the built artefact, not just package.json or requirements.txt.
• Is the old version still pulled in somewhere? Another package may depend on it. Check the full dependency tree.
• Did anything else change? A big upgrade can bring new install scripts or new sub-dependencies. Review the lockfile diff before you merge.

If you can, re-run the original proof against the upgraded build too. A version number is a claim. A failed exploit is evidence.

5. Stop it coming back

The best retest is one that runs by itself.

Where you can, turn the original proof into an automated test in CI. For example:

def test_user_cannot_read_other_users_invoice(client, user_a, user_b_invoice):
    client.login(user_a)
    response = client.get(f"/api/v2/invoices/{user_b_invoice.id}")
    assert response.status_code in (403, 404)

Now if a later change brings the bug back, the build fails. You find out in minutes, not months.

Not every issue can be tested this way. Config and infrastructure issues may need a scheduled check instead. But anything you can automate, you should.

6. Record the result

Before closing the ticket, attach the evidence. A good record includes:

• the original proof
• the retest steps you ran
• the result, with a request and response or a screenshot
• the date and who ran it

It also helps to use two different words. Fixed means the code changed. Verified fixed means someone re-ran the proof and it failed. Only the second one should close a security ticket.

7. When to bring in a fresh pair of eyes

The person who wrote a fix is not always the best person to test it. They know what they meant to do, so they test that.

For high-risk issues, ask someone else to retest. That might be another developer, your security lead, an external tester, or an automated tool you trust. Fresh eyes try things the author did not think of.

The checklist, in one place

1. Keep the original proof.
2. Re-run it exactly.
3. Test similar endpoints, roles, encodings and versions.
4. Re-check config fixes live, after deploy.
5. Turn the proof into an automated test where you can.
6. Record the evidence, and use "verified fixed".
7. Get a second person or tool to retest high-risk fixes.

It takes a little longer than closing the ticket. It saves a lot more time than finding the same bug twice.

About the authors: the BreachLine Labs team builds Nebula, an autonomous AI security engineer that proves impact with working exploits and retests fixes.

Drafted with AI assistance and reviewed and tested by the BreachLine Labs team.