Secrets leaks have become a disturbing trend on GitHub, and may pose a serious risk to your organization's software supply chain. Developers are leaving secrets such as login credentials, API keys, SSH keys, encryption keys, and database passwords exposed in their code and comments. Unfortunately, those secrets are an integral part of any application — and a prime target for threat actors to discover when stored in code repositories.
Once attackers discover those secrets they can use them to launch a variety of attacks on a the target organization, such as accessing sensitive information and trade secrets, and escalating a user's system privileges.
The secrets problem came to light recently after GitGuardian, an automated secrets detection and remediation tool vendor, issued its State of Secrets Sprawl 2023 report (registration required). Out of more than a billion new commits to GitHub that the company scanned it discovered 10 million secrets occurrences. Overall, one in 10 code authors had exposed a secret in 2022.
What's more, 80% of all secrets caught by live monitoring of GitHub were exposed through the personal repositories of developers, and a large share of those were corporate secrets.
The recent secrets exploit at CircleCI and other recent hacks show just how vulnerable secrets on the software supply chain have become. To tackle the problem you'll need to take an end-to-end security approach. Here's why.
[ See special report: Secrets Exposed: An Essential Guide for Securing Secrets in Software ]
Even finance services apps are leaking secrets
GitGuardian isn't alone in noticing secrets sprawl and the danger it poses to supply chain security. Earlier this month, Approov Mobile Threat Lab's analysis of the top 200 financial services apps in the United States, United Kingdom, France, and Germany found that 92% of those programs contained easy-to-extract secrets that could be used in scripts and bots to steal data. Within that group, cryptocurrency apps were more likely than other programs to leak secrets: 36% offered highly sensitive secrets when scanned.
A significant driver of secrets sprawl can be found in the DNA of modern applications, which are constantly accessing other systems in many ways, such as through APIs. You need a handshake to establish those communications, and that handshake is controlled by way of a secret, such as a user credential or encryption key. The many connections deployed in modern applications—part of the architecture of modern software—are a major contributor to the explosive growth of exposed secrets.
Modern application architecture is also one reason why so many secrets are exposed in software. Today's applications are complex systems that are segmented during development. Every developer works on their piece of the architecture, and all of the developers must communicate with each other.
All of that communication requires secrets, so developers create lots of secrets all the time. When you consider the proliferation of secrets and segmented workflows, it's easy to understand how developers may lose track of secrets created during the course of a project.
Devs don't have the time to catch flaws
Modern application development also makes it difficult to protect secrets. The acceleration of software development fueled by DevOps has nudged code warriors away from home-grown code and toward the use of other developers' code — both third-party and open-source. After all, no one wants to continuously reinvent the wheel when there's an open-source version available. That needs to be checked.
Unfortunately, the speed at which new iterations of software are being introduced often prevents developers from performing holistic security checks. Organizations are so concerned with increased functionality and speed of release that, despite good intentions, things meant only for testing make their way into production. If an application works, it's pushed out the door and into the wild, leaving flaws such as unencrypted S3 buckets, test passwords and user accounts exposed.
While time constraints limit how much effort developers can invest to find those flaws, hackers have all the time in the world to discover them.
Not all exposed secrets post a high risk — just because something is a secret doesn't necessarily mean an attacker can use it to access something important. Nevertheless, hard-coded secrets have become a dangerous epidemic in the software supply chain.
Your best solution: An end-to-end approach to secrets security
Many organizations, in attempting to protect secrets and their software supply chains, fail to take into account the complex architecture of modern applications. Too often they focus on one thing, such as uncompiled code or API security, or software composition analysis (SCA), which focuses on open-source packages.
SCA is an important lens, but it's only one piece of the puzzle — it can't cover the entire technology stack that makes up the application. Rather than examining a slice of the application and ignoring the entire communication and architectural flow, organizations need to look at the entire application.
Pursuing a holistic approach to software supply chain security is the only way to bring the problem of secrets sprawl under control. Through defense-in-depth — addressing all the activities associated with supply chain and application security risk — you can avoid looking at the problem through a single lens and get a true picture of the risks in your supply chain.
