Every developer eventually receives The Checklist. A client or manager forwards a PDF titled something like "essential security practices", assembled by someone selling a course, and asks: are we doing all this? Most of these checklists are not wrong. They are just unfalsifiable. "Validate all inputs" is advice nobody can disagree with and nobody can verify.
It happened to me on a client project: a security checklist written for beginners, complete with generic dangers and one-size-fits-all fixes. The lazy answer was "yes, we're covered". The useful answer, which became a document in the repo, was to take every single item and map it to the real code: file paths, mechanisms, and honest status marks.
The transformation is bigger than it sounds. "Protect against brute force" is a wish. "Login attempts are rate limited per account and per IP, with lockout thresholds, in this middleware file" is a fact someone can check, test, and break. The checklist asks the question; the mapping is the actual security work.
Some of the mappings turned out to be the most interesting engineering in the project. Take logout. The naive JWT story is that you cannot revoke a token, you just wait for expiry. The project's answer: every token carries a unique identifier, and logout adds that identifier to a blacklist checked on each request. Stolen tokens die when the session does, not when the clock says so.
Two-factor authentication had a subtler detail: the 2FA challenge token is single use. Once a code is verified, the challenge cannot be replayed, which closes a window most tutorial implementations leave open. Password rules differ per role, because an admin account and a customer account do not carry the same blast radius. Redirect targets after login are whitelisted, killing open-redirect phishing. And the contact and signup forms include honeypot fields: invisible inputs that humans never fill but naive bots always do, which quietly filters automated abuse with zero user friction.
None of these came from the checklist. The checklist said "secure your authentication". The mapping process forced the better question: what does secure mean here, in this file, for this threat?
My favorite section of the mapping document is the one most security theater omits: known advisories, accepted. Running a dependency audit on the project flags a couple of moderate findings in transitive dependencies. The document lists them, explains why they are not exploitable in this context, and notes that the "fix" would be a breaking downgrade that introduces more risk than it removes. That paragraph is more trustworthy than a green badge, because a clean audit output usually means someone ran an update command until warnings went away, understanding none of them.
Security is not the checklist and it is not even the code. It is the explicit, written relationship between the two. When the relationship is documented, new engineers can verify claims instead of inheriting folklore, auditors get file paths instead of assurances, and future me can tell whether a change breaks a guarantee some past me made.
So next time The Checklist lands in your inbox, resist both failure modes: do not dismiss it as beginner content, and do not nod it into a drawer. Fork it into your repo and annotate every line with what your code actually does, where, and why. The gaps you find are real work worth doing. The items you can point to are proof. And the ones you consciously decide not to fix, written down with reasons, are the mark of a team that actually understands its own security instead of performing it.