Blog White Papers

New Webinar: How to Prevent Code Leaks

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

Uncovering Secrets in Code—A Case Study

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
  • 52 Developers

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)
      • Tag/Enrich 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: 

  1. 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. 
  2. 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.
  3. 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. 
  4. Coverage. Open source code scanning tools do not include key secret categories like passwords. 
  5. 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.
  6. 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

If you’d like to learn more about the top security risks from code, please download our white paper. 


Meet Us At BlackHat 2020 & Enter to Win a Mirror Home Gym

BlackHat is virtual this year. But that isn’t stopping us from sponsoring and connecting with attendees.

In fact, we realize we’ve been all stuck and home, usually behind a keyboard. So we’re giving away a Mirror Home Gym to one lucky person who signs up and gets a demo from us. We only ask that you have a genuine interest and need for code security.

You can register for a free pass for parts of the conference, or you can sign up here and we can connect right away.



Why Code Security Unlocks the Next Trillion Dollar Software Opportunity

Noted investor Glenn Solomon recently made a compelling case in Forbes that the next big enterprise software opportunity will be fueled by developers. The first two trillion dollar trends—Saas and public cloud—revolutionized the way software is delivered and deployed, effectively making every company a software company. Now the opportunity lies in products that “make the software development and data management processes easier, faster, more secure and completely democratized.”

We completely agree. In fact, we know that the developer revolution has already begun. 

As Solomon says, “As every company strives to become a tech company, they must create an endless array of software to fuel their growth. So it’s no surprise that products enabling developers to build applications quickly, collaboratively, data-driven and productively will become the next trillion-dollar market.”

But just as importantly, products enabling developers to build secure software are key to unlock this rise.

Innovation, speed and collaboration in software development have completely changed over the last decade. Developers now have a vast arsenal of open source projects, libraries and components that can be shared instantaneously. They spin up their own cloud infrastructure and launch public services without waiting for operations or security teams. They have the power to choose their own tools, instead of being forced into the tops-down technology adoption of the past.  

But wait, there’s a risk? 

But the insight, governance and security around those great innovations has not kept pace. Code has become a major threat vector for hackers. Passwords, secrets, tokens and PII are frequently left in code. Valuable source code that contains true business advantage is open and available for theft and ransom. Developers are in the driver seat of the next giant wave. We need to arm them with tools to ensure they’re not steering us into a wall.

This is why we’re so passionate about security at the speed of code. It would be easy to lock up developers and make it secure. No Git, no open source, no IaC, no cloud-native. But there isn’t a single company that would make that choice. 

Innovation and speed will always win. That’s why the old security models just don’t apply in the land of developer-driven software. 

So what does code security in this new world look like? 

  • Authentication and authorization of developers in these new environments is critical, as well as fine-grained and trackable permissions that reach all the way to developer endpoints. As remote work is here to stay, we will see new ways to authenticate developers that rely on zero trust. 
  • Code security must address containers like Kubernetes and Docker. In a cloud-native world, many security vulnerabilities stem from misconfigurations. Code security must monitor and address those misconfigurations in containers, as well as Git. 
  • A focus on code provenance and authentication in open source projects. Developers need a quick and easy way to guarantee that the open source components they’re using are safe and compliant. 
  • Core security functions must be embedded into the natural workflows and tools of the developer and the CICD pipeline, making security policies actionable. Security has to adapt to devops, not the other way around. 
  • Understand that Git is the protocol fueling this adoption and use its powerful features to empower the developer to write more secure code from the beginning while giving security teams the information and control they need for vigilance and governance. 
  • And most importantly, empower the developer within their tools, their workflow and their pace. 

We must stop thinking of security as something that just “has to be done” for risk management. Our vision of code security unlocks greater innovation for companies, who can now make use of the latest tools without fear of a breach or misconfiguration. Code security will enable more innovation, at a faster pace.

We are thrilled that savvy investors like Glenn (and our own) see the potential of this massive opportunity that’s already well underway. We couldn’t be more excited to provide the security needed to unleash a powerful new wave of innovation. Join us on our journey to make code safe. 


Code scanning does not guarantee code security.

