# 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](/learning-labs-interview-and-templates/index-3/pre-release-security-checklist.md)                   | Right before deployment or feature launch          | Are we about to ship avoidable risk?                                                         |
| [API Review Checklist](/learning-labs-interview-and-templates/index-3/api-review-checklist.md)                                       | During design or before exposing new routes        | Does the API enforce object, function, and consumption controls?                             |
| [Cloud Change Review Checklist](/learning-labs-interview-and-templates/index-3/cloud-change-review-checklist.md)                     | Before IAM, network, storage, or platform changes  | Does the infrastructure change expand authority or blast radius?                             |
| [Production Readiness Security Checklist](/learning-labs-interview-and-templates/index-3/production-readiness-security-checklist.md) | Before declaring a service “ready”                 | Can the service be safely operated, observed, and recovered?                                 |
| [Secret Handling Checklist](/learning-labs-interview-and-templates/index-3/secret-handling-checklist.md)                             | During CI/CD and service review                    | Are secrets stored, injected, rotated, and observed safely?                                  |
| [IAM Review Checklist](/learning-labs-interview-and-templates/index-3/iam-review-checklist.md)                                       | During platform, pipeline, and cloud trust reviews | Which identity can do what, from where, and for how long?                                    |
| [Dockerfile Review Checklist](/learning-labs-interview-and-templates/index-3/dockerfile-review-checklist.md)                         | During image and service build review              | Does the image reduce avoidable package, user, and provenance risk?                          |
| [Kubernetes Deployment Review Checklist](/learning-labs-interview-and-templates/index-3/kubernetes-deployment-review-checklist.md)   | 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                                 |

## Related pages

* [From Zero to Useful](/learning-labs-interview-and-templates/index-3/from-zero-to-useful-how-to-start.md)
* [Break-Fix Labs and Tabletop Scenarios](/learning-labs-interview-and-templates/index-2/break-fix-labs-and-tabletop-scenarios.md)
* [Glossary++](/appendices-assets-and-reusable-artifacts/reading-paths/glossary.md)

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/learning-labs-interview-and-templates/index-3/security-review-checklists-and-cheat-sheets.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.