Insight

Secrets in source code

Dangerous and common

Andrew Casillas

Andrew Casillas

Associate Advisory, Cyber Security Services, KPMG US

+1 469-288-6038

Caleb Queern

Caleb Queern

Director, Cyber Security, KPMG US

+1 571-228-8011

Large organizations depend on software development to help drive business goals. Most aspire to deploy high quality, low risk code frequently in small batches to make them more competitive. Unfortunately, the software development life cycle (SDLC) is complex and prone to mistakes that can ultimately lead to expensive cyber security incidents. Among the common pitfalls is the tendency for developers to leave “secrets” written directly in software code. In this context, secrets is a term broadly used for bits of information you wouldn’t want others to know, including:

  • Credentials (i.e. usernames and passwords)
  • API keys or tokens
  • Private keys (RSA keys in particular)
  • Certificates
  • Database connection strings

The behavior of leaving such details unprotected and visible in codebases is known as “secrets sprawl”. Such leaked secrets increase the likelihood that an attacker discovers them and leverages the secret for unauthorized access, resulting in an expensive cyber security incident.

How does this happen? Despite increased adoption of DevSecOps preventative controls such as privileged access management and application security code scanning, several factors can lead to developers writing secrets directly in a codebase:

  • Developer inexperience with new SDLC technologies
  • Urgency to rapidly deploy code in a fast-paced work environment
  • Software developers utilizing their personal repository for work purposes

Even if a developer can catch their mistake, they may tend to simply make a commit to the repository to “remove” the exposed secret when this only buries the exposed secret deeper within the commit history where it can still be found by an attacker and used for malicious activity. Such incidents cost the organizations money, time, customer confidence, and reputation.

The good news is that options exist for identifying secrets in existing code repositories. Because manually sifting through code in search of secrets is unlikely to be time well spent, there are technical solutions that scan repositories and search through the latest commit and commit history looking for exposed secrets. Some products are available through commercial vendors while several popular options are available as open-source software tools. Modern Software-as-a-Service source code management platforms may even provide options for continuous detection of secrets across all one’s repositories.

Quick takeaways for reducing the risk presented by secrets sprawl:

  1. You cannot assume that because code is “behind the firewall” that it’s safe. Modern zero trust security assumes that attackers are indeed already inside one’s network. Err on the side of caution, be proactive, and develop a secrets scanning strategy that’s right for your organization before an urgent situation requires you to do so.
  2. Scanning for secrets in your highest priority applications alone is not okay. While it may be tempting to only scan the codebases of one’s highest priority applications, don’t forget that a secret in a seemingly obscure, low priority codebase can still grant an attacker access to a valuable part of one’s environment which they may use for surreptitious activity.
  3. Scanning for secrets in your highest priority applications first is okay. Scanning for secrets across an organization can be time intensive, so a risk-informed plan for identifying secrets in code repositories might prioritize the most important and actively developed codebases first.

While CISOs and CIOs have no shortage of work, collaborating to identify and clean up hard-coded secrets in software repositories is worthwhile, can be manageable and should reduce significant risk, allowing the organization to better focus on business goals like growth.