Build & release environment governance

A build and release environment governs what an organization is willing to ship into the world. Under Ring 6 doctrine, governance is not a review meeting; it is the configuration of the pipeline itself. If a sensitive artifact reaches a public registry, a Ring 6 practitioner treats that as a defect in the environment, not an operator mistake.

The structural release contract

• ▸All build steps run on pinned base images identified by sha256 digest, never by :latest.
• ▸Every build artifact is scanned for sensitive content (API keys, customer data, private keys) before leaving the builder.
• ▸Public release registries are physically separated from private registries; the build can only reach the public path after an explicit promotion step.
• ▸The promotion step is gated on a signed manifest of what is in the artifact.
• ▸Build logs are retained with tamper-evident hashing and a minimum 7-year retention window.
• ▸Secrets are injected at runtime via broker, never baked into the image.

# Example Cloud Build configuration enforcing sha-pinned images and a promotion gate
steps:
  - name: gcr.io/cloud-builders/docker@sha256:8dc210...
    args: [build, --tag, us-central1-docker.pkg.dev/${PROJECT}/ifo4/app:${SHORT_SHA}, .]
  - name: us-central1-docker.pkg.dev/${PROJECT}/ifo4/scanner@sha256:77a3...
    args: [scan, us-central1-docker.pkg.dev/${PROJECT}/ifo4/app:${SHORT_SHA}, --fail-on=critical]
  - name: us-central1-docker.pkg.dev/${PROJECT}/ifo4/promoter@sha256:1e52...
    args: [promote, --from-registry=ifo4, --to-registry=ifo4-public, --require-signed-manifest]

The pipeline above cannot leak a credential because the scanner is itself a build step and failure on critical findings aborts the build. It cannot ship an unsigned artifact to the public registry because the promoter will refuse to operate without a signed manifest. Ring 6 has turned a policy into a property of the environment.

Confirm your comprehension.