CoroidYour AI software factory
Documentation

Leaked secrets

How Security finds credentials in changes and in your history without keeping them, why a leaked secret closes only when someone attests it was rotated, and how to fix one.

A credential that reached a pushed commit is already leaked, even if a later commit removes it. Security finds credentials in your changes and history, keeps none of them, and treats each as open until someone confirms it was rotated or revoked.

What is scanned

  • Every change: each pull request's changes, as part of the Coroid Security check, and Coroid's own agents' changes before they are committed.
  • The default branch: each push, and once through its whole history. The history scan starts when a repository is connected or Leaked secrets is switched on.
  • Pull request branches: a credential pushed to a pull request branch opens a finding too, because it is already in the repository.

A branch that is pushed without a pull request is not scanned.

The history scan reads every reachable commit, newest first, and reads each file version once. It works in slices and resumes where it stopped. Each repository has limits on how much history is read (commits, bytes, time and file size); a repository past them shows partial coverage.

What is detected

Provider credentials in their known formats (AWS access keys, GitHub and GitLab tokens, OpenAI keys and others), authorization tokens, credentials assigned to names such as password or api_key, private keys, credentials inside URLs, and long high-entropy strings. Credentials assigned in code are matched only when the value is a literal, not a variable or a function call.

Coroid never keeps the value

A detected value goes from the detector straight to Coroid's credential broker, which returns a keyed fingerprint and drops the value. Only the fingerprint is stored. It is keyed per organization, so it cannot be compared across organizations or guessed offline.

Everywhere a secret would otherwise appear (findings, checks, review comments, logs), Coroid shows only the rule, the length and the location, for example [redacted secret: named_credential, 40 characters]. No part of the value is shown, not even its first characters.

Coroid never tries a credential it finds to see whether it works.

One credential, one finding

A credential seen in many commits is one finding with many occurrences. The same credential in two repositories is two findings, one per repository. When you attest one, Security lists the others with the same credential so you can attest them together. It never does so on its own.

A secret closes only by attestation

Removing a credential from the code makes its occurrences absent, but the finding stays open: anyone who read the repository before may have it. It closes only when an owner or admin attests what was done:

  • Rotated or revoked;
  • the date it was done;
  • an optional note.

Security records who attested and when, and shows it on the finding: "Rotated on 28 October, attested by Alex on 29 October". The finding moves to Rotation attested.

Fixing a leaked secret

Create the checklist task files a task in the project with these steps:

  1. Rotate or revoke the credential at its provider.
  2. Move it to where the project keeps its secrets.
  3. Remove it from the code.
  4. Attest the rotation in Security.

The task never repeats or tries the credential. It does not rewrite git history: removing a credential from history is a decision for your team, and does not make a leaked credential safe again.

Real credential or not a problem

On a secret finding, owners and admins answer Was this a real credential?

  • Real credential keeps the finding open until it is attested.
  • Not a problem records a false-positive exception that hides the finding, for example for a test fixture. Real credential removes that exception again.

These answers also help calibrate the detectors.

Blocking

Leaked secrets observes by default. It blocks only once its detectors have passed calibration and enforcement is on. See Protections and enforcement.

Organizations that had the earlier secret scan switched on in their organization policy keep being blocked by it, with its detector version, until the new detectors pass calibration. That earlier scan does not create findings, so an exception or an attestation cannot hide what it blocks.

On the organization default, Block new secrets and the largest change scanned are set under Leaked secrets.

Notifications

Secret findings do not send notifications yet. They appear in Security → Findings and in Overview.

GitHub secret scanning

If GitHub's own secret scanning is on for a repository, Security can import its alerts. A GitHub secret scanning alert stays open until someone resolves it on GitHub, so merging a fix does not close it there. See GitHub security alerts.