SBOM support for Bazel modules

[fmeum]

rules_license provides the basic license and package_info rules that serve as the basis for SBOM generation (and other kinds of supply chain analysis) for all kinds of Bazel dependencies. While individual rulesets that provide external dependencies can adopt these rules to annotate external deps with package metadata, there is no canonical way of doing this for Bazel modules themselves.

I would like to discuss and collect the steps we need to take to improve this situation. My ideas so far:

Add a purl type for Bazel modules

This would provide a canonical way to refer to a given Bazel module, even if that module is not in the BCR. I prepared a draft of a specification of such a type on this branch.

Make it easy for public Bazel modules to attach package_info

Compared to license information, which may easily vary on a per-target basis, package metadata as specified in package_info would usually apply to the entire module. By adding a small helper macro to rules_license, the required integration for Bazel modules could be reduced to "just":

# MODULE.bazel
bazel_dep(name = "rules_license", version = "0.0.8")

# REPO.bazel
repo(default_package_metadata = ["//:package_info"])

# BUILD.bazel
load("@rules_license//rules:current_module_package_info.bzl", "current_module_package_info")

current_module_package_info(name = "package_info")

The current_module_package_info macro would rely on native.module_name() and native.module_version() to populate defaults for all the fields on package_info automatically (e.g., the purl).

Bazel registry tooling could be extended add the boilerplate automatically to new modules.

Modules with more complex requirements could still override the default package metadata on a per-package or per-target basis or choose to not use the macro.

[fmeum]

cc @Wyverald @meteorcloudy @aiuto @shs96c @keith @meisterT

[darkrift]

PURL is already part of cyclonedx and spdx specifications.

Ref to cyclonedx 1.4 json schema
SPDX spec ref

[darkrift]

Support in rules_license was also added by bazelbuild/rules_license#143

[fmeum]

Yes, purl is the closest to a universal format we will get. rules_license has (unreleased) support for it: bazelbuild/rules_license@4f8f5f2

[meteorcloudy]

Nice, thanks for the context!

[aiuto]

That just got merged. There is another PR in flight to use it in the sbom maker.

[shs96c]

@fmeum I'm not sure that your assertion about package info being correct for an entire module is true. For example, in a monorepo, there may be several artifacts that could be produced that others could depend on (eg. java_export targets), and each of those could have different package info. That is, package info could be per-target.

[fmeum]

It's not meant to be an assertion about all modules, just about the common case. I added a paragraph to that section to explain other options for modules with more complex requirements. I'm just trying to keep the amount of boilerplate for the common case as low as possible.

[sluongng]

I like the idea about current_module_package_info.

On the REPO.bazel file: what would be the right way to set this up for repositories with 2 or more licenses? For example: https://gitlab.com/gitlab-org/gitlab uses a different license for /ee directory. Or https://github.com/open-telemetry/opentelemetry-go which contains multiple go modules with different versions underneath.

[fmeum]

https://gitlab.com/gitlab-org/gitlab

It's not very likely that this repo will become a Bazel module in the BCR anytime soon, so this is more of an example of a complex end-user repo. As such, a REPO.bazel file at the top-level could set the OSS license and the individual BUILD.bazel files in the subdirectories of /ee could set another license via package. I would generally expect a repo of this size to use a Gazelle language or some other mechanism to generate package_info targets anyway

https://github.com/open-telemetry/opentelemetry-go

This repo should be consumed as Go modules via the facilities provided by gazelle's go_deps extension. Each Go submodule would have its own pkg:go purl. It wouldn't be related to what we do for Bazel BCR modules.

[shs96c]

@fmeum reading the suggested purl spec, it looks good. I would point out that repository_url and download_url are already known qualifiers on a purl so the use of namespace may cause duplicate information to be included in the purl. That is, pkg:bazel/example.org/bazel-registry/[email protected] may be rewritten as pkg:bazel/[email protected]?repository_url=example.org/bazel-registry

I think there might be a valid counter argument that this is overloading repository_url and so the namespace is necessary, and that's entirely valid.

Within a single repo, it is also useful to know which target produced each artifact. It would be good to have a mechanism to (optionally) include that information too. Perhaps a target qualifier?

[fmeum]

@fmeum reading the suggested purl spec, it looks good. I would point out that repository_url and download_url are already known qualifiers on a purl so the use of namespace may cause duplicate information to be included in the purl. That is, pkg:bazel/example.org/bazel-registry/[email protected] may be rewritten as pkg:bazel/[email protected]?repository_url=example.org/bazel-registry

Thanks, I didn't know that repository_url was meant to refer to a package registry. It does look like the better way of encoding alternative registries. I will update the draft.

Within a single repo, it is also useful to know which target produced each artifact. It would be good to have a mechanism to (optionally) include that information too. Perhaps a target qualifier?

I was already considering including a way to refer to a particular target. Now that you bring it up as well, let me just include it in the spec.

[fmeum]

I updated the spec to use repository_url. I also found subpath to work well for what target would have specified. PTAL.

[shs96c]

LGTM. Thank you for making the changes.

[fmeum]

I made some small edits and added test cases. I started a draft PR and would submit it after discussing this topic at the next Rules Authors SIG meeting.

[aiuto]

Building pacakge_info dynamically sounds promising. The next step would be to tie it to build targets via package(default_package_metadata).
How do you propose to do that? Or, if that is not what you intend, how do you go about finding it doing an aspect traversal from a build target to the package data?

[fmeum]

That's this part:

# REPO.bazel
repo(default_package_metadata = ["//:package_info"])

This sets a repo-wide default, which is more straightforward then adding a package call to all packages. Individual packages and targets can of course still override this.

[fmeum]

I sent a draft PR implementing this macro: bazelbuild/rules_license#147

[aiuto]

Cool. FWIW... I am currently very interested in making SBOM generation work. But, of course, the user here is using WORKSPACE rather than bzlmod, so I want to try your thing along with a workspace rule. Having both would be great.

…

On Thu, Aug 1, 2024 at 6:37 AM Fabian Meumertzheim ***@***.***> wrote: I sent a draft PR implementing this macro: bazelbuild/rules_license#147 <bazelbuild/rules_license#147> — Reply to this email directly, view it on GitHub <#23166 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXHHHB3Z5CUE76ODUUOGN3ZPIFW3AVCNFSM6AAAAABLYQJE2GVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMRRGEYDANQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[fmeum]

@mzeren-vmw We discussed this in the Rules Authors SIG meeting, but would also be interested in your opinion on the purl spec addition.