Provided by: git-secrets_1.3.0-2_all 
NAME
git-secrets - Prevents you from committing passwords and other sensitive information to a
git repository.
Contents
• Synopsis
• Description
• Installing git-secrets
• *nix (Linux/macOS)
• Windows
• Homebrew (for macOS users)
• Advanced configuration
• Before making public a repository
• Options
• Operation Modes
• Options for --install
• Options for --scan
• Options for --list
• Options for --add
• Options for --register-aws
• Options for --aws-provider
• Options for --add-provider
• Defining prohibited patterns
• Ignoring false positives
• Secret providers
• Example walkthrough
• Skipping validation
• About
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.
*nix (Linux/macOS)
You can use the install target of the provided Makefile to install git secrets and the man
page. You can customize the install path using the PREFIX and MANPREFIX variables.
make install
Windows
Run the provided install.ps1 powershell script. This will copy the needed files to an
installation directory (%USERPROFILE%/.git-secrets by default) and add the directory to
the current user PATH.
PS > ./install.ps1
Homebrew (for macOS users)
brew install git-secrets
WARNING:
You're not done yet! You MUST install the git hooks for every repo that you wish to use
with git secrets --install.
Here's a quick example of how to ensure a git repository is scanned for secrets on each
commit:
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
Operation Modes
Each of these options must appear first on the command line.
--install
Installs git hooks for a repository. Once the hooks are installed for a git
repository, commits and non-fast-forward merges for that repository will be
prevented from committing secrets.
--scan Scans one or more files for secrets. When a file contains a secret, the matched
text from the file being scanned will be written to stdout and the script will exit
with a non-zero status. Each matched line will be written with the name of the file
that matched, a colon, the line number that matched, a colon, and then the line of
text that matched. If no files are provided, all files returned by git ls-files are
scanned.
--scan-history
Scans repository including all revisions. When a file contains a secret, the
matched text from the file being scanned will be written to stdout and the script
will exit with a non-zero status. Each matched line will be written with the name
of the file that matched, a colon, the line number that matched, a colon, and then
the line of text that matched.
--list Lists the git-secrets configuration for the current repo or in the global git
config.
--add Adds a prohibited or allowed pattern.
--add-provider
Registers a secret provider. Secret providers are executables that when invoked
output prohibited patterns that git-secrets should treat as prohibited.
--register-aws
Adds common AWS patterns to the git config and ensures that keys present in
~/.aws/credentials are not found in any commit. The following checks are added:
• AWS Access Key IDs via
(A3T[A-Z0-9]|AKIA|AGPA|AIDA|AROA|AIPA|ANPA|ANVA|ASIA)[A-Z0-9]{16}
• AWS Secret Access Key assignments via ":" or "=" surrounded by optional quotes
• AWS account ID assignments via ":" or "=" surrounded by optional quotes
• Allowed patterns for example AWS keys (AKIAIOSFODNN7EXAMPLE and
wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY)
• Known credentials from ~/.aws/credentials
NOTE:
While the patterns registered by this command should catch most instances of AWS
credentials, these patterns are not guaranteed to catch them all. git-secrets
should be used as an extra means of insurance -- you still need to do your due
diligence to ensure that you do not commit credentials to a repository.
--aws-provider
Secret provider that outputs credentials found in an INI file. You can optionally
provide the path to an INI file.
Options for --install
-f, --force
Overwrites existing hooks if present.
<target-directory>
When provided, installs git hooks to the given directory. The current directory is
assumed if <target-directory> is not provided.
If the provided <target-directory> is not in a git repository, the directory will
be created and hooks will be placed in <target-directory>/hooks. This can be useful
for creating git template directories using with git init --template
<target-directory>.
You can run git init on a repository that has already been initialized. From the
git init documentation:
From the git documentation: Running git init in an existing repository is safe.
It will not overwrite things that are already there. The primary reason for
rerunning git init is to pick up newly added templates (or to move the
repository to another place if --separate-git-dir is given).
The following git hooks are installed:
1. pre-commit: Used to check if any of the files changed in the commit use
prohibited patterns.
2. commit-msg: Used to determine if a commit message contains a prohibited
patterns.
3. prepare-commit-msg: Used to determine if a merge commit will introduce a history
that contains a prohibited pattern at any point. Please note that this hook is
only invoked for non fast-forward merges.
NOTE:
Git only allows a single script to be executed per hook. If the repository
contains Debian-style subdirectories like pre-commit.d and commit-msg.d, then
the git hooks will be installed into these directories, which assumes that
you've configured the corresponding hooks to execute all of the scripts found in
these directories. If these git subdirectories are not present, then the git
hooks will be installed to the git repo's .git/hooks directory.
Examples
Install git hooks to the current directory:
cd /path/to/my/repository
git secrets --install
Install git hooks to a repository other than the current directory:
git secrets --install /path/to/my/repository
Create a git template that has git-secrets installed, and then copy that template into a
git repository:
git secrets --install ~/.git-templates/git-secrets
git init --template ~/.git-templates/git-secrets
Overwrite existing hooks if present:
git secrets --install -f
Options for --scan
-r, --recursive
Scans the given files recursively. If a directory is encountered, the directory
will be scanned. If -r is not provided, directories will be ignored.
-r cannot be used alongside --cached, --no-index, or --untracked.
--cached
Searches blobs registered in the index file.
--no-index
Searches files in the current directory that is not managed by git.
--untracked
In addition to searching in the tracked files in the working tree, --scan also in
untracked files.
<files>...
The path to one or more files on disk to scan for secrets.
If no files are provided, all files returned by git ls-files are scanned.
Examples
Scan all files in the repo:
git secrets --scan
Scans a single file for secrets:
git secrets --scan /path/to/file
Scans a directory recursively for secrets:
git secrets --scan -r /path/to/directory
Scans multiple files for secrets:
git secrets --scan /path/to/file /path/to/other/file
You can scan by globbing:
git secrets --scan /path/to/directory/*
Scan from stdin:
echo 'hello!' | git secrets --scan -
Options for --list
--global
Lists only git-secrets configuration in the global git config.
Options for --add
--global
Adds patterns to the global git config
-l, --literal
Escapes special regular expression characters in the provided pattern so that the
pattern is searched for literally.
-a, --allowed
Mark the pattern as allowed instead of prohibited. Allowed patterns are used to
filter our false positives.
<pattern>
The regex pattern to search.
Examples
Adds a prohibited pattern to the current repo:
git secrets --add '[A-Z0-9]{20}'
Adds a prohibited pattern to the global git config:
git secrets --add --global '[A-Z0-9]{20}'
Adds a string that is scanned for literally (+ is escaped):
git secrets --add --literal 'foo+bar'
Add an allowed pattern:
git secrets --add -a 'allowed pattern'
Options for --register-aws
--global
Adds AWS specific configuration variables to the global git config.
Options for --aws-provider
[<credentials-file>]
If provided, specifies the custom path to an INI file to scan. If not provided,
~/.aws/credentials is assumed.
Options for --add-provider
--global
Adds the provider to the global git config.
<command>
Provider command to invoke. When invoked the command is expected to write
prohibited patterns separated by new lines to stdout. Any extra arguments provided
are passed on to the command.
Examples
Registers a secret provider with arguments:
git secrets --add-provider -- git secrets --aws-provider
Cats secrets out of a file:
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:
Just as it is a bad practice to add prohibited patterns that are too greedy, it is also
a bad practice to add allowed patterns that are too forgiving. Be sure to test out your
patterns using ad-hoc calls to git secrets --scan $filename to ensure they are working
as intended.
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
• Author: Michael Dowling
• Issue tracker: This project's source code and issue tracker can be found at
https://github.com/awslabs/git-secrets
• Special thanks to Adrian Vatchinsky and Ari Juels of Cornell University for providing
suggestions and feedback.
Copyright 2015 Amazon.com, Inc. or its affiliates. All Rights Reserved.
GIT-SECRETS()