To cut secrets scanning false positives, tune what counts as a secret, test whether a finding is live, exclude known test data through reviewed rules, and fix the habits that produce lookalikes. Never solve noise by switching detection off. A tuned scanner stays quiet and still catches the leak that matters.
Why do false positives happen?
Secrets scanners look for patterns: known key formats, high entropy strings, and words like "password" near a value. Each method has a typical false alarm.
- Format matching flags example keys in documentation and tests.
- Entropy checks flag hashes, identifiers and encoded data.
- Keyword matching flags variable names and placeholder values.
CWE-798, use of hard coded credentials, describes the underlying weakness. The scanner's job is to find real instances of it. Its noise is the cost of being sensitive, which you manage rather than eliminate.
Which fixes work, in order?
1. Triage by validity. The best filter is whether the credential works. If your tooling can check a candidate against the issuing service in a safe, read only way, a live result goes to the top of the queue and a dead one goes to a lower tier. Where validation is not possible, use format specific rules over generic entropy rules, because a rule written for one provider's key format produces far fewer mistakes than a rule for "anything random."
2. Separate real secrets from fixtures. Test data, sample configs and documentation need fake values that are clearly fake. Adopt one marker, such as an obvious prefix or a documented dummy domain, and write one rule that recognizes it. Keep fixtures in known directories and exclude those paths with a rule reviewed by a second person.
3. Use baselines carefully. Record existing findings once, triage them, and then alert only on new ones. A baseline is a decision, so store it in the repository, date it, and review it on a schedule. A baseline nobody reads becomes a place to hide real leaks.
4. Allow with a reason. Every ignore entry should state why, who approved it and when it expires. Inline comments that silence a line are fine if the reason is on the line and reviewed in the pull request.
5. Scan at the right moment. Checking before a commit or push, and in pull requests, keeps findings small and attributable. Scanning full history catches old leaks but produces a one time flood, so handle it as a project with an owner.
6. Remove the root cause. If developers keep pasting tokens into config, give them a secret manager and a local development pattern that uses environment variables. The OWASP Secrets Management Cheat Sheet is a good reference for central management, rotation and auditing.
What not to do
Do not raise entropy thresholds across the board until the alerts stop. That is how a real key with a modest score gets through. Do not auto close findings older than a certain age. Old credentials are often still valid.
Try it
You can see how a secrets scan reads a repository in our interactive demo below.
Open the full version at /demos/secrets-scanning.
What to do
- Measure first: sample fifty findings and label them real, fixture or noise.
- Replace generic rules with format specific rules where you can.
- Standardize one fake value marker and write a single rule for it.
- Add reviewed allow rules with a reason and an expiry date.
- Triage existing findings once, then alert on new ones only.
- Rotate every real credential you find, and treat the exposure as an incident even if it looks old.
- Review the labeled sample again after a month and compare.
Quick check
Is a false positive worth fixing?
Yes, because noise trains people to ignore the scanner. But fix it with a reviewed rule, not by disabling detection.
Do I need to rotate a secret the scanner found if it looks unused?
Yes. Once a credential is in a repository it should be treated as exposed. Rotation is cheap compared to proving it was never used.
Sources
Last reviewed: 18 October 2026.
