Why should I care if secrets are in my code?
Secrets, such as passwords, API keys, and tokens, are sensitive pieces of information that grant access to databases, services, and applications. They are like the keys to your house that you want to protect and keep safe. If these secrets are accidentally exposed in your code (main sources, tests, IaC, config, scripts, …), they can be obtained and used by malicious users. This could lead to unauthorized access, data breaches, and other security incidents.
For instance, if an API key is exposed in source code, it could be used to access the API, potentially leading to data theft, service disruption, or even financial loss if the API is tied to a paid service.
You certainly heard about what happened to Uber in 2016 when it experienced a data breach that exposed the personal information of 57 million users and drivers. The breach occurred because an access key was publicly exposed on GitHub, allowing hackers to access Uber's user data stored on Amazon Web Services.
That’s why it's crucial for developers to handle secrets carefully. They should never be hard-coded into source code or committed to version control systems. Instead, they should be stored securely using secret management tools and accessed through secure methods, such as environment variables.
How can Sonar help with secrets detection?
At Sonar, we believe in empowering developers to write Clean Code. Clean Code is code that is consistent, intentional, responsible, and adaptable. As part of our mission, we want to help you keep your secrets away from your source code. That way, you will be developing responsible code. Out of the box, the Sonar solution provides secrets detection features that will help detect if you are about to leak or if you have leaked a secret.
Sonar helps detect secrets from within the IDE through to your Continuous Integration (CI) pipeline
In the IDE, with SonarLint, as you are developing code and you accidentally write or paste into your code a string that looks like a secret, one of the 110 secret patterns supported by our 60 secret rules will be triggered. Following a true shift-left approach, you are warned before you push your code to your Git repository. It’s great and no one will even know that you were about to make a huge mistake.
Also, if you don’t use SonarLint (why wouldn’t you do it?) or if you decide to ignore its warnings, you will get the same detection capabilities as part of your code branch and pull request analysis in SonarQube and SonarCloud.
Sonar’s secrets detection is open-source
This feature is provided by a new open-source secret detection engine developed by Sonar. What is good with open-source is that you can see how it’s done, and contribute. We provide the definition of all our 110 secret patterns and a guide to explain to our community to contribute. This way, we expect this number of secret patterns to grow a lot during the coming months thanks to our awesome community. You don’t need to know any programming languages, it’s a fully YAML-based configuration.
Sonar’s secrets detection is ready for enterprise needs
For people who develop their own internal APIs and have to manage their own in-house secrets, there is no way for us at Sonar to know the format of these secrets. This is why, the SonarQube Enterprise Edition (and higher) provides the possibility to define your own secret patterns. This means you can make sure none of your internal secrets are leaking even internally to prevent attack from the inside. If you want to know more about how to add your own secret patterns, check the related documentation.
Let’s try secrets detection!
Ready to start the journey and prevent secrets from leaking? Install the latest version of SonarLint for your favorite IDE, upgrade your SonarQube instance to v10.3, or simply check out SonarQube or SonarCloud.
Alex