Rethinking Threat Modeling | From Security Review to Developer Action | Through the Lens of a Security Architect
An asset-driven approach to turning security design reviews into actionable security controls.
Most threat modeling sessions I've seen go the same way. Someone books a two-hour meeting, and a whiteboard fills up with arrows. A security person starts talking about spoofing, tampering, elevation of privilege and other familiar threat categories, while the developers nod politely. Two weeks later, the diagram lives in a folder that no one opens.
The intent was good, but somewhere along the way, the format lost the room.
The Problem Isn't Effort. It's Context.
Frameworks are useful because they give security teams structure. But when you're actually reviewing an application, the questions that matter are usually much more contextual. Developers, product owners and architects want to know what they are protecting, how it could be abused, what they should build to prevent it, and how they would know if something went wrong.
That became more obvious to me as I spent more time doing application security and security architecture reviews. A threat model can contain a long list of valid security concepts and still leave the development team asking, "Okay, but what do I actually need to fix?"
With modern applications, the problem becomes even more interesting. We now have SaaS platforms, cloud services, APIs, integrations, RAG pipelines and agentic systems. The security questions don't disappear; they become more dependent on the specific assets and interactions in the design.
A Different Starting Point: Assets, Not Categories
This is the idea behind A-SDF — Asset-Driven Secure Design Framework, which powers threatmodeling.in. Rather than beginning with an abstract threat category, I start with a simpler question:
Once the assets are understood, the review becomes much more concrete. A-SDF looks at areas such as the user, components, data, integrations, actions, and, for cloud and GenAI systems, identity and intelligence. The objective is to understand what those assets do, how they can be misused, and what controls are appropriate.
The resulting structure is intentionally simple:
Let's Take an Employee Compensation SaaS Portal
Imagine an employee reward and compensation SaaS platform. Employees can manage their profiles, upload resumes, download salary slips and interact with HR workflows. The platform may also integrate with an identity provider, HR system, payroll platform and other enterprise services.
If I start by asking, "What threats apply to this application?", I'll certainly find threats. But if I start with the assets, the review becomes much more specific.
Employee compensation data is an asset. Employee identity is an asset. Manager authorization is an asset. Resume documents are assets. The integrations and the actions the application can perform are also important parts of the design.
Now consider a simple salary-slip download. An employee receives a document ID and uses it to download their salary slip. What happens if they change that ID and request another employee's document?
The useful question isn't simply, "Is there an authorization vulnerability?" It is: Who is performing what action against which asset, and what is the result?
That gives us a practical reasoning model: Who → Does what → To what → Result. An authenticated employee manipulating a document identifier to access another employee's salary slip leads naturally to a server-side ownership or object-level authorization control. A detective control could log and alert on repeated cross-employee access attempts.
Now the finding is something a developer can actually act on. It is connected to the feature, the asset, the abuse case and the control rather than being another generic authorization statement.
And Then GenAI Changes the Conversation
This asset-driven way of thinking becomes even more interesting when reviewing GenAI and agentic systems.
Consider an internal AI assistant connected to company documents and business APIs. It can search a knowledge base, retrieve information, create tickets, call tools and potentially perform actions on behalf of a user.
Most security discussions naturally go toward prompt injection. That is important, but it is not the only question I want to ask. What does the AI system actually own or control?
The answer could include the user's identity, retrieved data, knowledge sources, system instructions, model access, tools, API credentials and the actions the agent is permitted to perform.
Imagine an employee asking the assistant for another employee's compensation details. Or imagine a malicious document retrieved through RAG attempting to influence an agent into calling a privileged tool.
The deeper question becomes: Can untrusted content or an improperly authorized user influence an action against a valuable asset?
That is why I see asset-driven review as useful beyond conventional web applications. The same reasoning can be applied to Cloud, GenAI, RAG and agentic architectures, where identity, intelligence, tools, data and actions can all become part of the security boundary.
Where Does AI Fit?
I built A-SDF as an AI-assisted platform because I believe AI can make security design reviews more accessible and reduce some of the repetitive work involved in getting a review started. But I don't believe an LLM should replace the security architect.
An AI can produce a very convincing list of threats. It can also produce a very convincing list of threats that have little relevance to the actual design. The goal, therefore, isn't to generate as many threats as possible. It is to understand the design and help identify what could go wrong with the assets that actually matter.
That is the problem I wanted to explore with A-SDF: use AI to assist security reasoning while keeping the security professional responsible for context, judgment and validation.
Read the top row the way a developer would. The asset is the internal knowledge base. The abuse case is exposure or unauthorized modification of the data behind the chatbot. The output then connects preventive controls, detective controls and risk. No taxonomy lookup is required to understand what needs attention.
The full model for this RAG-based chatbot covers more ground, including the parts of RAG that traditional application reviews may not naturally surface, such as what happens to data while it is being retrieved, processed and used.
Preventive and Detective, Together
Many security checklists stop at prevention: encrypt this, validate that, restrict access. Those controls matter, but controls can fail, configurations can drift, and assumptions can be wrong. That is why I wanted every A-SDF review to consider not only what should prevent misuse, but also how the organization would detect it if prevention failed.
It is a small structural choice, but it changes the conversation from "Did we put a control there?" to "What happens if that control doesn't work?"
A Threat Model Should Lead Somewhere
For me, a threat model shouldn't become a document that sits in a project repository until the next audit. A useful threat model should influence the design. A threat should lead to a security requirement, a requirement should lead to a control, and a control should eventually be testable.
That is the direction I'm taking A-SDF: connecting security design review with architecture analysis, integration security, cloud security, GenAI and agentic security, and security testing.
I'm still building it, still learning from real security design scenarios, and still refining the methodology and knowledge base. The central idea, however, remains simple:
Ask what the system owns, who can interact with it, what they can do, what happens if they misuse that capability, what controls should prevent it, and how we would detect it if prevention failed.
That, to me, is where threat modeling becomes more than a checklist. It becomes a practical security design conversation.
A Work in Progress
I've built a working implementation of this approach and released it as a beta at threatmodeling.in. It is not a finished product, and I don't intend to present it that way. The platform is in continuous development and refinement, and I'm actively improving the methodology, knowledge base and AI-assisted review capabilities as I learn from real-world use cases.
My goal is to keep it grounded in practical security engineering rather than simply building another AI tool that generates security terminology.
If you're an AppSec engineer, security architect, developer or threat modeler, try it with something real—a feature you're building, an application you're reviewing, or a GenAI system your team is experimenting with. I'd genuinely like to hear what it gets right, what it misses, and what you would expect from an AI-assisted design review.
Start with the beta at threatmodeling.in.