🛡️ Trust Center

🏗️ Architecture Overview

ThreatMeld runs entirely on Microsoft Azure (East US 2 region) with Cloudflare providing edge security. Here's what's actually deployed:

🔒 Security Controls

🌍 Data Sovereignty

Where Your Data Lives

All customer data is stored within Microsoft Azure's East US 2 region (Virginia, United States):

• Application database — Azure Cosmos DB (East US 2) with continuous 7-day PITR
• Secrets & keys — Azure Key Vault (East US 2)
• Message queues — Azure Service Bus (East US 2)
• Application logs — Azure Log Analytics / Application Insights (East US 2)
• Security monitoring — Microsoft Sentinel (East US 2)

Credential Storage Architecture

Credentials and sensitive data follow strict separation of concerns:

• Authentication tokens & keys — WorkOS AuthKit (managed identity provider)
• Application data — Azure Cosmos DB (encrypted at rest, partition-isolated)
• Application secrets — Azure Key Vault (HSM-backed, access-policy-controlled)

Data Residency Guarantees

• Customer data (tenant configurations, product subscriptions, triage decisions, user accounts) never leaves the Azure East US 2 region for storage.
• Advisory data (CVEs, vendor bulletins) is sourced from publicly available feeds (NVD, vendor RSS/CSAF, CISA KEV) and stored within our infrastructure.
• DNS and CDN edge caching is provided by Cloudflare — only static assets are cached at edge; no customer data is stored in Cloudflare.

Data Classification

🧪 Testing & Security Audits

Validated through automated testing, CI/CD security scanning, and independent adversarial audit:

