We are proud to announce the launch of the GitGuardian Labs innovation platform, a springboard for GitGuardian’s future projects and a place to share with the open-source community.

On this occasion, we had the pleasure to discuss this initiative with Eric Fourrier, GitGuardian's CTO & co-founder.

Eric, can you explain to our readers why you decided to launch GitGuardian Labs?

Since the beginning of GitGuardian in 2017, our DNA has been to experiment. Although our two solutions, GitGuardian Internal and Public Monitoring, have today reached a level of maturity widely recognized by our partners, it is important to continue exploring new avenues that will improve security and its adoption by the greatest number in the years to come.

The Labs will allow us to offer a common foundation for all our current and future initiatives to improve the global vision of security in the open source community. And we're hardly short of ideas on that front!

What are the objectives?

The objective is for us to keep momentum in bringing security best practices, tactics, and tools to the masses while remaining as relevant and user-friendly as ever. I believe that the threat landscape is witnessing one of its biggest transformations yet, and developers are now stage and center when it comes to protecting organizations.

That's why we committed to replicating the huge success that was GitGuardian's very first global scale operation, the "Good Samaritan", in other areas of the immensely complex digital world of today.

(Good Samaritan project: Since late 2017, GitGuardian has been watching over more than 40 million developers’ shoulders by notifying them every time they leaked a secret on a public GitHub repository, ed.).

Can you briefly present the newest projects?

We have already embarked on two innovative tools in this new venture: ggshield for Docker, and ggcanary.

The first one is an extension of our powerful CLI to run deep scans on any Docker image and easily parse potential secrets forgotten through the image creation process. This is an attack surface that is still too often ignored, even though a major incident last year showed that it could be easily exploited (the supply chain attack against Codecov, ed.).

With ggcanary, the approach was different. We asked ourselves: "OK, right now we are the developers' Cassandra—how could we enable folks to be pro-active, rather than reactive, in securing their source code?". The result is a project that eases the generation of decoy tokens to detect intrusions into environments, repositories, messaging systems, etc.

In my opinion, the true power of this tool lies in its ability to scale with automation. This opens up very interesting perspectives, such as the possibility of shifting left at every step of the SDLC—and every engineer could be responsible for their own link in the chain.

To finish, I know that you have a funny story about the early days of GitGuardian. Are you ok to share it?

Yes, the story goes back to the time when we were just starting to explore GitHub's public repositories with Jeremy (Thomas, GitGuardian's co-founder, ed.). One day, while I was looking at the logs to see which keys had been spotted, I came across credentials associated with a US governmental organization email. I couldn't believe my eyes. We immediately tried to contact the corresponding person to have them revoke the key, but there was no response.

After insisting for several days, the incident finally escalated to the security team, but we could sense that there was a great deal of misunderstanding about the causes and consequences of this leak, although it was simple to remedy. That's when we really grasped the magnitude of the problem we were trying to solve.

Thank you for your time!

You're welcome.