Software Engineering Institute (SEI) Podcast Series · Members of Technical Staff at the Software Engineering Institute

Threat Modeling: Protecting Our Nation's Complex Software-Intensive Systems

·35 min·2 clips

A threat combines four elements: an actor (who), the effect (what goes wrong), the objective (why), and the attack (how).

Tim Chick opens the episode as a conversation about building software-intensive systems through a cybersecurity lens. The core question is straightforward: how might someone attack the system, and how do you defend against it. Threat modeling is treated as an architectural and systems-engineering method that turns that question into practical action. It is presented as a way to guide requirements, system design, and operational choices, so teams can identify threats and shape mitigations. Natasha Shevchenko and Alex Vesey join Tim to explore that idea from different angles. The early discussion keeps circling back to the value of spotting threats before they harden into implementation decisions. Alex describes a path that many cyber analysts take from more operational or developer-oriented work into broader threat awareness. That progression starts with specific mitigations for specific threats in a specific system. It then expands into thinking about classes of threats and the patterns that can remove those threats more generally. The episode connects that progression to software development itself. Developers are reminded that they are not just writing code. They are making architectural choices, whether they label them that way or not. The conversation uses microservices as a familiar example of a pattern that is widely used but not automatically right for every problem. That point is not framed as a rejection of modern software practices. It is more a reminder that architecture should fit what is actually being built. The discussion then moves toward model-based systems engineering as a way to step up a level of abstraction. Once a team understands what it is really trying to build, it can choose patterns that match the mission and the risk. That shift matters because some threats are not merely patched. They are inherited from the structure itself. The guests keep returning to that idea. If a team chooses a certain architecture, it may accept certain risks before the first feature ships. The episode frames threat modeling as the discipline that makes those inherited threats visible early enough to change course. It also suggests that security thinking gets stronger when it moves from isolated fixes to architectural judgment. The result is a measured, practical conversation about how cybersecurity and system design reinforce each other. The tone stays explanatory rather than dramatic. The emphasis stays on consequence, not hype. The episode ultimately argues that good design and good defense are closely linked.

As heard by us

A clear case for threat modeling as a practical architectural lens.

Threat modeling is the episode's organizing idea, and it is treated as a practical way to build software-intensive systems from a cybersecurity angle rather than as jargon.

Read the full review in PlayNext →

Why you'd press play

Press play if you want threat modeling tied to real design choices, not abstract security slogans.

Read the full recommendation in PlayNext →

Listen to the show on

Apple Podcasts Spotify

Play clips from this episode More from Software Engineering Institute (SEI) Podcast Series