• Shannon AI adversarial pentest (April 14, 2026) — 2h10m engagement, 185 endpoints across 36 route files. Findings: 4 Critical + 7 High + 6 Medium. All 17 remediated and re-verified in PR #699, #713, #714. Scope covered stored XSS via vendor feeds, cross-tenant review queue access, session persistence on logout, privilege escalation, SSRF (DNS rebinding + IPv4-mapped IPv6 bypass), open redirect, user enumeration, SCIM token hash strength.
• 2,182 automated tests — 5-layer AAA framework (config · API via TestClient · E2E browser · smoke · deployed-bundle secret scanning) run on every commit via GitHub Actions CI/CD.
• 135 CodeQL alerts resolved — log injection (77), XML bomb, stack-trace exposure, XSS, sensitive data in logs, across PRs #687–#691.
• CI/CD security pipeline — four tools currently gate every build: pip-audit (Python dependencies), npm audit (JavaScript dependencies), Semgrep SAST (code-level static analysis), and CodeQL (GitHub's semantic analysis, Python + JS/TS). Build fails on high/critical findings. Planned additions: Gitleaks (secret scanning in-repo) and Socket.dev (supply-chain reputation).
• GitHub Actions supply-chain pinning — 9 third-party actions pinned to commit SHAs (#690) to prevent tag-squatting attacks.
• Input sanitization — defense-in-depth layer covers prompt injection, XSS, SQL injection fragment detection, shell metacharacter filtering, invisible Unicode removal, URL protocol allowlist; applied at frontend (sanitizeUrl) and ingestion (base_fetcher.py URL validation).
• Secret management — no hardcoded secrets; all secrets sourced from environment variables and Azure Key Vault (RBAC-based access, 90-day soft-delete, purge protection). HAR files with auth tokens purged from repo history (#686).

Infrastructure as Code

All Azure infrastructure is defined in Bicep IaC templates — Cosmos DB, Key Vault, Functions (API + Background), Service Bus, Static Web Apps, and Application Insights. No manual Azure portal configuration.

📡 Reliability & Data Freshness

Security intelligence that is hours stale is worse than useless — it creates a false sense of coverage. v0.10.1 introduced a multi-layer reliability pattern to ensure enrichment failures surface within an hour, not days.

Enrichment pipeline observability

• Heartbeat pattern (#719) — the daily refresh job writes a timestamp and per-source status (ok / empty / failed) to the enrichment_metadata container via a try/finally, so a partial failure is never silent.
• Public freshness endpoint — GET /api/enrichment/public/status exposes last_attempt_at, overall_status, and per_source.{epss, kev, vulncheck_kev} with entry counts and hours-since-update. Customers and external monitoring tools can poll this without authentication.
• Automated health check workflow — a GitHub Actions workflow runs twice daily (08:00 and 20:00 UTC) against the public endpoint, classifies staleness into four failure modes, auto-triggers the recovery job, and files a GitHub issue on persistent staleness.
• SDK log quieting (#724) — Azure Cosmos, Service Bus, urllib3, httpx, msal, and msrest loggers are pinned at WARNING level regardless of the application log level, so application telemetry is never drowned by vendored SDK chatter during an incident.

What we track

Data freshness is best-effort against upstream source availability. If a vendor feed is down, our status endpoint surfaces that — we do not fall back to stale data silently.

🛡️ Live Security Scan Results

Every deployment to production passes through 9 automated security checks (8 CI-gated + 1 periodic independent adversarial pentest). These results update with each successful release — what you see below reflects exactly what is running in production right now.

How this works: Our CI/CD pipeline runs all security checks on every code change. If any check fails, the deployment is blocked — code never reaches production with known vulnerabilities. This page auto-updates only on successful deployments, so these results always match what's live. View our CI/CD pipeline →

💳 Billing & Payments

Stripe handles all payment processing. ThreatMeld never sees, stores, or processes payment card numbers.

• Stripe is PCI DSS Level 1 certified — the highest level of payment security compliance.
• Tenant isolation enforced via metadata namespacing — each Stripe subscription is tied to its ThreatMeld tenant ID.
• Webhook signature verification is mandatory. If the webhook secret is not configured, all webhook requests are rejected (no silent bypass).
• Plan tiers: Free ($0), Standard ($25/mo), Pro ($50/mo), Team ($250/mo, 10 users) — each with enforced resource limits (users, products, vendors, API calls).

🏢 Data Processors & Subprocessors

Third-party services that process data on behalf of ThreatMeld. All are contractually bound to data protection obligations.

Infrastructure Processors

Application Processors

Data Source Providers (Not Processors)

Public data sources that ThreatMeld ingests. No customer data flows to these sources — we only read from them.

🚫 What We Don't Do

• We don't sell customer data. Ever. To anyone.
• We don't use customer data for model training. The AI remediation feature sends only public advisory content — never customer configurations, subscriptions, or triage decisions.
• We don't store payment card numbers. All payment processing is handled by Stripe (PCI DSS Level 1). Card details never touch our servers.
• We don't store passwords. Authentication is handled entirely by WorkOS AuthKit. We don't have a password database.
• We don't require device inventory. ThreatMeld tracks vendor/product subscriptions — you tell us what products you care about. No network scanning, no agents, no IP addresses required.
• We don't share data across tenants. Strict tenant isolation via Cosmos DB partition keys — each customer's data is partitioned and inaccessible to other tenants.
• We don't use tracking cookies. Zero first-party cookies. MSAL authentication tokens are stored in localStorage, not cookies. The only cookie present is Cloudflare __cf_bm (bot management, strictly necessary, exempt from consent requirements). No third-party analytics, no advertising pixels, no behavioral tracking. See our Cookie Policy for full details.
• We don't hardcode secrets. All application secrets are sourced from Azure Key Vault or environment variables. Zero secrets in source code — enforced by CI/CD static analysis scanning.

📋 Compliance Status

🚨 Incident Response

In the event of a security incident affecting customer data:

• Notification within 72 hours of confirmed breach to affected customers via email.
• Public disclosure on this trust page for incidents affecting multiple customers.
• Root cause analysis published within 30 days of resolution.

Report a Vulnerability

If you discover a security vulnerability in ThreatMeld, please report it to [email protected]. We commit to acknowledging reports within 24 hours and providing an initial assessment within 72 hours.

📬 Contact

For questions about data handling, privacy, or compliance:

• Security: [email protected]
• Privacy: [email protected]
• General: [email protected]

ThreatMeld is operated by RedEye AI Labs
Phoenix, AZ, United States