Semgrep users often ask about scanning code for secrets—passwords, API keys, GitHub personal access tokens (PATs), etc. Good news: you can now easily scan your source code for secrets using a new ruleset, as well as easily write custom secret-scanning rules tailored to your project and environment.
Secrets can be leaked in various file formats. To detect them, Semgrep has JSON support, alpha YAML support, and an experimental generic matching mode. This means Semgrep can scan many file types beyond the programming languages it already supports.
This new ruleset includes 38 rules specifically designed for secret detection. You can run a quick scan on your code using:
semgrep --config "p/secrets"
If you don’t already have Semgrep installed, here’s a Docker command you can run to scan your code using the ruleset:
docker run --rm -v "${PWD}:/src" returntocorp/semgrep --config p/secrets
There’s more than just API key and hardcoded password detection, too: the rules also cover webhook URLs, HTTP basic auth params, Slack tokens, PGP and OpenSSH private keys, plus other things you don’t want checked into version control.
With Semgrep’s simple syntax, it’s easy to extend any of these rules to fit the custom needs of your organization. You can also use Semgrep’s composition or filtering to fine-tune the rules (often to reduce false-positives) or find something that is not a secret. For example, you can exclude results from a file’s integrity checksum using pattern-not-regex, or entirely ignore a rule on specific files/paths by using the paths: key.
Secret detection can be a bit noisy by nature, so we recommend running these rules in an audit mode. This shows findings in the Semgrep App’s dashboard and sends email or Slack notifications, but doesn’t block the build when secrets are detected. As you examine your results, you can iterate on the rules so they find only the secrets you care about.
To use the ruleset in such a workflow, simply log in to the Semgrep App and then:
Add the secrets ruleset to a new policy (or add to an existing policy):
Make sure the policy is not blocking:
Add the policy to a project:
Then enable viewing of non-blocking results in the dashboard overview:
There are plenty of secret scanning tools out there, and we’ve heard good things about truffleHog, git-secrets, and shhgit, plus a couple dozen or so listed in this GitHub issue. If you know of other good tools, please add them to the issue!
