Why is a release security checklist a floor for threat modeling rather than a replacement?
answer
- It records other people's findings
- Answerable without seeing your design
- Known misses, never novel ones
- Ticked box is not an assurance
- Floor plus a trigger for modeling
basics
~20 sA checklist encodes threats already found on other systems, so it catches known misses cheaply and uniformly. It cannot see what is specific to your design: your business logic, your boundaries, your attacker. Put it beneath a model, not in place of one.
solid answer
~50 sA checklist is a record of other people's findings. Its items are written so someone who has never seen your design can answer them yes or no, which is what makes it cheap, repeatable and auditable - and what makes it blind to your system. Take the charity donation page rebuilt by two volunteers before a telethon. The checklist gets you transport encryption, a rate limit, updated dependencies, no committed secrets. It never asks who can change the payout account the donations settle into, or whether a refund path can move money outward, because those questions exist only once you look at this money flow. So I run the checklist as a floor that must always be met, and a model on top for anything touching money, personal data or a new trust boundary. They feed each other: a threat seen in three models becomes a new checklist line.
go deeper
Be ready to say plainly what a checklist can and cannot do: it catches known, repeatable misses, and it never asks what is unique about this design. Do not call a ticked list a threat model.
Explain the mechanics behind the limit - items are written to be answerable yes or no without seeing the architecture, while a model reasons from the actual flows and boundaries in front of you.
Demonstrate the feedback loop: threats found in models and incidents become new checklist lines so the floor rises, and stale lines get removed before the list becomes unreadable.
Be able to defend a checklist-only bar for low-risk changes and to name the trigger that forces a real model, so the programme scales without turning every commit into a session.
## Two different instruments A **checklist** answers "did we do the things that are known to matter?" A **threat model** answers "what could go wrong in *this* design?" They are not competing depths of the same activity; they run in opposite directions. A checklist starts from a corpus of past findings and projects them onto your system. A model starts from your system and reasons outward to what an attacker could do to it. That difference explains every property of each. Checklist items are written to be answerable by someone who has not read your architecture - that is what makes them cheap, uniform across teams, delegable and auditable. It is also precisely why they cannot see anything that is specific to you. ## What a checklist is genuinely good at - **Floor enforcement.** It stops the same known misses recurring across dozens of teams without a security engineer in every room. - **Cost.** Minutes, no session, no facilitator, no diagram. - **Consistency.** Two teams that tick the same list have met the same bar, which is a real property when you have more teams than reviewers. - **Memory.** It is how an organisation stops relearning a lesson. A recurring threat becomes a line, and the line survives staff turnover. None of that is small. Dismissing checklists as useless is as wrong as calling one a threat model. ## What it structurally cannot do - **Business logic and abuse of intended features.** Nothing on a generic list asks whether a discount can be stacked, whether a refund can exceed the payment, or whether a support tool can be pointed at an account it should not reach. Those threats live in the meaning of your workflow. - **Trust boundaries you invented.** Your list does not know that a background worker reads a queue that an unauthenticated endpoint writes to. - **Your attacker.** A checklist has no notion of who wants to attack you or why. An adversary motivated by disruption or reputation rather than money produces a completely different threat set, and no box on the list prompts for it. - **Composition.** Two individually acceptable components can be dangerous together. Items are evaluated one at a time. - **Absence as evidence.** A ticked list tells you the listed misses are absent. It says nothing whatsoever about anything not on the list - and the whole point of modeling is to find what is not on anyone's list yet. ## The worked case The donation page rebuilt by two volunteers, live in six days, taking money from anonymous internet donors. Checklist output: TLS enforced, form rate-limited, dependencies current, no secrets committed, admin login has a second factor. All genuinely worth having, all cheap. Now the questions the list did not ask. Who can change the bank account the donations settle into, and would anyone notice for a week? Can the same admin who takes donations issue refunds, and is there any record separating the two? If the page goes down for the two hours of the telethon, has the charity lost the campaign - is availability the real asset here rather than confidentiality? Every one of those is design-specific and none of them is exotic. A twenty-minute conversation over the money flow surfaces them; no checklist ever will. ## Using them together The practical arrangement is a floor plus a trigger. - The checklist is **mandatory and unconditional** - every change meets it. - A **model is triggered** by properties of the change: money or personal data entering a path that did not carry it, a new trust boundary, a new externally reachable surface, a new third party in the flow. - **Findings flow downward.** A threat found by a model or an incident, seen a third time, becomes a checklist line so the floor rises. A checklist that never changes is a fossil; one fed by real findings is an organisation's memory. The failure mode to name in an interview is the ticked box read as an assurance: "the checklist passed, so the design is safe." It passed means the known misses are absent. Everything else is still unknown, and saying so plainly is the answer the question is looking for.
- When is a checklist alone the right answer for a change?When the change adds no new trust boundary, no new externally reachable surface, no new data class and no new third party - a copy of a pattern the team has already modeled. Small internal changes of that shape do not earn a session, and insisting on one for every commit is how a modeling programme gets abandoned.
- How do you keep a checklist from rotting into a compliance ritual?Feed it from real findings. Threats that recur across models, and anything that caused an incident, become new lines; lines that never fail anything or that no longer match how the platform is built get removed. Keeping it short matters - a hundred-item list gets ticked without being read, which is worse than a ten-item list that gets thought about.
A checklist is the smoke alarm you fit in every room by regulation. A threat model is asking where this particular building would actually burn, and noticing that the only fire exit is through the kitchen.
saying these in an interview costs you the question
- Calls a signed release checklist a threat model
- Says checklists are useless because they miss things
- Treats a fully ticked list as proof the design is safe
- Never feeds new findings back into the list
- Applies one list to every system regardless of design