Security checklist
A practical, phase-by-phase checklist distilling the rest of this course into things you can verify are actually true of your systems, your pipeline, and your team — not just topics you've read about. This is a plain HTML checklist: checking a box is a visual aid for your own tracking while you work through it, nothing is saved to a server or persisted across visits, so re-checking items on your next visit is expected, not a bug.
☺ Explain it like I'm 10
Think of this like the checklist a pilot runs through before takeoff. No single item on it is surprising by itself — flaps set, fuel checked, doors closed — the value comes from running through every item, in order, every single time, instead of trusting memory on a day when something's different.
① Design & Threat Modeling readiness
Threat models exist for every system handling sensitive data or sitting on a trust boundary, and have been reviewed within the last two quarters Abuse cases and misuse scenarios are written into requirements alongside functional acceptance criteria, not tracked in a separate document Every identified threat has been categorized (STRIDE or equivalent) and carries either a documented mitigation or an explicit accepted-risk sign-off Trust boundaries and data classification (PII, PCI, secrets) are marked on the current architecture diagram, not just implied Third-party integrations and external APIs are included in the threat model, not just internally owned services A security stakeholder reviews the design before implementation starts, not after the code is already written Threat-modeling output turns into backlog tickets with owners, not into a document nobody opens again ② Pipeline Security readiness
A secrets manager (Vault, AWS Secrets Manager, or equivalent) is the only source of credentials — a repo-history scan turns up zero hardcoded secrets Pre-commit secret scanning (gitleaks, trufflehog, or equivalent) blocks commits containing high-entropy strings or known key patterns SAST runs on every pull request and fails the build on new high- or critical-severity findings SCA tracks every direct and transitive dependency against a current vulnerability feed, not just top-level packages DAST runs against a staging deployment before every production release Commits to protected branches require GPG or SSH signatures Branch protection is enforced: required reviews, required status checks, no force-push and no direct pushes to main Dependency update PRs (Dependabot, Renovate, or equivalent) are triaged at least weekly instead of left to accumulate CI jobs run with least-privilege, per-job scoped service tokens instead of one broad pipeline credential ③ Cloud & Infrastructure Security readiness
Every Terraform or CloudFormation change is scanned (Checkov, tfsec, or equivalent) before it's allowed to apply Policy-as-code guardrails (OPA/Conftest, Sentinel, or equivalent) block non-compliant infrastructure at merge time, not after it's already live IAM roles and policies are audited quarterly for least privilege, with unused permissions actually removed, not just flagged No IAM user in a production account holds long-lived static access keys Object storage (S3, GCS, Blob) is audited for public access, with default-deny as the baseline configuration Network segmentation (VPCs, security groups, subnets) has been checked against the current threat model, not last year's Compliance evidence (SOC 2, ISO 27001 control mappings) is collected continuously through automated capture, not assembled by hand right before an audit Encryption at rest and in transit is verified for every data store holding sensitive or regulated data ④ Response & Culture readiness
Incident response runbooks exist for the top threat scenarios from the threat model and are reachable during an actual outage, not buried in a wiki no one can find at 2am IR runbooks have been exercised in a tabletop simulation within the last six months A security champion is assigned on every team, with real time allocated for the role rather than an unpaid extra duty Security champions have a standing forum (monthly sync, shared channel) to surface findings across teams Security awareness training is scheduled on a recurring cadence for all engineers, not only for the security team Audit logs and forensic data are retained long enough to support a post-incident investigation, with integrity protected against tampering Every post-incident review produces action items that are tracked to closure, not just written up and archived