How to Reduce Risk From Exposed Secrets

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:  

• Cloud keys (AWS/GCP)  

• GitHub personal access tokens and CI/CD server keys (Jenkins, ADO)  

• PII, such as Social Security and credit card numbers  

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.  

Where do we find exposed secrets? 

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.  

Why is secrets exposure pervasive?      

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. 

Related attacks

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.  

What we recommend to prevent exposed secrets  

 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:

• Avoid git add * commands. 

• Name sensitive files in .gitignore. 

• Don’t rely on code reviews to discover secrets. 

• Use automated secrets scanning on repositories.  

• Use CLI or pre-hook commit tools when able to catch secrets before they get to your Git repository.  

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.  

Understanding common SDLC risks  

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.   

Get our new guide on the top unknown SDLC risks we uncover to get a sense of the risks that might be lurking in your development environment, and how to address them.