Skip to content

Metadata and Extensions

Eric Fitzgerald edited this page Nov 12, 2025 · 1 revision

Metadata and Extensions

Extend TMI with custom metadata on threat models, diagrams, threats, and other objects.

Overview

TMI supports extensible metadata on all major objects, allowing you to customize the platform for your workflows and requirements.

What is Metadata?

Metadata consists of custom key-value pairs that you can add to:

  • Threat models
  • Diagrams
  • Threats
  • Notes
  • Components (future)

Adding Metadata

Via User Interface

  1. Select the object (threat model, diagram, threat, etc.)
  2. Find the "Metadata" section
  3. Click "Add Metadata" or "+"
  4. Enter key and value
  5. Save

Metadata Format

  • Key: String identifier (e.g., compliance, owner, priority)
  • Value: String value (e.g., PCI-DSS, security-team, high)

Common Metadata Uses

Categorization

category: web-application
tier: production
environment: cloud

Ownership and Responsibility

owner: security-team
reviewer: john.doe
team: platform-engineering

Compliance and Governance

compliance: PCI-DSS,HIPAA,SOC2
data-classification: confidential
regulatory-requirement: GDPR

Workflow Integration

jira-project: SEC
status: in-review
review-date: 2025-06-01
approval-required: true

Custom Classification

attack-surface: external
data-sensitivity: high
business-criticality: critical

Metadata Best Practices

Consistent Naming

  • Use kebab-case or snake_case
  • Avoid spaces in keys
  • Be consistent across objects
  • Document your schema

Structured Values

For multiple values, use delimiters:

  • Comma-separated: PCI-DSS,HIPAA,SOC2
  • Pipe-separated: team-a|team-b|team-c

Documentation

Document your metadata schema:

  • What keys are used
  • What values are valid
  • What they mean
  • When to use them

Filtering and Searching

Filter by Metadata

Use metadata to filter:

  • Show only threats with priority: high
  • Filter threat models by compliance: PCI-DSS
  • View diagrams for environment: production

Search by Metadata

Search for objects with specific metadata values.

API Integration

Reading Metadata

Metadata is included in API responses:

{
  "id": "tm-123",
  "name": "Payment System",
  "metadata": {
    "compliance": "PCI-DSS",
    "owner": "security-team",
    "review-date": "2025-06-01"
  }
}

Writing Metadata

Update metadata via API:

PATCH /threatmodels/tm-123
{
  "metadata": {
    "status": "reviewed",
    "reviewer": "john.doe"
  }
}

See API Integration for details.

Advanced Uses

Custom Reporting

Generate reports based on metadata:

  • All high-priority threats
  • Threat models by compliance requirement
  • Items requiring review by date

Automation

Use metadata for automation:

  • Auto-assign based on owner field
  • Trigger workflows based on status
  • Generate notifications for review-date

Integration with External Systems

Map metadata to external systems:

  • jira-project → Jira project key
  • servicenow-ci → ServiceNow CI
  • repository-url → GitHub repo

Examples

Example 1: Compliance Tracking

Threat Model Metadata:

compliance: PCI-DSS,SOC2
data-classification: highly-confidential
audit-frequency: quarterly
next-review: 2025-Q2

Threat Metadata:

control-id: PCI-6.5.1
compliance-requirement: PCI-DSS
verification-method: code-review

Example 2: Team Organization

Threat Model Metadata:

team: platform-team
product: payment-service
owner: [email protected]
technical-lead: [email protected]

Diagram Metadata:

subsystem: authentication
responsible-team: security-team
sla: 99.99%

Example 3: Workflow Integration

Threat Metadata:

jira-ticket: SEC-1234
status: in-progress
priority: P1
target-date: 2025-04-01
assigned-to: security-team

Metadata Schema (Recommended)

Define a standard schema for your organization:

# TMI Metadata Schema

## Threat Model Level

- `owner`: Team or person responsible
- `compliance`: Applicable compliance frameworks
- `environment`: dev, staging, production
- `data-classification`: public, internal, confidential, restricted

## Threat Level

- `priority`: P0, P1, P2, P3
- `control-id`: Reference to control framework
- `jira-ticket`: Jira ticket ID
- `assigned-to`: Responsible party

## Diagram Level

- `subsystem`: Which subsystem this represents
- `level`: Context, L0, L1, L2
- `review-status`: draft, in-review, approved

Future Enhancements

Potential future features:

  • Metadata validation and schemas
  • Required metadata fields
  • Metadata templates
  • Bulk metadata updates
  • Metadata inheritance

Next Steps

Related Topics

Clone this wiki locally