Threat Modeling at Scale: More than shifting left

The session opens with a short primer on threat modeling, organized around four questions: what is being built, what could go wrong, what should be done about it, and whether the result holds up. The speaker, who leads a threat analysis team, describes the usual obstacles in a large company: developers focused on delivering features, tight release schedules, limited security expertise on project teams, and tooling that rarely supports threat modeling directly.

The core of the talk is how to run threat modeling across many projects without it becoming a bottleneck. Suggested steps include engaging once a design is reasonably settled but before build work begins, and choosing tools that allow asynchronous collaboration, so architects can edit diagrams, leave notes and review changes outside scheduled meetings. Reports should be tailored to each audience, from executive summaries to detailed engineering findings. The process itself should be defined in advance: what warrants a model, how requests arrive, when checkpoints happen, how disagreements escalate, and who owns remediation after delivery. Lightweight consultation summaries can handle one-off questions, and major architectural changes are the trigger for a full model. Findings can be compared against code scanning and penetration test results to spot gaps, and pentest scope can be narrowed to match.

The speaker argues that early threat modeling saves money because fixes are cheaper before production, and that repeated collaboration builds trust between security and development teams. Practical takeaways are to front-load documentation and diagrams, hold retrospectives to find recurring blockers, and present threat modeling as a checkpoint teams can move through rather than a gate. Audience questions covered developer pushback, how to decide when a model is required, and how release gating is enforced.