Threat modeling gives a security review a map. It identifies valuable data and operations, the actors that can reach them, the boundaries where trust changes, and the unwanted outcomes the system must prevent. The result directs inspection and testing toward consequences rather than treating every file as equally important.
Building the model from working code
A mature system may have architecture diagrams and security requirements. A vibe-coded product may have neither, so the audit reconstructs the model from routes, data stores, deployment configuration, integrations, and runtime behaviour. The code shows what the system currently trusts even when that decision was never documented.
The model is useful only when it stays tied to the implementation. An audit of vibe-coded software checks each claimed boundary against the code that enforces it and records gaps between the intended design and the running system.
| Model element | Audit question | Code evidence |
|---|---|---|
| Asset | What data or action needs protection? | Models, storage, critical operations |
| Actor | Who or what can interact with it? | Users, services, administrators |
| Entry point | How can an actor reach the system? | Routes, jobs, imports, webhooks |
| Trust boundary | Where does confidence change? | Identity, network, account, environment |
| Control | What prevents the unwanted action? | Checks, validation, isolation, tests |
From boundaries to concrete checks
The model narrows broad concerns into verifiable questions. If customer records are an asset, the audit asks which routes read them, how the caller is identified, where ownership is checked, and what gets recorded after access. That connects design-level reasoning to authorization in specific handlers.
The first pass usually follows a fixed sequence:
- Inventory assets: List sensitive data, privileged operations, credentials, and availability-critical services.
- Map actors and entry points: Include external users, staff tools, integrations, jobs, and machine identities.
- Draw trust boundaries: Mark where data changes owner, environment, privilege, or validation status.
- Describe unwanted outcomes: State what must not be read, changed, triggered, or interrupted.
- Locate controls: Tie each outcome to code, configuration, and tests that reduce the risk.
- Record uncovered paths: Prioritise gaps by consequence and reachability.
Why generated systems need reconstruction
Generated features can be individually coherent while relying on different assumptions. One route trusts a framework session, another accepts a signed callback, and a job reads records with broad service credentials. None is automatically wrong. The risk lies in the unexamined boundary between them.
Input validation illustrates the connection. The model identifies which inputs cross a boundary and what they can affect. The code review then verifies the exact checks applied before the data reaches that effect. This prevents a checklist from replacing system-specific reasoning.
The audit output
The deliverable is a living map linked to findings and evidence. It records the assets, actors, boundaries, unwanted outcomes, current controls, and missing checks. It also gives later changes a reference: a new integration or administrative action can be placed on the same map before it ships.
That discipline is part of the difference between a prototype and an engineering workflow built for production. Threat modeling does not predict every defect. It makes the system's trust decisions visible, so reviewers can test the places where a defect would matter most.
