Use each development check for the question it can answer
Design review examines trust boundaries. Code review examines the implementation. Automated tests repeat selected cases, and operational telemetry describes behavior after deployment. Each provides useful information, but a passing static check does not establish that the application’s authorization rule is correct.
Use SSDF and ASVS to help define product requirements. Record which requirements do not apply and why. Treating every warning as equivalent makes it harder to decide which result should block a release or require a specific change.
The asynchronous path missed the validation
In a fictional application, the interactive upload checks archive entries, while an asynchronous import calls extraction without that validation. A synthetic archive reproduces the problem. The list of reachable paths shows why a fix limited to the upload endpoint would be incomplete.
Move the required validation into the shared extraction path and check both callers. Test the original failure, normal input and errors, including whether a rejected archive leaves partial files or leaks resources. Finally, verify that the corrected build was deployed. A passing local test does not establish which code users are running.
Keep the finding connected to its release
The record should let the next person continue the work without reconstructing the investigation. Keep the original behavior and the final deployment connected through the following stages.
- Report: affected build and input, with expected and observed behavior.
- Triage: reachable paths, required conditions, impact and remaining uncertainty.
- Fix: responsible owner and the revised design or implementation.
- Verification: reproduction, regression tests and review evidence.
- Release: artifact, deployment and any action customers need to take.
Check that the release gate actually blocks the release
A verified tenant-isolation defect can justify blocking release while it remains unresolved. If an exception is allowed, identify its authority, evidence and expiry. The number of warnings alone does not explain whether that particular defect is acceptable.
Use a controlled failing fixture to verify the gate. Check the alternate release paths too. An authorized exception needs an attributable record; otherwise, the gate may work on the preferred path while the actual release goes around it.
Fix the reason the defect was missed
Duplicated validation, a mistaken assumption, inadequate test data and an unreviewed release path call for different improvements. Identify the cause and check whether the follow-up prevents recurrence. An AI-generated patch, green pipeline or clean scan can contribute evidence, but none on its own establishes that the product is secure.