How ThreatMap works

Customer impact metrics

The portal dashboard shows attributable successful IOC lookups, estimated analyst hours, recorded automation-rule detections and monetary savings availability. Counts disclose partial history and exclude uncertain records. The approved time assumption compares 15 minutes of manual source queries with 30 seconds using ThreatMap: 14.5 estimated minutes saved per eligible lookup, not a latency guarantee. Monetary savings remain unavailable without a comparable customer cost basis. Notification retries do not multiply detection counts.

One lookup, shared execution

1. Authenticate the session or API key and resolve current account state.
2. Validate a single IOC; enforce email verification, scope, plan, rate, and credits.
3. Select configured, enabled, applicable providers using user preferences and BYOK.
4. Use eligible cached results; call providers with bounded fan-out deadlines.
5. Normalize source context and native reputation, preserving failed/skipped statuses.
6. Build the aggregate, settle credits, and return data with attribution and metadata.

BYOK-derived results are private to the caller and bypass shared caches. Platform-only provider results remain eligible for shared caching. Fresh cached evidence remains available when the upstream circuit is open. Fan-out cancellation bounds provider and cache waits; authentication and credit processing have separate timing. Each running server limits simultaneous calls to one source. When it reaches that limit, the source is reported unavailable for that request while other sources can still answer. A cache-storage problem does not discard a successful source answer.

Mandiant is a planned source without an active adapter. Earlier cached aggregate results involving that integration are recomputed through supported providers.

Source reputation and aggregate score

Provider-native reputation remains attributable to that provider. Supported native numeric values are normalized and combined using reliability weights. Context-only data does not acquire an invented per-provider score. Missing reputation remains absent; successful context without numeric risk can produce a clean-consensus aggregate fallback.

ThreatMap aggregate bands are clean (0–20), suspicious (21–40), malicious (41–70), and critical (71–100). Review source evidence alongside the summary; a clean score is not a guarantee that an IOC is safe.

Storage and background work

RelataDB stores application records through its HTTP APIs. Security-critical writes require synchronous confirmation. Production shared session state and durable monitor queues require the configured Redis protocol endpoint. Credit operations use a durable Redis ledger and balance projection, with audit copies reconciled into RelataDB.

Monitor checks acknowledge queued work with 202 and a run ID. Workers record progress and deliver configured email, webhook, or Slack alerts asynchronously.

IOC and CVE lookups have a 30-second request deadline. A timed-out lookup returns a 504 error, and an unsettled credit reservation is refunded.

REST and MCP

Stdio and HTTP MCP proxy REST execution, sharing authorization, provider behavior, and charging. HTTP discovery and execution require credentials; stdio discovery is local, while execution needs an API key. BYOK removes source surcharges, not the base search credit. Latency and availability vary with provider and deployment health; no fixed sub-second guarantee applies.