Threat modeling is often treated as a one-time checkpoint in the development lifecycle — a security review that happens after the design is mostly done. That approach causes friction with engineering teams and misses the point entirely. Brook Schoenfield, CTO at Resilient Software Security, has built and led multiple AppSec programs over 20+ years, co-authored six books on software security, and contributed to the Threat Modeling Manifesto. In this episode, he breaks down why threat modeling should be woven into every phase of software delivery, how startups with zero security budget can still do it well, and where tools like ChatGPT actually help versus where they fall short.
You can read the complete transcript of the episode here >
How soon should threat modeling be introduced into the SDLC?
From the very start. Brook argues that threat modeling is not a discrete activity you schedule — it is fundamental to thinking about security at every level of software development.
- It mirrors how humans already think: If you drive a car or walk in an unfamiliar city late at night, you already have a threat model. The same instinct applies to building software — what could go wrong, and how do we protect against it.
- It operates at multiple levels of specificity: At the idea stage, it means asking “how might people misuse this?” At the code level, it means deciding between a single auth token vs. a token-plus-refresh approach based on threat exposure.
- It should be treated like any other design consideration: Performance, scalability, usability — security belongs in the same mental checklist. When organizations treat it that way, the special-engagement model (where a security person drops in late and creates friction) disappears.
The worst pattern Brook has observed: a security person arrives after design is mostly complete, writes up requirements nobody knew about, drops them on the team, and walks away. That approach creates friction on both sides and kills adoption of secure development practices.
What are the biggest stumbling blocks in threat modeling?
Even when teams embrace the idea of continuous threat modeling, three challenges consistently trip them up:
- Limited attack knowledge: People tend to think only about threats related to the functionality and data they are working with. They miss entire categories — like attackers who want computing power for crypto mining or botnets, regardless of what the software does.
- Risk rating confusion: Vulnerabilities are commonly called “risks,” but they are not. A vulnerability is a weakness that contributes to a potential risk. Proper risk rating requires understanding likelihood, impact, and context — a skill that takes deliberate effort to build.
- Defense-in-depth complexity: Many defenses have many-to-many relationships with attacks. Building layered defenses that collectively close off the attack surface requires understanding how monitoring, access controls, and architectural choices work together.
The good news: developers get better over time. With initial guidance from specialists, they learn which threats are relevant to their specific tech stack and architecture. Eventually, they no longer need the specialist at all — which is what developer-centric security aims to achieve.
Where can teams go to build threat modeling expertise?
Brook recommends several resources depending on skill level:
- STRIDE framework: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. A useful gateway for those uninitiated, though too general for mature programs. Even Microsoft has moved beyond it.
- Elevation of Privilege card deck: Created by Adam Shostack, free to download. Running through the cards prompts teams to consider attack categories they would otherwise miss.
- MITRE ATT&CK: Documents real-world attack techniques and links them to defenses through an ontology. Useful for understanding what has actually been used in the wild.
- Threat modeling tools with community editions: Several commercial tools offer free versions with built-in catalogs of threats and defenses — a practical starting point for resource-constrained teams.
- Microsoft Threat Modeling Tool: Free (not open source), available for nearly a decade. More suited to endpoint applications than cloud-native SaaS, but still helpful for getting started.
The key insight: you do not need an expert to start threat modeling. But your threat models will be significantly better with some specialized knowledge or structured resources guiding the process.
Should threat modeling be a one-time activity or continuous?
Continuous — but not in the way most people think. Brook frames it as building and refining a single model rather than repeating a process.
- As you move from idea to design to implementation, the model gets more specific for each feature or story.
- Someone working on a new product idea threat-models at a high level while someone writing a specific feature threat-models at a granular level — but both are contributing to the same model.
- In continuous delivery environments, software changes constantly. A point-in-time assessment made sense in waterfall; it is structurally insufficient for agile and DevOps.
The practical implication: security teams and engineering teams need to collaborate from the start. When engineers begin working on something new, they call their security person. Security people proactively ask what is coming down the pipeline. That simple communication pattern is the only way Brook has ever seen the “late security requirements” problem get solved in practice, a principle that applies equally to DevSecOps workflows.
What should resource-constrained startups focus on first?
For teams without a dedicated security engineer or budget, Brook recommends a practical ramp:
- Get security testing tooling running immediately. Open source tools like Semgrep are free and integrate into Git workflows via GitHub Actions. Even if they are noisy, they surface weaknesses in the code that would otherwise go unnoticed.
- Threat model to the best of your ability. Adam Shostack’s four questions cover it: What are we building? What can go wrong? What are we going to do about it? Have we done enough?
- Use freemium models. Tools like Snyk offer basic scanning at no cost. Start there and upgrade as revenue grows.
- Consider a part-time security consultant. As budget allows, bring in an experienced architect for periodic guidance rather than trying to justify a full-time hire.
The cost of skipping this: if you do not threat model during design, you build weaknesses that require expensive rework later. The barrier to entry for basic application security has never been lower — there is no longer a valid excuse for doing nothing.
Can ChatGPT solve application security problems?
No — but it can be a useful starting tool with clear limitations.
- Where it helps: If you know nothing about a security topic, ChatGPT provides a reasonable starting summary (comparable to an introductory chapter of any book). It saves time by aggregating information from multiple sources. AI-assisted search helps practitioners skip the manual URL-by-URL trawl.
- Where it fails: It hallucinates confidently. Brook asked ChatGPT to summarize specific chapters from his own book — the responses contained generic security information unrelated to the actual content. When asked about himself, it described him as a “woman fantasy writer” who does not exist.
- For AI-assisted coding: Experienced developers get significant productivity gains by iterating with code assistants — spotting mistakes, requesting fixes, and converging on working code quickly. But the AI does not distinguish between secure and insecure patterns in its training data. Without expertise to validate output, you inherit other people’s vulnerabilities.
The bottom line: ChatGPT is a tool, not a replacement for expertise. It helps beginners orient themselves and helps experienced practitioners save time. It does not do AppSec for you. For a deeper look at how generative AI intersects with security workflows, see building security using GenAI.
How does Brook rate common security practices?
Three rapid-fire ratings from the episode:
- Train employees during onboarding only (no continuous training): Rated -1 (off the scale). A Carnegie Mellon study found 67% of people will click a phishing link if the topic interests them. Without regular reinforcement, security awareness degrades rapidly. Acceptable use, phishing awareness, and data handling all need repeated reminders.
- Conducting periodic security audits: Rated 3. Essential but insufficient on its own. An audit is one piece of the testing regime. Between audits, software updates introduce new vulnerabilities. No single technique is sufficient — audits must be complemented by continuous automated scanning.
- Using a password manager with unique passwords: Rated 5. Non-negotiable. Every piece of software will eventually have a vulnerability (including password managers), but that is not a reason to avoid them. The alternative — reusing passwords — is far more dangerous than the theoretical risk of a password manager breach.
