What is status and timeline of SBOM work?

[peakschris]

Hi there,

SBOM is becoming increasingly important for all organizations, but Bazel still doesn't seem to have working SBOM support. I've seen this update: https://www.youtube.com/watch?v=9O-pr_yhjMI, and noticed that SBOM has been dropped from the bazel roadmap for this year.

From what I can piece together, the current state of play is:

• ✅ use rules_license in build repos to declare licenses and package data for your own and vendored code
• ✅ use https://github.com/bazelbuild/bazel/blob/master/tools/compliance/BUILD as reference implementation to write your own sbom tooling
• maven support: ✅ parse lockfiles, ❌ lookup licenses and descriptions Expose PackageInfo from imported packages bazel-contrib/rules_jvm_external#1196
• ❌conan support
• ❌pypi support Expose a rules_license PackageInfo from imported dependencies rules_python#2054
• ❌nuget support
• ❌npm support [FR]: Expose PackageInfo from imported rules aspect-build/rules_js#1842
• ❌general http_archive support
• ❌module.bazel support

The rules_license rules and bazel reference implementations are useful, thank you for that!

Is there still work to be upstreamed? And if so, what is the timeline for that? Or should we be rolling our own code to work around the gaps?

@aiuto

Thanks, Chris

[meteorcloudy]

Since @aiuto is no longer in the Bazel team, the SBOM work has unfortunately been deprioritized. But regarding supply chain security, we are working with the community on BCR provenance (see this doc). /cc @fweikert

[peakschris]

Ah, sad news about aiuto -- hope he has moved onto other interesting stuff -- and sad news about sbom deprioritization. This is a critical piece that comes OOTB in most other build systems; I think we need to find a way to fill the gap. We can't expect most bazel users to write this complex code themselves. Is there any more recent google work that can be upstreamed to help the community contribute towards this?

Build toolchain provenance (BCR) is also important but obviously a completely different topic.

[Geethree]

@loosebazooka ans @meteorcloudy any updates on that document?

[darkrift]

@loosebazooka @meteorcloudy Any update ?

[loosebazooka]

Yeah still working on this sorry.

[loosebazooka]

Hey so here's the document: bazelbuild/bazel-central-registry#2721

Please leave comments there. FYI this has nothing to do with sboms, just provenance attestations.

[shs96c]

There should be a rules_license release with support for the purl attribute in the PackageInfo. Once that's out, my plan (which I've not yet verified and checked with the other maintainers of rules_jvm_external, so this isn't the official plan!) is to add the licenses to the lock file we generate. This will allow us to annotate the generated targets with the correct information, which should allow the "maven" section above to green :)

I believe rules_rust already exposes license information, but it'd be handy for Python and JS to do the same. I've raised an issue with both rules_js and rules_python, and added a tracking issue to rules_jvm_external too.

[peakschris]

Thanks Simon, this sounds extremely promising!

I've come to the conclusion though that full coverage of all rulesets is going to take too long, and also may not provide the same quality of information as the official package manager sbom generator will. So I've been developing a different approach inspired by the bazel sbom generator:

• generate a workspace-level sbom by running each package manager's native sbom tool on the respective lockfile. For example, for maven a flat pom.xml can be generated from the lockfile which can then be fed into mvn. This may be expensive and requires mvn, dotnet etc all available locally, but the output is cached by bazel so only needs to be regenerated when the lockfile is updated.
• for each sbom:
  • generate a packages_used json with the aspect in bazel compliance
  • feed packages_used and package manager sboms into a python tool that pieces together an sbom for each target.

I'm undecided if this is approach is better than native support in all the bazel package manager integrations. What I like is that the tooling is much thinner, and I don't need to worry about the accuracy and completeness of the native package sboms, I just paste them in to my cyclonedx as required.