Secrets and credentials found in code has become one of the largest vulnerabilities leading to breaches. From SolarWinds to Nissan, we’ve seen massive issues stemming from undetected secrets just in the last few weeks.
We decided to do something about it. We’ve created the best way to find secrets in code, the BluBracket Community Edition, that is 100% free. Anyone with code can use the tool to scan for over 50 types of secrets. Just connect your GitHub account to our tool and you can ensure you’re secrets-free in five minutes or less.
The community provides support for the product, so in the next few weeks we are offering a $50 Amazon gift card to those who join our community via Slack and give us feedback in a survey.
It’s limited so if you’re interested, please join today to ensure your spot. Full details of the promotion are available here. Happy secrets hunting!
In today’s cloud-native and open source world, an application is made up of many components. Companies need to understand how the software supply chain works so they can ensure their own software is secure.
Software integrity is more important than ever, especially in light of the SolarWinds hack.
In this short clip from our full length discussion on Securing The Software Supply Chain, Jim Zemlin, Executive Director of the Linux Foundation, explains how the modern software supply chain works and what companies should understand about it.
He encourages all software consumers (which basically includes everyone) to understand where their software comes from, who wrote it, what license it holds, and is that software written in a secure manner.
If you’re interested in assessing your own code for vulnerabilities, try out a free trial of CodeInsights where you will quickly see a Code Risk Score for all of your code.
Your code is not just a means for you to deploy an application, it’s also the means by which a hacker can gain access to a network or the data contained within or without. This has become even more apparent with the advent of cloud native development, where a single app or service consists of numerous “moving” parts. Each of those components may or may not have access to a LAN, a database, a server, an API, or any other piece of the puzzle that could include sensitive information.
But how is that access gained? Sometimes through malformed/insecure code or vulnerabilities in the components. In other instances, it can boil down to secrets contained within your code.
What are secrets?
Secrets are bits of code that should remain secret, which enable an app to connect to an external service, account, or application. Secrets are one of most important items within your code, as without them your applications would not have access to other resources.
The last thing you want is to have your secrets either leaked or available for hackers to find.
But what are the most popular types of secrets that are commonly left in code? Let’s take a look.
An Application Programming Interface (API) key is typically used to help in the tracking and controlling how an API is being utilized by an application. This is done in order to prevent abuse or malicious usage of the API in question. API keys can also be used as a secret authentication token, so the application bearing the key can gain access rights for the API.
Encryption keys are random strings of characters, created to obfuscate data. These keys are created with algorithms such that every key is unique and unpredictable. Encryption keys are used with a number of applications, such as GPG, SSH, and SSL. These keys are also used in code to hash passwords and other sensitive bits of information.
Oauth is an open standard for authorization that can be implemented by anyone. This type of authentication works over HTTPS to authorize devices, APIs, servers, and applications. The Oauth type of authorization uses tokens instead of credentials, making them more secure than the traditional form of authentication.
A certificate is a small data file used for security in which the identity, authenticity, and reliability of a website or web application can be verified. Certificates are also known as digital certificates or SSL certificates. These forms of identity verification can be purchased from a Certificate Authority or created locally with a tool like Let’s Encrypt.
Passwords (or passphrases) are associated with a user account and give you access to services and applications. The real danger with passwords is that, when used in code, they are in plain text, which could make it very easy for a hacker to break into a network or a server.
How to prevent secrets from being compromised?
There are a few simple things you can do to prevent your secrets from being used against you. Here are just a few tips.
Encrypt your secrets, no matter if they are at rest or in transit. When you encrypt your secrets, an attacker cannot use them to access the accounts, services, or APIs. When you encrypt your secrets, an attacker cannot use them to access the accounts, services, or APIs without also having the encryption key.
Never commit secrets to Git repositories. You will have to use secrets in your code at some point. However, you do not want to include those secrets within the code you store on GitHub. Instead, put in placeholders for those secrets.
Use environment variables for secrets. The placeholders you use for secrets can be in the form of environment variables that can be injected into the code from hidden files or other applications. This advice is in accordance with the 12-Factor App guidelines.
Use a third-party tool, such as BluBracket’s Community Edition, to detect any secrets found within your code. These applications should consider factors like commit history, false negatives, false positives, monitoring, CI/CD integration, and user experience.
Instead of storing secrets directly in your code (within the Git repositories), store secrets in a secret manager, such as Hashicorp Vault, AWS Secret Manager, or GCP Secret Manager. Once you’ve done that, connect to the read/write secrets within your vault using the secret manager API.
As a developer, it’s up to you to use secrets intelligently, otherwise you run the risk of exposing information and accounts that could lead to a catastrophic data breach. With just a bit of extra work, you can avoid such an outcome.
The massive cybersecurity breach from SolarWinds by now has reached everyone in our industry’s attention. It’s a truly wide-spread and dangerous breach that, at least from what we know now, is an example of two trends in cybersecurity that frankly need more attention by any company writing code.
Code as an attack vector.
The need to secure the software supply chain.
While there are many complex mechanisms involved with this incident, let’s look at what companies should be doing today in these two areas to hopefully prevent these types of breaches in the future.
Code as an attack vector.
Turns out this may have started with a secret exposed in GitHub.
GitHub has become a fertile hunting ground for hackers. With the credential for their FTP server found in code, it may have been a way for the hackers to infiltrate and upload the malicious files. From these reports, it sounds as if a common GitHub misconfiguration was to blame (marking a repo public when it shouldn’t be) and then hardcoding secrets into the code. Both are very common. So common, we have an early release of our Community Edition which allows anyone to find secrets in code quickly and easily, and for free. Git security is no different than cloud security, where the majority of security vulnerabilities are due to misconfigurations.
The need to secure the software supply chain.
Besides secrets, code is of course an attack vector when malicious code is inserted into the supply. This can be done through open source or in this case by accessing repositories or update mechanisms and injecting lookalike code.
As more code drives production infrastructure, the need to understand who has access to repositories and what exactly is in them becomes ever more critical. Tampering with the repositories themselves becomes a major threat to every company writing code, which today is virtually everyone. A focus on code integrity is a must.
Every company needs to have a complete and detailed BoM and chain of custody of their software. This obviously isn’t just around open source risk. As was the case with SolarWinds, inserting malware upstream that goes undetected is a devastating tactic. Given the nested nature of applications today and how code is driving software production, code integrity is not an easy task to solve, but investing in code insight and integrity tools has become a must-have for any company serious about security.
We recently participated in a panel discussion on securing the software supply chain with Jim Zemlin, executive director of the Linux Foundation and Aparna Sinha, director of product at Google Cloud. In this clip, Jim talks about the need for software composition analysis and developer ID attestation:
Here’s a quick checklist on securing your code:
Run a secrets calling tool on all code repositories that includes active monitoring.
Develop a robust code composition analysis strategy with detailed BOMs and chain of custody for your code.
Search for your code in public Git repositories. If your code ever had secrets, finding one example means there are many more out there.
Invest in tools to monitor code integrity and Git misconfigurations.
Create a “shift left” culture in your organization where everyone is responsible for security throughout the organization and arm your developers with lightweight tools they can use to keep code safe.
We think undoubtedly this breach will bring new attention to code security, specifically around software integrity. As more sensitive information finds its way to code, there will be new emphasis on access and active monitoring. The key will be taming the security risks without slowing down the pace or innovation.
If you’d like a consultation on secrets, Git misconfigurations or software integrity, please contact us and we will help in any way we can.
Today’s software applications are complex and comprised of many components. More than 98% of all applications have open source. And in a recent survey, 75% of code bases were shown to have vulnerabilities. The key to managing risk is understanding the dependencies and where you may be exposed.
We are thrilled to be participating in a round-table event hosted by Signal Fire on how to secure the software supply chain, featuring two of the brightest minds in open source and cloud:
Jim Zemlin, Executive Director of the Linux Foundation and
Aparna Sinha, Director of Product Management of GCP at Google.
Our founder Ajay Arora will be joining them for this unique look at a security topic that affects every company building software. The event will be on November 12th at 9:30 Pacific. Please join us by RSVPing and bring your questions.
Most credential leaks from code happen in personal repositories, not sanctioned corporate ones. This happens because it’s so easy to clone and share code. Git by default is open and collaborative—good for open source but potentially a security risk if you don’t have the right tools and policies in place.
In this one hour webinar with BluBracket Founder Ajay Arora, learn how to prevent code leaks and other security risks from code. It’s on-demand so you can sign up and watch on your schedule.
In this one hour webinar, learn the top threats facing companies from their code environments and how to address them.
You will learn:
How Git-based environments post a threat to enterprise security
Why companies lack visibility into who has downloaded their code on unprotected devices
How to mitigate the threats from code without altering or slowing down the software development process
How code security must fit into an overall information security strategy
Secrets such as API keys, tokens or passwords are frequently left in code. These secrets are fundamental to productivity in our collaborative and complex software development cycle. But if they aren’t handled properly, they can put an entire infrastructure at risk.
In a recent academic research project, researchers found that thousands of secrets are actually leaked every day. Hackers have realized these secrets are a treasure trove for their efforts, as they can frequently unlock systems up and downstream from the code itself.
BluBracket recently undertook a detailed analysis of code repositories of a Fortune 100 company to identify secrets, as well as to understand the strengths and limitations of open source secret handling tools. We found that the number of secrets found were significant, but most importantly, the right secrets were found.
The open source scanning tools, especially TruffleHog, found hundreds of thousands of secrets in the same repositories. The only problem? The vast majority were false positives. In security, false positives mean security or engineering teams either can’t find or end up ignoring actual security vulnerabilities because of all the noise, or they spend far too much time and energy sorting through the noise to get to the actual risks. Unlike the open source tools, BluBracket suppressed thousands of these false positive secrets and delivered them in an easily understandable, actionable form.
BluBracket analyzed 132 public repositories from a Fortune 100 company in GitHub and found:
17 Keys/Tokens w/ High Confidence Rating (out of a total of 1229 total secrets found)
1229 Secret/token Types Identified
1015 Password Assignments
105 AWS Access Key IDs
72 Credential Assignments
20 Google API Keys
16 Private Keys
7 Repositories Contained Secrets
In contrast, the open source tool TruffleHog found over 127,000 false positive GitHub secrets in the exact same repositories, without any distinction of high or low confidence, making the result essentially useless for the security or development teams responsible for securing the systems. Other tools like GitLeaks suffer from the same issues. Many of the false GitHub secrets identified by TruffleHog were actually dependency declarations and not vulnerabilities at all.
Why are the differences so stark between BluBracket and open source scanning tools? One reason is our advanced methodology for secret detection.
The BluBracket methodology for secret detection:
Monitors 50+ most common secret types automatically
Ability to also define custom regular expressions
Ability to look for password/credentials
Comprehensive scan of all new commits and historical commits,
Scans commits in 2 phases:
Phase I – Regular Expressions
Phase II – Deeper Scan to exclude additional false positives
Dictionary of Keywords (eliminate example secrets)
Elevate secrets committed by developers within the organization/s
Creates unique hashes for secrets and eliminates duplicates
Implementing a robust rules engine furthering admins ability to eliminate false positives
Identify secrets that have leaked into open source
Scan developer contributions to other public repositories
Deep link to the exact file/line of code
There are six key advantages of a solution like BluBracket vs an open source secret scanning tool:
UI. The BluBracket CodeInsights tool makes use of a graphical UI to present the secrets in an easily viewable and reportable form. This makes it much easier to bridge the gap between developers and security teams. BluBracket also has APIs for customers who prefer to leverage their existing solutions like Splunk.
Continuous Monitoring. BluBracket does continuous monitoring of repositories, while most tools just do a one-time scan of the current code. BluBracket does an initial scan and then continues to monitor repositories and find new secrets. Some customers use the open tools to repeat the one time scan and try to determine a difference between the last time they scanned – but unless they are running their scan continuously there may be a gap in time where their secrets are exposed.
Engineering Resources & Cost. Open source tools require engineering resources to maintain and make use of the logs. Paying an engineer to maintain and utilize these tools can easily amount to six figures, when all expenses are taken into account.
Coverage. Open source code scanning tools do not include key secret categories like passwords.
Self Learning. A vendor like BluBracket is focused 100% on improving and maintaining its solution, ensuring new secret types are constantly being added. BluBracket has a rules engine that allows it to constantly learn false positives and refine its monitoring ability to zero in on true threats.
Comprehensive Code Security. Code scanning is just one part of the value of the BluBracket CodeSecurity Suite. Instead of implementing multiple point tools that need to be integrated and maintained, BluBracket delivers a comprehensive solution for code security, including full discovery, classification and alerting on multiple vulnerability types including misconfigurations, open source and permissive access.
The focus of a vendor like BluBracket is 100% code security. It’s entire team is dedicated to constantly improving the functionality and coverage of the product to ensure companies are secure and in compliance with their code assets.
If you’d like to evaluate the Code Security Suite and find your secrets in code or other vulnerabilities, please contact us.