Supply Chain Security

Use this page to understand how OpenBao Operator proves that published artifacts are attributable and reproducible.

OpenBao Operator follows a build-once, verify, then promote model. The goal is not only to build release assets, but to prove where they came from, how they were produced, and whether an independent rebuild arrives at the same bytes before anything is published.

Diagram

Build once, verify, then promote

Promotion is gated by trust evidence, not by rebuilding the same subject a second time during publish.

Decision matrix

Channel coverage

Channel coverage.

Channel	Primary workflow path	Blocking trust gates	Published output
CI	.github/workflows/ci.yml	Validation only. No publish path.	PR and branch confidence, but no public artifacts.
Edge	.github/workflows/publish-edge.yml plus reusable hardening	Provenance verification and byte reproducibility before publish.	GitHub Pages edge manifests, checksums, and provenance index.
Nightly	.github/workflows/publish-nightly.yml plus reusable hardening	Provenance verification and byte reproducibility before publish.	GitHub Pages nightly manifests, checksums, and provenance index.
Stable release	.github/workflows/release.yml	Provenance, reproducibility, signing, and release evidence gates.	GitHub Release assets, OCI images, chart artifacts, versioned docs, and machine-readable provenance metadata.
Prerelease	.github/workflows/release.yml	Provenance, reproducibility, signing, and release evidence gates.	GitHub Release assets, OCI images, chart artifacts, release notes, and docs deployment through /docs/next.

Decision matrix

Control families

Control families.

Control family	What it protects	Primary implementation surface
Governance	Branch, tag, and change-management expectations for release-critical paths.	Repository rulesets, signed semver tags, CODEOWNERS, PR checks, and pinned GitHub Actions usage.
Build inputs	Deterministic dependency resolution and low-drift toolchains.	Vendored Go modules, pinned base-image digests, pinned tool versions, and workflow-defined build parameters.
Provenance and signing	Evidence that published subjects came from the expected workflow and identity.	actions/attest-build-provenance, cosign, gh attestation, and the release verification scripts.
Reproducibility	Confidence that an independent rebuild matches expected bytes before publication.	hack/ci/verify-byte-reproducibility.sh, deterministic SPDX normalization, and release/channel hardening gates.
Release evidence	Retained proof that a release met the hardening contract at publish time.	Workflow run metadata, verification output, artifact listings, and provenance indexes.

Inspect

Inspect hardening entry points

bash

rg -n "verify-image-attestations|verify-byte-reproducibility|provenance-index" \
.github/workflows hack/ci

sed -n '1,220p' .github/workflows/release.yml
sed -n '1,220p' .github/workflows/reusable-channel-hardening.yml

Use this when you need to trace where a trust gate is implemented before changing the workflow or the scripts that back it.

Single-maintainer operating constraint

Human two-person approval controls are still limited by the current single-maintainer operating model. The project compensates with stronger automation, pinned workflow identity checks, and explicit release evidence requirements, but this does not create true multi-person release separation on its own.

Decision matrix

Common failure classes

Common failure classes.

Failure	Likely cause	Where to look first
Attestation verification fails	Workflow identity, signer identity, or source ref does not match the expected constraint.	Release workflow inputs and hack/ci/verify-image-attestations.sh.
Byte reproducibility fails	A build input or emitted artifact changed nondeterministically between rebuilds.	hack/ci/verify-byte-reproducibility.sh, normalized SPDX output, and build metadata sources.
Checksums or chart subject verification fails	A signed or attested subject was regenerated after evidence was captured.	hack/ci/verify-release-artifact-attestations.sh and the release job ordering.

Turn policy into release work

Release managementUse the concrete release procedure when you need the exact sequence of verification, publish, and post-release steps.Continuous integrationReview how these controls appear earlier in the branch and PR lifecycle before a release exists.Dependency license policyOpen the policy that governs which shipped dependencies are allowed into the release graph at all.Incident responseUse the supply-chain incident runbook when you need to freeze publishing, rotate credentials, or inspect recent releases.