We often work with sensitive information, such as API keys or passwords. It is essential to maintain the confidentiality of this secrets and prevent unauthorized access.
Despite our best efforts, accidents do occur, resulting in the unintentional exposure of secrets.
- 7 commits out of 1,000 exposed at least one secret.
- 4.6% of active repositories leaked a secret.
- 11.7% of authors who contributed leaked a secret.
At times, we may overlook adding a file containing secrets to .gitignore, leading to its accidental push to the repository.
We might unintentionally neglect to replace a secret with a placeholder.
There are moments when we hastily push changes without considering secrets.
Additionally, there are instances when we attempt to handle the addition of a secret by removing it from git, without promptly rotating the secret itself.
In certain cases, we may not even realize that we are dealing with a secret, such as when copying URIs containing access keys.
This oversight results in inadvertent disclosures of sensitive information. It's important to acknowledge that we are all human and susceptible to these oversights.
Recognizing such events and taking appropriate action is vital. This document outlines the procedure, and should you require assistance or feel uncertain, we encourage you to reach out for help. Asking for assistance is a responsible and proactive approach, and you can do so either through your NOC by requesting to initiate a security incident, or by directly contacting your security department.
It is crucial to promptly invalidate the exposed secret and replace it with a new secret. This is also known as secret rotation. It minimizes the risk of unauthorized access and potential misuse. This step is prioritized as the first action to be taken in response to the identification of compromised credentials.
It's natural for people to believe that turning a repository private or assuming that secrets won't be found is enough. However, it's important to understand that this approach is not sufficient and doesn't follow the best security practices. Research from 2024 revealed that over 90% of leaked secrets remained valid after 5 days. Additionally, the fastest breach in 2023, fully automated, occurred a mere 2 minutes after a secret was leaked to a repository. Actively addressing the exposure of secrets is essential. Relying only on secrecy or obscurity is not sufficient.
Summarized: Do always rotate any exposed secret. Really, do it always. There is no valid exception.
There are several ways to remove secrets from git: tools such as BFG Repo-Cleaner and git-filter-repo allow to rewrite the commit history of the repository and remove references to the secrets. However, and this knowledge is not widely spread: Git != Github.
Warning: Utilizing tools to remove sensitive data does not entirely eliminate the secrets from GitHub. Following the push of your changes to GitHub, additional steps are necessary to have them fully removed. In addition, dereference and garbage collect all objects in your local repository.
You can read more about these tools in the GitHub documentation.
It is not always possible or practical to entirely remove rotated secrets from GitHub. Especially when dealing with existing repositories with extensive history - means the inadvertently exposed secret has been present for a long time. In such cases, in case the rotated secret must be removed under all circumstances from Github, it is better to create a new repository with a clean history. This eliminates all data containing secret, that are not directly stored in Git, such as deleted feature branches in GitHub.
Summarized: Remove secrets if feasible. This is particularly manageable when responding within a few hours after exposure. Don't hesitate to seek assistance if necessary.
It is very often unnecessary to remove the discovered secrets from the entire Git history and from GitHub, if they have been rotated. Especially for existing older repositories, it is often a better approach to rotate the secrets, and after rotating to include them in an exception list instead rewriting the history. This approach allows such secrets to still be detected by scanners, but such matches will not be reported as a security breach. The same process is useful in the case of mistakenly identified secrets, also known as false positives. The exact process depends on the scanner in use. As example gitleaks: add a .gitleaksignore file.
Summarized: If secret removal is not appropriate in GitHub, or false positives occur, mark them accordingly so that automated tools can handle the situation.
Accidental exposure of secrets in a Git repository poses a security risk, but there are steps that can be taken to address the situation:
- Promptly rotate any exposed secrets.
- If feasible, remove the exposed secrets from the repository.
- Tag the rotated secrets, if removal is not possible or necessary.
In summary, it is important to acknowledge the human aspect of these oversights, recognize in case it happens, and take appropriate action in response to the exposure of secrets. Seeking assistance can expedite the steps needed to address and mitigate the exposure of sensitive information.