Threat Modeling Intensive with Complete AI: From a Developer's POV
Kris Yun, Software Engineer @ Shostack + Associates
Reflections from a Developer
Black Hat this year was very busy, and most of that was because I had my third opportunity to assist with a Shostack + Associates training at Black Hat. Developers come to the threat modeling table from a different place than security experts do and I think the training is incredibly worthwhile for people who actually build the code.
The Threat Modeling Intensive with Complete AI felt uniquely special because this was the first time we delivered a four-day course at Black Hat. Previously, we've delivered two-day Threat Modeling Intensives, but with evolving innovations in AI and LLM use cases, we wanted to answer questions from people curious about how, when, and why to use AI in threat modeling workflows. Our answer to those questions was Threat Modeling Intensive with Complete AI, a four-day experience where students learn the fundamentals of threat modeling and then level up their skills with AI in the equation.
The first time I took the Threat Modeling Intensive, the first question in The Four Question framework felt familiar: "What are we working on?" As developers in agile environments, we often collaborate closely with product and research teams, continuously translating business requirements into technical implementations. When answering the question, “What are we working on,” students draw data flow diagrams, with varying levels of technical depth. As a developer, this whiteboarding felt familiar; three to five engineers huddled around a diagram, pointing, drawing, and discussing components.
However, the next questions can feel unfamiliar for some developers. After pinpointing the product, we then ask the question, "What can go wrong?" I'll admit: this question wasn’t that confounding, as I've been in the security world for a little bit. But this question introduces students to brainstorming STRIDE threats and kill chains to identify potential threats. And if you’re a developer who already wrote down SQL injection and XSS attacks and feels stumped, you now have a chance to see the security experts show off their skills.
I feel similarly about the next question: "What are we going to do about it?" Here, students discuss potential mitigation strategies, ranging from addressing, accepting, transferring, or ignoring the risk. I love listening to discussions about the third question, because we see how different parts of an organization fit together. While the security engineers may have identified a threat and a mitigation strategy, a software manager may add this finding to the backlog because of a busy deployment cycle. We dive into and unpack the hard conversations about how to execute the suggested change, and I love hearing the different strategies participants ideate upon.
By the end of The Four Question Framework, students are asking the question, "Did we do a good job?" And I wish all software managers cared this much about retrospectives as the fourth question asks. Here, students reflect upon the outcomes from the previous three questions and suggest improvements for future iterations. As developers, we often hold retrospectives at the end of each sprint, but these can feel like a chore after a rushed timeline and tired devs. So, I love hearing former participants share stories about how they've baked retrospectives into their weekly workflows and wonder how software can do something similar.
This is to say: The Four Question Framework is highly applicable to security and beyond. Even if one doesn't have a security background, I encourage all engineers to register for an Intensive to understand how they can integrate security into their existing processes.
If these ideas stick with you, consider registering for the Threat Modeling Intensive Using AI at OWASP Global AppSec USA from November 2 - 4, 2026. This course will pair the topics from the Threat Modeling Intensive with hands-on experience in using LLMs for threat modeling. Register here! I'll be back soon with a post explaining some of my favorite parts about integrating LLMs into the Intensive, but I'll give you my most surprising one now: in our trainings, I've met students who've never used an LLM at work and people who use it daily. Surprisingly, EVERYONE is at least a little confused about LLMs. The shape of that confusion may be different (from "how do I start" to "I know how to use an LLM, but not how or when to use it in threat modeling") but it's pretty universal. So if you're on the fence because you feel like you don't know enough, that's all the more reason to sign up for this training. Every training opens with a notice welcoming diversity of thought, and I felt this was especially pertinent for a class where almost every attendee is unsure if they're using LLMs "correctly." The Intensive is a great space to experiment, evaluate, and iterate with professionals from a spectrum of backgrounds.
Image by midjourney: "Infographic illustration divided into four equal quadrants, featuring a friendly robot demonstrating threat modeling steps. Impressionist colorism, watercolor style, clean lines, indigo purple, lime green, bright orange, and red orange palette. Top Left (1. What are we working on?): Robot happily examines a glowing blueprint/system architecture diagram, holding a pencil, wearing a tiny yellow hardhat. Top Right (2. What can go wrong?): Robot looks curious and alert, using a magnifying glass to inspect a cartoonish bug or small red warning icon on a digital screen. Bottom Left (3. What are we going to do about it?): Robot smiles confidently, holding a shield or placing a puzzle piece into a wall to block a gap. Bottom Right (4. Did we do a good job?): Robot proudly holds a checklist with green checkmarks and gives a thumbs up, representing validation and review."."