New Bazel Ruleset Helps Developers Build Secure Container Images

Google has made it simpler and more secure to build container images using the Bazel build system.

Bazel, an open source build and test tool similar to Make and Maven, supports projects in multiple languages and builds for multiple platforms. Developers use Starlark, a human-readable, high-level build language, to create rules instructing Bazel on what to do. A rule specifies the input files and the type of output that would be generated as a result, such as an executable or a library file. Related rules are combined into a ruleset, such as rules for creating binaries and running tests.

Bazel can be used to create Distroless builds, or minimal base images where what is in the runtime container is restricted to only the components necessary for the application. Minimal base images reduce the burden of managing risks associated with security vulnerabilities in the components and address governance issues in the software supply chain.

The new rules_oci ruleset “modernizes” the process for creating Distroless builds by adding supply chain security metadata to the container images, wrote Google Open Source Security Team’s Appu Goundan in the post announcing the general availability of rules_oci. Because Bazel supports managing and caching dependencies by their integrity hash, it can make assurances about the supply chain. Developers can get a software bill of materials showing what went into the container, allowing organizations to make informed decisions about the images they are using.

While the new ruleset doesn't automatically generate a software bill of materials, it can attach the bill of materials generated by other rulesets (such as rules_license and one for Distroless), says Sahin Yort, a software engineer at Bazel consultancy Aspect Development.

The new rules_oci ruleset allows developers using Bazel to create Docker containers instead of the older rules_docker ruleset, which is now in maintenance mode. The advantage? The new ruleset allows developers to create Docker containers even if a docker daemon is not already installed on the machine. Yort also notes that rules_oci is runtime agnostic in terms of where it looks for config files for registry authorization, unlike rules_docker which works with standard Docker paths for configuration. 

Aspect created a migration guide to help organizations make the transition from rules_docker to rules_oci.

Code signing, another new capability available with rules_oci, allows users to verify that the container image was not modified by someone else after it was created by the developer who signed it. The previous rules_docker did not have the code signing capability, Yort says.