Bazel Blog

Enhancing Security Metadata in BCR with Attestation Support

By Appu Goundan and Florian Weikert on 01 August 2025

Bazel Central Registry is the go-to source for discovering and managing Bazel modules. Over the last few months Aspect Build, Bazel Central Registry and the Google Open Source Security Team have been working together on enhancing the security of the software supply chain. We are happy to announce that attestation support in BCR is now available. This includes updated GitHub Actions for packaging and releasing rulesets. It also enables pre-submit verification of this new security metadata on the registry.

For module maintainers this allows easy publishing of signed provenance with module releases. For consumers, this means a greater availability of security metadata to make informed decisions when including or updating dependencies.

Get Started Today

Publishing Attestations

If you are using release_ruleset with the publish-to-bcr legacy app to publish your modules to BCR, you should:

  1. upgrade your release_ruleset to use the new attestation generating workflow
  2. follow the instructions to setup the new publish-to-bcr workflow

To see how this affects a release, let's use the example of aspect_rules_lint which has been publishing modules with attestations since v1.3.4. You will see a new publishing artifact `attestations.json' that contains information about your attestations. On successful publication, BCR will preserve and mirror attestations for publishing artifacts. Please note that since BCR does not mirror the source archive, it also does not mirror the source archive's attestation. The BCR UI will attach a blue indicator to a release version informing users that attestations are available for consumption. image

Verifying Attestations

Once you've generated and published your attestations, you can validate them. For the purposes of this example, we will once again use aspect_rules_lint. There are three critical files to attest to cover a module version:

  1. MODULE.bazel (published to BCR)
  2. source.json (published to BCR)
  3. the packaged module source (not hosted on BCR): rules_lint-v1.3.4.tar.gz

Keep in mind that attestations for MODULE.bazel and source.json are generated by the publishing workflow github.com/bazel-contrib/publish-to-bcr/.github/workflows/publish.yaml and attestations for the source archive are generated by the release workflow github.com/bazel-contrib/publish-to-bcr/.github/workflows/publish.yaml. We need these workflow references when verifying the attestations.

Verify MODULE.bazel

Let's try to validate MODULE.bazel. To illustrate this, we'll do it by hand, though your build infrastructure should automate it. On the command line you can do this using the GitHub CLI.

The GitHub CLI uses attestations that were uploaded to the attestations store during publication. The attestation can be seen in the attestations tab for a project.

Download the file from BCR
$ curl -sSO https://bcr.bazel.build/modules/aspect_rules_lint/1.3.4/MODULE.bazel
Run the GitHub CLI attestation verification workflow
$ gh attestation verify MODULE.bazel \
    --repo aspect-build/rules_lint \
    --source-ref refs/tags/v1.3.4 \
    --signer-workflow github.com/bazel-contrib/publish-to-bcr/.github/workflows/publish.yaml@refs/tags/v0.0.1

Loaded digest sha256:e0758f32323887cfe0b9d6e9f01f803f50a3f5efb6a229fc6791e99bd91ea038 for file://MODULE.bazel
Loaded 1 attestation from GitHub API

The following policy criteria will be enforced:
- Predicate type must match:................ https://slsa.dev/provenance/v1
- Source Repository Owner URI must match:... https://github.com/aspect-build
- Source Repository URI must match:......... https://github.com/aspect-build/rules_lint
- Source repo ref must match:............... refs/tags/v1.3.4
- Subject Alternative Name must match regex: ^https://github.com/bazel-contrib/publish-to-bcr/.github/workflows/publish.yaml@refs/tags/v\*
- OIDC Issuer must match:................... https://token.actions.githubusercontent.com

✓ Verification succeeded\!

The following 1 attestation matched the policy criteria

- Attestation \#1
  - Build repo:..... aspect-build/rules_lint
  - Build workflow:. .github/workflows/release.yml@refs/tags/v1.3.4
  - Signer repo:.... bazel-contrib/publish-to-bcr
  - Signer workflow: .github/workflows/publish.yaml@refs/tags/v0.0.1

