How to Prevent Credential Leaks in Source Code

TL;DR

Prevent credential-based breaches by scanning repositories for exposed secrets, rapidly revoking or otherwise addressing confirmed credentials, and stopping leaks before code is pushed. Secrets can appear in committed files, commit metadata, pull request comments, and issue descriptions, so protection must cover the entire software development workflow rather than only the latest version of a codebase.

Transcript

All right. Hello. All right, show of hands, who here has ever told anybody a secret? I think every hand goes up. Yeah? All right, now keep your hands up if you've ever told somebody a secret and that person's told somebody else your secret, that person tells somebody else your secret, until all of a sudden it feels like the whole world knows your s... Read More

Key Insights

• A secret is a credential that demonstrates authorization when requesting access to a service, including an API key, OAuth token, digital certificate, or another access credential. The presentation focuses on structured credentials rather than less structured patterns and passwords.
• Credential leakage is often human error, not deliberate misconduct. A developer may temporarily place a real credential in code for testing or debugging, finish the task, and then accidentally push the credential to a repository with the surrounding code.
• Deleting a credential from the latest commit is not sufficient remediation because earlier Git commits can preserve it. A repository's history must be considered when investigating exposure, while the compromised credential itself may still require action from its issuer or owner.
• Secrets can appear throughout the software development workflow. Committed files are the most common location described, but credentials also occur in commit metadata, pull request comments, and issue descriptions, with each location capable of creating meaningful exposure.
• Commit metadata can expose credentials when a developer mistakenly enters a username and password where an IDE requests a Git author name and email address. The incorrect values can then accompany every subsequent commit pushed from that configuration.
• A single exposed credential can create broad downstream consequences. The SolarWinds example illustrates how access to servers can enable malware injection into software updates, extending a compromise from a software provider to its customers and their connected organizations.
• GitHub secret scanning works by matching committed content against GitHub and partner credential patterns, then sending relevant matches to a partner verification endpoint. The credential provider can confirm the match and decide whether to revoke the secret, notify the user, or take another action.
• Exposed credentials can attract attempted use very quickly. In GitHub's controlled AWS credential experiment, attempted use occurred within the hour and produced fraudulent charges, demonstrating why organizations should respond immediately rather than assume an unnoticed secret is harmless.

Questions & Answers

Q: What is a secret in software development?

A secret is a credential used to show a third-party service that a request is authorized. Examples in the presentation include API keys, OAuth tokens, digital certificates, and other credentials. These structured values can grant access to services or resources, so exposing them in a repository or another development surface can allow unauthorized parties to attempt to use that access.

Q: How do credentials accidentally leak into source code?

Credentials can leak when a developer inserts a real token or key into code for a quick test or debugging session and later pushes the code without removing it. Leakage can also result from configuration mistakes, such as entering login credentials into Git author fields, or from inexperienced developers intentionally leaving a secret in code because they underestimate the potential consequences.

Q: Why is deleting a secret from the latest commit insufficient?

Deleting an exposed credential from the latest commit only changes the current version of the repository. The credential may remain visible in earlier Git history, much like deleting the latest message does not erase an entire conversation. Remediation must account for the historical exposure and take appropriate action on the credential rather than assuming that editing the current file has ended the risk.

Q: Where can secrets leak besides committed source files?

Secrets can leak anywhere people collaborate while building software. The presentation identifies commit metadata, pull request comments, and issue descriptions in addition to committed files. A credential in any of these locations can create the same kind of access risk, so scanning and response processes should cover the broader development workflow rather than focusing exclusively on source files.

Q: How does GitHub secret scanning detect leaked credentials?

GitHub scans repository content for patterns associated with GitHub credentials and credentials supported by participating service providers. When a partner pattern matches, GitHub sends the match to that provider's verification endpoint. The provider checks whether the match represents a real credential and can then revoke it, alert the affected user, combine those actions, or choose another suitable response.

Q: What happens when a credential is exposed publicly?

A publicly exposed credential may be discovered and tested very quickly by bots or people. In the controlled example described, GitHub intentionally exposed an AWS access key and secret while coordinating with AWS. Within the hour, the credential received repeated use attempts and generated fraudulent charges, showing that delayed remediation can create direct and rapidly increasing consequences.

Q: Why can one leaked credential cause a supply chain breach?

One credential can provide access to a sensitive system that distributes software to many customers. In the SolarWinds example, attackers used exposed access to reach servers and inject malware into customer software updates. Customers then received the altered updates, extending access to those organizations and potentially their customers, which turned the original credential exposure into a wider supply chain compromise.

Q: How can organizations reduce credential-based breaches?

Organizations can reduce risk by scanning repositories and related development surfaces for exposed credentials, validating detections, and acting immediately on confirmed matches. They should inspect private repositories as well as public code, account for secrets retained in Git history, and build controls that prevent credentials from being pushed. Credential issuers can contribute by supporting verification, notification, and rapid revocation workflows.

Summary & Key Takeaways

• Credentials often leak through ordinary human mistakes, such as placing an access token in test code and then pushing that code to a repository. Developers may also expose credentials through incorrectly configured Git author information or intentional shortcuts. The appropriate response is to improve detection and prevention rather than assign blame.

• Removing a secret from the latest version of a file does not remove it from earlier Git history. Effective detection must therefore inspect commits and other development surfaces, including metadata, pull request comments, and issue descriptions. Every detected credential deserves attention because a secret can retain its impact regardless of where it appears.

• GitHub scans public repositories for its own credential patterns and participating providers' patterns, then sends matching credentials to provider verification endpoints. Providers can verify a match and choose an appropriate response, such as revocation or user notification. Organizations can reduce exposure further by enabling scanning for private repositories and preventing leaks earlier.