Finding Secrets in Code the DevSecOps way

Secrets in code have become a massive security challenge for two main reasons:

  1. Code driven automation is ubiquitous. Passwords and credentials are quite often accidentally, and sometimes intentionally, checked into code.
  1. SaaS and IaaS has led to proliferation of tokens used to invoke other services. These tokens, especially in publicly visible code, are a huge threat to enterprise resources.

The best way to address this challenge is to prevent secrets from making it to code in the first place. Enable developers to find/fix secrets in code pre-commit on their machine (shift-left)—before they are committed to code, and hence well before they are pushed to remote repositories. 

If a secret is found pre-commit, developers may then resolve the issue by removing the secret before continuing with the commit. They may replace the hard coded secret with a secret from a secret manager or, where appropriate, a configuration variable. In some cases, when the developer has a strong reason to believe the flagged secret is acceptable, they may add an annotation indicating why they chose to proceed with the commit. Settings can be configured per repository so the tool only scans relevant files/folders.  

Integrating secret detection into the CICD pipeline is an effective way for security and development teams to work together to address the problem of secrets in code. 

Developer-First

It is critically important to leverage a developer-first solution with the following attributes: 

  • able to accurately detect all common secret types, including passwords, 
  • has low false positives – flag only active secrets and strong passwords, 
  • easily integrates with any CICD vendor, 
  • integrates with SIEM and other Security management solutions to provide an organization-wide risk view.

Prevention and Detection

Developers don’t like to break builds. They prefer to find and fix issues on their machine. It is much more challenging to mitigate/remediate risk from secrets already in repositories, so it’s far better to make sure secrets are not checked into code in the first place. Leveraging GitHub checks or similar tools to show failed checks as part of the PR workflow in GitHub also allows developers to find and fix security risks as part of the development process.

But it’s not enough to rely on developers to keep secrets out of code and hope that nothing dangerous finds its way into a repository. Security teams should use the same tools they recommend for developers. Leveraging data from developer machines and CICD pipelines, they are able to monitor code risk trends over time for the entire organization and across different teams. 

Get Started
BluBracket Community Edition is a perfect place to address the problem of secrets in code the DevSecOps way. The tool allows developers to find and fix secrets pre-commit and also empowers security teams to automatically find secrets as part of the CICD pipeline. The Community Edition is free to use with your GitHub account and contains tools for both developers and security teams. In this case, it’s better to use both a belt and suspenders to ensure a company’s code is safe.

Get started now with the BluBracket Community Edition

Share on facebook
Share on twitter
Share on linkedin
Share on reddit