"The Workshop That Always Happens"

Jessy Lang: Welcome back to Security Dialogues. I'm Jessy, and this is episode eleven. Just the two of them tonight, and a sentence that every product team has said out loud at least once, usually in a meeting that ended without a date: we should really do a threat model.

Jessy Lang: Last time I promised you the threat model that always slips to next quarter. Tonight is about what changes when it doesn't slip, because it simply happens, every time, built from what is actually there.

Tess Calder: I've sat in a lot of those workshops. Eight people, a meeting room, a whiteboard, four hours blocked after three weeks of calendar negotiation. The first hour goes to arguing about the diagram. The second hour goes to threats that sound plausible. In the third hour somebody has to leave for another meeting. And the output is a photo of the whiteboard.

Marcus Hale: A photo that is out of date by the next release.

Tess Calder: Usually by the next sprint.

Jessy Lang: Marcus, Tess, this is where tonight starts.

— I. The Photo of the Whiteboard —

Marcus Hale: Let me be fair to the workshop before we pick at it. Putting eight people who rarely talk to each other into one room is valuable. Somebody from operations says that service doesn't run where you think it runs... and the whole drawing changes. I don't want to lose that.

Tess Calder: Nobody's saying throw it out. We're saying look at what it costs. Eight people for four hours is thirty-two hours of expensive attention, before anyone has written a single finding down. Which is why it happens once, before a big release, if it happens at all.

Marcus Hale: And a product that ships several times a year ends up with a threat model... that describes a version nobody runs anymore.

Jessy Lang: So what's the actual problem? That people are busy?

Tess Calder: That's the first of three. It's done rarely, because it's expensive. It's done from memory, because the room only knows what the room remembers. And it decays, because the product keeps changing and the photo doesn't.

Marcus Hale: Only the first one is about people being busy. The second is the one I'd like to look at... because it's the one nobody complains about.

— II. What the Method Actually Asks —

Jessy Lang: For anyone who has never been in that room: what is the method, actually?

Marcus Hale: Most teams use something called STRIDE. It's a mnemonic for six kinds of things that can go wrong. Spoofing: someone pretends to be somebody or something they aren't. Tampering: someone changes data or code they shouldn't be able to change. Repudiation: someone does something and can later deny it, because nothing recorded it. Information disclosure: data reaches someone who shouldn't see it. Denial of service: something can't do its job because it's overwhelmed or blocked. And elevation of privilege: someone ends up with more power than they were given.

Tess Calder: And you ask those six questions about every part of the system, and about every connection between the parts.

Marcus Hale: So what's the hard part?

Tess Calder: It isn't the six questions. They fit on an index card. The hard part is the system you ask them about. The method assumes you have an accurate picture of what exists and how it's wired together. In a workshop, that picture is whatever the room remembers.

Marcus Hale: And what does a memory-based picture miss?

Tess Calder: Whatever nobody thinks of. The library that was pulled in two years ago. The debug port someone left open. The admin endpoint from the first version. The second deployment in another region that exactly one person knows about.

Jessy Lang: So the weak point isn't the method. It's the input.

Marcus Hale: The method is fine. The input is memory.

— III. A List Is Not a Model —

Tess Calder: There's a shortcut people take here, and I want to deal with it, because it sounds like the answer. We already have vulnerability lists. Scanners produce them every night. Why isn't that a threat model?

Marcus Hale: Because a list tells you what's wrong with the parts. A threat model tells you how somebody could abuse the whole. Those are different questions. A vulnerability in a component is a fact about the component. Whether it matters depends on where the component sits, what can reach it, and what it can reach in turn.

Tess Calder: I can take a boring component with an ordinary flaw and turn it into a way in, if it happens to sit next to something valuable with nothing between them. And I can ignore a scary-looking one if it's buried behind three layers I can't cross.

Marcus Hale: The list can't tell those two situations apart. A model can, but only if it contains the wiring, not just the parts.

Jessy Lang: So you need the parts and the wiring, together, before the six questions even begin.

Tess Calder: That's the whole problem in one sentence.

— IV. Four Sources, One Model —

Marcus Hale: This is where the TrustSource Threat Model Agent does something I find genuinely different. Before it runs any STRIDE analysis, it builds the model from four things that already exist in most organisations, just scattered across different tools and different people.

Jessy Lang: Walk us through the four.

Marcus Hale: One: the software bill of materials, the SBOM, which lists every component in the product. Each component can be checked against known vulnerabilities, the CVEs, which stands for Common Vulnerabilities and Exposures. So that source answers a question: what did we bring in, and what is publicly known to be wrong with it?

