Securing secrets is an endless and uphill battle. API tokens, cloud credentials, and database URLs have a terrible habit of getting exposed everywhere – from private repositories to CI job logs and Slack messages. And let's not forget those leaks tend to happen when your security teams least expect them, usually during "out of office hours" and far beyond your perimeter–think personal GitHub repos of your developers.
Matching your hardcoded secrets against millions of others leaked on GitHub.com.
For every secret that is found exposed in your perimeter (inside repositories that you own and that are hosted on GitHub, GitLab, Bitbucket, and Azure Repos or Slack channels and Jira projects), GitGuardian will now run an automated check to verify if that same secret was not found to have leaked publicly–in code, issues and gists of projects hosted on GitHub.com and located outside your organization's perimeter.
This isn't merely an update; it's a direct integration of our latest project HasMySecretLeaked into GitGuardian. HasMySecretLeaked is the cornerstone, storing every secret we find as we sift through billions of public GitHub commits. It holds more than 20 million secrets and keeps growing every day. Now, it seamlessly blends into our platform and gives you infinite visibility over GitHub and the activity of its hundred million developers!
Here's what it looks like
The Publicly leaked tag is your signal for quickly identifying incidents with exposure outside your perimeter. It's more than just a label; it's telling you that someone has leaked your secret in a project your organization didn't even know existed and that this secret is now visible to anyone on GitHub, including malicious bots and attackers.
In the example below, a valid Google API key was found twice inside the same file in a private GitLab repository (in two different commits). GitGuardian indicates this API key has leaked nine times outside the organization's perimeter!
Public leak checks are automatically run for open incidents where the secrets were found to be anything other than invalid (status = valid | has no checker | failed to check | unknown). Still, you also have the option to trigger a leak check if needed.
Beyond tagging incidents, the feature provides a comprehensive view of where a secret has been publicly leaked–up to 10 locations and their URLs (files, issues, or gists) are listed. This enriched context allows for investigation and validation of the leak before deciding what action to take and how to respond.
Treat your 'Publicly leaked' secrets first
Prioritization is critical when dealing with a growing pile of hardcoded secrets incidents. For this purpose, we recommend you harness the power of GitGuardian's enriched incident context by using filters on the secrets' validity, severity score, and tags, such as the new Publicly leaked one.
This can help you narrow your hundreds or thousands of exposed secret incidents to a few critical ones requiring immediate attention. If your GitGuardian workspace is on our Business plan, you can start filtering on the Publicly leaked tag right now.
Or first read more about this feature in the official GitGuardian documentation.
Yes, the severity scoring engine already takes it into account!
Public leakage is also included in GitGuardian's automated severity scoring feature. A new built-in rule designates a CRITICAL severity to non-invalid secrets leaked publicly no more than once. You can also customize these severity rules based on the number of places a secret has publicly leaked or create a new one.
Beyond your already hardcoded secrets: Check ALL your secrets
While tagging your incidents when secrets are found to have also leaked publicly is a significant leap forward, our commitment to your secrets' security goes beyond this. With HasMySecretLeaked, you can extend your protection to check ALL your secrets (in vaults, build pipelines, .env files, cloud provider built-in secrets stores, and many other places) for leakage on GitHub.com.
Read more about how you can achieve this with the help of ggshield, the GitGuardian CLI:
Ziad Ghalleb
