Skip to content
HANU
Deploy Hanu
Menu

By role

CTOs and engineering leaders

Security that shows up as a failing check on a pull request is a security programme engineers will tolerate. One that shows up as a ticket queue is one they will route around.

security platform for CTOssecurity in the CI pipelineshift left security platform

What changes

Findings arrive where the code is — as check runs and pull requests in the forge the team already uses — and correlation runs before the merge rather than after the incident review.

It has to be in the pull request, not beside it

Remediation is pushed back as a GitHub check run, a GitLab job, or a CircleCI/Jenkins step. A developer sees the finding on the diff, in context, at the moment they can still act on it cheaply.

Correlation belongs before the merge

An unpinned third-party action is not a finding on its own. It becomes one when the same workflow also handles a deploy credential. That reasoning is available as a PR gate, so the cheap fix happens before release.

You should know exactly what leaves

The stack runs in your account with its own datastores. There is no Hanu-hosted control plane, no usage ping and no licence callout. That is a sentence you can put in a customer security questionnaire without a caveat.

A reasonable first fortnight

Not a migration plan — the first two weeks, in the order that produces something useful fastest.

  1. Connect GitHub or GitLab and enable the pull-request gate on one repository that matters.
  2. Read the correlation rules that fire on the gate so you can defend the signal-to-noise ratio to the team.
  3. Attach read-only cloud roles and let the first full scan run overnight.
  4. Pick the two highest-scoring compound risks and hand them to the owning team as normal backlog work.

Questions this role tends to ask

Will this slow down our pull requests?
The gate is opt-in per repository, and the rule set that runs on a pull request is the correlation set, not the full org scan. You choose which repositories gate and which only report. Nothing blocks a merge until you decide it should.
How do findings reach engineers?
As a GitHub check run on the commit, a GitLab job, or a CircleCI or Jenkins step. The finding appears on the diff with the rule, the score and the contributing signals, so the developer can judge it without opening a security console. Fixes are proposed as a pull request where a mechanical fix is possible.
What exactly leaves our infrastructure?
Nothing. The self-host stack contains its own datastores, there is no Hanu-hosted control plane, no usage telemetry and no licence server callout. Outbound traffic is limited to the cloud provider APIs and forges you configured read-only.
Can I explain the score to my board without a security background?
The score is arithmetic: a severity base, a bounded increment per additional signal, and multipliers for public exposure, crown-jewel reach and known-exploited status. The risk carries every contributing signal and the rule that fired, so the explanation is the evidence list rather than an assertion.

What it is not

Hanu is not a SIEM and does not try to be one — it correlates and hands the result to the response process you already run. It is not a certified SOC 2 Type II service for self-hosted customers; the evidence engines and audit trail support your own controls. And it does not cover Oracle Cloud, which exists in the codebase as stubs only.

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.

Deploy HanuSee what is paid