Understand how secrets end up exposed, and how to prevent this risk.
Secrets are extremely pervasive in software development environments, and their exposure is one of the most common risks unearthed by the Legit platform. This is troubling because secrets are often the first foothold that attackers leverage to mount much larger attacks.
The types of exposed secrets we find most often include:
And exposed secrets are not just a hypothetical risk. In a recent survey of 350 IT and cybersecurity professionals and application developers, TechTarget's Enterprise Strategy Group (ESG) found that the top cybersecurity incident (related to internally developed cloud-native apps) experienced by survey respondents in the previous 12 months was secrets stolen from a source code repository.
We regularly find exposed secrets in source code, which can be accessed by any user with access to the repository.
But increasingly, we are finding exposed secrets in many other places as well -- like yaml files, build logs, containers, bash scripts, artifacts, Jira, Confluence, Slack, and more.
Secrets sprawl has become a significant issue in modern development, largely due to the increasing complexity of tools and integrations required to build and run applications. Modern apps depend on hundreds of secrets -- such as API keys, third-party tokens, and cloud credentials -- to function effectively.
At the same time, developers face pressure to innovate and deliver code quickly, often resorting to shortcuts to save time. One common shortcut is embedding secrets directly into code during development to streamline testing and quality assurance (QA).
The problem arises when these secrets are unintentionally left exposed. For instance, a developer might use a key during testing and move the code into production without removing or replacing it. Whether it's due to oversight or convenience, this practice leaves secrets exposed, creating a continuously growing risk to the organization.
A significant data breach at Sisense was traced back to an accidental exposure of sensitive data via a GitLab repository. A hardcoded secret in the repository provided unauthorized users access to Sisense's cloud storage, leading to the compromise of vast amounts of customer data.
Toyota announced a data breach caused by a subcontractor who accidentally published source code containing a hardcoded secret access key on a public GitHub repository. This exposed the personal data of nearly 300,000 customers, highlighting the risks associated with insufficient security practices around sensitive information management.
Focus first on SaaS services keys (e.g., AWS access keys), since if code is leaked, credentials to SaaS services are immediately usable if they are valid, whereas internal credentials require attackers to also have network connectivity.
Our recommended best practices include:
Avoid committing secrets to any Git repository. Once in the Git history, remediation steps are lengthy:
Change the source code to not rely on hard-coded secrets by using a password manager, environment variable, etc. Then revoke the sensitive data.
Use encryption to store secrets within Git repositories.
Use local environment variables, when feasible.
Use secrets as a service solutions (e.g., Hashicorp Vault, CyberArk Conjure, etc.).
Avoid secrets within build logs and sharing secrets via messaging services.
Reduce AuthZ and Admin credentials to least privileged.
As development environments grow increasingly more complex, they introduce more risk, such as vulnerable code or misconfigurations of build tools. Managing secrets effectively becomes critical in safeguarding your organization against potential threats.