How to Prevent Secrets from Creeping into Code
All too often, secrets are found in released code, exposing the owner to security risks. These secrets include passwords, API keys, encryption keys, tokens, database credentials and other private company information.
Having hardcoded secrets in source code is dangerous, and despite developers’ most serious efforts, secrets can still creep in. Developers may take shortcuts while writing code and pass secrets into it, or they may not recognize the impact of the secrets in their code. Also, most scanning solutions leave it up to the developer to determine why their code is flagged for an issue. Finally, most tools look for secrets in code repositories, after the leakage has occurred, which requires painful remediation (i.e., rotating the secret).
Properly managing, storing and securing secrets can be complicated, misunderstood or simply skipped due to time constraints. In addition, if companies don’t know when and where secrets enter projects, they can’t prevent releasing them with the project and compromising their security.
Credentials and other secrets that creep into code regularly make news headlines — and the number of exposures is increasing due to human error. Tools that catch secrets in the IDE and throughout the CI/CD pipeline — before they have the chance to cause issues — are game changers.
Understanding How Secrets Get in Code
Being able to detect secrets before they are leaked in code enables organizations to reduce their risk exposure. By detecting them in the IDE, you can avoid the pain of having to remediate them by rotating the secret. But first you need to understand how secrets end up in code at all. Some reasons are:
1. Lack of Knowledge
Possibly due to inexperience or improper training, some developers simply may not be aware of proper secrets management and source code security. It takes only one developer being unaware of best practices for handling secrets in code to put a company in the hands of a threat actor. If knowledge is power, then the best line of defense is a knowledgeable team.
2. By Mistake
A developer may temporarily hardcode credentials or confidential information for a quick local test, with the intention to remove them afterward. However, sometimes those files are accidentally committed to a public repo, making those temporary changes permanent. Even if the code is deleted afterward, someone could have made a copy that contains the secret before it was cleaned up. To err is human, but when the consequences can have a potentially massive impact, it’s best to proactively prevent mistakes as much as possible.
3. Blind Trust
Problem-solving on your own is a great way to learn, and sometimes the problem is so specific that the only way to approach it is by hacking it yourself. If it’s eating up a lot of time and you aren’t finding a solution, it’s better to look for help from a mix of product documentation and sites like Stack Overflow. However, while these materials offer useful explanations and examples, they should not be simply copied and pasted and trusted at face value.
Code on Stack Overflow and in documentation can answer questions, but it’s not the most secure way to achieve a solution. For example, documentation often includes snippets of code to illustrate a product’s features but may not mention whether it should be used carefully and whether there’s a more secure option. Result? Bad code. Any solution you pull into the codebase should be properly assessed to confirm it’s aligned with quality standards and won’t bring issues into the code.
Another trust issue leading to secrets leaking into code is the increased use of AI-generated code. As generative AI becomes increasingly popular for code development, you can expect the number of lines of code that need to be scanned and the number of issues with secrets to increase. AI-generated code can lead you to think that the right way to connect to a service is to hardcode the token or secret. Depending on the quality of the prompt and the awareness of this problem, the AI may not produce clean code, and it can lead to secrets leaking. AI-generated code can be a good basis for understanding how to connect to a service, but you must modify it to use a secrets vault.
Ultimately, you must challenge any code you find or generate with AI. Organizations must ensure their developer teams have the proper code-quality tooling to prevent secrets from creeping into code and to resolve any that do leak as early as possible in code development.
Catch Secrets from the Start
When an exposed secret is flagged at the point of introduction, whether in real time during coding or when it is about to be committed, it can save teams a lot of trouble. Human error happens, but with the right checks at the right time, you can prevent the error’s repercussions early on.
The best place to detect and address these issues in the development workflow is at the very beginning, in the IDE. Secrets detection capabilities in SonarLint, SonarQube and SonarCloud enable organizations to detect publicly known secrets in source code, eliminate their leakage and reduce the security risk of illicit or unsanctioned access to private data. Developers using SonarQube Enterprise Edition 10.3 and above can also create custom secret pattern detection rules. Pairing them with Clean as You Code (CaYC) and Learn as You Code approaches support delivery of clean code — code that produces maintainable, reliable and secure software.
By eliminating secrets in code in the IDE from the start of development, teams can prevent secrets from entering their repository. Detecting and removing secrets early in project development reduces complicated and costly remediation required when exposed secrets are discovered late in the release cycle.
