Git secret scanning

Revised October 4, 2026. The previous version incorrectly attributed the Bybit theft to a private key committed to Git, cited an unsupported “11% of repositories” figure, used obsolete scanner commands and fixed competitor prices, and overstated several products’ coverage. Those claims have been removed. This guide focuses on what a team can configure, test, and verify.

What is Git secret scanning?

Git secret scanning looks for credentials or credential-like material in source files and commit history. Detection commonly uses provider-specific or generic patterns. A match establishes that the scanned material resembles a secret; it does not establish that the issuer still accepts it, what it can access, or whether anyone misused it. Provider validity checks, when supported and enabled, answer a narrower question about current status.

Define the boundary before choosing a tool. Which repositories, branches, historical commits, pull requests, issues, wikis, CI artifacts, and collaboration stores matter to your team? GitHub documents scanning Git history across branches plus several hosted text surfaces. GitLab documents separate push protection, pipeline secret detection, and client-side detection. Their coverage and configuration differ. A local Git scanner cannot infer that it has inspected a hosted issue or a Slack message.

Set up three useful scan points

1. Before code is pushed

Enable the host’s push protection where available and verify which secret types it blocks. GitHub says push protection covers a subset of identifiable patterns; a large or complex push may be skipped or time out. GitLab’s push protection can block a push unless an allowed bypass is used. Keep a local hook if it helps developers, but test whether each contributor has it installed and whether bypasses are logged.

2. After a push or merge request

Enable repository or pipeline alerts and assign a person who will receive and triage them. On GitHub, confirm the repository’s eligible secret-scanning features and supported patterns rather than assuming every plan has the same coverage. On GitLab, check whether pipeline detection runs for merge requests as well as the default branch. Test the route with a nonfunctional sample that matches a configured rule in a private test repository; never publish a working credential to test a scanner.

3. Existing history and local files

Run a historical scan for repositories that predate the new controls. In current Gitleaks versions, “gitleaks git .” scans a local repository’s Git patches, while “gitleaks dir .” scans files in a directory. The old “detect” and “protect” subcommands are deprecated. Inspect Gitleaks’s log options when coverage must include other refs or a particular commit range. A baseline can separate old findings from new alerts, but it is a tracking aid, not permission to leave a live key usable.

Triage a finding without confusing four states

Record the exact location and who could read it. Decide whether it is a real credential format or a test value. Check current validity with the issuer only when a safe supported method exists; otherwise mark it unknown and ask the issuer or owner. Then determine the principal, permissions, expiry, and workload at the issuer. Finally review available activity logs for unexpected use. “Found,” “active,” “privileged,” and “misused” are distinct conclusions.

Coverage can be narrower than a product name suggests. GitHub’s documentation says paired patterns, such as an AWS access-key ID and secret, require both parts in the same file and repository. Push protection supports only certain patterns and versions. A clean result is evidence about the configured source and detector set, not proof that no credentials exist elsewhere.

Respond at the issuer first

For a potentially active exposed key, the service owner should coordinate a replacement, revoke or rotate the old value at the issuer, and verify that dependent workloads still run and the old value fails. Review issuer logs within their actual coverage. Remove exposed copies and repair the path that leaked them. GitHub advises revocation or rotation before rewriting repository history; history rewrites change commit hashes and cannot remove other people’s clones or forks. Record the owner, action, time, and remaining unknowns.

Choose a scanner by a repeatable test

Native GitHub scanning is a starting point for GitHub-hosted work; native GitLab controls cover GitLab workflows; Gitleaks offers a configurable local Git and file scan. Compare their current documentation and run the same nonfunctional fixture through the surfaces and stages you need. Check supported patterns, historical coverage, alert delivery, validation, access required by connectors, and the human response workflow. Avoid a fixed detector count or price copied from an older article.

Cremit Platform scans credentials in supported connected GitHub, GitLab, and Bitbucket repositories, and in configured sources such as GitHub Packages, S3, Google Drive, Slack, Jira, Confluence, and Notion. It records locations, checks supported credential types with their issuers, adds available AWS access-key or GCP API-key permission context, and lets a team assign and track response. It does not cover every source, prove misuse, or rotate and revoke a key automatically. A Git host’s push protection and a connected-source investigation can answer different parts of the same case.

A rollout checklist

List sources and owners; turn on the protections your host and plan support; scan existing history; test one nonfunctional finding end to end; define who validates and revokes at the issuer; track a small set of outcomes—unreviewed, unknown validity, confirmed active, revoked, and false positive. Revisit source access and detector coverage when a new repository, token format, or collaboration tool is added.

Secret scanning false positives: how to triage findings

What an exposed key says about machine access