T
Security & trust

How terep thinks about security

terep is designed as a security‑first, API‑driven backend for teams running modern threat modeling and STRIDE analysis workflows.

Platform overview

terep focuses on ingesting Data Flow Diagrams (DFDs), building a System Knowledge Graph (SKG), and running a rule‑based STRIDE engine. The platform is designed to minimize the data it needs in order to provide useful, versioned threat models that engineering and security teams can automate and review.

  • • API‑first backend that lets you define systems, ingest DFD JSON and generate STRIDE threats on demand.
  • • SKG and threat snapshots structured to support audit‑friendly history, diffs and visualizations.
  • • Role‑based access model and JWT‑based auth to align terep access with your internal policies.

Data model and threat modeling context

At its core, terep stores systems, DFD snapshots, SKG views and threat model snapshots. Customers typically ingest architecture and configuration data that is already documented elsewhere and want a consistent way to reason about risk over time.

  • • DFDs describe trust zones, nodes and flows rather than raw traffic or production logs.
  • • Threat snapshots store structured STRIDE findings associated with systems and DFD versions.
  • • SKG and Mermaid exports are designed for reviews, documentation and collaboration around architecture and risk.

Security controls (illustrative)

The implementation details below are representative of a security‑focused SaaS backend and should be validated through your own due‑diligence process.

  • • Encryption in transit using modern TLS configurations.
  • • Encryption at rest for customer data using cloud‑native key management.
  • • Segregated environments for development, staging and production.
  • • Strong authentication with JWTs and support for role‑based access control in the backend.
  • • Scoped API tokens or service accounts for CI/CD and automation use‑cases.
  • • Change management and peer review across infrastructure and application code.

Data protection & privacy

terep is intended to support customers' obligations under common privacy and data protection frameworks (for example, GDPR) when terep is used to process personal data as part of architecture and threat modeling activities. Exact responsibilities are governed by the agreement between terep and each customer.

  • • Data Processing Addendum (DPA) describing roles and responsibilities where terep acts as a processor or service provider.
  • • Configurable data retention approaches aligned with your internal standards and regulatory needs.
  • • Support for regional hosting and residency discussions, where available.
  • • Logical separation of customer workspaces and data boundaries.

Compliance posture (illustrative)

The terep product is positioned to support customers who operate under frameworks such as SOC 2, ISO 27001 and similar regional regulations. The exact certification status of any production deployment should be confirmed through the sales and legal process.

  • • Focus on audit‑ready logging around DFD ingestion, threat model generation and version history.
  • • Controls expected to map to common trust service criteria for security and availability.
  • • Export capabilities designed to help evidence modeling activity and review workflows.

Incident response & vulnerability reporting

If you believe you have identified a security issue with terep, we encourage responsible disclosure.

  • • Use the security contact details referenced in your customer agreement or, for this demo site, the Support form.
  • • Avoid sending exploit details through general contact forms; a secure channel can be coordinated as needed.
  • • terep intends to follow a documented incident response plan, including triage, containment and customer notification where appropriate.

Shared responsibility

Operating a secure threat modeling program is a shared responsibility between terep and each customer.

  • • terep manages the security of the platform and underlying infrastructure.
  • • Customers manage who they grant access to, how they configure systems and DFD ingestion, and how threats are triaged and remediated.
  • • Customers remain responsible for complying with their own regulatory and contractual obligations.

This Security & Trust page is illustrative marketing copy for terep and does not constitute legal advice, a binding security commitment or a complete description of controls. Any production deployment should be accompanied by formal documentation and contractual terms.