By definition, secrets such as API keys, OAuth tokens, passwords, or certificates are highly sensitive data. However, they are too often found on Git servers. But these secrets can give very extensive rights and open access to a large part of the information system, even to the most sensitive data, with catastrophic business consequences.
What are the solutions to store your secrets? How to detect the secrets present in your source codes? Astrakhan offers you a simple and efficient solution, what is it? Read our article below.
Secrets in source code
Secrets such as API keys, OAuth tokens, passwords, or certificates are by definition sensitive data. However, they are too often found on Git servers and are thus distributed and propagated to each new clone or fetch of the repository. This is however a bad practice and a well-known vulnerability listed in the OWASP Top 10 (A3:2017-Sensitive data exposure). Still, it is common for AWS Access Key and AWS Secret Key to leak into repositories on GitHub that can lead to big bills in the best case. You only have to look at this history to be convinced:
It is therefore all the more problematic that with the adoption of “Infrastructure as Code”, these secrets can give very extensive rights and open up access to a large part of the information system, even to the most sensitive data, with catastrophic business consequences.
Let’s add that once added in Git, a secret can’t be deleted anymore or with difficulty. To do so, it is necessary to be able to rewrite the Git history, to propagate the history in all the copies, and finally to make sure that git-GC is running to permanently destroy the objects concerned. Finally, revoking this secret is the only viable solution.
Different solutions are available to manage your secrets:
● A first category of tools offers symmetric encryption to store an encrypted version of your secrets in Git. This is the case for tools like Sealed Secret or Ansible vault for example.
● A second category comes in the form of vault services that allow you to manage your secrets, access them from your applications, organize their rotation and track exactly who is consuming them. Cloud providers all offer this service under the name of Secret Manager for AWS and Google Cloud or Key Vault for Azure, which is also available on-premise with Hashicorp key vault.
● Finally, if you are working on a Cloud project with managed services, Cloud providers offer libraries to use in your source code based on IAM authentication. The latter authorizes the connection to its services without requiring any secret. It consists of creating and attaching an IAM role to your application. This role allows access to a database or any other service supporting this type of authentication.
The last solution with IAM authentication is recommended, ahead of the use of a vault service, itself ahead of the use of symmetric encryption.
Detecting secrets in your source code
Git Secrets, Truffle Hog, Git Leaks, GitLab/GitHub Watchman, tools are multiplying to help you detect and protect your sensitive data by scanning your Git repositories.
To avoid the introduction of new secrets, one solution is to integrate one of these tools into your CI/CD pipelines. Since new developments are made on feature branches that are submitted for review before being merged to the “master” (or “develop”) branch, the objective of the CI/CD is to block any feature branch merge that contains secrets to keep a clean Git history on the “master” branch.
If this solution is interesting to monitor one repository, what about if you have hundreds of them?
At Astrakhan, we suggest a simple and efficient solution through this script that will perform the following steps:
● Recursively list all the projects of a GitLab group
● Run Git Leaks on each project
● Transform the Git Leaks report into a JUnit XML report integrated and rendered via the GitLab interface
And even send (or comment in the shared version) the detected secrets to Splunk or your monitoring solution to allow a follow-up through the dashboards and also the implementation of alerts in the form of email notifications to the authors of the concerned Git commits.
