Is a secret still present in your git history? Verify in the blink of an eye.
Knowing is half the battle, remediating is the other half — and we’re here to help you with both.
Today, we’re introducing Presence Checks in GitGuardian for Internal Repositories Monitoring. For each incident in the dashboard, users will now be able to verify if the leaked secret is still present or if it was completely removed from the git history.
How does the Presence Check work?
A secret incident is made of one or several occurrences. Each occurrence is attached to one repository and one commit at a time, ensuring it is unique. It is the presence of such a commit, in the full repository’s history that GitGuardian verifies.
Technically, GitGuardian’s Presence Check is an API call to your VCS (GitHub, GitLab, or Bitbucket) to fetch the commit attached to the incident occurrence. If the API call returns an error with a status code 404 (Not Found), it means that the commit (or the repository) has been deleted.
How does this help you?
Use case 1 — Prioritizing your incidents
In the Incidents section of your dashboard, you can find a table listing all your secrets incidents and the total number of occurrences for each. Additionally, the count is now split between the occurrences still present in your git repository and the ones that have been rendered non-existent (following deletion of the repository or rewriting of the git history).
For example, removing all traces of the secret in your git repositories may be one of your organization’s requirements for complete incident remediation. If that is the case, you can now filter your incidents to only view the ones still present in the git history.
Use case 2 — Obtaining proof of deletion
For security teams
With the Presence check, it is possible to verify the presence (and thus reachability) of every occurrence of the leaked secret in your git repositories. For each incident, GitGuardian displays the dates at which each occurrence was first and last seen and if it is still present or not in the git history.
GitGuardian will regularly check for the presence of occurrences, to the best of its ability and considering existing VCS API rate limits, to mirror the state of your git repositories. You can also manually run the Presence check should you need to force update the status of the occurrences of an incident.
Once you have deleted the repository or rewritten the git history, return to your incident's page to obtain the secret's occurrence proof of deletion. When the occurrence is removed from the git history, GitGuardian will stop checking for its presence.
⚠️ Important — Remediation always starts with revoking and rotating the secret. Rewriting the git history to delete all evidence of the leaked secret is an optional step and should never be considered sufficient to mitigate the initial threat. To learn more, read our guide Exposing secrets on GitHub: What to do after leaking credentials and API keys.
For developers
If you choose to put your developers in the loop for the incidents they are involved in, they will receive a link to a feedback collection form.
On this form, GitGuardian will now display the total count of occurrences and the status of their presence in the git history. Developers rewriting the git history will now be able to verify on their end if the occurrences have been completely removed.
What’s next?
Alert fatigue is real and we are aware security professionals are overwhelmed by the volumes of alerts they receive from all the tools across their stack. Making sure GitGuardian doesn’t strain their attention any further and provides them with the right information to prioritize or put an incident on hold is one of our pillars in product research and development.
In our upcoming sprints, we will work on introducing Validity checks. For each incident and when possible, GitGuardian will perform a non-intrusive API call to the service provider to check the validity of the leaked secret.
Sign up below to stay up to date with our progress.
