Security First, Transparency Always: Inside GitGuardian's Responsible Disclosure Process

Since its creation in 2017, GitGuardian has automatically detected secret leaks in all public commits on GitHub, and sent warning emails to the developers concerned through its Good Samaritan Program. Although this method is efficient and enables secrets to be revoked quickly, it does have certain limitations. Indeed, there are a number of problematic scenarios. For example, a secret may be deleted from GitHub following our email, but remain valid because it has not been revoked. Likewise, a secret may belong to a company, and the person who leaked it is no longer part of it or is a contractor who doesn't know how to deal with it.

Overall, we find that 70% of the valid secrets we detect are still valid 3 years after their initial exposure. This clearly requires a call to action, as leaked corporate secrets are probably not being remediated as they should be. As a matter of fact, the most sensitive secrets we uncover are, unsurprisingly, linked to the critical components of modern business: code and artifact repositories, databases or virtual machines. Their exploitation is often straightforward, yet they represent a direct and major security risk.

Responsible Disclosure

Aware of the potentially devastating impact of some of the highly sensitive secrets we uncover, such as those of private Artifactory instances or Azure Storage Accounts, to name but a few, we have decided to overcome the limitations mentioned above by identifying corporate secrets and contacting the corresponding companies.

The secret to your Artifactory: A Deep Dive into Critical Exposures

In this context, the use of responsible disclosure practices makes perfect sense. Vulnerability disclosure is a well-known and documented process that provides a structured approach to cybersecurity collaboration. By following well-defined rules and best practices, such as using encrypted emails, or respecting disclosure delays, organizations and cybersecurity researchers can effectively work together to remediate leaked secrets.

Six months ago, GitGuardian set up a clear procedure for notifying companies of leaks of sensitive secrets, based on two fundamental points.

Firstly, we are committed to ensuring that "security comes first." To achieve this, our first priority is to get in touch with the security teams who are best placed to assess and deal with the leak quickly. In our exchanges, we prefer to use GPG-encrypted e-mails to preserve the confidentiality of the data exchanged.

Secondly, the content of our exchanges is as transparent as possible. We present precisely where the leak is (i.e. GitHub, DockerHub, or private resources), the nature of the associated secret, how it can be detected, and whether it is valid or not.

Key Takeaways

In the time we've spent helping to fix tens of incidents, we've witnessed every kind of behavior: from a fix in minutes to no response at all. While some of the critical secrets we uncovered are still valid today, the positive outcome is that most of the leaks disclosed have been remediated, or will be soon.

Along, the clear responsible disclosure process that we put in place, we also maintain a dedicated registry that tracks the disclosed leaks and the state of the corresponding communications. This ensures fairness and transparency and makes it possible to externally audit this activity.

Since October, we have disclosed 24 leaks to an equivalent number of different companies. Most of them - 15 to be precise - have been resolved. This excellent result is due to the fact that we were able to contact the security teams of the companies concerned directly.

Of the 9 remaining leaks, 4 have been acknowledged and are currently under investigation. We are therefore very confident that they will be resolved too. For the other 5, we have received no response to our emails despite our efforts to find the right contact (i.e. a Staff Security Engineer, the CISO or the DPO). This is quite worrying as we are talking about large organizations putting their security at risk.

Like many other researchers, we also get much better response rates when security teams are contacted directly. Having an easily identifiable address makes it easier for researchers. This reinforces the need for every organization to identify the right contacts in the event of security incidents, and publish them on their sites or via ad hoc mechanisms such as the security.txt file. Sadly, a disclosure email concerning a 6-year-old secret from an oil company's Artifactory went unanswered. The leak, meanwhile, was silently fixed several months after its disclosure.

Public Acknowledgments

While some companies do not behave according to the accepted rules of responsible disclosure, and forbade us to communicate on our findings, others are exemplary in their communications with researchers and the way they credit them.

We are pleased to have worked closely with such companies, and honored to be credited in their hall of fame following the responsible disclosure of secrets leaks:

And this is just the beginning! We are proud to help build a safer world for both individual developers and companies.