a threat model
Before you can decide whether a lock is good enough, you have to ask: good enough against WHOM? A bicycle cable stops a casual thief but not someone with bolt cutters; planning for one is silly if you face the other. A threat model is the security version of that question made explicit: a clear statement of what you are protecting, who the attacker is and what they can do, and therefore which attacks are in scope and which are deliberately out of scope.
Concretely, building a threat model means writing down four things. First, the ASSETS — what is worth protecting (user passwords, private keys, the integrity of an update). Second, the ATTACKER's capabilities and goals — can they send network packets, run unprivileged code on the machine, observe timing, control a co-located VM, or hold physical access? Third, the TRUST BOUNDARIES — the lines across which data goes from trusted to untrusted, such as the boundary between your process and network input, between user space and the kernel, or between a sandbox and its host; every input crossing such a boundary must be validated. Fourth, the resulting in-scope threats and the defenses for each. A worked example: for a web server, the network is untrusted, so the trust boundary is at the socket; all incoming bytes are hostile until parsed and validated; an attacker who can send requests but not run local code is in scope, while an attacker with physical access to the server room may be explicitly out of scope.
It matters because security claims are meaningless without it — 'is this secure?' has no answer until 'against what?' is fixed. The honest framing: a threat model is a set of assumptions, and its biggest danger is an unstated or wrong one (assuming the local user is trusted when they are not, or that a boundary is enforced when it is not). It pairs with DEFENSE IN DEPTH — layering independent defenses (least privilege, sandboxing, canaries, ASLR) so that breaching one does not breach all — precisely because any single assumption in the model might fail. A threat model is a living document, revisited as the system and its attackers change.
// a tiny threat model for a web service: assets: session tokens, user data attacker: can send arbitrary HTTP, cannot run local code (in scope) has physical server access (OUT of scope) trust boundary: the socket -> validate every byte that crosses it defenses: input validation, least privilege, ASLR + DEP (defense in depth)
Naming assets, attacker, and trust boundaries turns 'is it secure?' into a question that can actually be answered.
A threat model is only as good as its assumptions; the silent or wrong assumption (trusting an input or boundary that is not actually trustworthy) is where most failures hide — pair it with defense in depth so no single assumption is load-bearing.