Product

Product Features SDLC How to Compare Docs Screenshots

Start here

Getting started Download Questions

More

Security Roadmap About

Product

One page, every repository you own

You give it a credential that can read your code. It finds every repository that credential can reach, reads all of them, and puts what it found on one list in the order that a person should actually work through it.

1. Reach the codeConnectionhost, credential, scopeInventoryevery repository in scopeCloneall branches, full historyIn memorynothing kept on disk2. Read it, with ten enginesgitleakscredentialsTruffleHogcredentials, live checksemgrepcodegosec, banditcode, second opinionsyftbill of materialsgrype, OSVvulnerabilitiestrivyTerraform, K8szizmorCI pipelinesImage readerbase imagesMalicioustyposquats, hooksReachabilityis any of it actually called3. Decide, and keep the recordTriageexample or credentialRankverified, exploited, reachableYour decisionsexceptions, grades, baselinesReportsand an audit trailNothing is sent anywhere. The clone, the cleartext of every credential and every engine's raw outputexist only inside the scan, in memory where the machine allows it, and are gone before the run finishes.What is stored is a hash and a mask.

1. It reaches the code

A connection is a host, a credential and a scope. Twelve kinds of host are supported, and an estate that grew by acquisition usually needs three or four of them at once. Each connection carries its own labels for what the systems behind it hold, which is what later lets the same finding be a medium in one place and a critical in another.

From there it asks the host what repositories that credential can see, and clones them. Every branch, and the whole commit history behind them, because a credential deleted last March is still in the history and that is where most of them are.

Which branches is the connection's own decision, because an account holding a handful of release repositories and an account that has collected thousands of abandoned feature branches want different answers. A history too large to walk inside one run is walked across several, newest first, carrying on from where the last run stopped until it reaches the first commit, and using the hours nobody else wants to get there.

2. Ten engines read it

Three of them look for credentials, and they disagree with each other, which is the point. Three read the code. Three read the dependency tree and what it is built on. One reads the pipeline. They run against a working tree that exists only for the length of the scan.

Where a machine has enough shared memory, the whole thing runs in memory and never touches a disk, because the cleartext of every credential found passes through those files on its way to becoming a hash and a mask. Where it does not, the scan says so in the log rather than doing it quietly.

3. It decides what is worth your attention

Raw output from ten engines across a real estate is tens of thousands of findings and most of them are noise. Everything between that and the screen is the part that matters: entropy and pattern rules that separate a credential from an example, a fidelity pass that reads code findings back in context, a reachability verdict on every dependency, and a ranking that puts a credential the provider just confirmed still works above a critical nobody can reach.

Every one of those judgements shows its reasoning as a sentence, so a person can disagree with the argument rather than just the answer, and every rule behind them is editable from a page in the product.

4. It writes down what is there, not only what is wrong

A finding exists because somebody published an advisory. A component exists because it is in the tree. So the bill of materials a scan builds is kept: every package, every version, every license, and every repository and branch it sits on, searchable by name or by package URL. That is the only kind of table that can answer "is this exact version anywhere in our code" on the morning a release is announced as compromised, two days before there is an advisory to match on.

5. It keeps the record

A finding that somebody set aside is not deleted. It carries who decided, why, and when the decision lapses, it still appears in the report files marked as excluded, and the decision is in an audit log that can be searched. That record is the difference between a scanner and something an auditor will accept.

The same applies to a run that did not finish. A repository stopped at its time limit keeps the passes that did complete and is reported as partial rather than as scanned or failed, because it is neither and a reader needs to know which half they are holding. An account nobody has put anything in yet is recorded as empty, not as a failure, so a red row on that page still means something the night it appears.

What it never does

It does not write to your repositories, open pull requests, revoke keys or change anybody's settings. Every credential it holds is read only by design, and the product refuses to ask for more. Nothing about your code is sent anywhere: no cloud service, no telemetry, no license check. The only outbound traffic is to public vulnerability databases, and to a credential's own issuer when live verification is switched on, which is one flag away from off.

What it takes to run

One machine

Any Linux host with Docker. Four cores and eight gigabytes covers a few hundred repositories on a nightly schedule. The database is MariaDB and it comes up with the stack.

A read only token

One per host. Read access to code, and to organization membership if you want the access inventory. Nothing that can write.

About ten minutes

One command installs it. Adding a connection and starting the first scan is a page and a button. The scan itself takes as long as your estate takes to read.

See it running before you install anything

Thirty six screenshots of every page, from a demonstration instance holding twenty repositories worth of scan output.

Screenshots Getting started