GIT-SECRETS(1)

📦
version 1.3.0 · 5 versions
, in fedora 43, fedora 44, nixos 26.05, nixpkgs unstable

💖 git-secrets 💖 (that's the manual page name, section 1, bestie — we're literally reading the GIT-SECRETS() page together rn)

okay so. real talk. this tool is the friend who slaps the coffee out of your hand before you commit your AWS keys to GitHub. let's get into it 💅

✨ NAME ✨

git-secrets — prevents you from committing passwords and other sensitive information to a git repository. that's it. that's the whole vibe. 🫶

🎀 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 🦋

like, the entire shape of the tool, no cap:

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 🌸

so git-secrets scans your commits, your commit messages, and your --no-ff merges, and its whole job is to stop secrets from sliding into your git repositories. if a commit, a commit message, or literally any commit in a --no-ff merge history matches one of the prohibited regular expression patterns you've configured — boom, the commit gets rejected. no keys in the repo, periodt. 🔥

🧚 INSTALLING GIT-SECRETS 🧚

git-secrets has to live somewhere in your PATH, okay? that's how git picks it up when you run git secrets. PATH placement is the whole assignment bestie, don't skip it.

⭐ *nix (Linux/macOS) ⭐

okay first, a little relic from the docs themselves — the original page literally ships with this build warning in it, so here it is, word for word, because I refuse to edit the historical record:

System Message: WARNING/2 (README.rst:, line 43) Title underline too short. \*nix (Linux/macOS) ~~~~~~~~~~~~~~~~~

anyway 💀 you can use the install target of the provided Makefile to install git secrets and the man page. and you can customize the install path using the PREFIX and MANPREFIX variables. slay.

make install

⭐ Windows ⭐

run the provided install.ps1 powershell script. this copies the needed files to an installation directory (%USERPROFILE%/.git-secrets by default) and adds that directory to the current user PATH. iconic behavior.

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. every. single. repo. no shortcuts.

here's a quick example of how to make sure a git repository gets scanned for secrets on each commit:

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

💜 ADVANCED CONFIGURATION 💜

add a configuration template 🎀

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

hooks for all your local repos 🦋

add hooks to all your local repositories:

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

custom providers 🍓

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 it's also possible to scan a repository including all revisions — like, every revision, the whole lore:

git secrets --scan-history

(still going bestie, do not close the tab 💅)

✨ OPTIONS ✨

🌸 Operation Modes 🌸

okay so real talk — each of these options must appear first on the command line. like, first first. no cutting the line, bestie 💅

  • --install — installs git hooks for a repository. once the hooks are installed for a git repo, commits and non-fast-forward merges for that repo get straight-up prevented from committing secrets. iconic protective behaviour, honestly 🛡️
  • --scan — scans one or more files for secrets. when a file contains a secret, the matched text from the file being scanned gets written to stdout and the script exits with a non-zero status. each matched line gets written with the name of the file that matched, a colon, the line number that matched, a colon, then the line of text that matched. if no files are provided, all files returned by git ls-files are scanned. it's giving thorough 🔍
  • --scan-history — scans the repository including all revisions 😭 the whole lore, every era. when a file contains a secret, same deal: matched text goes to stdout, script exits non-zero, and each matched line comes out as filename + colon + line number + colon + the matched line of text.
  • --list — lists the git-secrets configuration for the current repo or in the global git config. your receipts, basically 🧾
  • --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. little pattern-generating besties 🫶
  • --register-aws — adds common AWS patterns to the git config and makes sure keys present in ~/.aws/credentials are not found in any commit. the following checks get 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: okay so 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 make sure you do not commit credentials to a repository. no cap, do the work 💀
  • --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. rude but effective 💅
  • <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 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 pattern.
  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, 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 get ignored 🙈

-r cannot be used alongside --cached, --no-index, or --untracked. pick a lane, bestie.

  • --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 searches 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. global girlie behaviour 🌍

💜 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. sometimes you just mean it literally, y'know? ✨
  • -a, --allowed — mark the pattern as allowed instead of prohibited. allowed patterns are used to filter out 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 🌸

so egrep-compatible regular expressions are what's used to determine if a commit or commit message contains any prohibited patterns. these regular expressions are defined using the git config command. and it's important to note that different systems use different versions of egrep — for example, when running on macOS you'll use a different version of egrep than when running on something like Ubuntu (BSD vs GNU). yes, the vibes differ per platform, that's just how it is 😭

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

🎀 IGNORING FALSE POSITIVES 🎀

sometimes a regular expression might match false positives. for example, git commit SHAs look a lot like AWS access keys. the audacity 💀 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 expression 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. tidy ✨

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's 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 make sure they're working as intended. test your faves before you ship them, bestie 🫶💖

🔐 SECRET PROVIDERS 🔐

okay so sometimes you don't want a regex, you want to check against a literal list of secrets you already know about. like, you want to make sure no credentials sitting in ~/.aws/credentials ever end up in a commit. and honestly? in those cases it's way better to keep those secrets in one location instead of scattering them across git repos in git configs like some kind of chaos gremlin 🫠

that's where secret providers come in, bestie. a secret provider is just an executable that, when you invoke it, outputs prohibited patterns separated by new lines. that's it. that's the whole vibe check.

you add one with the --add-provider command:

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

✨ notice the -- ✨ — this is the main character of this paragraph. it makes sure that any arguments associated with the provider get passed along to the provider every single time it's invoked when scanning for secrets. no arguments left behind, periodt.

🧪 EXAMPLE WALKTHROUGH 🧪

let's actually walk through it, because this is where it gets good 👑

say you've got this subject text (stored in /tmp/example):

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

and you've registered these patterns:

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

now you run git secrets --scan /tmp/example and boom 💥 — you get this 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

so let's break it down 🔍 — the prohibited pattern value of password\s*=\s*.+ will match these two lines:

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

...but the first match gets filtered out, because it matches the allowed regular expression of ex@mplepassword. and since there's still one line left over that didn't match, the whole thing counts as a secret. sorry bb 😭

and here's the ✨iconic✨ part: because those matching lines are placed on lines that start with the filename and line number (like /tmp/example:3:...), you can totally build allowed patterns that take filenames and line numbers into account in the regular expression. so for example, you could whitelist an entire file with something like:

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

or, alternatively, allow just a specific line number of a file — if that line is unlikely to change — with something like:

git secrets --add --allowed '/tmp/example:3:.*'
git secrets --scan /tmp/example && echo $?
# Outputs: 0
⚠️ keep this in mind when you're creating allowed patterns, fr fr — you want to make sure your allowed patterns aren't inadvertently matched, because the filename is included in the subject text that allowed patterns get matched against. sneaky little detail, but it matters 💅

🙈 SKIPPING VALIDATION 🙈

use the --no-verify option when you hit a false positive match in a commit, a merge, or a commit message. this skips execution of the git hook and lets you make the commit or merge. it's giving "i know her, she's fine" — just don't abuse it, bestie 💀

🌈 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 🫶

and the legal bit, no cap: Copyright 2015 Amazon.com, Inc. or its affiliates. All Rights Reserved.

okay that's the whole page, bestie — you made it to the end 🎀 that little line down at the bottom of the original is just the footer doing its thing: it's the GIT-SECRETS() manual page slot, holding the source/version and the date. so like, consider it signed, sealed, delivered, and lowkey iconic. go forth and keep those secrets secret 💜✨

📦 where this page comes from