Software Supply Chain: Preventing Breaches Early

Secrets in code is one of the most common attack vectors today.  The Solarwinds attack is probably the most recent and egregious example, but for every Solarwinds incident there are dozens, if not hundreds, of similar breaches every day that go unreported.  Having a breach of any kind is, of course, a serious matter.  Even if you are fortunate enough to have detected company secrets in your repositories before they have been found by bad actors, you are incurring serious costs to remediate them.  

For those of us who have had to remove code from the history of a Git repository, we all know it’s not as simple as pressing a delete button.  Not even close.  This is why it’s so important to have a complete solution for detecting secrets in code. A complete solution to this problem starts at the source—when the developer first attempts to commit the code into their local git repository.

Step 0:  Catch secrets before they are committed

By using a tool that leverages pre-commit hooks on the developer workstation, the secrets-in-code problem can be stopped before it even starts.  Pre-commit is just like it sounds.  When the developer runs the “git commit” command on their workstation, the pre-commit hook performs its task before the code is actually committed to the repository.  I’m sure it’s obvious at this point, but if the pre-commit hook is tasked with scanning for secrets and blocking the commit, you’ve not only avoided the breach potential but also the costly need for your operations team to remediate.

But how do I ensure I’m not slowing down development?

Ensuring security without sacrificing developer velocity is the constant balancing act.  Do I let my developers go all out and just have my operations team run around remediating everything after the fact,, or do I slow down developers?  How many times have you heard the saying a stitch in time saves nine?  The saying couldn’t be more appropriate here.  

Remediation is costly, and not remediating secrets in code can be even more costly.  Let’s take a closer look at the actual “velocity hit”.  If the secret scanning tool  leverages intelligent analysis algorithms that minimizes false positives and allows the developer to ignore non-sensitive secrets , the velocity hit should be negligible.  False positives are what will kill the deal here.  If the developer is frequently being blocked for things that aren’t important they are going to quickly find a workaround to the tool.  On the other hand, if the developer is seeing that the tool is helping them to avoid potentially costly and embarrassing mistakes, they are going to embrace and welcome an occasional short delay.  In this case the “delay” is well worth it when all of the potential downstream after-effects (potential breach, remediation time and energy, build stoppage, and/or delays in product releases) are taken into account..

OK, I’m convinced.  What other aspects should I consider?

It’s important to understand that slowing down development is one of the last things you want to do.  As such, a tool that’s going to prevent breaches as early as possible in the development lifecycle should work with developers, not against them.  

  • The tool should work with the development environment that the developers are using.  Most of the common IDEs today support pre-commit hooks, so this shouldn’t be a problem.  
  • Test secrets are commonly used in Document, QA, Test, Sample and Example paths, just to name a few.  The tool should leverage an ignore file, similar to the .gitignore file, that allows the developer or the operations team to configure which secret types or paths should be ignored.  
  • The scan time should be negligible.  The pre-commit scanning tool should be intelligent enough to create a bounding box of what is actually critical to scan and only take a deeper look at what is really interesting, thus minimizing the actual scan time.

In addition to performance considerations, there are a number of other things that can be helpful in a pre-commit tool.  

  • Secrets: the library of secrets scanned for should be extensive (AWS, Slack, GitHub, GitLab, Azure, GCP, Stripe, Bitbucket, etc.) and of course include passwords and credentials.  The tool should also identify environment and other sensitive file types.
  • RegEx: the tool should allow the developer or operations team to add their own regular expressions to search for.  
  • Commit signing: the tool should check if the commit is going to be signed or not and block or notify the developer.  
  • Platform support: the tool should work on the platforms, and operating systems that your company leverages.

There’s obviously a reason BluBracket is going into all of this.

Yes, of course.  BluBracket has just such a solution, and it’s free!  BluBracket is serious about security and serious about shifting security as far left as possible.  The BluBracket CLI Tool allows you to do all of the above and it’s part of the BluBracket Community Edition which is totally free.  

Share this post!