Exposed Machine identity credentials (api keys, passwords, tokens, etc…) are not a static analysis, code security issue, they’re an IAM security issue. Here’s the first 5 questions everyone should be asking when their key leaks out:

• Is the credential still active?

• Who’s credential is it?

• What resources does the credential have access to?

• What permissions does the credential have on those resources?

• Where should I go to revoke the credential?

Open Source version:

Enterprise Version:

You can invoke the open source command with the following:

$ trufflehog analyze

For the past several years, TruffleHog has pioneered the use of key verification to answer the first question: is this a valid key? Today, we’re officially extending TruffleHog to answer all 5 questions.

Who’s key is it?

Seems like a silly question, since most of the time we know who exposed it, but often the person who exposed the API key is NOT the person who created it. 

Above we see Bob exposed a key in his code, but we can’t see that Alice actually created the key.

The first thing TruffleHog Analyze surfaces is who created the key:

The above example is analyzing a GitHub key Classic Personal Access Token (PAT). In the case of GitHub Classic PATs, sometimes it can be surprising to see just how many repos personal access tokens have permissions to, when senior developers have accrued access to hundreds of repos over a decade of development, which takes us to our next most important question:

What resources does the key have access to?

Oh boy can this get complicated. Let’s stick with our Classic GitHub Personal Access Key example (PAT) that leaks out in a public GitHub repository (super common situation). And that developer is a member of multiple GitHub organizations and has a bunch of personal repositories and side projects in their account. Their PAT assumes the same level of resources the developer has:

That’s a terrifying amount of risk for a key that likely only needs access to one repo or one org. Prior to TruffleHog Analyze, we didn’t have a way to enumerate that risk. 

Our TruffleHog Enterprise customers often ask us questions like: 

• How do we know which keys to prioritize for remediation first? 

• How do we know which keys give access to our GitHub organization? 

• (Most importantly) How do we know the full range of attacks a hacker could execute with our exposed PAT if we can’t answer these questions? 

Fortunately, we can know all of these things with TruffleHog Analyze.

But there’s still a question of what level of access the key actually has on those resources, which brings us to our next question.

What permissions does the key have on those resources?

There’s a big difference between a PAT that can read 100 repositories and a PAT that can write to 100 repositories. One of those keys can publish malware and backdoors to code that could be run on countless systems. The other can be used to look for more API keys!

Understanding the differences in a key’s permission set is critical for remediation efforts, but there’s no way to do that by just looking at a static string in your source code.

TruffleHog Analyze will enumerate what those permissions are, and surface them to you in a single command.

The reality is scary permissions assigned to no resources presents no risk, but scary permissions on scary resources can grind a business to a halt. Looking at the permissions and the resources together tell us the full story, and we need both pieces of the puzzle.

Where should I go to revoke it?

Once we know who’s key it is, which account the key belongs to, what resources the key can access and with what permissions, we can now rotate the key. To assist our customers and community members in rotating exposed API keys, we created step-by-step guides for the key creator to follow. You can find our guides here: https://howtorotate.com/docs/tutorials/github/

How do we get all this information?

Before TruffleHog Analyze, key owners would need to log into the SaaS provider’s IAM UI, look around for the API keys page and then piece together what resources and permissions the key has. Surprisingly, many SaaS providers don’t make it easy to find the API keys page, nor identify all of the resources / permissions attached to that key.

We took a different approach with TruffleHog Analyze. All key metadata, resources and permissions are currently self-discovered from the API key itself. 

How? We use a combination of techniques, all designed to be stateless, and minimize potential impact of making API calls from the key. These techniques include:

• Identifying scope from headers and API endpoints

• Testing permissions with stateless API calls

• Sending malformed requests to stateful API endpoints to observe permission errors

• …more…

How many key types can we analyze?

At launch, TruffleHog Analyze supports ~30 different key types. We prioritized building credential analysis functionality for the 30 most-frequently leaked key types. We’re actively working on adding analysis for many more of the remaining 800+ key types that TruffleHog can detect, and invite the community to help build more out.

Here is the full list supported at the time of writing this:

• Airbrake

• Asana

• Bitbucket

• GitHub

• GitLab

• HuggingFace

• Mailchimp

• Mailgun

• MySQL

• OpenAI

• Opsgenie

• Postgres

• Postman

• SendGrid

• Shopify

• Slack

• Sourcegraph

• Square

• Stripe

• Twilio