How To Evaluate Secret Detection Tools
An overview of 3 requirements for a secret detection program, and how to do it with Endor Labs.
An overview of 3 requirements for a secret detection program, and how to do it with Endor Labs.
An overview of 3 requirements for a secret detection program, and how to do it with Endor Labs.
An overview of 3 requirements for a secret detection program, and how to do it with Endor Labs.
An overview of 3 requirements for a secret detection program, and how to do it with Endor Labs.
.png)
Secrets run the internet, enabling services to control client access to everything from your Netflix account to backend databases. But according to a 1Password report, secret management is only getting harder with the continuing explosion of cloud applications. The consequences of a leaked secret are all over the news. Big names like Okta, Microsoft, and Uber experienced secrets-related breaches in 2022. The average financial damage of a secrets leak averages $1.2m in revenue. This is driven by the need to rotate secrets and worsened when an organization isn’t willing to add automation or stop the reuse of secrets.
Three Ways Bad Actors Exploit Secrets
There are three primary ways secrets are used against an organization:
- My source code is leaked, exposing my secrets, and my organization has a massive incident.
- An insider uses a leaked secret to gain unauthorized access to other company assets.
- An external actor discovers a leaked secret found inside a public repo to gain unauthorized access to corporate assets
Current Secret Management Practices Aren’t Cutting It
Improved development practices, such as not reusing or hardcoding secrets into apps, reduces the probability of leaked secrets. But that number is never going to fall to zero unless you stop using secrets altogether. 1Password found a staggering 80% of IT/DevOps organizations admitted to not managing their secrets well, while 2/3rds of IT and DevOps leaders said they’re interrupted at least daily to find a secret or manage their company’s secrets. With poor management and sprawl as the status quo, imagine how hard it is for these teams to know with any certainty whether there’s been a leak.
A secret scanning tool addresses this problem by detecting leaked secrets and enabling remediation before they’re discovered. It’s important to note that secret management is a team sport. When creating your program, the security and development teams should jointly evaluate options to make sure everyone’s requirements are fulfilled. In this blog we address requirements your teams should consider before making a shortlist.
Security Team Requirements for Secret Scanning
When you’re first implementing a secret management program, it’s most likely to be driven by the security team. At that stage, getting visibility is the top priority, followed by the creation of workflows and then a process for focusing on what matters. Their tool requirements, in order of importance, are:
Requirement #1: Improves secret security posture
Requirement #2: Saves security team’s time
Requirement #3: Helps organization grow secret management program
How Accurate and Comprehensive is the Risk Assessment?
First things first, if you’re going to adopt a secret scanning tool, you want to make sure it gives an accurate, comprehensive picture. A common pattern of secrets programs today is that secrets are only identified on the default branch. But did you know that a secret can be exposed by being committed but not actually ending up in the managed version of the source code? If the tool only scans the default branch, the results will show “false negatives” (the absence of potentially leaked secrets) and your organization will have a false sense of security. To address this problem, the tool should look across all versions of the source code (the full Git history) to appropriately qualify the risk in your environment and understand your attack surface.
Context is Everything: The Right Scan at the Right Time
Can one scan address all your secret scenarios? Probably not! There are three different types of scans that can make your secret management program more robust:
- Scan Pre-Commits— Scan for secrets in the code before committing the code to your repository during the automated pre-commit checks. This helps developers identify and remove sensitive information from their code files very early in the development life cycle.
- Scan a Specific Code Reference— Scan for secrets only on a defined path in the context of a checked-out branch, commit SHA or tag to identify secrets and raise findings. This is subtly different from the pre-commit scan, in that it’s scanning what is created when your developers commit.
- Scan Complete History— Scan for secrets in all existing branches or tags to identify if a secret has ever been leaked in the history of the project and raise findings. This helps you to identify if any secret has ever been leaked even if it was not leaked in the context of what you are working on right now.
How Does the Tool Help You Prioritize Your Time?
When implementing a secret scanning tool, you’ll want to understand how the tool fits into the security team’s workflows. Secret validation is a very simple way to help the team prioritize their time by eliminating noise (secrets that haven’t actually been leaked) so they can focus on the results that impact your security posture.
Secret validation is simply a way to focus time effectively. Consider the scenario of launching your secrets program. Without prioritization, it’s going to be hard to decide what to tackle first because you’ll be flooded with alerts for any type of secret. Validation allows you to perform an immediate filter to see what is noise and what you know can have an impact. The tool should be able to differentiate between three categories:
- Valid Secrets— The secret is active and potentially exploitable
- Invalid Secrets— The secret has been deactivated
- Unvalidated Secrets— The secret can’t be validated and needs to be assessed to determine if it’s providing access to resources
Can the Tool Identify and Consolidate Duplicate Secrets?
Another dimension of prioritizing results is the de-duplication of secrets. A duplicated secret is one that’s in the source code in two different locations. Reused secrets increase the attack surface and the risk of unauthorized access, and the management of duplicates can be complex and error-prone. Deduplication of secrets saves your security team time by consolidating multiple issues pointing to the same remediation into one issue.
How Customizable Are the Rules?
We’ll come out and say it: Your organization is special. You have your own applications and patterns of managing secrets. Like other organizations, you’re using a combination of public (e.g. AWS API) and bespoke secrets. While every vendor should be able to support those public secrets with out-of-the-box rules, they can’t support your exact needs for bespoke secrets. As your program matures, you’ll need to DIY rules to check for and validate bespoke secrets. To support this growth, look for tools with two types of rules:
- System Rules— Out-of-the-box rules for public services such as GitHub, GitLab, AWS, Bitbucket, and Dropbox.
- Custom Rules— Rules built by your team to scan and detect the secrets for any service.
Development Team Requirements for Secret Scanning
Once a secret management program has achieved visibility, workflows, and focus, it’s time to implement governance elements for the development team. There are two governance requirements that the tool must support:
Requirement #1: Saves development team’s time
Requirement #2: Prevent secret leakage
How Does the Exception Workflow Function?
An exception workflow with an informed review is the first step. An automatic exception process with an informed review for false positives enables controls to check for secrets to be bypassed quickly in the right contexts. This enables developers to communicate with security when a finding has been assessed as irrelevant (for example, a secret might only be used in a test environment). The workflow should fit seamlessly into the developer’s other workflows so that it’s a quick and easy task. In practice, this should be as simple as the developer adding a comment to the code (e.g. endorctl:allow). Via a control like GitHub branch detection, the team should require a review and approval of the exception request. Once approved, the secret won’t appear in any future scans.
How Can We Check for Secrets Prior to Commit?
A defense in depth strategy - multiple layers of controls - are critical to preventing leakage. If your developers are the only layer of defense prior to committing, then a leak is inevitable. Developers need controls to prevent leaks from being committed to the source code in the first place. This is where pre-commit scans (discussed in Context is Everything) come into play. This function can reduce the probability that your developers will have to deal with rotation, acting as an important cost control mechanism.
Secret Scanning with Endor Labs
With Endor Labs, your security team can prioritize handling valid secrets and your developers can quickly mitigate using clear instructions for remediation. With the ability to set up system or custom rules, and scan at the right time, teams can rest easy that they won’t end up on a “wall of shame” for a leaked secret.
Check out this 3 minute demo to see secrets scanning in action. To learn more, schedule a 20 live minute demo with our experts.
