No, We Won't Be Threat Modeling

The talk addresses what security practitioners can do when developers, teams or whole organizations say no to threat modeling, whether because they see no value, lack resources or are simply not interested. The speaker lays out the common objections: the process takes too long, feels too conceptual, should be left to specialists, or seems redundant next to scanners and penetration tests. He argues that threat modeling belongs with the people writing code, since they make security decisions continuously during development.

The middle section covers how threat models fail, both when they are never done and after they are produced. Failure modes include relying on a single hero modeler, treating a system's snapshot as a perfect representation, chasing fashionable attacks while missing common ones, and producing documents only to tick a governance box. For getting buy-in, the speaker suggests meeting teams where they already work, such as inside existing design review templates, asking a simple open question rather than handing over checklists, and framing the work as an evolving practice where an imperfect first model still helps. He also recommends offering concrete mitigations packaged with abuse cases that can be turned into tests.

The closing advice is to let each team shape its own methodology, to treat tool output as a starting point rather than a finished report because of false positives, and to measure value by comparing findings before and after design changes. Priorities should rest on exposure and business factors rather than precise risk numbers. Success looks like developers asking questions unprompted, requesting examples, and maintaining a shared repository of models that stays current.