As you start developing your secrets security strategy, it’s likely that GitHub repositories’ secrets aren’t top of mind. GitHub — unarguably the de facto collaboration platform for developers — provides innumerable benefits but also exposes you to some commonly overlooked secrets security risks, such as secrets hiding in publicly exposed repositories.

To avoid accidentally leaking secrets into your GitHub repositories, it’s important to adopt complete secrets security, beginning with the adoption of best practices.

In this post, we’ll discuss why exposed secrets in your GitHub repositories present a unique security concern. We’ll then walk through some best practices to get you started with secrets security.

Secrets: The Keys to the Development Kingdom

Secrets are sensitive information — passwords, API keys, private keys and database credentials — that developers use to access the resources they need to do their jobs. But if an attacker gets hold of these secrets, the attacker can gain unauthorized access to a system or application. From there, the attacker might compromise data or perhaps launch an attack on other systems, which is known as a supply chain attack.

Leaking secrets into a GitHub repository can have severe consequences. If the repository is public, anyone can access the secrets, including attackers. Even if the repository is private, leaking secrets still puts the network at risk. If a team member with access to the repository is compromised, the attacker can use the team member's credentials to breach the system and move laterally after gaining access to the vulnerable secrets

How Are Secrets Leaked?

Secrets can become exposed to the public in a few ways, such as storing them in code. If a developer hardcodes secrets into their code or configuration files and the code is pushed to a GitHub repository, those secrets are also pushed. Or maybe a developer accidentally commits a file that contains secrets, having forgotten to remove the file before pushing the code to a public repository.

An often overlooked scenario resulting in secrets exposure involves promoting private repositories to public repositories. Because private repositories aren’t held to the same level of security as public repositories, secrets tend to find their way into the public repo. The most avoidable exposure, though, are secrets leaked as part of the commit comments. As improbable as that sounds, it happens.

Preventing Exposed Secrets

To prevent leaking secrets into a GitHub repository, make sure to adopt these best practices:

Use Environment Variables

Instead of hardcoding secrets in your code or configuration files, use environment variables. Environment variables refer to variables set outside the code that the code can access. With environment variables, you can keep your secrets separate from your code, which makes it easier to manage and secure them.

Implement Secret Management Tools

Secret management tools, such as HashiCorp Vault or AWS Secrets Manager, allow you to store secrets securely and access them when needed. You can also use these tools to rotate secrets, which you should do regularly, making it harder for attackers to compromise them.

Use .gitignore

.gitignore is a file that specifies which files should not be committed to a repository. You can use .gitignore to exclude files that contain secrets, which will stop you from pushing them to your GitHub repositories.

Treat Private Repositories as If There Were Public

Just because you’re part of an internal project doesn’t mean your project will remain internal. Use the same security controls as you would if your project were external.

Implement Secrets Scanning Tools

Code and repository scanning tools — such as Checkov and Prisma Cloud — can do more than detect secrets in your code. They can also validate that a secret is still active, which mitigates noisy alerts and the likelihood that you’ll be overwhelmed by false positives.

These tools can also shift your secrets security left because they can look for common patterns that indicate the presence of secrets and enable you to identify and remove them before pushing the code to your repository.

Using Checkov to Identify and Remediate Exposed Secrets

Using the open-source tool Checkov can help your team shift your secrets security left and adopt proactive secrets management. By applying checks in the command line, you can use Checkov to detect passwords, cloud provider keys and JSON web tokens, as well as especially dangerous secrets like Slack tokens and Stripe access keys.

Checkov uses the following secrets scanning techniques:

• Regular Expression Scanning: Does the string follow the pattern of secrets of that type, such as an AWS Access key?
• Keyword-Based Scanning: Does the key contain a word associated with a secret, such as “password”?
• Entropy-Based Scanning: Does the value differ enough from a real language that it’s likely a secret — such as EuN21!HHvaS%JPTQU&cx?

Secrets Validation with Checkov and Prisma Cloud

To better prioritize your exposed secrets remediation efforts, using Checkov via the command line will provide information about detected secrets. More importantly, it will provide validation information about the secrets, which will identify if they’re currently active and should be prioritized. Checkov does this via a series of inert calls that use the secrets solely to verify valid responses.

The increasing number of exposed secrets in modern codebases parallel the steep increase in recent supply chain attacks. Mitigating the risk of damaging attacks due to secrets leakage relies on early detection and prioritization.

Prisma Cloud — powered by Checkov — features developer-friendly integrations that enable pull request scanning. With pull request scanning, you can benefit from inline comments that identify secrets and indicate if they’re valid and should be prioritized.

And when you use the Prisma Cloud platform via the Projects screen, you can monitor your repositories in real time to get information about detected secrets and each secret’s detailed risk posture.

How to Remediate Exposed Secrets

The time it takes for a hacker to exploit a leaked secret varies depending on factors such as:

• The Nature of the Secret: Some secrets are more valuable than others. For example, an API key for a popular service may have more value to a hacker than a generic password.
• The Visibility of the Leaked Secret: If the secret is publicly visible on GitHub, then it could be discovered and exploited quicker than if buried in a commit history.
• The Level of Activity on the Repository: A repository with high activity may have a greater chance of being discovered and exploited in a short period.

It's always best to assume a leaked secret can be discovered and exploited. Take immediate action to remove the vulnerable secret and change associated credentials. You’ll also want to monitor for suspicious activity on any systems or services that use the compromised secret.

If you find your secrets exposed anywhere online, follow these steps to remediate the issue:

1. Disable and revoke the key as soon as possible.
2. Identify which services have been accessed by the keys and start relevant InfoSec or data leakage processes.
3. Review logs for nefarious activities, such as VMs you didn’t spin up.
4. Clean your git history or log history where possible — it’s not always easy.
5. Create a new key and distribute it to the various services that need it.
6. Monitor your services for any that break because you haven’t updated the key for the service.

If the secret lurks in your git history and can’t immediately be deactivated or decommissioned, you can remove it from your git history. This process, however, is extremely complex and dangerous if done incorrectly.

Getting Started with Shift Left Secrets Security

Leaking secrets into a GitHub repository can have significant consequences. And even if subsequent code changes appear to remove secrets, others can still access them within the Git history.

To prevent leaking secrets, follow best practices. Use environment variables, secret management tools, .gitignore and a comprehensive cloud-native application protection platform (CNAPP) with advanced secrets scanning capabilities.

And if you’re unfamiliar with Prisma Cloud’s full-stack, multidimensional approach to securing exposed secrets, take it for a free 30-day test drive.

Elevate Your Secrets Know-How

Want to learn more about shifting your cloud security left? Download the DevSecGuide to IaC Security and discover how you can embed IaC security guardrails throughout the DevOps lifecycle.