Tess Calder: Two: the results of static application security testing, SAST. A tool reads your own source code without running it, and flags weak spots. Those weaknesses are catalogued as CWEs, the Common Weakness Enumeration. That source answers: what did we write ourselves, and where is it fragile?

Marcus Hale: Three: the OBOM, the operations bill of materials. If the SBOM says what the product is made of, the OBOM says what is actually running in operation: the operating system, the runtime, the containers, the installed packages. It answers: what is really out there?

Tess Calder: And four: the deployment structure. How the pieces are wired together. Which service talks to which, what's reachable from the outside, where the trust boundaries sit. It answers: what can reach what?

Jessy Lang: Who normally owns those four?

Marcus Hale: Usually four different teams. The build team owns the bill of materials. Application security owns the static analysis. The platform or operations team owns what's running. Architects or DevOps own the picture of the deployment. They're all competent, and they rarely sit in the same meeting.

Tess Calder: Which is why the threat model so often ends up as the one document that needs all of them and belongs to none of them.

Marcus Hale: Merging the four inputs automatically means nobody has to chair that meeting before the real work can begin.

Jessy Lang: Four sources, four questions.

Tess Calder: Four tools, four owners, four dashboards. In a workshop, that's four people who didn't bring their dashboard.

Marcus Hale: And the merge happens first. Only then does the STRIDE analysis start, on a model that's already full of facts instead of guesses.

— V. Evidence Before Imagination —

Marcus Hale: Let me name what changes. A workshop starts with imagination: what could go wrong? Smart people brainstorm. This starts with evidence: here is what exists, here is what's known to be weak, here is how it connects. Then the method asks its six questions. I'd call the result default diligence.

Tess Calder: Explain default.

Marcus Hale: Everything this show has said since episode five comes down to this: the thorough version of the work only happens when somebody forces it. A scare, an audit, a regulator. Thoroughness has been the exception, which is exactly why it's the thing that slips. If building the model costs very little each time, the thorough version becomes what happens by default, and skipping it becomes the thing somebody has to decide.

Tess Calder: Which flips who has to make the effort.

Jessy Lang: Last week was about borrowed trust. Is this related?

Marcus Hale: Closely. A generic threat checklist is borrowed: somebody else's list of what usually goes wrong, applied to your system. A model built from your own components, your own code findings and your own deployment is owned. It's the same difference as last week, applied to threats instead of platforms.

— VI. What the Merge Changes —

Tess Calder: Make it concrete, because the merge sounds neat on paper. Take a made-up product: a service that handles file uploads.

Marcus Hale: An illustration only, not a real case. A component in its SBOM has a known vulnerability with a high base score. On its own, that's a number someone else computed. Now the OBOM shows the component really is deployed in the running service, and the deployment structure shows that service is reachable from the internet with nothing in front of it. Same component, same CVE, an entirely different weight.

Tess Calder: And the reverse. Same CVE, but the component only exists in a build-time container that never reaches production. Different weight again, in the other direction.

Marcus Hale: That's the environmental context from episode eight, the one nobody fills in. The merge fills it in, because the OBOM and the deployment structure are the context.

Tess Calder: The same goes for the SAST findings. A weakness in a function that parses untrusted input on that internet-facing service is a different animal from the same weakness in an internal batch job that runs once a night.

Jessy Lang: So by the time the method asks its first question...

Marcus Hale: It's already asking it about the right part of the system.

— VII. STRIDE on a Populated Model —

Jessy Lang: Let's walk the six questions over that made-up upload service, so people can see what the merge feeds into each one.

Marcus Hale: Illustration again, not a real system. Spoofing first: who can pretend to be what? The deployment structure shows where the trust boundaries are, so the question lands exactly where traffic crosses into the service from outside. How does it know who is calling?

Tess Calder: Tampering: can somebody change what the service stores or runs? The SAST findings matter here. A weakness class like path traversal, where a filename can walk out of its folder, is a tampering threat with a specific place in the code behind it.

Marcus Hale: Repudiation: if somebody uploads something harmful, can we show who did it? This is the category where the inputs help least. Whether the records exist is something a person has to confirm. A good model flags it as a question instead of guessing the answer.

Tess Calder: Information disclosure: where does sensitive data sit, and who can read it? The deployment structure shows which stores sit behind which services. A component from the SBOM with a known flaw that exposes files or memory becomes a disclosure threat if it sits in front of that store.

Marcus Hale: Denial of service: what can be overwhelmed? The OBOM shows what really runs on the exposed endpoint, runtime included, and the exposure tells you who can send it as many requests as they like.

