Product

Product Features SDLC How to Compare Docs Screenshots

Start here

Getting started Download Questions

More

Security Roadmap About

Free and open source, self hosted

Every repository you own, read for the things that get people in trouble.

Leaked credentials, vulnerable code, risky dependencies and misconfigured infrastructure, across twelve hosting providers, from one web page. It walks every commit on every branch, asks the provider whether a key still works, and keeps a record of who decided what.

MIT licensed. One command to install. Nothing leaves your network, every call it makes to your code host is a read, and the cleartext of a found credential is held in memory rather than written to a disk.

12
hosting providers
9
scanning engines
3
secret engines, cross checked
0
writes to your repositories

The problem is not finding things. It is finding the ones that matter.

Point any scanner at a real estate and it returns thousands of findings. Nobody reads thousands. Most of this product is about the second half of that sentence.

It asks whether the key still works

A credential that looks like a credential is a guess. Git Code Review sends candidates to the provider that issued them, so a finding says this key is live rather than this looks like a key.

It says which ones it cannot reach

Most vulnerable packages sit in code the application never calls. It works out which, from facts about the tree, and says why on every finding. On one corpus that moved 278 of 361 out of the way.

It tells you when its own grade is too high

When the triage pass has already decided a finding is not what its rule was looking for, the page says so and offers a lower grade, with the reasoning. Accepting it is one click and it is recorded.

It asks a model once, and remembers

Validate one finding or five hundred with your own model. A lower reading lowers the grade, never on a live risk like a credential, and every answer becomes a rule with a test, so the next finding like it costs nothing.

Decisions expire

An exception carries a reason, a reviewer and an end date. When it lapses the finding comes back. Nothing is deleted and nothing is permanent by accident.

It answers the Tuesday morning question

A release is announced as compromised and there is no advisory for two days. The inventory is built from the bill of materials rather than from the findings, so a name typed into the box comes back with every repository and every branch holding that exact version.

It knows who can reach what

Every finding shows what the repository holds, who owns it and who can push to it. The same credential in a payment system and a brochure site are not the same problem.

It never writes to your code

Every call to your host is a GET. No fix branches, no pull requests, no comments. That is a tested property, and it is why security teams sign it off.

What it finds

Credentials

gitleaks, TruffleHog and the host's own alerts, over every commit on every branch. A key deleted last year is still in the history, and that is where most of them are. Values never leave the scan: what is stored is a hash and a mask.

Code

semgrep across thirteen rule packs, with gosec added for Go where it reads a whole package rather than a file at a time. Findings two engines agree on say so.

Dependencies

A real SBOM from syft, then grype and OSV over it, with the CISA exploited list and EPSS scores on top so the ranking means something. A pom that names three libraries and resolves to forty is read as forty, and a .NET project that was never built is read from its project files rather than reported as having no dependencies at all.

Malicious packages

Typosquats, install hooks that fetch and run, dependencies that do not come from a registry, and the OpenSSF malicious packages feed. None of these has a CVE, which is the point.

Infrastructure and pipelines

Terraform, Kubernetes manifests, Dockerfiles and the CI workflows themselves. The pipeline builds everything else, so it is worth reading.

Container images

The base image each Dockerfile names, pulled and read without building anything. On most applications that is where the critical count actually lives.

And in your editor, before the commit exists

The nightly scan tells somebody about a credential that has been in the history for three months and now has to be rotated. The editor is the only place where it can still be stopped instead.

Four editors, one language server

Visual Studio Code and Cursor install the same package. The JetBrains IDEs and Eclipse run the language server underneath it, and so does anything else that speaks the protocol. Open or save a file and it is read by the same engines and graded by the same triage the nightly scan uses, so the editor and the report agree with each other.

From your server, to your server

The download is a page in the product rather than a marketplace listing, because this server is the one holding your rules and plenty of these installations have no way out to the internet. The file you are editing goes to that same server and is deleted once it has been read. Nothing is stored, and only the lines you changed are marked.

What it does in the editor Install it on Windows On macOS or Linux

Where the code goes, and where it goes wrong

A short, plain walkthrough of how software gets from somebody's laptop to the people using it, what can be poisoned along the way, and where a scanner helps.

See the walkthrough

Install it

One command on a clean Ubuntu server. It brings its own database, its own engines and a web interface on port 8083.

curl -fsSL https://git.failoverlb.net/github-code-review/-/raw/master/get-gcr.sh | bash

The longer version