From Design Docs to Security Requirements: Scaling Threat Modeling with LLMs

Security teams don't have the bandwidth to review every feature that ships. Manual threat modeling is thorough but slow, and the quality varies depending on who's doing the review. This talk looks at how LLMs can help close that gap, not by replacing security engineers, but by getting you to a reasonable starting point faster.

We'll go through what happens when you throw unstructured inputs like design docs, Jira tickets, and meeting notes at LLMs and try to get useful security requirements out. I'll cover the approach of breaking features down into DFD3 components (processes, external entities, data stores, data flows, trust boundaries) as a structured intermediate step before threat identification, and how kill chain methodologies like MITRE ATT&CK can group requirements into attack narratives that actually tell a story about what can go wrong.

Some practical takeaways from experimentation: making assumptions and clearly stating them works better than generating false positives that kill reviewer trust. Small prompt variations make a surprisingly big difference in output quality. And most people including experienced security folks end up evaluating LLM output on vibes rather than any structured criteria, which is ok to an extent, but hard to metricize without datasets and ground truths.

We'll also get into the hard parts: LLMs lack tribal knowledge about your org, they don't retain context across assessments by default, and consistency is difficult to measure without ground truth. The talk covers how to think about precision and recall for threat model outputs and where the 0-60 is easy but 60-80 gets really hard.

This is aimed at security engineers and AppSec practitioners who want to use AI tooling practically without pretending it solves everything.