Tess Calder: And elevation of privilege: can someone turn small access into big access? That's where the vulnerability findings and the wiring combine. A flaw in a component that runs with broad permissions, one hop from something that holds the keys.

Jessy Lang: Six questions, and each one has something real to hang on.

Marcus Hale: Five of them do, in this example. The sixth, repudiation, is flagged as a question for a person. That's a good outcome, not a failure.

Tess Calder: A model that says I don't know this one, ask someone, is worth more than one that has an answer for everything. We covered what the other kind looks like in episode seven.

— VIII. What Comes Out —

Jessy Lang: And what does a person actually get at the end?

Marcus Hale: Risks and countermeasures. For each part of the system and each connection, which of the six kinds of problems applies, what the threat looks like, and what would reduce it.

Tess Calder: Here's what I'd test any tool like this against. Can I ask: why is this threat on the list? And get an answer that points to something real. A component, a finding, a connection in the deployment. If the answer is because the model said so, that's episode seven all over again.

Marcus Hale: That's the line between an assistant that's grounded and one that confabulates. A threat with evidence behind it can be checked in two minutes. A threat without it has to be believed.

Tess Calder: I'm not claiming every tool clears that bar. I'm saying it's the bar to ask for. Of anyone's. Ours included.

Marcus Hale: And the same goes for the countermeasures. A useful one names what to change, where, and why it reduces that specific threat. Not a general reminder to be careful.

— IX. The Part That Stays With You —

Marcus Hale: Now the part I'd underline. The agent proposes risks and countermeasures. How much each risk matters, and whether you accept it, fix it, or work around it, stays with the customer.

Tess Calder: Why is that the right split, though? If the agent can analyse all of this, why not let it decide?

Marcus Hale: Because only you know three things. What each asset is actually worth to you, which is the tier list from episode eight. How much risk you're willing to carry. And which countermeasure fits your budget, your team and your constraints. A tool can propose. It can't know what you can afford to lose.

Tess Calder: And accountability. When a regulator or a customer asks who accepted this risk, they want a name. They don't want a model version.

Marcus Hale: So the design is simple. The agent does the exhaustive part. The human does the judgment part. And the boundary between them is explicit.

Jessy Lang: That sounds like a relief rather than a loss.

Tess Calder: It is. Nobody went into security to spend four hours drawing boxes.

— X. How to Review It in an Hour —

Jessy Lang: Suppose that list lands on your desk. What does a person actually do with it?

Marcus Hale: I'll ask the questions and Tess answers, the way she'd brief a team. First: what do you check before you read a single threat?

Tess Calder: The picture itself. Is the exposure right? Does the model think something is internal that's actually reachable from outside, or the other way round? If the picture is wrong, everything downstream is wrong, and it's a five-minute check by whoever knows the deployment.

Marcus Hale: Second: what do you look at next?

Tess Calder: What's missing. Which services have no static analysis results, no operations bill of materials. The blanks tell you where the model is weakest.

Marcus Hale: Third: how do you pick what matters?

Tess Calder: You put your own asset values on it. Which of these threats touch the things on your tier-one list? Most of the list will be real but minor. A handful will be the ones that would hurt.

Marcus Hale: Fourth: what happens to each countermeasure?

Tess Calder: It gets an owner, a size and a decision. Do it now, schedule it, or accept the risk. Accepting is allowed. It just needs a name next to it.

Marcus Hale: And fifth: what do you do with the whole thing afterwards?

Tess Calder: You keep it. The next run gets compared against it, so the decisions you made last time don't have to be argued again unless something changed.

Jessy Lang: In an hour?

Marcus Hale: For a focused product, that's realistic for a first pass. A big estate takes longer, but it's still review work, not invention work.

— XI. Tess Reads the Map —

Tess Calder: From my side, a model like this is a map I'd want before an engagement. And the first thing I'd check is whether it matches reality.

Marcus Hale: What would you look for?

Tess Calder: Three things. First, the gaps. If no static analysis ran on one service, that service has a blank where its code weaknesses should be. A good model shows the blank instead of pretending it's clean. It's the silent zero from episode ten: coverage next to findings.

Marcus Hale: And the second?

Tess Calder: What a model built from tools can't see. Business logic. A clever abuse of a feature that works exactly as designed. People being talked into things. None of that lives in a component list.

Marcus Hale: And the third?

Tess Calder: Whether the countermeasures are the kind a team can actually do on a Tuesday... not just ones that look right in a document.

Marcus Hale: The first one is a feature, honestly. An evidence-based model makes its own gaps visible. A workshop never tells you what nobody thought of.

