One graph for your operations.
Controls, risks, findings, vendors, contracts and audits are rows in one PostgreSQL schema with foreign keys between them. The modules your team uses are views onto that schema, not separate products synced overnight.
One graph, many surfaces
207 data models in one schema. A control links to the risks it treats, the policies that state it, the vendors it depends on and the findings that threaten it. Modules are views that read and write the same rows, not separate tools federated by name.
Workflows on live state
Approvals, reviews, retests and remediation run against current records. Each tenant sets a fix-action policy for remediation: auto, confirm, or never.
Integrations, stated plainly
AWS, Microsoft 365 and Entra ID, Jira, Confluence, Slack and Salesforce are exercised against real systems. Splunk, Sentinel, Okta, ServiceNow, Tenable, Qualys and Rapid7 connectors are built and switch on with credentials. Most connectors read. Slack notifications and the ServiceNow and Freshservice ticket sync write back.
AI in the workflow
A teammate per tenant with memory, streaming chat that cites findings, audit-pack drafts, auditor-email replies a person approves before they send, and an 8-page board report. You pick the model: Anthropic by default, Ollama, or any OpenAI-compatible endpoint.
Security and audit trail
Per-tenant OIDC SSO with presets for Entra ID and Google, RBAC, CSRF protection and rate limiting. Audit events are hash-chained with SHA-256, so tampering shows. The first admin comes from a single-use setup token; no default password ships.
Your data, your stack
Each customer runs its own container service and its own Postgres database on AWS. Isolation is at the stack, not a tenant column. Exports are CSV. An air-gapped mode pairs with a local model.
Questions the schema answers.
Each is a join or a graph path query across tables in the same database, not an export stitched from six tools.
- Which findings reach a SOC 2 requirement, and through which asset and control?
- Which controls are affected by a finding on the CISA KEV list?
- Which engines can detect CVE-2021-44228, and with how many detectors?
- Which vendors have documents expiring this quarter?
- Which external auditors can see which audits right now?
- What did our compliance posture look like 30 days ago?
Thirteen scan engines, one dispatch path.
A scan plan fans out to one isolated container task per engine. Results come back over an HMAC-signed ingest, severities normalize to five levels, and every finding gets an EPSS exploit probability and its CISA KEV status. Feed snapshots are cached, so a feed outage doesn’t change scores mid-run. Up to 10 scan tasks run at once per tenant; failed jobs retry, then dead-letter.
| Engine | What it finds | Runs |
|---|---|---|
| nuclei | Known CVEs, exposed panels, misconfigurations on web targets | built in |
| trivy | CVEs in container images, filesystems and IaC | built in |
| prowler | Cloud posture checks for AWS, Azure and GCP | built in |
| nmap | Open ports and service versions | built in |
| openscap | SCAP benchmark compliance on hosts | built in |
| lynis | Host hardening gaps | built in |
| zap | Web application DAST findings | built in |
| nikto | Web server misconfigurations and missing security headers | built in |
| kube-bench | CIS Kubernetes benchmark failures | built in |
| openvas | Network vulnerability scanning | needs your service |
| wazuh | Host agent alerts and vulnerability data | needs your service |
| bloodhound | Active Directory attack paths | needs your service |
| falco | Runtime security events from containers | needs your service |
Detection catalog
12,958 nuclei templates and 1,306 prowler checks, indexed at boot by content hash. Ask which engines can catch a CVE: Log4Shell has 44 nuclei detectors.
Plan-driven scans
Pick a policy (KEV-only, critical-only, CIS, by tag, or custom) and the planner resolves the exact detectors. KEV-only resolves to 479; critical-only to 1,856.
Cross-engine correlation
The same issue found by two engines on one asset becomes one fused finding with both sources shown. Assets merge across engines behind a confidence gate.
Risk-narrative graph
Assets, findings, controls and framework requirements are edges in one graph. A recursive path query answers how a finding reaches a requirement, and every finding carries the controls it affects.
One run, recorded.
On 3 May 2026 we ran every engine against a demo tenant in one 12-minute pass and wrote down what happened.
Read the full runengines passed
failed
skipped: need your service
findings persisted end to end
All 81 severities normalized to the canonical five. The run surfaced 13 bugs (10 in the platform, 3 in engine adapters), and all 13 were fixed. The four skipped engines are the ones that need a backing service you run.
What it doesn’t do yet.
If you’re evaluating opsnite, you should know these before the first call, not after the contract.
- OpenVAS, Wazuh and BloodHound need a backing service you run. The adapters are certified; we don’t host the services.
- The BloodHound adapter enumerates attack paths but doesn’t score them for risk ranking yet.
- Falco has only been validated against a stub event source.
- Scans dispatch when you run a plan. Cron-style scheduling is on the roadmap.
- Splunk, Sentinel, Okta, SailPoint, ServiceNow, Freshservice, Tenable, Qualys and Rapid7 connectors are built but haven’t run against a live customer system.
- The framework catalog is requirement IDs and titles, not written control narratives.
- No SCIM, no in-product e-signature, no Word redlining, no Parquet export.
- The calendar exports .ics; it doesn’t push into Google or Outlook.
- The auditor-email autopilot takes a pasted email. It doesn’t read a mailbox.
- opsnite itself has no external audit report yet.
Want a deeper architecture walkthrough?
Send us your use case and we’ll walk through how the data model handles it on a call.