I'm sure you would agree that, in today's digital world, the majority of 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, or sometimes just referred to as 'Secrets,' are pieces of user or system-level confidential information that ought to be carefully protected and accessible to legitimate users only. We all know how important it is to keep these assets secure to prevent account misuse and breaches.
A reality check: How often do you make proactive efforts to protect these assets? Rarely, I'd say.
Among the worst mistakes a developer can make when it comes to application security is to accidentally commit confidential information publicly on the Internet. Surprisingly, secrets and credentials are accidentally leaked more often than you might expect, and there are intelligent tools that scan public repositories in search of committed secrets.
With the mission of empowering developers to take control of their own code integrity, SonarLint, a free and open source IDE extension from SonarSource, recently announced a new feature for its software that aims to help 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.
Does this sound interesting to you? Continue reading to find out more.
First – why you should care
Let's take a moment to look back a little and see why this new SonarLint feature would be so important and useful to any developer.
Somewhere in your life, you might have used a credit card for online purchase and immediately received a call from the credit card company asking if you intended to go ahead with the purchase. If you did, no problem, all's well. If not, 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.
There may be a recurring connection to a cloud-based database as part of the code development and delivery process, or you may need credentials to access an API of a third-party company.
In that process, there is a chance you hard-coded credentials temporarily to ease use, or a colleague may have added confidential information for a quick local test, and then accidentally committed those files to a public repository. And...those temporary changes are now 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.
Next thing you know, someone has compromised the account, or worse yet, this small security lapse has provided someone with a small staging point for a larger infrastructure breach.
Breaches of this type are more common and potentially catastrophic than you might realize. There have been a number of news articles in the past year highlighting incidents where malicious users have stolen API keys embedded in public source code repositories such as GitHub and BitBucket. StackOverflow, Uber and more recently Shopify are examples of high-profile security incidents where secrets sprinkled in publicly visible files created havoc. Imagine the damage it could have done to the brand reputation.
Human error will continue to occur, but by performing the right checks at the right time, the error can be prevented from occurring in the first place. The previous case illustrates how exposure of 'secrets' detected at the relevant point of introduction, e.g. during programming or just before committing your code, could have saved a great deal of trouble.
The best place to detect and address these issues in your development workflow is at the very beginning of it, that is, in your IDE, Integrated development environment. There are a lot of large companies that have learned this lesson the hard way.
Advanced rules that detect AWS secrets in-IDE
With the recent addition of new rules for detecting cloud secrets, SonarLint protects AWS authentication credentials and Amazon Marketplace Web Service (MWS) credentials from leaking publicly. Check out the rules that safeguard MWS auth tokens, AWS Access Key, Key ID, and Session tokens.
SonarLint protects your credentials against public leakage by acting as your first line of defence. 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.
This is important because compromised accounts can have not only individual or resource-level ramifications, such as the possibility of account hacking, but also adverse consequences for 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.
Besides identifying such problems, SonarLint is also able to provide clear guidance on how to resolve 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 supported in popular IDEs such as VS Code, IntelliJ IDEA, PyCharm, CLion, WebStorm, PHPStorm, and Rider, with Visual Studio, Eclipse, and more to follow.
To start securing your code base you can download SonarLint for VS Code or SonarLint for your JetBrains IDEs. Or if you were already using SonarLint in your IDE, you can simply update the plugin to the newest version to enable this feature.
As a next step, the company also plans to extend the 'Secrets' detection functionality to other public cloud providers. In the future, you can expect SonarLint to support more cloud providers, SaaS products, and database providers.
Developers who use other SonarSource solutions – SonarQube or SonarCloud for delivering quality and secure code can extend their code security experience to their IDE. By installing SonarLint for free, not only can they immediately benefit from powerful features such as secret detection but also improve the overall code quality and security of their code base by sharing rules and analysis settings from SonarQube or SonarCloud to SonarLint to coalesce the entire development team on a single definition of code health.
