[Sample] A critical finding is fixed. What still needs checking?
Sample Security Decisions guide: verify the fix, regression coverage, and release scope before launch. Placeholder content for reviewing this series.
![[Sample] A critical finding is fixed. What still needs checking?](/_next/image?url=https%3A%2F%2Fwww.quillaudits.com%2Flanding%2Fwhy%2Fcard-image-2.2.png&w=1080&q=75)
SAMPLE CONTENT — This write-up is a placeholder for reviewing the Security Decisions series. The example is hypothetical and has not received a protocol-specific security review.
The decision
A critical audit finding has been fixed. What still needs checking? Verify that the fix blocks the original failure path, preserves expected behavior, and is included in the exact version being released.
When it arises
A team is preparing a launch after changing code in response to an audit finding. The reviewed commit and planned deployment may differ.
Failure path
A patch blocks one entry point. A second path reaches the same vulnerable operation. Tests cover only the first path, so the release still contains the underlying issue.
What to verify
Reproduce the original issue against the old code. Confirm it fails against the patched code. Test alternate entry points, expected successful operations, permissions, and boundary conditions. Compare the reviewed commit, build configuration, initialization, and deployment parameters with the proposed release.
Evidence to request
Finding identifier, patch diff, reproducible regression tests, reviewed commit hash, deployment scripts, dependency versions, configuration, and written reviewer sign-off for the stated scope.
Scope and limits
A finding-specific recheck establishes evidence about that finding within an agreed scope. It does not establish that every contract, integration, or operational process is secure.
Relevant example — hypothetical
A withdrawal fix checks authorization in one function but leaves a second withdrawal route unchanged. A regression test for both routes exposes the remaining path before launch.
Related reading
OpenZeppelin Access Control: https://docs.openzeppelin.com/contracts/4.x/access-control
QuillAudits research: https://www.quillaudits.com/research
Next step
Define the release version and ask the security reviewer to confirm the remediation and any changes outside the original audit scope.
Contents
