Threat modeling has a reputation for being heavyweight and complex — something that requires formal diagrams, dedicated workshops, and specialized expertise. But what if the most valuable version of it takes just two minutes and four simple questions?
We spoke with Adam Shostack, a leading expert on threat modeling, author of Threat Modeling: Designing for Security and Threats: What Every Engineer Should Learn from Star Wars, and a consultant who spent nearly a decade at Microsoft shaping their security development lifecycle. Adam breaks down how organizations can make secure by design practical, lightweight, and embedded in everyday development work.
You can read the complete transcript of the episode here >
What does secure by design actually mean?
Adam uses a physical-world analogy: if you want a secure building, you think about fences and bollards before construction begins — not after. Software is no different. Once APIs, file formats, and log structures exist, other teams take dependencies on them, making changes expensive.
Secure by design means integrating security decisions at the same time you make architectural decisions. A concrete example: if a team builds with prepared statements from day one, SQL injection disappears as a vulnerability class. If they start with dynamic SQL queries, they eventually face a costly rewrite — and junior developers learn the wrong pattern along the way.
The distinction between “secure by design” and “secure by default” matters too. An application might support MFA (secure by design), but if it is buried three layers deep in settings rather than turned on during account creation, most users will never enable it. Defaults shape behavior.
What is threat modeling and how do you keep it lightweight?
At its core, threat modeling answers four questions:
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good job?
That is it. Adam emphasizes that simply pausing to ask “what can go wrong?” — even for two minutes — delivers enormous security value. You do not need formal diagrams or week-long workshops to get started.
He shares a personal example: while writing a script to create a Spotify playlist, he paused to consider that he was piping URLs from Spotify directly into his browser. Could Spotify (or an attacker who compromised Spotify) run arbitrary code on his machine? A few seconds of thought led to basic input validation — checking for HTTPS, the correct domain, and the absence of semicolons that could enable command injection.
How should threat modeling fit into agile development?
Adam’s strongest recommendation: do not treat threat modeling as a review gate. Instead, embed it in backlog grooming and sprint planning.
The reasoning is practical:
- If you wait for a code review to raise security concerns, someone has already written the code. Now you are arguing about rework.
- Two minutes of “what can go wrong?” during story writing prevents a day of coding followed by a rewrite.
- Story point estimates become more accurate when security considerations are factored in upfront rather than discovered later.
The cost of deferring is non-linear. A one-story-point feature that ships with a security flaw can balloon to ten story points once other teams take dependencies on the API, requiring coordinated changes, monitoring code, and potentially incident response.
How do you scope threat modeling without boiling the ocean?
Adam references a principle from Izar Tarandach: “threat model every story.” The key is the first question — what are we working on right now?
- A front-end team should focus on front-end threats, not the database.
- A database team should focus on database threats, not the UI.
- If you are doing a technical debt sprint or adding major new components, then zoom out to the whole architecture.
This alignment keeps threat modeling focused, productive, and proportional to the work being done in each sprint.
What role does communication play in security programs?
Adam is direct: security professionals are often cynical, critical, and snarky. Nobody responds well to “your code sucks.” Effective communication is essential for security programs to succeed.
His advice:
- Listen and engage. If you are helpful, developers come back. If you are mean or unavailable, they stop asking.
- Use real-world examples. Stories in the news — ransomware hitting the British Library, United Health disruptions affecting prescriptions — make abstract threats concrete and relatable.
- Show empathy. When a colleague is struggling because of a real-world security incident, use that moment to gently connect it to your organization’s own risks rather than lecturing.
- Communication goes both ways. Engineering teams need to be receptive to security feedback, and security teams need to stop being the “Department of No.”
What is STRIDE and how does it organize threat thinking?
STRIDE is a mnemonic that helps teams systematically answer “what can go wrong?” It stands for:
- Spoofing — Can someone pretend to be someone else?
- Tampering — Can someone modify data or code?
- Repudiation — Can someone deny having performed an action?
- Information Disclosure — Can sensitive data leak?
- Denial of Service — Can the system be made unavailable?
- Elevation of Privilege — Can someone gain unauthorized access?
Adam uses Star Wars to teach these concepts accessibly. R2-D2 refusing to play a message for anyone except Ben Kenobi raises questions about authentication and identity management. The Death Star’s thermal exhaust port — an obvious design flaw exploitable in seconds — illustrates what happens when secure software development principles are ignored.
You do not need STRIDE to threat model. Simply asking “what can go wrong?” in an open-ended way works. But STRIDE provides structure that helps teams be more systematic and thorough.
What is cyber public health and why does it matter?
Adam is working with the nonprofit CyberGreen on a concept called cyber public health. The idea: just as public health tracks measles incidence to inform policy, cybersecurity needs population-level statistics about attacks.
Today, we lack answers to basic questions: What is the incidence of ransomware? Do Yahoo accounts get taken over more frequently than Gmail accounts? Without this data, threat modeling relies on intuition rather than evidence.
The goal is to build infrastructure that provides real-world attack frequency data, enabling organizations to make better-informed decisions about where to invest their security efforts.