Code scanning is an integral part of application security. Since BluBracket is considered to be the industry’s first comprehensive code security solution, there can be confusion over how code security relates to code scanning. Is it the same thing? Does BluBracket replace common SAST or DAST tools? 

The answer is no. Code scanning tools are a necessary part of application security, but on their own don’t give security and devops teams the complete insight, control and protection of their source code, which includes developer and endpoint machine activity.

Collaborative coding with Git and open source, Infrastructure as Code and cloud-native development have all contributed to the need for comprehensive security for code. Not to mention the importance of code as intellectual property has risen greatly for most companies as software continues to “eat the world.” 

And the threats continue to rise. According to Verizon’s 2020 Data Breach Investigation Report, 43% of attacks were on web applications, more than double the results from last year. The time for comprehensive code security is now, while robust code scanning tools are still an important piece of the toolbelt.

Code scanning 101

As OWASP defines it “Source code analysis tools, also referred to as Static Application Security Testing (SAST) Tools, are designed to analyze source code and/or compiled versions of code to help find security flaws.” These tools build dependency trees, comparing them to known vulnerabilities. 

SAST tools, oftentimes called white box testing, are used by developers on their uncompiled code to find potential vulnerabilities. SAST is an “inside-out” approach to security given it scans the code itself, and not a running application. 

DAST tools are used later in the development process and are more akin to penetration testing. They run against compiled applications to see which vulnerabilities are actually exploitable. It’s an “outside in” approach. 

Companies with robust application security requirements generally run both DAST and SAST tools. But increasingly, they are turning toward a complete code security environment to protect their code and data. 

A new threat surface.

Code scanning tools don’t address many of the most common, and growing, code security issues today, including:

  • Secrets, tokens and passwords inadvertently left in code by developers. 
  • Configuration errors in Git or cloud deployments that lead to unauthorized access.
  • Code proliferation to unknown machines with little to no access controls or tracking of where the code is cloned. 
  • Webhooks and unauthorized application access that can provide a way-in for hackers. 
  • Accidental leakage of code from enterprise private repositories that can be used for ransomware or by competitors.
  • Intentional theft of source code that can be used for ransomware or sold to competitors. 

A complete code security program goes beyond application security basics like code scanning to include new threat surfaces, such as those in Git-based source code management systems. It should address developer behavior on both the server and endpoints, which includes their own personal machines they may have cloned code to. A comprehensive security suite should also address security concerns while not hindering developer velocity. If the tool isn’t built with the developer in mind and is too cumbersome, it won’t get used. Also be sure the tool fits into your CI/CD workflow so it’s directly integrated into the development workflow and not an afterthought.

If you’re interested in learning more about the Top Risks from Code, you can download our whitepaper. 

OWASP is also a great resource to participate in and learn from. Their top ten list is required reading. And for companies looking to strengthen their company’s software security, the Software Assurance Maturity Model (SAMM) is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization. 

Code has grown more complex, collaborative and important to virtually every organization doing business today. Companies are increasingly realizing that a comprehensive code security solution is a fundamental step in their application security journey. Let us know if we can help. 


Git it right—How hackers exploit Git misconfigurations & what to do about it

This month, Mercedes Benz left 580 source code repositories open and available for anyone to access on the Web. These repositories not only contained valuable source code for vehicle components which could be used for attack, they also contained passwords and tokens that unlocked access to other Mercedes private servers. 

Was this a product of a sophisticated hacking cartel who targeted Mercedes Benz? Hardly. It was simply a misconfiguration of GitLab that allowed anyone to create an account and download the code. 

This breach goes to show that code is a valuable target for hacking, and that common misconfigurations in Git are to blame for many security breaches. 

As the Mercedes example shows us, code is not only IP that needs protection—it’s also mined every day for secrets, tokens, passwords, and other credentials. As important information increasingly finds its way into source code in the form of Terraform scripts, ML models, and even security policies themselves, code becomes an even greater threat vector. 

Here are three common misconfigurations in Git that can lead to security breaches:

Problem #1

Leaving a .git folder in a publicly accessible computer/server.

