Seven years ago I created TruffleHog; today I'm putting this blog out with the creator of GitLeaks, to reshape the industry on how we think about secrets in our code.

Secret scanning has become a core pillar of AppSec, alongside SCA and SAST, as one of the fundamental responsibilities of an application security team’s mission to keep source code secure. 

Many companies now offer those 3 pillars as part of a shift-left, DevSecOps CI/CD suite to keep your source code secure.

They’re wrong. API keys in your source code is an identity and access management (IAM) issue. It has very little to do with code security.

Let’s look at a few facts:

• You don’t remediate exposed API keys by authoring more code, you log into an IAM platform and rotate the key.

• You don’t validate remediation with a code review, you send an API request to verify that the key is no longer live.

• Employees don’t just leak keys/passwords in source code, they leak secrets in S3 buckets, Slack channels, Jira and many other places.

• Minimizing the impact of and/or preventing keys from leaking isn't done in your code repository. Rather, it's in your IAM settings where the key was generated, by using stricter IAM policies, key generation controls, and key management.

• Most exposed keys flagged in static review move out of main, but stay live and exposed forever.

DevSecOps Code Security is a Recipe for Failure

DevSecOps calls for flagging vulnerabilities as code is authored and before it gets pushed into production.

But API keys are not a production issue. They belong in production. They don’t belong leaked/exposed in pre-production.

So already the model is broken. We don’t stop the vulnerability (leaked/exposed key) from manifesting itself by blocking a build, it’s already as bad as it’s ever going to be by the time CI/CD sees the secret; it’s already leaked in pre-production.

What’s worse is that CI/CD checks can pass even when secrets are exposed in pre-production. How?

• CI/CD won’t check all branches

• CI/CD often doesn’t check old commits

• CI/CD can’t check deleted/dangling commits

  
  

Remediation happens outside of your code

Code security issues are fixed by authoring a new version of code, having it reviewed, and presto, you’ve fixed your vulnerability.

When an API key leaks out (take AWS for example), the fix is to log into AWS IAM, and rotate the credential:

Validation of the fix also can’t be done through static code review. You’ll need to either use a tool like TruffleHog to see if the key is live, or you’ll need to log into AWS.

A few (but not all) reasons the key needs to be revoked:

• The code was likely cloned with the live key into dozens (hundreds?) of laptops

• The key can live on in revision history

• The key can live on in branches

• The key can live on in deleted commits that can still be downloaded.

API keys leak everywhere

If you think implementing controls to prevent secrets in source code will prevent your keys from leaking, you’re going to have a bad day.

• Twitter was breached from an API key in their Slack

• Okta was breached from API keys in their Ticketing System

• Datadog was breached from API keys leaked via CICD

• Tesla was breached by public k8s console leaking keys

• Cameo was breached by credentials in the mobile app

• Nature’s Basket was breached from keys in an S3 bucket

This is not a story of code security. It’s a story about identity and access management (IAM).

We cannot square peg round hole this problem into application security, code security, CI/CD, DevSecOps, ASPM, or whatever buzz word you want to call it.

The solutions and tools for those buzz words do not fix this problem, and we have hard data to back that up.

We need a new set of tools to tackle this problem. This is a story of identity (specifically Non-Human Identity, NHI, but more on that later)

TruffleHog provides many of these tools today, such as:

• Scanning old commits/branches/deleted code

• Scanning more than code (ie Postman, S3, Containers, logs, etc…)

• Linking directly to the IAM portal to revoke the key

• Validating if the key is live or not

• Surfacing what account the key belongs to

TruffleHog has and will continue to be the most popular, and most powerful free and open source tool for helping with leaked secrets identities, and we plan to keep it that way, through a set of identity and IAM centric solutions.

We've got some big ones coming this year; stay tuned for what's coming.