The --source-ref refs/tags/v1.3.4 flag ensures the build came from an officially tagged commit.

The --signer-workflow github.com/bazel-contrib/publish-to-bcr/.github/workflows/publish.yaml@refs/tags/v0.0.1 flag corresponds to the approved builder workflow and version. While it is optional for verification, it's recommended to ensure the official publishing workflow was used. For a builder with many versions this can be a regex like ...@refs/tags/v\\d+\\.\\d+\\.\\d+$, but your build's policy file can map the correct version to the artifact in question.

Verifying source.json

Repeat the process used for MODULE.bazel with source.json

$ curl -sSO https://bcr.bazel.build/modules/aspect_rules_lint/1.3.4/source.json
$ gh attestation verify source.json \
    --repo aspect-build/rules_lint \
    --source-ref refs/tags/v1.3.4 \
    --signer-workflow github.com/bazel-contrib/publish-to-bcr/.github/workflows/publish.yaml@refs/tags/v0.0.1

Verifying source archive attestations

Verification of source archives needs a minor tweak to --signer-workflow since they are generated by a different builder: github.com/bazel-contrib/.github/blob/master/.github/workflows/release_ruleset.yaml. The source archive is also not mirrored or hosted by BCR, so it must be downloaded from the project's release archives.

$ curl -sSLO https://github.com/aspect-build/rules_lint/releases/download/v1.3.4/rules_lint-v1.3.4.tar.gz
$ gh attestation verify rules_lint-v1.3.4.tar.gz \
    --repo aspect-build/rules_lint \
    --source-ref refs/tags/v1.3.4 \
    --signer-workflow github.com/bazel-contrib/.github/.github/workflows/release_ruleset.yaml@refs/tags/v7.1.0

Verifying with a downloaded attestation

You can skip the github attestation store lookup and use a downloaded attestation instead. For example, with MODULE.bazel:

Download the file from BCR and its attestation

$ curl -sSO https://bcr.bazel.build/modules/aspect_rules_lint/1.3.4/MODULE.bazel
$ curl -sSO https://bcr.bazel.build/modules/aspect_rules_lint/1.3.4/MODULE.bazel.intoto.jsonl

Use the --bundle flag to run the verification workflow with the downloaded attestation

$ gh attestation verify MODULE.bazel \
    --repo aspect-build/rules_lint \
    --source-ref refs/tags/v1.3.4 \
    --signer-workflow github.com/bazel-contrib/publish-to-bcr/.github/workflows/publish.yaml@refs/tags/v0.0.1 \
    --bundle MODULE.bazel.intoto.jsonl

Limitations

  1. If you want to publish your module to BCR, you must use attestations generated by the community Github Actions Workflows defined in release_ruleset and publish.
  2. If you are using your own actions and attestations generators, BCR may reject your release. You can still generate attestations for them, but your release may not include them via the publish action (set attest:false on publishing)

What's Next?

The work on Bazel attestation support in the BCR is ongoing and as this capability matures, we can expect to see:

  • Broader support for different attestations types and sources which is currently limited as we work out any issues with the build and publishing flows.
  • Increased adoption leading to strong policy decisions as more of a developers dependency tree is accompanied by attestations.
  • Further improvements to the tools for generating and verifying attestations making it easier for maintainers and users to benefit from this feature.
  • Deeper integration into Bazel to allow first class support for attestations.

We encourage module maintainers to explore integrating attestation generation into their release workflows and for Bazel users to start leveraging the available tools to verify the attestations of their dependencies. This collaborative effort is key to building a more resilient and trustworthy software supply chain with Bazel.

Acknowledgements

The Aspect Build team (@kormide, @alexeagle) for their work on improving release processes for Bazel developers and specifically on the reusable actions for producing the secure SLSA attestations with these reusable workflows.

The extended BCR team (@meteorcloudy, @adincebic) for their work validating and mirroring attestations on BCR making them easily available for consumption.

The SLSA team (@ramonpetgrave64) for their work ensuring we were producing our SLSA attestations that allowed higher level audits on build processes.