BazelCon: Streamlining VMware

### Overview At BazelCon, Daniel Mshlab presented VMware's initiative to streamline its open source software (OSS) license compliance process using Bazel. Open source components often comprise over half of modern codebases, requiring rigorous identification, tracking, and compliance with varying legal and security requirements. Traditionally, VMware's compliance workflow relied on post-build local scans or continuous integration pipelines paired with asynchronous reviews by legal and security teams. However, this process introduced significant development friction and delays when unapproved packages were flagged late in the development cycle. To address these bottlenecks, VMware created a new developer-centric workflow built around a custom Bazel rule called `oss_audit`.

### Key Topics - **Friction in Traditional OSS Compliance:** Identification and tracking of OSS dependencies typically occurred post-build or in CI, causing multi-day review turnarounds and costly late-stage remediation. - **Shift-Left Compliance via Bazel:** Using Bazel aspects and build rules to inspect dependency graphs and validate compliance directly during the build. - **Automated Artifact Generation:** Producing deterministic Software Bill of Materials (BOM) files and tracking unresolved or unapproved packages through issue reports. - **Enterprise Integration:** Synchronizing build-time checks with internal legal and security review tools, including support for temporary suppression mechanisms and multi-service aggregation.

### Technical Details The solution centers on the `oss_audit` Bazel rule, which leverages a Bazel aspect to traverse the build target's dependency graph. This aspect identifies both direct and transitive dependencies across targets such as RPM packages (via `rules_pkg`), tar archives, and Java binaries.

The rule consumes two primary data sources: the build target itself and lists of approved and denied packages populated from VMware's internal review systems. Upon execution, `oss_audit` generates two outputs: 1. `bomb.yaml`: A deterministic bill of materials structured as key-value pairs linking package identifiers to metadata, transitive dependency details, and copyright notices. 2. `bomb_issues`: A dedicated issues file listing dependencies that are unreviewed, pending approval, or explicitly denied by legal or security teams.

During a live demonstration using a Java application importing Google Guava via `rules_jvm_external`, Mshlab illustrated how the aspect detects transitive dependencies. When a denied package (`findbugs-jsr305`) was introduced, the build failed immediately with an explanatory alert. Developers needing temporary leeway can specify a `suppressed` list attributed with a build number, allowing the build to pass while maintaining an active reminder to refactor. In production pipelines, automation consumes the generated BOM to file review tickets asynchronously for new packages, fetches updated approval lists, and commits them back to source control for subsequent builds. For microservice or multi-service architectures, service-level BOMs can also be merged into a unified top-level product BOM.

### Takeaways Integrating OSS compliance into the Bazel build pipeline shifts compliance checks directly to build time, transforming a multi-day feedback loop into instantaneous notifications. This eliminates developer toil, prevents late release-blocking remediation, and guarantees comprehensive BOM tracking across direct and transitive dependencies. While initially deployed for Java, VMware is expanding `oss_audit` support to C++ and other languages, aiming to collaborate with the broader Bazel community toward standard open-source licensing infrastructure.