Skip to main content
ZeroPath generates a threat model for each application it identifies in a repository. The threat model captures how the application is structured, who uses it, what trust boundaries matter, what attackers are realistic, and what parts of the codebase should be treated as out of scope. Threat models are not just notes in the dashboard. ZeroPath feeds this context back into scanner agents, triage, reachability reasoning, Dynamic Testing, and downstream prioritization so future analysis is aligned with the application you actually operate.
The Threat Model tab is currently an early-access dashboard feature. A threat model appears after a full scan identifies at least one application in the repository.

​
How Threat Models Are Created

Threat models are generated automatically during full scans. When ZeroPath identifies an application, it creates an application overview and, once the threat-modeling agent has enough context, a structured threat model for that application. For monorepos, a repository can have multiple application threat models. The repository Threat Model tab shows an application picker so you can review each application separately.

​
What You Can Edit

Each application has an Application Overview plus fixed threat-model sections:
  • Components - services and infrastructure pieces.
  • Interfaces - HTTP handlers, jobs, CLIs, webhooks, queues, and other entry points.
  • Actor Types - legitimate users, services, and integrations.
  • Authn/Authz Model - identity, authorization, tenancy, and permission rules.
  • Control Plane - security-relevant configuration and operational controls.
  • Attacker Types - realistic attacker starting positions.
  • Application-Specific Attacker Objectives - goals that matter for this app.
  • Datastores - persistent data locations and sensitivity.
  • Assumptions - deployment or architecture assumptions the scanner should rely on.
  • Out of Scope - code paths, environments, or concerns to exclude.
You can also add custom sections when your team has context that does not fit one of the fixed sections.

​
Edit Attribution

When you save changes to a fixed section or the application overview, ZeroPath marks that content as customer-edited and records who made the edit and when. This lets your team distinguish between content generated by the scanning agent and content your team has written or revised. Each fixed section shows:
  • Whether it was edited by a customer or generated by the agent.
  • The name of the person who last saved the section, when available.
  • When the customer last saved the section, distinct from when the agent last refreshed its generated content.
The application overview similarly tracks whether it has been customer-edited, so you can see at a glance whether the overview reflects your team’s input or the agent’s automatic identification.

​
Generation and Freshness

Each threat model includes timestamps that help you understand how current its content is:
  • Agent generated at — when the scanning agent last wrote section bodies. If the threat model has never been regenerated, this is not shown.
  • Evidence checked at — when the platform last compared the application’s inventory against the stored evidence, whether or not that comparison led to a regeneration. This can be more recent than the generation date, letting you see “checked today, unchanged since last week” rather than just a single staleness date.

​
Editing A Threat Model

1

Open the repository

Go to the repository in ZeroPath and select the Threat Model tab.
2

Choose an application

If the repository contains multiple applications, choose the application from the sidebar.
3

Review generated context

Read the application overview and fixed sections. Look for missing trust boundaries, incorrect auth assumptions, or out-of-scope paths that should be ignored.
4

Save edits

Edit the relevant section and save. Future scans and validation workflows use the updated context. Your edits are preserved across agent regenerations — customer-edited sections are pinned so that a subsequent scan refresh does not overwrite your changes.

​
When To Update It

Update the threat model when:
  • The application adds or removes authentication flows.
  • A new tenant boundary, role model, or admin surface is introduced.
  • A new datastore or sensitive data type becomes relevant.
  • A path or service should be explicitly out of scope.
  • A scan produces findings that reflect a wrong assumption about how the app is deployed.

​
Operational Notes

  • Threat models are per application, not just per repository.
  • If the tab says no applications have been identified, run a full scan first.
  • If a generated threat model is missing for an application, the next full scan can generate it.
  • Edits require permission to modify SAST configuration.
  • Dynamic Testing uses the same application context when deciding how to exercise a deployed target.