Because Git users pull code (clones) to their native machines, the code proliferates. Companies today have little to no idea who has actually cloned their code on what machines. It’s then very easy for a backup file to find its way into an unprotected server or for the web developer to mis-configure the webserver and leave it open and available in the website directory. 

Recently, the official GDPR advice site left their .git folder on a web server. Hackers proactively scan the web looking for this type of folder. In the GDPR case, a hacker found a MYSQL password that could have been used to potentially access and modify the site itself without notice. 

According to Threat Post, “Open .git directories are a common problem – a scan of more than 230 million web domains worldwide in 2018, in fact, uncovered 390,000 web pages that were vulnerable due to the issue.”

Problem #2

Code is inadvertently marked public. 

This misconfiguration is very common, which makes sense when you take into account GitHub’s history in open source, where the default is always public and the access is very permissive. Companies who use GitHub for closed source need to be vigilant to ensure these defaults are not applied to proprietary source code. 

An example with far reaching implications comes from Samsung where the company left dozens of critical code repositories on GitLab marked as public.  According to the security researcher quoted in the article, one repository contained credentials that allowed access to an entire AWS account that held several employees’ private GitLab tokens stored in plaintext. 

Companies need a way to audit and view code settings and developer actions in concert, so they can be alerted on these vulnerabilities. By helping companies find who has cloned their important code or even who may have publicly posted it, we make sure the risks from this type of vulnerability are lowered. BluBracket CodeInsights helps you find passwords and tokens, and also generates alerts when critical code is made public.

Problem #3

Unauthorized webhooks or application access to all code repositories.

Developers frequently use applications or services to provide data, complete a function or provide a service that enhances their own work. This saves time and increases productivity, but it can also expose companies to both IP theft and hacker attacks into critical systems via credential leaks. 

When a developer gives an application access to the code, it generally gives access to all repositories she has access to. Token authorization is mapped to the user, not the repo. And currently there is no easy way for managers or security personnel to audit and view the applications or webhooks used in code. Once the app has access, it can be a trojan horse into the code, and thus into other infrastructure or applications. 

Most companies have lists of authorized applications and webhooks, as well as configuration settings that are required to keep things safe, but having a security policy in a document is much different than deploying a system (like ours) that actually enforces and alerts on these policies. As coding becomes ever more componetized, understanding the linkage and permissions for these types of applications and webhooks is crucial for true security. 

How to Git it right.

The truth is while Git-based systems like GitHub, Gitlab and Bitbucket are fantastic for developer collaboration, speed and productivity, they just aren’t instrumented for security. They’re platforms that rely on other companies to augment critical functionality. 

By adding a security tool like BluBracket, companies gain the advantages of Git-based development, while mitigating the security risks and helping developers shift security left. If you’re interested in learning more about our vision for security at the speed of code, please contact us to learn more or download our Top 5 Security Risks from Code white paper to dive deeper. 


Get a Free Code Security Audit

It seems everyday we are seeing more breaches emanating from code and code source code management systems like GitHub. Hackers are sharing tips everyday saying code repositories are one of the best ways to infiltrate a company’s private assets.

Git is the wild west and wasn’t designed for corporate security. To help untangle the confusing landscape of code security, we are offering a free scan and detailed Public Code Security Report for those companies using GitHub– with no obligation. You will gain knowledge of credential vulnerabilities as well as insight into developer activity. 

It only takes 30 minutes of your time to find out:

  • How many total and confirmed secrets in code or other vulnerabilities that can put your at risk.
  • Which developers committed those secrets to public code. 
  • Total number of repositories and organizations linked to your company. 
  • Potential PII in code available for all to see. 
  • Which developers are most active in your organization. 
  • The number of new repositories created in the last 30 days.

Request your free code security report.


Why GitHub Security Isn’t Enough.

Last week, GitHub made a series of announcements at GitHub Satellite, including some great news around code scanning and increased security for their platform. We love to see this because the more companies who use GitHub (and GitLab and Bitbucket), the better for the industry, and the more value BluBracket can provide on top of these platforms. And while GitHub has many useful security features, especially around open source projects, GitHub security is not enough for most large companies who value their code. Why?

