This tool is worth attacking

One per connection, read only by design. Each is encrypted at rest in the database with a key derived from the installation's own secret, and is decrypted only in memory when a scan is about to use it. It is never written to a log, never returned by the API, never shown back on the settings page once saved, and never included in a report or a notification. The same is true of every other secret the product stores: identity provider client secrets, SMTP passwords, webhook URLs.

This is the part that matters most, and it is worth being precise about.

• The cleartext of a found credential exists only inside the running scan, in the files the engines write and in the process reading them.
• Those files are placed in shared memory where the machine has enough of it, so nothing reaches a disk. Where it does not, the scan says so in the log rather than doing it quietly, and the files are overwritten rather than merely unlinked.
• Before anything is stored, the value becomes two things: a SHA-256 fingerprint, and a mask showing the first four and last three characters. Those are what the database, the reports, the web pages, the API and the notifications all carry.
• A private key is not masked but named, so a report says the key type rather than a row of asterisks that tells you nothing.

The consequence is that this product cannot show you a secret it found, even to somebody who owns the database. That is deliberate. The mask and the fingerprint are enough to find the line and to know whether two findings are the same key.

Your git hosts. The public vulnerability databases, which are asked about package names and versions, never about your code. And, only when live verification is switched on, the issuer of a candidate credential is asked whether that credential still works. That last one is the only case where a value goes anywhere, it is to the service that issued it, and one flag disables it for the whole run.

There is no telemetry, no analytics, no crash reporting, no update check and no license check.

• Local accounts require a second factor, with recovery codes, and the first administrator is made to set both up before reaching anything.
• Single sign on against any OpenID Connect provider, with group to role mapping.
• Three roles. A reader can read and nothing else, a developer sees only the organizations and repositories assigned to them and can ask for an exception, and an administrator can approve one.
• An administrator can view the product as another user to reproduce a problem. That session is refused every write, at the middleware, before any route runs, and both the start and the end of it are audited.
• Sessions are signed cookies with the usual flags, protected against cross site request forgery, and there is a content security policy on every page.

• Behind a reverse proxy that terminates TLS. It listens on loopback and speaks plain HTTP on the assumption that something is in front of it.
• On a host with enough shared memory for the scan to stay out of the disk. A gigabyte is plenty.
• With a read only credential, scoped to what you actually want scanned.
• With the database volume backed up and treated as sensitive: it holds the encrypted connection credentials and the map of where your secrets have leaked.
• Access to the product restricted to the people who would be allowed to read the repositories it scans, because that is effectively what it grants.

Open an issue in the repository. If it is exploitable, say so in the title and leave the working details out of the public issue.