Where can Gitleaks catch a mistake?
A developer can run the scanner on a private working copy or add a check before Git saves a change. A team can also run it during automated checks, which helps when someone’s local check did not run. Choose which files and history the team expects each check to cover.
The scanner reports potential matches. A clean result covers the inputs and rules it checked. It does not prove every credential stayed private.
What changes if you run the scanner through GitHub Actions?
The core Gitleaks scanner is MIT-licensed. The separately distributed Gitleaks Action has its own license terms and documents a free license key for GitHub organization use. Review the action’s current terms and the cost of running your automated checks.
Keep the scanner rules and the expected check in your project. When you move hosts, re-create the check in the new workflow. Review who can see logs and reports, and keep sensitive findings out of public comments or downloads.
What should you do with a finding?
Record where the finding appeared and who owns the credential, using a label in the handoff. If it is an exposed real credential, revoke it at the issuing service and replace it where your app uses it. Closing a scan finding leaves the credential itself unchanged.
Gitleaks documents redaction for console output and logs. Check each output separately before sharing. Keep findings restricted because they can include file paths and other context.
How would you plan a check without using a real key?
Draw a fictional project, a proposed commit and a scanner result. Do not run a scan or write any credential value.
- Choose the check pointMark a check before committing and an automated check before merging.
- Draw a flagged changeLabel it “possible mail credential.” Pause the change and name the person who would verify it privately.
- Draw a missed runMark what should happen if the scanner did not run. Leave detection and workflow behavior untested.