[Developers]

Threat Model Domain

A security architect is reviewing a proposed API gateway before deployment. She creates a threat model, places nodes for the gateway, the authentication service, the backend database, and an external threat actor, then d

Category: Api DomainsLast Updated: Feb 24, 2026
api-domains

Overview#

A security architect is reviewing a proposed API gateway before deployment. She creates a threat model, places nodes for the gateway, the authentication service, the backend database, and an external threat actor, then draws attack edges showing credential stuffing and SQL injection paths. Within an hour, she has a shared, versioned diagram that the whole team can review, annotate with mitigations, and hand off to the penetration testing team. That collaborative, graph-based approach is what the Threat Model domain provides.

The domain offers a threat modelling and security analysis visualisation system. Users build named threat models containing typed nodes (web services, threat actors, hosts, databases, APIs, networks) and directed edges (attacks, exploits, communications, dependencies) to map security scenarios and identify vulnerabilities. Models are scoped to their owning organisation in PostgreSQL with access controls enforcing secrecy levels.

Key Features#

  • Graph-Based Threat Modelling: Build threat models as interactive graphs with typed nodes representing system components and directed edges representing relationships, attacks, and data flows.

  • Node Types: Model diverse system components including web services, threat actors, hosts, databases, APIs, and networks, each with category classification and custom properties.

  • Edge Types: Define relationships between nodes including attack paths, exploitation vectors, communication channels, dependencies, and containment relationships.

  • Visual Layout: Save and restore visualisation layout configurations so team members can return to the same view and collaborate on threat model analysis.

  • Property Storage: Attach arbitrary metadata properties to both nodes and edges for flexible documentation of system characteristics, vulnerabilities, and mitigations.

  • Secrecy Level Controls: Apply classification levels to threat models to control access based on personnel clearance, ensuring sensitive security analysis is appropriately protected.

  • Organisation Scoping: Threat models are scoped to their owning organisation with access controls ensuring models are only visible to authorised personnel.

Mermaid Diagram#

Use Cases#

  • Cybersecurity Architecture: Map system architecture components, data flows, and trust boundaries to identify potential attack surfaces and security weaknesses before deployment.

  • Defence & Government: Model threat actors, their capabilities, and potential attack paths to understand threats facing classified systems and prioritise defensive investment.

  • Critical Infrastructure: Visualise how vulnerabilities in different ICS or SCADA components could be exploited through attack chains to assess overall risk exposure to operational technology environments.

  • Vulnerability Management: Document security controls and mitigations on the threat model graph to evaluate defensive coverage and identify gaps that require remediation.

Integration#

The Threat Model domain supports security analysis across the platform:

  • Vulnerability Management: Threat models reference known vulnerabilities.
  • Threat Actor Profiles: Known threat actors can be represented as nodes in models.
  • Investigation Management: Threat models support security investigation analysis.
  • Reporting: Threat model visualisations can be exported for documentation.

Open Standards#

  • MITRE ATT&CK: Attack pattern nodes within threat models carry ATT&CK technique identifiers (e.g. T1003) and kill chain phase annotations, enabling attack paths to be mapped to the industry-standard adversarial tactic and technique taxonomy.
  • Traffic Light Protocol (TLP): Model secrecy levels implement the FIRST.org TLP marking scheme (TLP:WHITE, TLP:GREEN, TLP:AMBER, TLP:RED), controlling how threat models may be shared and distributed across teams.
  • NATO Security Policy C-M(2002)49: The COSMIC classification hierarchy (COSMIC CONFIDENTIAL, COSMIC SECRET, COSMIC TOP SECRET) is implemented as a ranked access-control tier, allowing models containing classified intelligence to be handled under NATO information security policy.
  • EU Classification Scheme (Council Decision 2013/488/EU): EU RESTRICTED, EU CONFIDENTIAL, EU SECRET, and EU TOP SECRET levels are modelled directly, enabling threat analyses that must comply with EU institutional data-protection requirements.
  • GraphQL (June 2018 specification): All threat model create, read, update, and delete operations are exposed through a typed GraphQL API, with strongly typed node and edge schemas and JSON scalar fields for flexible property storage.
  • JSON (RFC 8259): Graph nodes, edges, and layout configurations are stored and transmitted as JSON documents, using PostgreSQL JSONB for efficient querying and indexing of graph state.
  • OAuth 2.0 / JWT (RFC 6749 / RFC 7519): API access is gated through RS256-signed JSON Web Tokens verified against a JWKS endpoint, with role-based access control determining which threat models a user may read or modify.

Last Reviewed: 2026-02-24 Last Updated: 2026-04-14

Ready to Build?

Get started with our APIs or contact our integration team for support.