Posted on July 29, 2024 by Dwayne McDaniel

Member post by Dwayne McDaniel, GitGuardian

Leaked credentials, aka secrets, are an easy way for bad actors to gain access to your environments and data. While no one intends to leave these valuable API keys, tokens, and passwords out in the open, the complexity of the modern software development lifecycle means there are many chances for secrets to leak into some unexpected places. On GitHub alone, GitGuardian discovered over 12.7 million hardcoded credentials added throughout 2023. Their research shows this is a growing problem.

One of the more surprising places that secrets can end up is, ironically, in the files you use to prove how you are securely building your artifacts: your SLSA provenance files. Let’s take a look at how this happens and what you can do about it. 

SLSA means producing documents

You most likely have heard of Supply-chain Levels for Software Artifacts (SLSA), the framework to enhance the security of software supply chains maintained by the OpenSSF community. As the project phrases it, “It’s how you get from “safe enough” to being as resilient as possible, at any link in the chain.” It is, without a doubt, a valuable tool in the fight against threats like Log4Shell, SolarWinds, and the XZ Utils Backdoor.

There are two core concepts at the heart of SLSA, attestation and build provenance. These are defined by the project as:

What ends up in provenance files

Your build provenance is stored in provenance files. These files contain metadata such as the source repository tags that the build process uses, as well as all the parameters used and all configuration steps’ output. That last part is where you might be surprised to find credentials.

Even if you are using a secrets management platform or vault system, at the end of the day, those secrets get faulted at runtime. Most likely, while you are documenting your build process, your provenance files are going to contain some API keys or authentication tokens. Worse yet, if you have hardcoded credentials in your code base, those secrets are guaranteed to show up in all your logs and attestations. 

code example

An example provenance file in JSON format containing credentials for a DB server called BLAM

Keep reading

Implement Secrets Detection And Redaction for SLSA

You never know who will access your SLSA documentation and what they might do with that information. Fortunately, there are steps you can take to minimize the risks associated with these artifacts and it is likely you are already doing something similar with your log files.

To prevent attackers from simply reading plaintext credentials from log files, you need to sanitize your log files. Hopefully, you already have the tools to address this well-known issue. Fortunately, you can most likely leverage that same tooling to scan for secrets inside these provenance files in order to remove them. 

When thinking about solving the issue of secrets in documents related to the SLSA framework, consider the following:

1. Automate Secrets Scanning:

   – Integrate automated tools to scan source code, configuration files, and build artifacts for secrets.

   – Tools like GitGuardian, TruffleHog, and Detect Secrets can identify hard-coded secrets in the codebase.

2. Automate Secret Redaction:

   – Automatically replace any detected secrets with placeholder values (e.g., `<Redacted>`) as a step in the build process.

   – This can be done as part of the document creation process before the file is ever commented to disk.  

3. Keep Secrets Out Of Version Control:

   – Enforce strict version control practices to prevent secrets from being committed to repositories.

   – Implement pre-commit hooks that scan for secrets before code is committed.

Stay safe while implementing new frameworks

If you are already implementing SLSA for your project, thank you! The SLSA framework provides a robust approach to securing the software supply chain, and that is something we should all strive toward. No matter where you are on the adoption path, it is important to remember that, like any new approach to solving a security issue, we need to be mindful of any new attack surfaces and ways attackers can exploit our work. 

The importance of secrets detection and redaction within this framework cannot be overstated. Bad actors are actively looking for ways into your environments, and leaked credentials provide an easy path. Fortunately, there are many tools on the market you can integrate into your workflow that can automatically scan for secrets. Once found, a little scripting can automate the redaction process and help keep all your files free from plaintext credentials. 

Make sure when someone reads your attestations, they get proof they can trust your artifacts but not unintended access to your systems.