Make every exception narrow, give it a reason, have someone review it, and give it an expiry. Allow one exact value or one line, not a whole directory. An allowlist with no reasons and no owner is where real leaks quietly hide.
Why allowlists go wrong
Developers want the red build to go away. The quickest fix is a broad rule: ignore the whole test folder, ignore this file type. Months later a real key sits in that folder and nothing alerts. Each broad exception is a permanent blind spot.
Exception types, narrowest first
| Type | Scope | Risk |
|---|---|---|
| Inline comment on one line | One line | Low |
| Exact value allowlist | One string everywhere | Low if the value is truly fake |
| File level | One file | Medium |
| Path or folder | Many files | High |
| Rule disabled | Everywhere | Highest |
The detect-secrets project supports an inline pragma, for example, that excludes a single line or the next line from detection without regenerating its baseline, and a mode for listing all such exceptions for review. Other tools have equivalent features under other names.
Rules for a healthy allowlist
- Reason required. Each exception explains why the value is not a secret, for instance "documented example token".
- Owner named. Someone answers for it.
- Review in pull requests. Treat allowlist changes as security relevant changes.
- Expiry. Add a review date. Stale exceptions get re-checked.
- Prefer fixing the cause. Replace realistic fake values with obviously fake ones.
- Standard test values. OWASP recommends using standard test secrets across the organisation to reduce false positives. Publish a short list teams can copy.
- List and count exceptions monthly. A rising count is a signal.
A review checklist for exceptions
- Is the value truly not a credential? Test it against the issuer if unsure.
- Could the exception hide other values nearby?
- Is the file shipped to customers or only used in tests?
- Is there a safer fake value that would not trigger the rule?
Tune the rule instead, when the pattern repeats
If the same kind of false positive appears across teams, fix the rule: require a keyword nearby, raise a threshold, or exclude generated files such as lockfiles. Read what entropy means in secret scanning. For fixture design, see fake credentials in test fixtures.
Quick check
Is it OK to allowlist a whole test directory?
Usually not. Test directories can hold real keys that developers pasted for convenience. Prefer line level exceptions or fix the fixture values.
Who approves exceptions?
The code owner for the file, with security reviewing changes to shared rules. Keep the approval in the pull request history.
Safeguard policies and gates can be set to block new findings on pull requests, and you can try a free scan.
Sources
Last reviewed: 19 October 2026.
