Corporations can spend millions to install effective cybersecurity infrastructure, but what they might fail to notice is that vulnerabilities could be hiding in plain sight in developer repositories. To make database connections, calls to APIs, and many other functions more convenient, developers will often hardcode various credentials, keys, and secrets into a configuration file, or sometimes directly into a function itself. While this practice makes it convenient for developers, it opens up a myriad of vulnerabilities and cybersecurity challenges.
Our recent research dove deep into over 25,000 repositories, almost 2 million commits, and 820,000 pull requests. The results give in-depth insights into the growing issue of hardcoded secrets. Hardcoded secrets can be usernames and passwords, access tokens, API keys, private keys in public-private encryption, and any other authentication or authorization secrets that lets the application execute functionality specific to a corporate account. In the report we came up with, over 45,000 secrets were found and analyzed. The results show that many organizations are unaware that the "keys to their kingdom" are publicly available, leaving them vulnerable to unauthorized access to infrastructure and sensitive data.
The report separates encrypted and encoded secrets from "exposed" secrets. Exposed secrets are categorized as those disclosed without encryption. These secrets, when stolen, are the most dangerous to an organization, because they can be used without any other effort, such as brute forcing weak encryption or performing dictionary attacks on encoded secrets.
Even more concerning, for every 1,000 repositories with exposed secrets, 7 of them were publicly available to anyone on the internet. Of all repositories with secrets, 38.15% of them were in repositories that work with Personally Identifiable Information (PII), leaving these organizations open to compliance violations and critical data theft.
A surprising insight drawn from the analysis is that corporations experience a seasonal cadence to secrets creeping into code bases, which might correlate with their efforts of periodic rotations of secrets across the board or, alternatively, engineering cadence, ramp up and churn.
With a high-performance development and DevOps environment, it’s not unusual for secrets to slip into repositories during rapid deployment. Speed and convenience are often the nemesis of good cybersecurity, but you can fit security into automated deployment procedures. With only one repository, it can be easy to spot a mistake, but enterprise development involves potentially thousands of repositories. Even with numerous repositories, you can automatically discover and remediate hardcoded secrets with the right tools.
Here are a few practical ways you can remediate secrets in code now without interrupting and impeding current development operations:
1. Always scan for new and existing hardcoded secrets
If you remove every secret today, a developer could accidentally deploy a configuration file with stored secrets tomorrow. You need tools in place that continually scan and discover any sensitive information before developers deploy files to a production environment. A good scanning tool will discover, categorize and classify files with hardcoded secrets to make it easier for DevOps to prioritize remediation.
2. Prioritize remediation based on risk
Not every vulnerability is created the same, and hardcoded secrets are no different. Hardcoded secrets to your AWS dashboard have a much higher impact on corporate security than secrets used to read non-sensitive data. Collaboration at this step is critical to create a remediation plan that prioritizes the most vulnerable infrastructure.
3. Rotate keys and revoke any exposed secrets
As you refactor code and remove hardcoded secrets, you should revoke any passwords and keys found in your repositories. For all you know, your sensitive data was already discovered by an attacker, indexed in search engines, or saved for later use. Rotation of keys is also important to reduce the window of opportunity for an attacker should they obtain access to secrets in the future.
4. Educate and train developers
Developers don’t think like hackers, so they need training on the myriad of ways that certain code architecture and structure can leave an application vulnerable to attacks, including hardcoded secrets in configuration files and directly embedded in functions. They might also need help working with preferred ways of storing keys, such as using environment variables.
5. Add new security to code procedures
Every organization has their own rules to code performance, but they all have commits and pull requests in a team environment. The right tools will scan and alert developers of hardcoded secrets during a commit, or it will block a developer from merging code with hardcoded security during a pull request. These two safeguards put you into a "shift left" approach to cybersecurity to protect from disclosing secrets in production.
Conclusion: Taking a Shift Left Approach to Code Deployment Reduces Risk of a Compromise
As more corporate developers deploy hardcoded secrets into public repositories, organizations must put the right safeguards in place. Our research shows the need for more implementation of automation tools to catch these issues before attackers discover them. You can better protect your data, your infrastructure, and greatly reduce risk by implementing automation that supports a shift left approach to DevOps cybersecurity.
