Test and operate
Complete a web security review
Review architecture, code, dependencies, configuration, tests, and recovery as one release decision instead of one final scanner run.
Web security lives across the whole delivery path, so the review is a release decision, not a final scanner run. A clean scan proves no known-bad dependency shipped. It says nothing about whether your business rules are correct.
A dependency scan is clean, but a new bulk-delete route checks authorization only for the first note. The release still contains a high-impact application flaw. No automated tool would flag that, because the code is valid; the logic is wrong.
Review the release as a whole
Walk the changed trust boundaries, not the whole app. For this release, check where new input enters, where authorization decisions live, and what dependencies and configuration changed.
[ ] threat model revisited for changed boundaries
[ ] authorization checked on every new read and write, including bulk
[ ] negative tests run (wrong user, missing proof, bad input)
[ ] dependency and deployment findings triaged
[ ] logs and alerts fire for the new paths
[ ] rollback rehearsed
Record each finding as a decision with an owner and a date, so nothing is silently forgotten.
Finding: bulk-delete authorizes only the first item
Path: POST /notes/bulk-delete with mixed-owner ids
Impact: high — cross-tenant deletion
Decision: fix before release Owner: flavio Date: 2026-08-03
Blocking every low-risk finding delays fixes that matter. Make each ship, fix, or accept decision from a reproducible path, impact, owner, and date. Block release when a credible high-impact path remains open.
Review one release across changed boundaries, authorization, input, dependencies, production configuration, monitoring, and rollback. Attach evidence for every finding and rerun one regression check after the deployed fix.
Lesson completed