Preventing your Cloud ‘Secrets’ from Public Exposure: An IDE plugin solution

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^[1], 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^[2], Uber^[3]
and more recently Shopify^[4]
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^[5]
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^[6]
or SonarLint for your JetBrains IDEs^[7]. 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.