Edition 31: The role of diagramming in design-stage security is changing
LLMs are changing how Security teams think about design stage security. Diagramming is no longer mandatory, but that does not make it irrelevant.
One of my many 'a-ha' moments when I led AppSec at a Fintech company was when we presented a thought-through, well-drawn threat modeling diagram (essentially a DFD with assets, trust zones, and controls called out) to a senior architect. He was impressed that we could represent a complex system in a single diagram with reasonable accuracy. But he had two problems with this diagram:
Given how dynamic our Data Platform was (the scope of the threat model was a subset of our Data Platform), he felt the diagram would be out of date within 24 hours of the diagram being drawn (I think he was being a little dramatic, maybe it would take 7 days to get out of date :P)
He wasn’t sure what to do with all this information. He found it educational, but it did not clearly answer the question, “So what do we do now”? I gave the usual speech on how we’ve generated threats from the analysis and how those can be mapped to requirements. Again, he was impressed with the methodology, but felt the entire exercise was overkill for what it generated (a set of threats that helped build a set of security requirements) and could not scale.
While I didn’t agree with all the criticism, it was an important piece of feedback. Diagramming was useful, but not scalable. It was OK as an exercise in understanding a system (I always felt better informed when we got the diagram right), but the effort-to-reward ratio is not enticing for most organizations.
We continued to create diagrams as needed (primarily for the Security team’s use), but we modified the program to include Rapid Risk Assessments and empower Security Champions. It worked reasonably well (at least I felt that way), but I wasn’t satisfied with the answers to the criticisms raised by the architect.
About 18 months after this episode, we started Seezo. Our first product helps scale Security Design Reviews. The hypothesis was this:
Until now, the best way to integrate security into the design stage has been to translate a bunch of unstructured information (design docs, Jira tickets, conversations with dev teams, etc.) into a diagram that follows a bunch of rules (DFD, Cigital-style threat model, etc.). Then analyze this diagram (either manually or through Threat Modeling products) to generate artifacts that are useful to your stakeholders (Threats in some cases, Security Requirements in others).
This changes with LLMs, given they can help us skip the diagramming step. You can now go from unstructured data to security requirements without needing the intermediary step of diagramming.
24 months in, the hypothesis largely holds true, but I think there’s additional nuance to it:
For a subset of companies, diagramming is how they think. For such companies, diagrams are not an intermediate step to generate a threat model, but an integral part of how teams communicate with each other. This is especially true in certain industries (e.g., automotive and IoT) and regions where teams may not share the same first language (diagramming does not need mastery over a common language). In such companies, it makes sense for diagramming to be a core part of any design-stage security activity as well.
Diagramming can move from being a “must have” for design reviews to “only in some cases”. LLMs can do a great job of identifying which reviews require deeper analysis, and companies can enforce manual steps like diagramming when deeper, manual reviews are necessary.
Enforcing new artifact creation as a prerequisite for a Security Design Review is a good way to ensure your program never scales. Security teams should start with what data is already available (PRD, Jira Epics, Design Docs, etc.) and request additional artifacts only after one round of analysis (which can be automated) of existing information.
What is Design-stage Security?
Terminology confusion: There are so many terms that sorta talk about the same thing: Threat Modeling, Security Design Review, Secure-by-design, Design-stage security, security architecture review, and so on. Now, if you want to get all technical, you could find differences in each of these terms. But in reality, they all point to: “review artifacts (usually non-code, but sometimes involves code and deployment configs too) and generate a list of things that can go wrong from a security perspective”. I am using 2 terms in this post:
Design-stage security: All the security activities performed before an engineering team starts building the feature/product
Security design review: Activity of reviewing artifacts that describe what engineers plan to build (PRDs, design documents, Jira epics, etc) and generating a list of security requirements for that feature
In theory, I wish we just called all of the above terms “Threat Modeling”. I really like how Adam Shostack talks about it in his Fast, Cheap, & Good essay (bonus points for the Daily Show meme :P). But unfortunately, that term elicits such purity tests (“that’s not what we mean by threat modeling”) that it’s best to find another term to describe these activities
Fun fact: We initially called our first product “Seezo TM”, but half of all demo calls went into the “but that’s not threat modeling” argument. We ultimately renamed the product to “Seezo SDR” to avoid confusion.
How do LLMs change things?
Design-stage security has always started with messy, unstructured information. Unlike code scanning or cloud configuration reviews, there is no single format or structure for inputs. Security teams rely on design documents, Jira tickets, meeting notes, and diagrams provided by product or engineering teams.
That’s why questionnaires and diagrams became popular. They acted as intermediaries, a way to turn unstructured input into structured forms. Once structured, you could apply rules and extract threats, controls, or requirements, just like SAST tools do to code.
LLMs make that intermediary step optional. They can extract structure and context directly from unstructured data, effectively merging two steps into one.
There are still challenges, especially non-determinism and the balance between consistency and creativity, and there’s a lot of nuance on when to make the trade-off, but that’s a topic for another day.
In practice, this means the first draft of a security design review no longer needs a human in the loop to draw diagrams or fill out forms. You still need humans to review results and provide context. LLMs will never capture all of the tribal knowledge that a senior security architect can offer.
The Snyk moment for security design reviews
If you were around AppSec in the 2010s, you remember how code reviews worked. They were manual, inconsistent, and dependent on who bothered to look. Tools like HP Fortify and IBM AppScan existed, but they never achieved full coverage or ease of use. The next wave of tools, like Snyk, Semgrep, and GitHub Advanced Security, succeeded partly because they aligned with how engineering was changing. As teams adopted CI/CD pipelines, these tools naturally fit into the workflow and enabled automatic security checks. Today, every pull request gets scanned, and coverage is close to 100 percent by default. Cloud security followed a similar path.
Design-stage security never caught up. Coverage for security design reviews is stuck where it was 15 years ago: manual, selective (“high-risk features only”), and dependent on who remembers to file a ticket.
LLMs change that equation. They allow us to run automated assessments on every feature change. This doesn’t remove human judgment, but it ensures that every change gets a first-pass review.
Can LLMs draw good diagrams?
If diagrams make security design reviews easier to consume and help some teams communicate, why not let LLMs draw them? After all, if they can Giblify us, they can probably handle a few DFDs.
LLMs are already quite good at generating diagram drafts. The challenge is precision. Layout accuracy, naming consistency, and boundary clarity vary a lot, especially since every company has its own “style” of diagramming. A single misplaced trust boundary or misnamed asset can make the output confusing or even misleading.
So, while LLMs can create quick first drafts, they are not ready to run the process fully autonomously.
That said, this will likely change soon. Two years ago, code generated by LLMs looked impressive but was barely usable. Diagram generation is at a similar stage today: promising but not yet production-ready.
How should security teams think about diagramming?
Diagramming tools have improved a lot in recent years, and not because of AI. Better UX, real-time collaboration, and wider use of standards like C4 have made diagrams richer and more consistent with how modern teams build and ship software.
Security engineers should work with developers to set practical guidelines for diagramming. For example, if your company uses C4, decide what security considerations belong at each level. This makes diagrams more useful without turning them into compliance exercises.
Another angle worth exploring is how to make diagrams easier for LLMs to consume. I like what companies like IcePanel are doing here. They allow diagrams to be exported as llms.txt, a structured representation that LLMs can interpret easily. Changes like these can help security teams analyze designs faster without asking engineers to create new artifacts.
Just don’t turn any of this into a mandate. The fastest way to kill adoption is to make diagramming a precondition for a security design review.
The bottom line
Design-stage security is gonna see dramatic improvements over the next 12-18 months, and diagramming will not be the mainstay. It will be entirely eliminated in some companies, but will remain an important part of the program in others. If your organization falls into the latter category, ensure you consider how diagramming can help improve things for security teams and developers.
That’s it for today! Is your org still relying heavily on DFDs? Am I killing the joy of security design reviews by being too bearish on diagramming? Are you already scaling design-stage security using LLMs? Let me know! You can drop me a message on Twitter (or whatever it is called these days), LinkedIn, or email. If you find this newsletter useful, share it with a friend, colleague, or on social media.