PS Product SecurityKnowledge Base

📋 Security Review Checklists and Cheat Sheets

Intro: A checklist is not a substitute for judgment. It is a short forcing function that makes sure the reviewer asks the questions most likely to change the decision.

What this page includes

  • an index of review checklists in this pack;
  • short guidance on how to use them well;
  • a stage-by-stage table for when each checklist matters.

When to use a checklist

Use a checklist when:

  • the review is time-boxed;
  • the reviewer is new or context-swapping;
  • the same failure mode appears repeatedly;
  • the team needs a common minimum bar.

Do not use a checklist as a way to avoid understanding the system.

Checklist index

Checklist Best time to use it Primary question
Pre-Release Security Checklist Right before deployment or feature launch Are we about to ship avoidable risk?
API Review Checklist During design or before exposing new routes Does the API enforce object, function, and consumption controls?
Cloud Change Review Checklist Before IAM, network, storage, or platform changes Does the infrastructure change expand authority or blast radius?
Production Readiness Security Checklist Before declaring a service “ready” Can the service be safely operated, observed, and recovered?
Secret Handling Checklist During CI/CD and service review Are secrets stored, injected, rotated, and observed safely?
IAM Review Checklist During platform, pipeline, and cloud trust reviews Which identity can do what, from where, and for how long?
Dockerfile Review Checklist During image and service build review Does the image reduce avoidable package, user, and provenance risk?
Kubernetes Deployment Review Checklist During workload or cluster admission review Does the deployment rely on safe defaults for workload identity, isolation, and observation?

Good checklist habits

  • keep the checklist open during the real review, not only as prep;
  • mark stop-the-line issues separately from “improve later” issues;
  • add the specific evidence reviewed: PR, YAML, logs, dashboard, ticket, or diagram;
  • write one-paragraph conclusions after the checklist, not just checkboxes.

Three ways to avoid checklist theater

  1. Ask at least one abuse question, not only a hardening question.
  2. Ask at least one evidence question, not only a design question.
  3. Ask at least one ownership question, not only a control question.

A simple decision legend

Marking Meaning
Yes The reviewer saw evidence that the control exists and is being used correctly
No The control is absent or clearly weak
Partial The control exists, but only for part of the system or only in some environments
Unknown The reviewer needs more evidence before deciding

---Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.