Well, all of the sensible answers can be summed up in one simple rule:
There is just no safe way to commit passwords or other sensitive values into a Git repository that will be cloned by a rotating cast of developers. And there is no foolproof automated way of catching such mistaken commits. So all the advice has to be built around these concepts:
- Preventing your developers from doing this;
- Detecting it quickly when they do;
- Remediating any lapses that get past your measures.
So the advice I can give is:
You need developers who give a damn
If your developers just don't give a damn about correctness and security, then abandon all hope. You can lead a horse to water but you can't make it drink.
Careful, thorough code review
Even if you have a developers who do give a damn, they will likely still slip up now and then. This means that your developers need to review each other's code, spot the mistakes and require them to be fixed.
Top-notch developer automation
Why do your developers need sensitive passwords in the first place? In my experience, this is a symptom that the developer automation is lacking. For example, a common scenario is that the application interacts with an RDBMS and so, a shared database is created somewhere and developers need credentials to log on to that.
So fix that. Use a tool like Docker or Vagrant so that your build scripts provide your developers with local, throw-away instances of all the external resources the application needs, with minimal need to configure connection strings or usernames or passwords or anything.
Code analysis tools
There are analysis tools that are able to assist such a review process by inspecting your code and guessing spots where there might be trouble. These tools can never be completely reliable; they will produce some false positives and miss some real issues. Some of the tools are also just bad, so evaluate anything carefully before you commit to it. I evaluated SonarQube on Java programs and was generally impressed with it; it does contain some rules to search for possible security weaknesses. (I have no affiliation with the company.)
Secret management tools
Instead of writing your programs so that they read secrets from environment variables or configuration files (or even worse, hardcoded secrets!), write them so that they obtain them from a secret management system like Vault or Keywhiz. This does however require your developers to work a bit harder to learn the tool and integrate with it—which in turn requires them to give a damn.
Standardize secret management
If you don't adopt a tool like Vault or Keywhiz, you should still nevertheless standardize the mechanism whereby your applications access passwords and other secrets. For example, require all of your applications to read their passwords from a file named
appname-credentials.json. Then you can:
- Have your code reviewers reject any code that doesn't follow the practice;
- Add a rule to
.gitignore to reject any file names that meet that pattern.
Structure your codebase to provide a "safe" location for sensitive files
("Safe" in scare quotes because while this is incrementally safer than lots of codebases I see, it's not really all that safe...)
One problem I keep seeing in many Java applications is that they obtain all their configuration from configuration files that get bundled with the application's JAR or WAR archive. They do this because:
- Popular Java build tools like Maven or Gradle provide a default, conventional mechanism for bundling such configuration files;
- Popular Java frameworks make extensive use of such files and make it very easy to access them;
- Developers, more often than not, just don't give a damn about security or correctness.
One trick that has been used in many projects that I've been part of is to configure the build tool so that it, in addition to the default locations, it also bundles configuration files from an another, project-standard location that has a
.gitignore file that prevents anything in there from ever being checked in.
This still has a weakness: the passwords don't get checked in, but they get bundled into the application archive files that your developers build. If they then hand those out to external people, they've disclosed passwords.