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

Take this course offline

Get every free book, course edition, and software download.

Get the download library →