How to Run Static Code Audits to Detect Exposed Secrets Using Gitleaks

The Silent Danger of Exposed Secrets in Code

In modern software development, delivery speed is frequently prioritized, which opens room for critical human errors. One of the most dangerous oversights is the accidental commit of secrets — such as API keys, database passwords, and access tokens — directly into the code repository. In practice, this means anyone with access to the code, whether an internal collaborator or an external attacker, gains the keys to your company's digital kingdom. The problem is compounded by the fact that Git history is immutable by default, meaning even if you delete the file in the very next commit, the sensitive information remains permanently recorded in the project's depths.

To combat this problem systematically, the industry relies on security-focused static code audit tools. Static analysis consists of examining source code without executing it, hunting for suspicious patterns that indicate leaks. Tools like Gitleaks have become the industry standard for this task, operating as automated watchdogs that comb through every line of text looking for known credential signatures. The great benefit of this approach is automation: instead of relying on human review — which is fallible and exhausting — the machine does the heavy lifting of scanning before damage occurs.

How Gitleaks Works Behind the Scenes

Gitleaks is a command-line program written in Go, specifically designed to detect secrets in Git repositories, whether local or remote. The technology behind it relies on an intelligent combination of regular expressions (regex), which are text pattern-based search rules, and Shannon entropy, a mathematical measure of randomness. In practice, while regex identifies known formats like AWS keys or GitHub tokens, entropy analysis can detect strings that look like randomly generated passwords, even if they do not follow a predictable corporate pattern.

When you run Gitleaks, it traverses the Git commit log, analyzing the differences introduced in each change. This means it looks not only at the current state of files, but at the entire modification history of the project. If someone inserted a secret key two years ago and later removed it, Gitleaks will still be able to find it unless the history has been rewritten. This depth of analysis is fundamental because attackers frequently browse the history of public and private projects looking for secrets forgotten by inattentive developers.

Installation and First Steps with the Tool

Installing Gitleaks is a simple process adapted to the market's major operating systems. If you use macOS, you can use the Homebrew package manager by running brew install gitleaks in your terminal. For Linux users or container-based CI environments, the tool can be downloaded directly as a compiled binary or run through an official Docker image. In practice, having the tool installed means you now have a universal command called gitleaks ready to be triggered at any moment on your machine.

The most basic command to audit a local repository is gitleaks detect. When executed at the root of a Git project, it starts a complete scan of all branches and commit history. The result is displayed in the terminal, pointing out exactly which file contained the secret, the affected line, and the responsible commit. Here is a practical example pointing to a local directory:

gitleaks detect --source . --verbose

The parameter --verbose instructs the tool to provide full details about each occurrence found, facilitating initial diagnosis by the developer.

Configuring Custom Rules for Your Project

Although Gitleaks comes with dozens of predefined rules to detect keys from popular providers like Google Cloud, AWS, Slack, and Stripe, every organization has its own peculiarities. Many companies use internal tokens, proprietary password formats, or custom encryption keys not covered by standard rules. To solve this, Gitleaks allows creating a custom configuration file, usually named .gitleaks.toml, located at the repository root.

In this configuration file, you can define new rules using regular expressions and adjust entropy thresholds. Below, we present a functional example of a Gitleaks configuration file that adds a rule to detect a fictional internal corporate key pattern:

title =