The things people ask first

Yes. MIT licensed, no paid tier, no seat count, no edition with the useful parts removed. There is nothing to buy and nobody to talk to. The only cost is the machine it runs on and the hour it takes to tune the first scan.

It connects to your git hosts with a read only credential, finds every repository that credential can reach, clones all of them including every branch and the full history, and runs ten open source engines over them. Then it does the part that matters: works out which of those findings are real, ranks them, and keeps the record of who decided what about each one.

Those engines are excellent and they are the same ones the commercial products run underneath. What is missing when you run them yourself is everything around them: something that knows what a repository is worth, that can tell an example from a credential, that ranks a verified key above a critical nobody can reach, that remembers who set what aside and why, and that gives one list across every host you use. That gap is the product.

Somebody responsible for security across more than about twenty repositories who does not have a budget for the commercial answer, or wants to know what is there before asking for one. It scales down fine to a handful of repositories and up to a few hundred on one machine.

No. There is no cloud component, no telemetry, no analytics and no license check. The only outbound traffic is to your own git hosts, to the public vulnerability databases which are asked about package names and versions rather than about your code, and, if you switch live verification on, to a credential's own issuer.

No, and it is built so that it cannot. It never opens a pull request, never pushes, never revokes a key and never changes anybody's settings. Every credential it asks for is read only and it refuses to ask for more.

No. A found credential exists in cleartext only inside the running scan, in shared memory where the machine has enough of it. Before anything is written down it becomes two things: a SHA-256 fingerprint and a mask showing the first four and last three characters. The database, the reports, the API and the notifications all carry only those. The product genuinely cannot show you a secret it found.

It asks the service that issued a candidate credential whether that credential still works, using that service's own introspection endpoint. It is the strongest signal the product produces. It is also the one case where a value goes anywhere, so if your environment does not allow that, one flag disables it for the whole run and everything else still works.

Whoever you give an account to, subject to three roles: reader, developer and administrator, where a developer sees only the organizations and repositories assigned to them. Treat access to the product as equivalent to read access to every repository it scans, because that is close to what it is.

A Linux host with git, docker and the compose plugin, and a user that can talk to the docker daemon. Four cores and eight gigabytes covers a few hundred repositories on a nightly schedule. Put a reverse proxy in front of it for TLS.

It is dominated by cloning, so it depends on your estate rather than on the machine. A few dozen small repositories is minutes. A few hundred, some of them large and with long histories, is a couple of hours, which is why it belongs on a nightly schedule.

It keeps what it already finished, down to the half repository. Each pass over a repository writes what it has as it completes, so one stopped at its time limit still reports the credentials and the code findings it did get through, and is counted as partial rather than as scanned or failed. Repositories it never reached are left exactly as they were and nothing in them is counted as fixed. The run is marked interrupted rather than finished, so the scan history does not lie.

Yes, and there are three separate answers depending on why. The ceiling on a whole run is a setting in hours rather than an environment variable nobody can reach. What each engine may take from the machine is on the same page, and those numbers multiply, which is worth understanding before raising any of them. And a repository whose history is simply too large for one run can be given a window: each run walks so many days of history, records where it got to, and carries on from there, using the idle hours between scheduled scans to get to the end.

Yes. The limit is a setting, it defaults to one, and each running scan is stopped by its own button rather than by one button that means whichever is running.

GitHub, GitLab, Bitbucket, Azure Repos, AWS CodeCommit, Google Cloud Source Repositories, Assembla, Beanstalk, Subversion and Perforce Helix Core. Subversion and Perforce have no git history to walk, so the credential history pass does not apply to them, and the connection form says so before you set one up rather than after.

That number is normal and most of it is not real. Sort by verified credentials, then by what is being exploited in the wild. Set a baseline if the backlog is historic. Filter dependencies to the ones that are actually reachable, which on most estates removes three quarters of them. Then look at the top ten rules by count, which are usually half of everything, and decide once what each is worth. There is a guide for exactly this.

Blast radius, the Software tab, which is built from the bill of materials rather than from the findings. There is no advisory for a compromised release for a day or two, so a table built from advisories cannot answer this at all, and this one can because it never asked whether the package was interesting. Type the name or the package URL and you get every repository and every branch holding that exact version, with the license and whatever advisories do exist, and the search exports as CSV, JSON or a CycloneDX document.

Every judgement the product makes carries the sentence that justifies it, so you can disagree with the reasoning rather than only with the answer. Beyond that: a verified credential is a fact, because the provider was asked. A vulnerability on the exploited list is a fact, because somebody published that it is being used. Everything else is an argument, and the product shows you its argument.

Change it. A rule or a CWE can be regraded across the whole estate, or one finding regraded on its own, and the engine's original grade stays visible beside yours. An override can also be scoped so that it does not apply where a system carries a particular label.

You can set it aside, and no, nothing is deleted. An exception covers one finding, an exclusion covers whatever matches a rule, and a rule mute covers everything a rule will ever produce and needs a second administrator to agree. All three carry who decided, why and when it lapses, and an excluded finding still appears in the report marked as excluded.

Snyk is ahead on curated vulnerability data, on reachability where it builds a real call graph, on fix pull requests which this deliberately does not do, and on ticketing integrations. This is ahead on credentials, which is the thing Snyk covers least well and which is usually the finding with the shortest fuse. There is a page that scores forty capabilities against Snyk, GitHub Advanced Security, Semgrep, Checkmarx One and GitGuardian and leaves in the rows that go the other way.

GitHub Advanced Security is excellent and it is on GitHub. If your entire estate is on GitHub and you are willing to pay per developer, it is a strong answer. This one covers twelve hosts, costs nothing, and keeps a governance trail that a per repository security tab does not.

Deep static analysis for Java, PHP and Ruby, because free semgrep reads one file at a time and there is no second engine for those three yet. There is an editor API and no editor plugin. Nothing measures how long a finding has sat open or attributes it to a team, which is the part of executive reporting the commercial products still do better. And the vulnerability data is public rather than curated, which means it is sometimes later than a commercial feed. All four are on the roadmap and all four are on the comparison page.