The state of
Secrets Sprawl
per AppSec engineer in 2021
The growing problem of secrets sprawling in corporate repositories can only be solved by enabling collaboration between AppSec and Developers.
The growing problem of secrets sprawling in corporate repositories can only be solved by enabling collaboration between AppSec and Developers.
Ransomware and other large-scale cyberattacks (SolarWinds, Colonial Pipelines) or vulnerabilities (Log4Shell) have made headlines around the world. Software supply chain attacks have seen their number explode, and this comes as no surprise considering the plethora of vulnerabilities and misconfigurations found across software development environments.
Unsurprisingly, a lot of attacks start with the compromise of a leaked secret. Credentials are a nightmare for security engineers because they can end up in so many places: build, monitoring, or runtime logs, stack traces, and … git history.
The results of our 2022 Secrets Sprawl report comforted our view that the only way to address the challenge of secrets sprawling within corporate repositories is to enable a shared responsibility between AppSec and Devs.
Source code is a huge wealth of knowledge. It also happens to exist on pretty much every developer’s workstation, which they probably take home with them. You probably don’t want your secrets being all over the country.
Over 6M secrets detected in 2021
2x increase compared to 2020
On average, 3 commits out of 1,000 exposed at least one secret,
+50 % compared to 2020
It should come as no surprise that leaks are proportional to user adoption, and this is especially true for newcomers rapidly gaining in popularity.
‍
Supabase, which has consistently ranked in GitHub’s top-20 fastest-growing open-source startups and launched 50,000 databases in 2021 only, is a telling example. Another one is PlanetScale, a serverless database platform released in 2021 Q4, which immediately started appearing on our radars.
When it comes to open-source, GitHub certainly is the first platform that comes to mind. Yet it is not the only resource for code-sharing. Since Docker popularized the use of containers to package apps, its official public registry, Docker Hub, has become another developers’ favorite.
The layers making up Docker images are as many additional attack surfaces that can too easily be left out of the security perimeter. For attackers, it is yet another chance of finding an access vector, just as demonstrated by the Codecov breach.
This motivated us to conduct our first study on the extent of secrets sprawl in Docker Hub a few months ago. To deepen this first estimation, we reiterated the exercise, this time with a 5x larger sample. Here are our results:
In 2020, GitGuardian launched Internal Repositories Monitoring for Enterprise.Â
Monitoring thousands of repositories in real-time and scanning for the entire history of corporate codebases, we gained a realistic view of the state of application security in the DevOps era.
If there is a single conclusion to be drawn from the data, it is that
‍the amount of work required for both remediating real-time incidents and investigating leaks detected in the git history (which can still represent a threat) far exceeds current AppSec teams' capabilities.
Secrets detection is a very essential part of security. It’s one of the basics that you need to cover all the time. Otherwise, you’re going to expose your endpoints online and you’re going to suffer endless attacks. When it comes to application development, secrets detection is essential to a security program. You need to have it. Otherwise, you’ll fail.
On average, in 2021, a typical company with 400 developers and 4 AppSec engineers would discover
With each secret detected in 13 different places on average, the amount of work required for remediation far exceeds current AppSec teams capabilities (1 AppSec engineer for 100 developers).
Our intuition that private repositories permeate a false sense of secrecy, causing even more leaks to occur compared to public ones, could be confirmed:Â
Not only private repositories are more likely to be affected, but they also reveal the real magnitude of secrets sprawl.Â
I think people are getting more aware of secrets. [...] I think that it has had a positive impact on the culture itself. You’re only as good as the software you write, and you’re in for a world of hurt if you put the keys to the castle inside of that source code that could be somehow reverse-engineered. By separating the two, the source code and the keys, you’re one step ahead of that. I think it’s essential.
One core feature introduced in 2021, Developer in the Loop allows security engineers to share an incident with the developer who committed the secret. We are firmly convinced that a Shared Responsibility Model is key to enable application security at scale (security teams own the process, but developers are involved), and just a few months into the release the results already speak for themselves.
Start by monitoring commits and merge/pull requests in real-time for all your repositories with native VCS or CI integration, where the ultimate threat lies (shift at team level).
Progressively enable pre-receive checks to harden central repositories against leaks, and “stop the bleeding”.
In the meantime, educate about using pre-commit scanning as a seatbelt (shift at developer level).
Plan a longer-term strategy to handle older incidents discovered by the git history scanning.
Implement a Secrets Security Champion program.
If you want to learn more about how GitGuardian solutions can help you improve on code security, don’t hesitate to contact us.
The new ways of building software create the necessity to support new vulnerabilities and new remediation workflows. These needs have emerged so abruptly that they have given rise to a young and highly fragmented DevSecOps tooling market. Solutions are specialized based on the type of vulnerabilities being addressed: SAST, DAST, IAST, RASP, SCA, Secrets Detection, Container Security, and Infrastructure as Code Security. However, the market is fragmented and tools are not well-integrated into the developers’ workflow.
GitGuardian, founded in 2017 by Jérémy Thomas and Eric Fourrier, has emerged as the leader in secrets detection and is now focused on providing a holistic code security platform while enabling the Shared Responsibility Model of AppSec. The company has raised a $56M total investment to date.
With more than %ndowg%K installs, GitGuardian is
Its enterprise-grade features truly enable AppSec and Development teams in a collaborative manner to deliver a secret-free code. Its detection engine is based on %ndet% detectors able to catch secrets in both public and private repositories and containers at every step of the CI/CD pipeline.