Thesis: Default gitleaks rules ignore that well-known example. A fixture that uses it will not prove the scanner works unless a local rule names the string. The job that is supposed to stay green must not load that rule, or the sample fails for the demonstration instead of for a real leak.
What we tried first
The sample has two paths. The required job scans the application tree and should pass when that tree is clean. A second command, written in the README, points at a fixture and should fail, so a reader can see the gate work without turning the default branch red. We put the example key in the fixture and ran the default rules against it. Exit code 0. "No leaks found." The required job was also green, which is what we wanted. The fixture was green for the wrong reason. A documented fail path that passes does not demonstrate the control.
The working shape
The fail command uses a config with one rule for that exact string. Default rules stay on the required job. That job does not scan the fixture directory.
default rules on the example key → exit 0
local rule for that string → exit 1
required job does not load the local ruleChecklist
- Do not treat the AWS documentation example key as a detector test against default rules.
- Keep the fail fixture off the required path.
- A local rule that names the string is the command that should exit non-zero.
Related: the action tag fails before it scans. The fixture is in the public sample. How we deliver: methodology.
Engineering commentary only — not audit, legal, or certification advice.