Building ThreatWeaver: lessons from engineering a multi-tenant security platform

Security teams often operate multiple scanners, repositories, ticketing systems and reporting processes. Each tool may be useful, but the operating picture becomes fragmented: assets are duplicated, findings lack consistent ownership, risk context is scattered, remediation status is difficult to reconcile, and leadership reporting requires manual work.

ThreatWeaver was designed as a multi-tenant system of record that can ingest security data, normalize assets and findings, prioritize remediation, support application-security workflows, and produce governed technical and executive reporting.

This was not only a dashboard problem. The difficult engineering work sat underneath: tenant boundaries, changing source data, long-running integrations, risk enrichment, workflow state, evidence, permissions, AI safety and reproducible reporting.

In a multi-tenant security platform, adding a tenant identifier to a table is not enough. Isolation must be preserved through authentication, authorization, database access, background jobs, caches, file exports, dashboards, integrations and operational tooling.

The design principle is straightforward: every data access path should make tenant context explicit, enforce it close to the data, and remain testable. Privileged support and administrative workflows require their own controls, auditability and narrowly defined reasons for access.

This is also a product concern. Roles, client organizations, service teams and stakeholders need different views without creating hidden paths across tenant boundaries.

Scanner and repository integrations do not deliver perfectly stable records. Assets change identity, findings reappear, source fields evolve, syncs fail partway, and the same exposure may be described differently across systems.

ThreatWeaver’s ingestion approach preserves source context while normalizing information into tenant-scoped assets and findings. Streaming and background workflows need checkpoints, retries, idempotency, observability and clear failure states so operators can understand whether data is fresh and complete.

Active and fixed status should be the result of explainable reconciliation rules. Otherwise, the platform can create false progress or reopen work without enough evidence for users to trust it.

Severity alone does not tell a team what to fix first. ThreatWeaver combines established vulnerability signals such as CVSS, CISA KEV and EPSS with asset and workflow context to help organize remediation.

The engineering challenge is to keep prioritization explainable. Users need to understand why an item moved, which source contributed a signal, how an exception affects the result, and whether an SLA is approaching or already breached.

The product therefore connects risk to work: owners, campaigns, tickets, due dates, exceptions, evidence and validation. A score becomes valuable when it helps a team make and verify a remediation decision.

ThreatWeaver uses a tiered assistant for tasks such as fix planning, ticket text, summaries and root-cause analysis. The architecture is designed to answer many requests without an external language-model call and to ground generated assistance in governed security data.

Probabilistic output should not silently replace security truth. Scanner evidence, vulnerability records, workflow state, permissions, policy gates and compliance calculations remain deterministic. AI can explain, organize and propose; users still need traceability and controlled actions.

This separation improves reliability, privacy and cost control while making it clearer which parts of an answer are sourced facts and which are generated assistance.

Executive dashboards, compliance views, technical exports and remediation reports should not each invent their own version of risk. They need to derive from the same governed records, definitions and workflow state.

That means reporting requirements influence data modelling early. History, ownership, exceptions, evidence, control mappings and status transitions must be available before a reliable board view or audit export can exist.

Custom dashboards are useful, but flexibility needs guardrails so teams do not publish attractive charts whose numbers cannot be traced back to the underlying records.

• Treat tenant isolation as an architectural boundary across storage, authorization, jobs and reporting
• Preserve source evidence while normalizing assets and findings into a usable operating model
• Separate deterministic security logic from probabilistic AI assistance
• Design remediation workflows around ownership, SLAs, exceptions and verification—not dashboard counts
• Build executive reporting and technical workflows from the same governed source of truth
• Make integrations observable, resumable and safe to operate as data volume grows

Building an operational security product forces engineering and cybersecurity to meet in the same decisions. That is the model BluCypher brings to client software: experienced product engineering with security designed into architecture, delivery and operation.