Every surface, one graph
Most security platforms are one surface with a marketing department. This is thirteen, and the reason they are in one product is that the failure you care about happens between them.
Every figure, with the command that counts it
how these are countedEvery figure above is reproducible from the source
- 32 security domains
find src/domains -maxdepth 1 -type d ! -path src/domains | wc -lThe old site said 30+; 32 is the real count. - 600+ detection engines
find src -name '*.engine.ts' | wc -l → 622Rounded down from 622 engine files, which include a few stubs. - 609 behavioural detections
grep -rhoE 'id: *"RULE-[A-Za-z0-9-]+"' src/correlation/rules/behavioral | sort -u | wc -lThe old site said 610. Corrected to 609. - 75 correlation rules across two tiers
tier1Rules (34) + tier2Rules (41) registration arrays, counted at runtime because both spread rule packs - 166 typed signals on the bus
SignalType union in src/shared/signals/types.ts - 96 MITRE ATT&CK techniques mapped
grep -rhoE '"T[0-9]{4}(\.[0-9]{3})?"' src/correlation/rules/behavioral | sort -u | wc -lThe old site said 48 — that was an undercount. 122 across all correlation rules, behavioural and both tiers. - 368 AWS service checks registered
AWS_ENGINES in register-aws-engines.ts — 368 unique capability keysWas 366 until the October-2026 defence work wired llmjacking and acm-transparency-audit. - 77 Azure service checks registered
AZURE_ENGINES in register-azure-engines.ts — explicitly wired enginesCapabilities without an explicit engine fall back to createAzureCapabilityEngine, so 77 is the hand-written set, not the reachable set. - 77 GCP service checks registered
GCP_ENGINES in register-gcp-engines.ts — explicitly wired enginesSame fallback as Azure: createGcpCapabilityEngine covers the rest. - 4 CI/CD providers with live feedback
src/domains/supply-chain/ci-provider-feedback.ts — GitHub, GitLab, CircleCI, Jenkins - 7 compliance frameworks with evidence engines
compliance/{soc2,iso27001,hipaa,pci-dss,gdpr,nist800}.engine.ts + EU AI Act controlsThe old site claimed 8 by counting CIS and FedRAMP; neither has an engine. CIS lives in behavioural rule packs instead. - 68 queue workers
find src/queue/workers -name '*.ts' | wc -l - 0 bytes of your telemetry leave your account
docker-compose.selfhost.yml — every datastore runs in your stack - 0 LLMs anywhere in the detection or scoring path
Only two LLM call sites exist: src/domains/governance/ai-advisor.ts:127,149 — no engine imports it
Nothing on this page is a rounded-up number. Where a count is in flux the figure is the conservative one, and the caveat is shown above next to its command.
How the surface is organised
There are five stages and they are strictly ordered. A collector that produces something the normaliser cannot type does not ship; an engine that wants to alert directly rather than emit a signal does not exist.
| Stage | What happens | What it produces |
|---|---|---|
| Collect | Read-only APIs, webhooks and CI callbacks pull inventory, configuration and events. | Raw provider payloads |
| Normalise | Everything is coerced into one of 166 typed signals with resource, principal, account and confidence attached. | AtomicSignal |
| Detect | Tier-1 rules evaluate one signal against history and context. 609 behavioural detections. | Annotated findings |
| Correlate | Tier-2 rules join signals from different providers inside a declared window. 75 rules in total. | CompoundRisk with a score |
| Respond | Remediation routes to a tracker, a pager or a forge check run; evidence stays attached. | Jira, ServiceNow, XSOAR, PagerDuty, Slack, GitHub |
The 68 queue workers behind that pipeline are ordinary jobs in your own Redis. Nothing about the pipeline is hosted, which is why the same architecture runs in a namespace with no egress.
Cloud and infrastructure
| Surface | What is collected | Registered checks |
|---|---|---|
| AWS | IAM, S3, EC2, VPC, Lambda, RDS, EKS, KMS, CloudTrail, GuardDuty findings, ECR | 368 |
| Azure | Entra ID objects, subscriptions, NSGs, storage, AKS, Key Vault, activity logs | 77 |
| GCP | IAM, projects, VPC firewall, GKE, Cloud Storage, KMS, audit logs | 77 |
| Kubernetes | Workloads, service accounts, RBAC bindings, admission posture, image provenance | — |
| Containers and images | Base-image age, known CVEs, registry provenance, drift from the declared image | — |
Oracle Cloud is deliberately absent. It exists in the codebase as stubs and is not supported, which is a sentence we would rather write here than have you discover during an evaluation.
Identity, human and non-human
Identity is 66 engines and the largest domain after infrastructure for a reason: this is where privilege actually accumulates, and where the difference between "granted" and "used" lives.
| Surface | What is collected |
|---|---|
| Cloud identities | Users, roles, service accounts, trust policies, permission boundaries, unused grants |
| Workforce identity | Okta, Microsoft Entra ID, Microsoft 365, Google Workspace, LDAP — group membership and privilege paths |
| Non-human identity | API keys, CI credentials, OIDC trust, key age and rotation, first-use history |
| Access graph | Which principal resolves to which resource, and how many assumption hops separate it from a crown jewel |
| Authorisation inside Hanu | 6 RBAC roles: OWNER, ADMIN, SECURITY_ENGINEER, ANALYST, DEVELOPER, VIEWER |
Code, application and supply chain
| Surface | What is collected |
|---|---|
| Repositories | GitHub, GitLab — history, branches, protection rules, contributors, exposure of secrets in history |
| CI/CD | GitHub Actions, GitLab CI, CircleCI, Jenkins — workflow changes, action pinning, actor identity, runner configuration |
| Dependencies | SBOM, resolver output, release freshness, publisher identity, provenance attestations |
| Static analysis | Semgrep findings; Snyk and Trivy results ingested rather than re-scanned |
| Containers and IaC | Image composition, IaC scan results, drift between declared and deployed infrastructure |
| Application surface | API inventory, endpoint exposure, web application posture, ASPM correlation of code to runtime |
The reason these sit in one product rather than four is the same in every case: a repository holding a deploy credential, a workflow that was edited, and a credential that then became readable are three facts from one system, and the judgement lives in the conjunction.
Runtime, network and edge
| Surface | What is collected |
|---|---|
| Runtime and endpoint | CrowdStrike and SentinelOne detections, process and agent telemetry, workload drift |
| Network | VPC flow, security groups, exposure of services, egress destinations, network policy drift |
| Edge security | CDN and WAF configuration, TLS termination, header posture |
| Authentication posture and domain hygiene | |
| Network and malware signals | Ingested detections joined against cloud and identity context rather than queued separately |
AI workloads, agents and the model supply chain
This is the newest surface and the one with the least mature tooling across the industry, so it is worth being precise about what is actually collected: metadata about access and reach, never inference content.
| Surface | What is collected |
|---|---|
| Model access | Which identity can invoke which models — Bedrock, SageMaker and the Azure and GCP equivalents — from where |
| LLMjacking | First-use credential validation, model enumeration and invocation as ordered stages inside a window |
| Model posture | Endpoint configuration, network exposure, logging posture, data reach of the identity that owns the endpoint |
| Agents | Agent identities, the tools and data they resolve to, first-use reach against sensitive resources |
| MCP servers | Registered servers, ownership, served tool definitions over time and what a change broadened |
| Shadow AI | Model endpoints and AI services present in the estate that appear in no inventory |
Data and cryptographic posture
| Surface | What is collected |
|---|---|
| Data stores | Object storage exposure, database posture, encryption at rest and in transit, backup configuration |
| Data classification | Which findings touch personal, financial or otherwise regulated data, so sensitivity can weight a score |
| Certificates | Certificate transparency, expiry, key strength, issuer reputation and whether the issuer is still trusted |
| Keys and secrets | KMS key policies, rotation state, key material provenance, secrets exposed outside the vault |
| Cryptographic inventory | Where weak primitives are still in use, and which workloads depend on a key that should not exist |
Certificate and issuer tracking is what made the eMudhra emSign hierarchy in October 2026 answerable rather than merely alarming: eight intermediate certificates were withdrawn after a ceremony flaw left their keys recoverable, the root above them was dropped from the public trust bundles, and a platform that models issuers as supply-chain dependencies can tell you which of your own certificates came through either. The two cases are scored differently — a compromised intermediate means someone else can prove they are you, a removed root means your chain stops validating — and both entries record identifierQuality: "name-pattern", so nobody mistakes a name match for a fingerprint match.
Compliance and governance
| Framework | What the evidence engine produces |
|---|---|
| SOC 2 | Control-to-finding mapping across the trust services criteria, from live findings |
| ISO 27001 | Annex A control evidence with the finding ids that satisfy each |
| HIPAA | Safeguard evidence mapped to technical controls |
| PCI DSS | Requirement evidence for the controls the platform can observe |
| GDPR | Data-handling and access control evidence |
| NIST 800 | Control family evidence from the same findings the team works from |
| EU AI Act | Controls for AI systems and the data they touch |
Governance engines sit alongside: policy documents as first-class objects, AI system registration, and reporting that a CISO can hand upward without re-keying numbers into a slide.
Response, operations and the operator console
| Capability | Detail |
|---|---|
| Outlets | Jira, ServiceNow, Cortex XSOAR, PagerDuty, Slack, or a Splunk or Datadog pipeline |
| Developer feedback | Check runs and job steps in the forge — GitHub, GitLab, CircleCI, Jenkins |
| Remediation | Proposed pull requests where a mechanical fix exists, with the finding attached |
| Case management | Findings, risks, remediations, activity and a per-tenant audit log |
| Operator console | Separate surface for running multi-tenant deployments — tenant lifecycle, configuration, operators |
| Reporting | CISO reports and coverage views generated from the same findings, not from a parallel data entry process |
24 provider integration modules exist under src/integrations/providers. That is a module count rather than a certification count, so the list above names the ones worth naming instead of leaning on a number.
What is not here
This section exists because a capabilities page without one is a page you should not trust.
- Oracle Cloud. Stub engines only. Not supported, and not presented as supported.
- No SIEM. There is no event store to query arbitrary time ranges against, no custom query language and no log retention product. Response routing hands work to the systems you already run.
- No cloud-native runtime agent. Endpoint and runtime detections are ingested from CrowdStrike and SentinelOne rather than collected by an agent we ship.
- No Wiz, Jamf, Rapid7, Sumo Logic or Intune integration. No provider module exists for any of them.
- No SCIM provisioning. Zero hits for SCIM in the source tree. Identity inside Hanu is managed in Hanu, or through SSO/SAML on the editions that include it.
- No CIS or FedRAMP compliance engine. CIS is delivered as behavioural rule packs; FedRAMP appears as remediation text only.
- No automatic remediation. Proposed pull requests and routed tickets, yes. Something that changes production on its own, no.
- No prompt or inference content. The AI surfaces collect access and reach metadata. Prompt text and completions are not read, stored or analysed.
Questions
How much of this is in the free Community edition?
Do I have to connect everything for it to be useful?
RULE-T2-014.Is the capability list the same across editions?
How do you avoid the false positives that come with this many checks?
Can we see the code?
What happens when a domain has a collector but no rule worth running?
Run it in your own account
One Docker Compose stack, your datastores, read-only credentials into your clouds. The Community edition is free to run in production.