Launching ‘Secret Detection’ to keep your Cloud ‘Secrets’ safe
Most digital applications we work on require some type of credentials –– to connect to a database with a username/password, to access computer programs via authorized tokens, or API keys to invoke services for authentication. Credentials a.k.a ‘Secrets’ are pieces of user or system level confidential information that should be carefully protected and accessible to legitimate users only. And we all recognize that safeguarding these assets is of prime importance to prevent account misuse and potential breaches.
Reality check: How often do you proactively take action to keep these assets safe? Rarely, I'll bet.
With the mission to enable developers to take charge of their own Code Security, we are excited to announce a new feature in SonarLint that helps developers identify and prevent leaks of AWS user or system-level authentication credentials before they are committed to a repository and leaked from user’s local source code or files.
If you aren’t familiar, SonarLint is a free and open source IDE extension that allows developers to instantly detect and fix Code Quality and Code Security issues as they write code.
Sounds interesting? Then read on to learn more.
First – why you should care
Before we dive into the details of this new SonarLint feature, let’s back up a little and take a look at why you should even care.
You may have come across a scenario somewhere in your everyday life where you used a credit card for a larger online transaction, and immediately got contacted by the credit card company to check if you truly intended to make the transaction. If you did, no problem, all’s well. If not, a fraudulent activity was just caught before the transaction was complete – saving you and your credit card company the complexity of an after-the-fact compromised account.
The same applies to code development.
As part of your code development and delivery, there could be a recurrent connection to a cloud-based database or access to a third-party API using credentials. Possibly you temporarily hard-coded credentials for ease of use or a colleague added confidential information for a quick local test and then accidentally committed those files to a public repo. And...those temporary changes just became permanent….Yikes! Even with after-the-fact deletion of the code, there is still the chance that someone made a copy of your secret before the cleanup.
The next thing you know, the account is compromised or worse yet, this small security lapse gave someone the surface to perform a larger infrastructure breach.
Such breaches are more common and potentially catastrophic than you may realize. StackOverflow, Uber and more recently Shopify are examples of high-profile security incidents where secrets sprinkled in publicly visible files created havoc. Think of the brand reputation mayhem it could have created.
Human error happens and will continue to do so, but with the right checks at the right time, the error can be prevented in the first place. In the previous case, if the exposure of ‘secrets’ had been flagged at the point of introduction, i.e. real-time during coding or when you are about to commit your code, it might have saved a whole lot of trouble.
By now you may have realized that the best place to detect and address these issues in your development workflow is at the very beginning of it i.e. in your IDE.
Advanced rules that detect AWS secrets in-IDE
SonarLint now includes new rules to protect AWS authentication credentials and Amazon Marketplace Web Service (MWS) credentials from leaking publicly. Specifically, we’ve added two new rules to Safeguard MWS auth tokens and to Safeguard AWS Access Key, Key ID, and Session tokens. In addition, SonarLint also now delivers 5 rules covering Alibaba Cloud AccessKeys, IBM API keys, Google Cloud service account keys, Google API keys, and Azure Storage Account Keys.
SonarLint acts as your first line of defence to detect and avoid any public leak of credentials. By flagging issues at the point of introduction (i.e. shifting issue detection further left), you can take immediate action and prevent the leak in the first place.
That’s important because compromised accounts not only have individual or resource-level ramifications such as potential account hacks but can also be detrimental to the confidentiality of your customers. For example, compromised MWS tokens can be used to get illicit access to databases that contain customer information such as credit card numbers, email, shipping addresses, and merchant sales records.
With SonarLint installed in your IDE, these ‘Secret’ detection rules will enable you to catch the presence of such credentials at the first point of entry i.e. in the source code or in language-agnostic files (e.g. xml, yaml, json) before they are committed to the repo.
Not only does SonarLint flag these issues, it is also able to provide clear in-context guidance to address them. You then have full flexibility to take action and address the code being flagged; bringing you one step closer to delivering secure code.
Getting started in your IDE
This feature is currently available in SonarLint for Visual Studio, VS Code, Eclipse, IntelliJ IDEA, PyCharm, CLion, WebStorm, PHPStorm, and Rider.
To start securing your code base you can download SonarLint for your IDE. Existing SonarLint users can simply update the plugin to the latest version to get access to this new feature.
The beginning of a new gateway for secrets detection
As the next step, we plan to extend the ‘Secrets’ detection functionality in SonarLint to other public cloud providers. Later on, you can expect SonarLint to support more cloud providers, SaaS products, and database providers.
Stay tuned to learn when these features are planned for SonarLint in the SonarLint Product Roadmap.
If you use SonarQube or SonarCloud, this is a great opportunity to extend your code security experience to your IDE. By installing SonarLint for free, not only can you immediately benefit from powerful features such as secret detection but also improve the overall code quality and security of your code base by sharing rules and analysis settings from SonarQube or SonarCloud to SonarLint to coalesce your entire team on a single definition of code health.
We hope you benefit from this new SonarLint feature. To leave your thoughts, join us in the community!
Editor's Note: This post was originally published in August 2021 and has been updated and refreshed to reflect new SonarLint capabilities.