What is secret scanning?

Secret scanning is the automated search of source code, commit history and other text, such as issues, logs and chat exports, for strings that look like credentials, so that a team learns about a leaked secret and can reissue it before someone else uses it.

How scanners decide what is a secret

Most scanners combine three signals:

• Known formats. Many providers give keys a recognizable prefix, for example sk_live_ for Stripe secret keys (Stripe) or AKIA for long-term AWS access key IDs (AWS). A pattern for each format catches them with few false alarms.
• Randomness. A long string with high entropy assigned to a variable called password or token is suspicious even without a known prefix.
• Validation. Some tools try the candidate against the provider to see whether it still works. TruffleHog, for one, says it "can log in to confirm if that secret is live or not" (TruffleHog README).

Where scanning runs

• On the hosting platform. GitHub's secret scanning "scans your entire Git history on all branches" and also looks at issues, pull requests, discussions and wikis, and it runs for free on public repositories (GitHub Docs).
• Before the push. Push protection "blocks pushes that contain secrets before they reach your repository" (GitHub Docs). By default, people with write access can bypass a block by giving a reason.
• On the developer's machine. The OWASP cheat sheet suggests detection "in the IDE, as part of test-driven development, or via pre-commit hook" (OWASP). Open-source tools such as Gitleaks and TruffleHog work here and in CI. Gitleaks' maintainer has declared it feature complete, with future releases limited to security patches (Gitleaks README).

What scanning doesn't do

A scanner finds copies. It doesn't make the value safe: a secret found in history has already been readable by everyone with access to that history, so the finding is a reason to reissue, not a reason to relax once the line is deleted.

It also misses things by design:

• values without a recognizable format, such as a database password like correct-horse-battery;
• places it isn't pointed at: laptops, private chats, screenshots, a colleague's notes;
• secrets split, encoded or templated in ways the patterns don't expect.

And it does nothing for the reason the secret was there. If developers have no good place to get values from, the next commit brings the copy back.

Common mistakes

• Treating zero findings as zero exposure. It means zero findings in the places and formats scanned.
• Fixing the file, not the value. Deleting the line and force-pushing leaves the old value valid at the provider.
• Allowing bypasses with no follow-up. A bypassed push block should create a task to reissue the value.

Crunu and scanning

Crunu has no secret scanner. It doesn't search repositories, CI logs or chat, and we don't plan to pretend otherwise. Use your Git host's scanning and push protection, or an open-source scanner in pre-commit and CI.

Crunu works on the other half of the problem: giving values a home so they don't need to be in the repository. Environments hold the real values, encrypted on your devices, and crunu run passes them to programs at start time. When a scanner finds something, move the value into an environment, reissue it at the provider, and save the new value there. The guide to sharing .env files with a team covers that setup.

Sources

• GitHub Docs: About secret scanning, checked October 30, 2026.
• GitHub Docs: About push protection, checked October 30, 2026.
• OWASP Secrets Management Cheat Sheet, checked October 30, 2026.
• TruffleHog README, checked October 30, 2026.
• Gitleaks README, checked October 30, 2026.
• Stripe Docs: API keys, checked October 30, 2026.
• AWS IAM: Programmatic access with AWS security credentials, checked October 30, 2026.