Good development practices to reduce the risks of leaking a secret.
- Avoid git add * commands
- Name sensitive files in .gitignore and .npmignore
- Store your secrets in a safer place
- Use temporary credentials
- Whitelist your IPs
- Restrict permissions associated with your keys
- Protect your development / testing secrets as well as your production secrets
- Don't share secrets over emails, Slack, Skype, etc.
- Use GitHub scanning tools
Using wildcards can easily capture files you do not want to share.
Instead of wildcards, name each file you want to add, for example, git add README.MD. Before committing your changes, use git status command to list track and untracked files. When you commit with git commit, your untracked files will not end up in source control.
GitHub published a collection of useful .gitignore templates.
See these examples for Python or Go.
Here are some filenames that are frequently associated with leaks: .travis.yml files, Dockerfiles, docker-compose.yml, .env files, config.py, .zshrc, Jenkinsfiles, ...
If you use npm to develop your project, see how to use .npmignore.
When possible, use environment variables to hold your sensitive tokens, keeping these out of source control.
If you use Heroku, see how to use environment variables: Heroku configuration variables.
Advantages
It's simple.
Disadvantages
This approach may not be feasible at scale because there is no way to easily keep developers, applications and/or infrastructure in sync.
Advantages
- Your secrets are synced.
Disadvantages
- You have to deal with your encryption keys securely.
- No audit logs. Your .git repos will be cloned by multiple developers, applications or servers. Soon your secrets will spread your organization, and you will lose track of where they are and who has access to them.
- No groups that let you easily specify permissions for multiple users.
- Hard to rotate access. Rotating access implies to revoke the key and redistribute it. The distribution part is not easy to handle with git repositories.
There are secrets management services like Hashicorp's Vault or Square's Keywhiz.
Advantages
Centralization really has a few advantages:
- It prevents secrets sprawl.
- It provides audit logs.
Disadvantages
The main disadvantage of these solutions is the cost of adoption. Their overhead is significant:
- As they introduce a single point of failure, they must be hosted on a highly-available and secure infrastructure.
- All the codebase must be changed.
- Keys giving access to the system must be carefully protected.
Some API providers make it possible to issue credentials with an expiration date.
For some API providers, you can add an extra layer of security by whitelisting your organization's IP addresses.
It is very rare to have to generate root access keys (with full permissions). Some API providers allow granular permissions to their endpoints, enable read/write splitting or role-based access control.
A rule of thumb: accesses should be granted on a need-to-know basis only.
This is a common mistake. The line is not clear between development, testing, and production secrets. Production secrets can end up in development/testing and vice versa.
Yes, these services were designed to keep your conversations private. No, they were not designed to store your secrets in plain text.
Ever had one of these long email conversations forwarded to you with information that was not meant to be shared buried in the thread?
Don't encourage copy-pasting secrets in multiple places. This increases the surface area for hacks.
Keep in mind that why the good development practices exposed above help you reduce the risk of a leak, none of these actually prevent your secrets from being pushed to GitHub. Because good development practices are sometimes ignored.
We are the authors of a GitHub scanning tool called GitGuardian.