Let's talk about threat modeling. If that phrase makes you picture whiteboards and diagrams and never-ending meetings, I get it. But here is the actual truth. Most developers do threat modeling all the time. We just don't call it that. Today, I want to show you how to do it on purpose in about 15 minutes. Hi, I'm Tanya Jenka, also known as SheHexPurple. Welcome to DevSecStation, a podcast for software developers who want to build more secure software. In each episode, I'll share a short practical lesson about secure coding, software security, and how to build safer systems without slowing development down. You can jump in at any episode, at any time. No homework required. This episode is sponsored by MAES. One of the biggest problems in security right now is that every vulnerability or cloud scanner says everything is critical, and honestly, no one has time for that. MAZES uses AI agents to investigate vulnerabilities in context, so you can focus on the issues that are actually exploitable in your environment and not just theoretically scary. Their AI agents also generate and prioritize fixes that knock out multiple vulnerabilities at once, which is honestly the kind of scaling that security teams really need right now. Learn more about maze at mazehq.com slash devsec. If you're building a new feature, adding an endpoint, integrating a service, or changing how data flows through your system, this episode is for you. So for your information, you do not need security approval, special tooling, or a diagram app or tool to do this. You can just start now. Threat modeling sounds complicated because we wrapped it in process, but at its core, it's actually very simple. Threat modeling is just intentionally thinking about what you're building, what you're protecting, and how it could be misused. That's it, seriously. The goal is not to predict every single possible attack, it's to notice obvious problems before they turn into security incidents and then fix them. Developers do this informally, literally, all the time. You add a new endpoint and you think, hmm, should this be authenticated? I should add authentication. You store something new in the database and you think, is this sensitive? You integrate a service and you think, oh, what's gonna happen if this goes down? If this goes down, then what? What should I do? That's literally you threat modeling. The difference is that when we do it casually, it's very easy to miss things. But when we do it intentionally, usually we catch all the important stuff. So how about we try it? I'm gonna give you a simple way to threat model one feature without a diagram. Okay, are you ready? Step one, define the thing. Write down on a piece of paper or type it out what you're building in just one sentence. So for example, I'm building an endpoint that lets users update their profile. If you cannot describe a feature simply, that's already a signal that you probably have a problem here. Okay. Step two, let's identify what you are protecting. Ask yourself, what data is involved? Is it sensitive? Who should be allowed to do this action? Would it be bad if something went wrong and what would that be? Step three, identify entry points and trust boundaries. Ask yourself, where does this data come from? Where does it cross from untrusted into trusted? Where do we rely on authentication and authorization? I have a tip for you. These are the same places you look at during a secure code review. Remember that from the last episode? Okay, step four. Ask three misuse questions. You don't need a long list, just ask a few things such as, what if someone who shouldn't do this tries to do it anyway? What if this input is malicious or otherwise unexpected? What happens if this fails in a really weird way? If you can answer those questions, you're doing threat modeling. Step five, decide what needs a control. So for anything that you feel uncomfortable about, you need to decide, do we already have a control to protect against this? And if not, does one need to be added? This is where threat modeling turns from just a discussion into action. We don't just want to identify threats, we want to defend against the ones that actually scare us. Shall we do our bad better best thing now? I think we should. A bad approach for threat modeling is assuming security testing will just catch everything later. It pushes risk downstream, where fixes are more expensive, and it might get missed. A slightly better approach is thinking about threats casually while building. This helps, but it's inconsistent, and it depends largely on memory, which, as we know, is not a reliable way to do things. The best approach is threat modeling each new app or feature on purpose. One feature can be 15 minutes, a single page of notes, done. When you do this regularly, secure design becomes a habit. If you do just one thing after this episode, please do this. Threat model one feature that you are currently working on. Use the five steps that we just covered. Write it down somewhere that your team can see it. So you could put it in a PR description, a ticket, or a simple markdown file, whatever it is that makes sense to you, but so it won't disappear. You don't need to solve everything. Just identify one place where a control is missing or unclear and then fix it. That's a huge win. Threat modeling is not security theater. It really can create true value. It's a way to ensure fewer surprises happen to you later. When developers do it themselves, security stops becoming a blocker for you. And instead, security starts to be part of what you think of as good design. Thanks for listening to DevSecStation. If you enjoyed this episode, please subscribe, share it with a friend, or leave a review. It helps more people discover the show. If you'd like to learn more, I'm Tanya Jenka, also known as SheHacksPurple. And I teach secure coding training for software developers. You can find me online at shehackspurple.ca. Thank you for being here.