GitHub’s Open Source Roots

Customers who rely on GitHub for code security, even the enterprise level version of GitHub, are exposed to numerous vulnerabilities—not by any fault of GitHub, but rather because GitHub was built and rolled out for open source projects, only later adding features for the enterprise. That means the protocol and product are designed for code proliferation and sharing by default. It’s not instrumented to give security teams insight into developer actions and security vulnerabilities. 

Here is a summary of why GitHub security isn’t enough:

  • GitHub doesn’t track or expose code on developer endpoints (workstations, VMs, etc). The number one code exfiltration vector is the developer endpoint, not the repository. Git providers such as GitHub, BitBucket and GitLab are doing nothing about clones and copies of code on developer machines. We are. 
  • Since Git is a distributed source control system, users download all code in the repository to their end machine. This equals code proliferation. Security teams have no visibility or control over where their valuable code has been downloaded. And as we have seen, unprotected machines can be easily hacked or simply lost track of. 
  • GitHub’s DNA is in open source, so its tooling and focus is on developers in public projects. It wasn’t built for security teams or devsecop teams; it was built for open source developers who it serves very well. 
  • GitHub covers GitHub, which means if your company uses multiple Git providers (most large companies do) you are out of luck. BluBracket has a holistic approach to enterprise security which means it allows you to view all of your code actions, vulnerabilities and alerts from all Git providers in one pane of glass.
  • GitHub doesn’t focus on or alert on developer actions. For instance, you may want to be alerted if a core developer is pushing code from a private repository to open source, or changing the repo’s designation to public.
  • GitHub has no way to fingerprint your important code and then discover it in public repositories, wherever that may be, or tell you which secrets detected in your private enterprise have also been leaked into open source. Many companies have been surprised to learn how much of their proprietary source code has made its way to the public domain. Developers frequently re-use and push code developed for the company to open source or other public repositories. This can give hackers a way to access your protected infrastructure.
  • GitHub doesn’t have code classification. To do security effectively, you have to determine the signal vs noise. Enterprises need a tool to classify code by importance to the business, and have all permissions, alerts and security policies follow that classification. 

Comprehensive Code Security

BluBracket is the industry’s only comprehensive security solution for code, securing every major Git-based solution including GitHub, Bitbucket and GitLab. Unlike GitHub, BluBracket analyzes developer behavior and Docker containers for vulnerabilities. It allows you to set and then enforce your security policies across all Git repos, regardless of what cloud or on premise solution you choose. 

We believe Git and GitHub in particular are industry-changing services that have driven massive gains in innovation and collaboration. We are thrilled to offer advanced security solutions on top of these platforms for companies who understand the risk now inherent in code sharing sites. 

Learn more about BluBracket’s Code Security Products or contact us for a free Code Security Audit Report


Securing developers in the time of Covid-19.

We’re all adjusting to the new normal, where we have to scramble to work remotely. Developers in particular need to stay productive—securely. No one needs to deal with a security crisis on top of a global health crisis. 

That’s why we’re offering our CodeInsights product free of charge for the next 90-days. No strings attached. 

With CodeInsights, you can enable your developers to stay productive wherever they work, on tools of their choice, securely. Security and technology teams can finally get the visibility and control they need over Git and make security policies actionable without getting in the way of your developers’ workflows. This offer is available to any organization that has been impacted by COVID-19. 

If you’re interested in finding out more about more and applying for the program, please find the details here

BluBracket is a young and growing company. We want to help those in the most need first, so please bear with us as we evaluate and service interest. While we know there are bigger issues facing our world, we hope that by offering our small piece of the security puzzle, we can enable companies to stay secure and productive. 


AMD’s Xbox source code stolen and held for ransom.

When the source code to control the graphics of the new Xbox Series X console was stolen the news grabbed the attention of many in the security world. It’s a nightmare no company wants to go through—key IP stolen and held for ransom. If no buyer is found, the hacker will post the IP for all to clone on Github. 

The implications stemming from this incident are far from over. Read all the details from our COO and President on how it happened and what to do about it so it doesn’t happen to your company.