Fitting in
The pull request gate
A step in the pipeline asks your server whether a change may merge, and the answer is pass, warn or fail under one policy for the whole estate.
Only what the change added
The server reviews the files a pull request touched at the merge base and at the head, and maps every line across the diff. Code that moved, a renamed file, or an old line somebody edited stays old. A gate that fails on the backlog fails every build on the first day and is switched off by the second, so the backlog is the nightly scan's to report and the gate never mentions it.
The history inside the change
A credential added in one commit and deleted in the next leaves a clean final diff and a key in the history. The gate reads the commits in between, so it is still found.
One policy, in a file
A live credential, code two engines agree is high or worse, a malicious package, a known exploited or reachable critical dependency, public storage, an admin port open to the world, a privileged container, untrusted input in a workflow step. Each category names the rule ids behind it, each one checked against a file that should trigger it. Every run records the policy version and a hash of the file, so a blocked pull request can always be traced to the rule that blocked it.
Monitor first
Every repository starts in monitor mode: a run that would have failed passes with a warning and records that it would have blocked. Switch a repository to enforce when the would-be blocks are ones you agree with. A workflow can make its own check stricter and never laxer, because anybody who can push can edit a workflow file.
Your decisions travel with it
An approved waiver lets its own finding through and nothing else, and an expired one covers nothing. Learned rules lower a new finding the same way they lower an old one. The gate keys findings the same way the web app does, so a decision made there is a decision here.
The build agent needs almost nothing
The client is one bash script, with curl, jq and git. The server fetches the commits itself, with the credential its scans already use, into a mirror it keeps for each repository, so a pull request from a fork works the same way and nothing is uploaded. If the server cannot be reached, the client still checks the change for credentials with gitleaks and fails on one it finds.
Still read only
No finding is filed, no comment is posted, and nothing is written to the code host. The pipeline uploads the SARIF of new findings with its own token, and branch protection does the holding.
What it does not do
You add the workflow and make it a required check yourself; there is a GitHub Actions template and nothing to install on the host. GitLab, Azure Pipelines and Jenkins are read by the client, with no template yet. There is no page for the would-be blocks yet, so in monitor mode they are read from the audit log. The policy is a file in the data volume rather than a settings page. A run is stopped at five minutes, and on a server that has never run a scan the first one spends most of that downloading the vulnerability databases.
Every feature page carries one of those. The comparison page scores the same ground against five products people pay for, including the rows that go against us.