Storing and managing secrets like API keys and other credentials can be challenging, even the most careful policies can sometimes be circumvented in exchange for convenience. We have compiled a list of some of the best practices to help keep secrets and credentials safe. Secrets management doesn’t have a one-size-fits-all approach so this list considers multiple perspectives so you can be informed in deciding to, or not to, implement strategies.
- Never store unencrypted secrets in .git repositories
- Don’t share your secrets unencrypted in messaging systems like slack
- Store secrets safely
- Use encryption to store secrets within .git repositories
- Use environment variables
- Use "Secrets as a service" solutions
- Restrict API access and permissions
Never store unencrypted secrets in .git repositories
It is common to wrongly assume that private repositories are secure vaults that are safe places to store secrets. Private repositories are not appropriate places to store secrets.
Private repositories are high value targets for bad actors because it is common practice to store secrets within them.
In addition, .git is designed to sprawl. Repositories get cloned onto new machines, forked into new projects and new developers regularly enter and exit a project with access to complete history. Any secrets that exist within a private repository's history will exist in all new repositories born from that source.
If a secret enters a repository, private or public, then it should be considered compromised.
A secret in a private repo is like a password written on a $20 bill, you might trust the person you gave it to, but that bill can end up in hundreds of peoples hands as a part of multiple transactions and within multiple cash registers.
Avoid git add * commands on git
Using wildcard commands like
git add *or
git add . can easily capture files that should not enter a git repository, this includes generated files, config files and temporary source code.
Add each file by name when making a commit and use git status to list tracked and untracked files.
According to git-scm:
“Remember that each file in your working directory can be in one of two states: tracked or untracked.
Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. In short, tracked files are files that Git knows about.
Untracked files are everything else.”
- Complete control and visibility over what files are committed
- Reduces the risk of unwanted files entering source control
- Requires thought and consideration when adding files
- Takes additional time when making a commit
- Can mistakenly miss files when committing
TIP: Committing early and committing often will not only help navigate file history and break up otherwise large tasks, in addition it will reduce the temptation to use wildcard commands.
Add sensitive files in .gitignore
To prevent sensitive files ending up within git repositories a comprehensive
.gitignore file should be included with all repositories and include:
- Files with environment variables like .env or configuration files like .zshrc or .config
- Files generated by another process (such as application logs or checkpoints, unit tests / coverage reports)
- Files containing “real” data (other than test data) like database extracts.
Don’t rely on code reviews to discover secrets
It is extremely important to understand that code reviews will not always detect secrets, especially if they are hidden in previous versions of code. The reason code reviews are not adequate protection is because reviewers are only concerned with the difference between current and proposed states of the code, they do not consider the entire history of the project.
If secrets are committed into a development branch and later removed, these secrets won’t be visible or of importance to the reviewer. The nature of git means that if a secret gets overlooked in history it is compromised forever as anyone with access to the repository can find this secret in previous revisions of the codebase.
TIP: As a rule, automation should be implemented wherever predefined rules can be established, like secrets detection. Human reviews should be left to check code for errors that cannot be easily predefined, such as logic.
Use automated secrets scanning on repositories
Even when all best practices are followed, mistakes are common. When dealing with highly sensitive data, no chances should be taken. GitGuardian offers a free secrets scanning solution for developers which should be installed on both private and public repositories.
Visibility is the key to great secret management, if you don’t know you have a problem, you cannot take action to fix it. Secrets scanning provides essential visibility over your internal systems.
It is important to also consider that even the best secrets management systems and policies do not prevent newly generated secrets entering the code base or old secrets being extracted and included again.
- Difficult to circumvent and ignore compared to tools that need to be manually run
- Much faster and more accurate than relying on human checking
- Can detect secrets buried within logs and history that manual reviews and searches will not uncover
- Live scanning ensures all active data leaks are captured