Container Registry and Software Supply Chain Platform  ·  View 15 of 33  ·  4 · Runtime

Build to Attested Push

How an image acquires provenance, an SBOM, a signature and an inclusion proof before anyone can deploy it.

Editable source SVG draw.io All views
GitLab Tekton Pipeline SPIRE Fulcio Harbor Rekor Attestation Service 1. push event · rev abc123f 2. node + workload attest 3. JWT-SVID · 5 min 4. build from pinned base 5. push image 6. sha256:9f3c… 7. syft → CycloneDX SBOM 8. SVID → signing cert 9. cert · 10 min validity 10. log DSSE entries 11. inclusion proof 12. push referrers 13. artifact event 14. verify subject and signer 15. reject: human credential Build to Attested Push — Critical Flow Provenance signed by a developer's personal credential is refused at receipt, not at admission. v 1.0 · owner Platform Engineering · date 2026-09

Decisions

  • The builder authenticates with a SPIFFE workload identity; a provenance document signed by a personal credential is rejected
  • Provenance, SBOM, scan result, test result and promotion all use one DSSE envelope format and one verification path
  • The source revision named in provenance is checked to exist in a repository on the allowed-source list

Answering question 3

  • Keyless short-lived certificates from Fulcio for the normal path — no key custody, revocation is an identity operation
  • Long-lived HSM-held keys for the air-gapped and base-image release paths, where the log and IdP are not reachable
  • Both verify against TUF trust roots, so verification never calls the signing service

Risks

  • Fulcio and Rekor are on the critical path of a build, though not of a deployment; an outage queues signing rather than stopping builds
  • Artifacts signed while Rekor is down are admissible only in non-production until their proofs land
◀  Multi-Region Topology All views Scan Pipeline  ▶
Solution Architecture v1.0 · Data & AI Global Practice · 2026-09 · 33 views · open-source, on-premises15-build-and-attest-sequence