NAME¶

git-secrets - Prevents you from committing passwords and other sensitive information to a git repository.

SYNOPSIS¶

git secrets --scan [-r|--recursive] [--cached] [--no-index] [--untracked] [<files>...]
git secrets --scan-history
git secrets --install [-f|--force] [<target-directory>]
git secrets --list [--global]
git secrets --add [-a|--allowed] [-l|--literal] [--global] <pattern>
git secrets --add-provider [--global] <command> [arguments...]
git secrets --register-aws [--global]
git secrets --aws-provider [<credentials-file>]

DESCRIPTION¶

git-secrets scans commits, commit messages, and --no-ff merges to prevent adding secrets into your git repositories. If a commit, commit message, or any commit in a --no-ff merge history matches one of your configured prohibited regular expression patterns, then the commit is rejected.

INSTALLING GIT-SECRETS¶

git-secrets must be placed somewhere in your PATH so that it is picked up by git when running git secrets.

make install

PS > ./install.ps1

brew install git-secrets

cd /path/to/my/repo
git secrets --install
git secrets --register-aws

ADVANCED CONFIGURATION¶

Add a configuration template if you want to add hooks to all repositories you initialize or clone in the future.

git secrets --register-aws --global

Add hooks to all your local repositories.

git secrets --install ~/.git-templates/git-secrets
git config --global init.templateDir ~/.git-templates/git-secrets

Add custom providers to scan for security credentials.

git secrets --add-provider -- cat /path/to/secret/file/patterns

BEFORE MAKING PUBLIC A REPOSITORY¶

With git-secrets is also possible to scan a repository including all revisions:

git secrets --scan-history

OPTIONS¶

cd /path/to/my/repository
git secrets --install

git secrets --install /path/to/my/repository

git secrets --install ~/.git-templates/git-secrets
git init --template ~/.git-templates/git-secrets

git secrets --install -f

git secrets --scan

git secrets --scan /path/to/file

git secrets --scan -r /path/to/directory

git secrets --scan /path/to/file /path/to/other/file

git secrets --scan /path/to/directory/*

echo 'hello!' | git secrets --scan -

git secrets --add '[A-Z0-9]{20}'

git secrets --add --global '[A-Z0-9]{20}'

git secrets --add --literal 'foo+bar'

git secrets --add -a 'allowed pattern'

git secrets --add-provider -- git secrets --aws-provider

git secrets --add-provider -- cat /path/to/secret/file/patterns

DEFINING PROHIBITED PATTERNS¶

egrep-compatible regular expressions are used to determine if a commit or commit message contains any prohibited patterns. These regular expressions are defined using the git config command. It is important to note that different systems use different versions of egrep. For example, when running on macOS, you will use a different version of egrep than when running on something like Ubuntu (BSD vs GNU).

You can add prohibited regular expression patterns to your git config using git secrets --add <pattern>.

IGNORING FALSE POSITIVES¶

Sometimes a regular expression might match false positives. For example, git commit SHAs look a lot like AWS access keys. You can specify many different regular expression patterns as false positives using the following command:

git secrets --add --allowed 'my regex pattern'

You can also add regular expressions patterns to filter false positives to a .gitallowed file located in the repository's root directory. Lines starting with # are skipped (comment line) and empty lines are also skipped.

First, git-secrets will extract all lines from a file that contain a prohibited match. Included in the matched results will be the full path to the name of the file that was matched, followed by ':', followed by the line number that was matched, followed by the entire line from the file that was matched by a secret pattern. Then, if you've defined allowed regular expressions, git-secrets will check to see if all of the matched lines match at least one of your registered allowed regular expressions. If all of the lines that were flagged as secret are canceled out by an allowed match, then the subject text does not contain any secrets. If any of the matched lines are not matched by an allowed regular expression, then git-secrets will fail the commit/merge/message.

IMPORTANT:

SECRET PROVIDERS¶

Sometimes you want to check for an exact pattern match against a set of known secrets. For example, you might want to ensure that no credentials present in ~/.aws/credentials ever show up in a commit. In these cases, it's better to leave these secrets in one location rather than spread them out across git repositories in git configs. You can use "secret providers" to fetch these types of credentials. A secret provider is an executable that when invoked outputs prohibited patterns separated by new lines.

You can add secret providers using the --add-provider command:

git secrets --add-provider -- git secrets --aws-provider

Notice the use of --. This ensures that any arguments associated with the provider are passed to the provider each time it is invoked when scanning for secrets.

EXAMPLE WALKTHROUGH¶

Let's take a look at an example. Given the following subject text (stored in /tmp/example):

This is a test!
password=ex@mplepassword
password=******
More test...

And the following registered patterns:

git secrets --add 'password\s*=\s*.+'
git secrets --add --allowed --literal 'ex@mplepassword'

Running git secrets --scan /tmp/example, the result will result in the following error output:

/tmp/example:3:password=******
[ERROR] Matched prohibited pattern
Possible mitigations:
- Mark false positives as allowed using: git config --add secrets.allowed ...
- List your configured patterns: git config --get-all secrets.patterns
- List your configured allowed patterns: git config --get-all secrets.allowed
- Use --no-verify if this is a one-time false positive

Breaking this down, the prohibited pattern value of password\s*=\s*.+ will match the following lines:

/tmp/example:2:password=ex@mplepassword
/tmp/example:3:password=******

...But the first match will be filtered out due to the fact that it matches the allowed regular expression of ex@mplepassword. Because there is still a remaining line that did not match, it is considered a secret.

Because that matching lines are placed on lines that start with the filename and line number (e.g., /tmp/example:3:...), you can create allowed patterns that take filenames and line numbers into account in the regular expression. For example, you could whitelist an entire file using something like:

git secrets --add --allowed '/tmp/example:.*'
git secrets --scan /tmp/example && echo $?
# Outputs: 0

Alternatively, you could allow a specific line number of a file if that line is unlikely to change using something like the following:

git secrets --add --allowed '/tmp/example:3:.*'
git secrets --scan /tmp/example && echo $?
# Outputs: 0

Keep this in mind when creating allowed patterns to ensure that your allowed patterns are not inadvertently matched due to the fact that the filename is included in the subject text that allowed patterns are matched against.

SKIPPING VALIDATION¶

Use the --no-verify option in the event of a false positive match in a commit, merge, or commit message. This will skip the execution of the git hook and allow you to make the commit or merge.

ABOUT¶

Copyright 2015 Amazon.com, Inc. or its affiliates. All Rights Reserved.