Tess Calder: And my job starts exactly where the inputs end. Which is a better place to start than a blank wall.

— XII. A Photo Versus a Live Feed —

Jessy Lang: Earlier you said threat models decay. How does this one not?

Marcus Hale: A threat model done once is a snapshot, the same shape as the audit report from episode nine. True on the day, quietly out of date afterward. The only fix for a snapshot is to take the picture again, and a workshop is too expensive to repeat for every release.

Tess Calder: If the four inputs are kept current, the model can be rebuilt when they change. The SBOM with each build, the static analysis in the pipeline, the operations bill of materials from what's running, the deployment description whenever it changes. The question stops being when do we find four hours, and becomes what changed since the last run.

Marcus Hale: Which is a much smaller conversation. Only the difference needs a human.

Jessy Lang: So it goes from a photograph to something closer to a live feed.

Marcus Hale: A window instead of a photograph, to borrow last week's phrase. You still have to look through it.

— XIII. What the Workshop Is Still For —

Marcus Hale: I don't want anybody to leave thinking the room is obsolete. The room gets better. You walk in with a populated model instead of a blank wall, and the first hour of arguing about the diagram simply disappears.

Tess Calder: And the time goes to the questions only people can answer. Which of these risks do we actually care about. What is this trade-off worth. Who owns the fix.

Jessy Lang: So the workshop shrinks.

Marcus Hale: It changes from collecting to deciding. Which is the part it was always best at, and the part nobody wanted to start with a stack of loose facts anyway.

Tess Calder: And the people who used to leave in hour three now have a reason to stay for the part that matters.

— XIV. What It Costs —

Tess Calder: Cost, because nothing on this show is free.

Marcus Hale: The inputs have to exist. A bill of materials per build, static analysis in the pipeline, an operations bill of materials, a description of the deployment. If a team has none of that, the first run is mostly a list of what's missing.

Tess Calder: Which isn't a bad first result.

Marcus Hale: It is an inventory audit nobody had to ask for... After that, someone reviews what comes out, and reviewing an evidence-backed list is a shorter job than producing one from a blank wall.

Jessy Lang: And who pays for it?

Marcus Hale: For many manufacturers, regulation does. The Cyber Resilience Act expects an assessment of the cybersecurity risks of a product, documented, and kept current through its support life. A threat model that can be rebuilt whenever the product changes is a very direct answer to that expectation.

Tess Calder: Same pattern we keep seeing. Security argues for it, but the obligation is what pays for it.

Marcus Hale: I've stopped minding which argument wins, as long as the model gets built.

— XV. The First Run —

Tess Calder: What does the first run actually feel like? Be honest.

Marcus Hale: Humbling, usually. Not because the tool failed, but because it surfaces what was never written down. A service with no operations bill of materials. A deployment that exists in somebody's head. A repository where static analysis has never run.

Tess Calder: And that's the useful part.

Marcus Hale: I'd rather a team finds that out from a model on a Tuesday than from an incident. The first run is partly a threat model and partly an honest list of your own blind spots.

Tess Calder: Which a lot of teams would never schedule a workshop for, because it sounds like an admission.

Marcus Hale: It stops sounding like an admission once it's just what the first run produces for everyone... Nobody has a complete set of inputs on day one. The point is that the second run is better than the first.

Jessy Lang: Progress you can see.

Marcus Hale: Which is rarer in this field than it should be.

— XVI. Default Diligence —

Marcus Hale: So here's where I land. For eleven episodes, the villain has been some version of nobody did the homework. This is the first time on this show that the homework gets done by default, by something that doesn't get tired or reassigned, and that hands back the one part that has to stay human.

Tess Calder: I'll still test it. I test everything. But I'd rather test a model built from the real components, the real findings and the real deployment than a photo of a whiteboard.

Marcus Hale: That's all I'd ask anyone to do. Test it, check the evidence, and make the call yourself.

Jessy Lang: The thorough version, by default, with the judgment left where it belongs.

Tess Calder: I'll take that over a photo.

— Outro —

Jessy Lang: Default diligence: the thorough version of the work, happening unless somebody decides to skip it. I liked that this episode didn't promise the machine would decide anything. It promised the machine would gather everything, so that people could spend their hours on the part only people can do. If you've ever sat through a workshop that ended as a photograph, or you have a threat model that actually stays current, tell us. We read everything. Subscribe wherever you're listening to this, and leave us a rating if you've ever been handed a picture of a whiteboard as documentation. Next time: an agent that doesn't help with one task but takes on a whole role. A compliance manager, a security manager, on a clear brief. What it does by itself, what it hands back, and why that line has to be drawn on purpose. Until then.