Retest a security fix without losing the evidence
Verify the repaired behavior on the deployed build, include a legitimate allow case, and record what remains outside the retest.
A security retest checks whether a specific repair addresses a specific finding. It is not a second full assessment unless that broader work is separately scoped. Start with the original evidence, the proposed fix, and the exact build that contains it.
Do not close a finding because a pull request was merged. The relevant service, worker, or configuration may still run an older version. Record the deployed version before repeating the approved test.
What should the retest record contain?
| Item | Question |
|---|---|
| Original finding | Which behavior and boundary failed? |
| Repair | What control changed? |
| Deployment | Which build, environment, and configuration are active? |
| Fixture | Are the test identities and records in the expected state? |
| Deny case | Does the unauthorized action now fail safely? |
| Allow case | Can an authorized user still complete the task? |
| Related paths | Does the same handler have another in-scope entry point? |
| Result | Fixed, partially fixed, not fixed, or unable to verify? |
These are suggested review fields. The OWASP reporting guidance supports clear reporting of evidence and limitations; it does not make a retest equivalent to a security guarantee.
How do you distinguish a repair from a broken test?
Confirm that the endpoint is reachable and that the fixture still represents the original conditions. A missing account, disabled feature, or unavailable worker can make an unauthorized action fail for the wrong reason.
Exercise a legitimate operation with the same relevant configuration. For an authorization repair, pair a denied cross-tenant request with an allowed same-tenant request. For a revocation repair, check both the retired credential and its approved replacement.
Inspect the returned data and side effects, not just the status code. A request can return an error after creating a job or writing a record. Include the resulting state when it matters to the finding.
How do you close the finding?
Attach the new evidence to the original record. Keep the original observation intact. State any change in scope or inability to reproduce the earlier setup.
If the repair covers only one of several affected paths, mark the result partial and name the remaining paths. If the scope expired, obtain renewed permission before running additional tests.
A useful closure statement is narrow: the named behavior passed the recorded tests on the specified build. It does not say that the application has no other defects. Plan a review and retest with Sourced around the risks your team needs to resolve.
Know what you will get from a review
Explore an illustrative finding with evidence, a proposed fix and retest criteria. Discuss your systems, review questions and deadline when you are ready.