6.7 Build Supply Chain and Releases

Use this when operating registries, mirrors, repository caches, remote downloaders, or vendoring as a shared Bazel dependency-intake service.

Use this when a fresh build must resolve every module, archive, generated repository, toolchain, and required image without public network access.

Keep committed dependency declarations, lockfiles, ruleset-generated files, patches, toolchains, validation, and rollback coherent through one Bazel-aware update.

Define when complete build evidence and immutable outputs form a technically eligible release candidate, before approval, signing, or publication.

Use this when deciding which identities may build, write cache entries, sign, or publish and where their credentials can leak.

Use this when binding an artifact to source, materials, invocation, configuration, and builder without claiming more than the evidence proves.

Design and test an artifact-scoped component inventory by joining configured-graph metadata with packaging or inspection evidence and making incomplete or unknown coverage explicit.

Bind an accepted signer to an immutable artifact digest, keep credentials outside Bazel actions, and make verification, replay defense, and compromise recovery explicit.

Choose a Bazel policy-check boundary by the evidence it can observe, when it must block, and the trusted invocation that prevents the gate from being silently omitted.

Publish an authenticated, eligible immutable subject replay-safely by reconciling stable intent with destination state.