The short version. Clone, analyse, report. The engine reads your repository — including its history — for exposed secrets, vulnerable dependencies, insecure infrastructure-as-code and unsafe CI/CD configuration. It never pushes, never opens a pull request, and never writes anything back.
What this engine does
Secrets in git are the clearest example of why history matters: a credential removed in the current commit is still readable to anyone who clones. Public-commit research has reported roughly 10 million new secrets exposed in a single year, with detections up 67% year over year (Jit, 2026). A scan of the working tree alone misses all of it.
- Secrets across git history — API keys, tokens, private keys and credentials in past commits, not just the current tree.
- Dependency risk with an SBOM — known-vulnerable packages, including transitive ones, with the path that pulls them in.
- Infrastructure as code — Terraform, CloudFormation, Kubernetes manifests and Dockerfiles checked for misconfiguration.
- CI/CD configuration — over-permissive workflow permissions, unpinned third-party actions, secrets exposed to untrusted triggers.
- Static analysis of application code — injection, unsafe deserialisation, weak cryptography and authorisation gaps at the source level.
What it deliberately does not do
This engine is read-only by construction. It holds a token to your source, so the boundaries are strict:
- No writes of any kind. No commits, no branches, no pull requests, no issues, no comments.
- No use of your token beyond the clone. The token is scoped to reading the repository you named and is not stored in our database.
- No exploitation. Findings are established by reading code and configuration, never by running the application.
- No third-party repositories. You must be authorised for the repository you submit.
- No retention of your source. The clone lives in the scan workspace and is destroyed when the run finishes.
How we prove you are allowed to run it
Authorisation is a hard gate, not a checkbox in our terms. A scan starts only if the asset is verified by Domain Control Verification — you place a DNS TXT record or a file we specify — or you supply an explicit legal-authority attestation stating you own the target or are authorised to test it. A request carrying neither is refused with HTTP 403, at every tier, with no override. For repositories the proof is possession of a token that can read them, plus your attestation that you are authorised — a private repository cannot be DCV-verified the way a domain can.
Where your data goes, and when it is deleted
Everything runs on EU infrastructure: edge functions in EU regions, scan compute in Frankfurt, object storage under EU jurisdiction, model inference through an EU endpoint. Nothing is used to train any model — ours or a third party's — and that is a contractual term in the DPA, which every plan gets.
- The report — kept two years, so you can hand it to an auditor next year.
- Raw uploaded material — third-party scanner files 30 days, application binaries 60 days, then deleted automatically.
- The anonymous homepage preview — content erased after 24 hours.
- The authorisation record — kept, because it is the evidence that the scan was permitted.
The full schedule is in our Privacy Policy, and the sub-processor list is on the Trust Center.
How a run actually works
The repository is cloned into an isolated workspace on an EU machine. Deterministic tooling does the mechanical work — history walking, dependency resolution, IaC parsing — and the agents interpret, deduplicate and prioritise what it produces. That split matters: a model deciding whether a string is a live credential is guessing, while a scan that verifies the pattern and the entropy is not.
When the run ends the workspace is deleted, source included. What remains is the report.
What you get at the end
A prioritised list where an exposed live credential outranks a theoretical high-severity issue in a dev dependency, because that is the order in which they will hurt you. Each finding carries the file and line (or the commit, for history findings), the reason it matters, and the fix — including which secrets need rotating rather than merely deleting.
What this engine cannot find
Static analysis has well-known blind spots, and pretending otherwise is how teams end up over-trusting a green result:
- Runtime behaviour — configuration injected at deploy time, feature flags, and anything the code decides only in production.
- Business-logic flaws that read as perfectly valid code.
- Whether a detected secret is still live: rotation status has to be confirmed by you.
- Vulnerabilities in closed-source dependencies you consume as binaries.
- Code paths in submodules or private registries the clone cannot reach.
We publish this list for the same reason we publish our own assessment report, limitations section included: a vendor that cannot tell you what its tool misses is asking you to take the rest on faith.
Frequently Asked Questions
Do you scan the whole git history or just the latest commit?
The history. A secret deleted in the current tree is still readable to anyone who clones the repository, so history is where the finding usually lives.
What access does the engine need?
Read access to the repository you submit, for the duration of the scan. The token is never stored in our database, and nothing is ever written back to your repository.
Do you keep a copy of our source code?
No. The clone exists only inside the scan workspace and is destroyed when the run completes. Nothing is used to train any model, contractually.
Can it open a pull request with the fix?
No. This engine is deliberately read-only. Remediation code is provided in the report for your team to apply.
Does it replace GitHub Advanced Security or Dependabot?
It overlaps and adds context: one prioritised report across secrets, dependencies, IaC and CI/CD, with the reasoning for the order. Keep whatever already works for you and use this as the cross-cutting view.