Introducing a Better Way to SCA for Monorepos and Bazel
Endor Labs’ reachability-based SCA now supports Bazel so you can get fully accurate results without any of the messy workarounds usually required for monorepos.
Endor Labs’ reachability-based SCA now supports Bazel so you can get fully accurate results without any of the messy workarounds usually required for monorepos.
Endor Labs’ reachability-based SCA now supports Bazel so you can get fully accurate results without any of the messy workarounds usually required for monorepos.
Endor Labs’ reachability-based SCA now supports Bazel so you can get fully accurate results without any of the messy workarounds usually required for monorepos.
Endor Labs’ reachability-based SCA now supports Bazel so you can get fully accurate results without any of the messy workarounds usually required for monorepos.
We’re excited to announce that Endor Labs now supports Bazel, the go-to build system for projects built in monorepos and developing in multiple programming languages and platforms. With this capability, we support the ability to analyze the security and operational risk of software built on Bazel, including native Bazel rules for Java, Python, and Golang. And our coverage will only grow from here!
If you’re a Bazel user, you probably already know why it’s a big deal and can skip to Why Bazel is Hard for SCA Tools. But if you’re new to Bazel, understanding the problems it solves for development teams is the key to understanding the benefits of a Bazel-compatible SCA tool.
Why Bazel is a Big Deal
Time-consuming build processes often kill development productivity and directly impact the business's bottom line.
Collaboration can be challenging in organizations operating out of monorepos, especially those with a substantial number of developers (500+). While trying to overcome these challenges, Google created Bazel, an open source build system especially tailored for monorepos. Bazel is an essential solution that ensures efficiency and prevents productivity from screeching to a halt by solving two problems:
- Wasted build time— Bazel speeds up builds through parallel builds and caching.
- Wasted troubleshooting time – Bazel ensures reproducible builds (which prevent unintentional software changes/differences) because its build config files require dependencies to be explicitly stated for each project module (rather than inferring them from language-specific manifest files as is typical for most build systems and package managers).
TL;DR — Bazel makes software development faster and your dev team loves it.
Why Bazel is Hard for SCA Tools
Existing software composition analysis (SCA) solutions generally don’t cut it for monorepos and teams relying heavily on Bazel. This is because Bazel is designed to completely manage its dependencies and Bazel support for each language varies. But teams relying on Bazel can’t live without it. To meet compliance and security obligations, they create workarounds that cause their own set of problems. At Endor Labs, we understand this challenge firsthand as we are monorepo users ourselves!
Challenge 1: Lack of Bazel and Language Support
One of the challenges with Bazel is that very few vendors can analyze software built using Bazel. Even those that offer Bazel support often have limited language coverage (such as only supporting certain Java Bazel rules). This doesn’t work because Bazel is designed to collaborate across multiple languages. If the SCA tool doesn’t support the languages in your Bazel-driven monorepo, you won’t get complete or fully accurate results.
Challenge 2: Requirement to Build Entire Monorepo
SCA tools commonly require the entire monorepo to be built to yield results. Given the extensive size of monorepos (they can have more than 1000 packages!), this approach lacks scalability. It’s also impractical for integration into a CI/CD environment, as it's unfeasible to spend hours analyzing software for every commit. These inefficiencies could significantly hinder developer productivity.
An Example Workaround with Bazel and Java
Given the lack of out-of-the-box SCA support for Bazel, monorepo teams are often forced to meet their security and compliance obligations through extensive workarounds. We faced the same issues at Endor Labs! We’ll use our Java packages to illustrate the problem.
To accommodate tools that didn’t support Bazel, we had to maintain a pom.xml file that could be referenced by those tools. Managing dependencies through the both pom.xml and build.bazel files posed significant challenges for our developers. It introduced the complexity of updating library versions, as well as adding or removing libraries in multiple places. On several occasions, discrepancies between our pom.xml and build.bazel files led to less than optimal outcomes, such as increased vulnerabilities, missed vulnerabilities, incorrect dependency graphs, and licensing issues. Regrettably, this led developers and security engineers to invest their time in addressing issues that, in reality, were non-existent for our team.
Having heard similar stories from our customers, prospects, and friends, we knew we weren’t alone. If you’re maintaining a Bazel workaround like our Java example, now there’s a better way!
How Endor Labs Helps Monorepo Teams Using Bazel
In large monorepos, the number of software packages can be enormous. For example, we’ve worked with customers where a single monorepo had 1000+ packages and this is frequently an issue. Scanning each package on every pull request could bring development productivity to a halt! For this reason, we prioritized supporting the ability to scan targets using Bazel queries or by explicitly defining the Bazel targets.
Taking a page from the Bazel philosophy, we use Bazel targets so that you can scan only what matters to you, scan in parallel, and scan only when something has changed. To help monorepo teams speed up their development and testing, we favor a practical inline scanning over the traditional “scan everything at once”,
For example, all Java binaries in a monorepo can be discovered using a Bazel query such as this example that returns two targets:
The same query can be used to define which targets to scan, using the same “language” that Bazel users are so familiar with.
As mentioned earlier, scanning all (Java) targets within a monorepo is not a scalable approach and can consume several hours. To address this issue, we offer the option to selectively scan only those targets that are affected by a specific file changes (like a file being changed in a pull request), for example:
By using the rdeps feature of Bazel, only the targets being impacted by the file src/java/main/lib/top_x.java are scanned. This capability saves hours of scan time since only what’s being changed will be analyzed! You can also accomplish the same feat in a completely native way to Bazel with a Bazel rule that lets you manage regular testing in a Bazel-native way.
Get Started with Endor Labs
With Bazel-native support, you can use Endor Labs to analyze your software in a way that's compatible with Bazel, more accurate, and more closely aligned with the Bazel philosophy than traditional SCA tools. If you want to learn more, we’d love to chat.