Enforce artifact integrity validation in deployment gates
Implementation Effort: High – Enforcing signature and provenance checks at every deployment boundary is a sustained program spanning GitHub Actions, Azure signing tooling, and admission controllers, with ongoing tuning as capabilities reach general availability. User Impact: Low – Verification runs inside deployment pipelines and is managed by platform and security teams; end users are not prompted or affected. Lifecycle Stage: Deploy
Overview
Enforce artifact signature and provenance validation in deployment gates before software can move into target environments. Verification at the deployment boundary ensures only approved, untampered artifacts can be released.
Signing build artifacts and generating provenance attestations only provides value if something downstream actually checks them. Without enforcement at the deployment boundary, signed and unsigned artifacts flow into production through the same path, and a threat actor who compromises an artifact registry or build cache can still push a tampered image or package into a live environment.
This task implements SLSA artifact verification requirements and aligns with NIST SSDF PS.2.1 (provide a mechanism for verifying software release integrity) and PS.3.1 (securely archive the necessary files and supporting data, including integrity verification information and provenance data, for each release).
Artifact integrity validation gates are deployment-time checks that inspect every artifact for a valid cryptographic signature and provenance attestation before allowing it to proceed. In GitHub Actions, add verification steps that use GitHub artifact attestation verification tooling to confirm the artifact's provenance maps to an approved repository and workflow. For Azure deployment targets, use signature verification controls such as Notation and, where appropriate, Azure Kubernetes Service Image Integrity; as of this writing, AKS Image Integrity is in preview and supports only the audit policy effect, which means it is non-blocking, so do not rely on it for production enforcement gates. Current Microsoft documentation also requires the Azure Policy add-on, an AKS cluster running Kubernetes 1.26 or later, OIDC issuer enabled, and the EnableImageIntegrityPreview feature flag. Where deny enforcement is required, use production-supported admission controller patterns — for example Ratify (the CNCF project that AKS Image Integrity is built on) deployed as a Gatekeeper external data provider, or Kyverno with Notation image verification — or equivalent signature-validation controls, and treat AKS Image Integrity itself only as an Azure-managed audit signal until Microsoft documents general availability and deny enforcement support. In Azure DevOps, use pre-deployment gates or external validation endpoints to verify signature and provenance evidence before a release proceeds.
When deployment gates enforce artifact integrity, the deployment pipeline itself becomes a trust boundary between verified and unverified software by blocking artifacts that cannot prove their origin and integrity. By requiring every artifact to prove its origin and integrity before it can be deployed, this task supports Verify explicitly and Assume breach.