Implement artifact signing and build provenance
Implementation Effort: High – Standing up signing and provenance for every release, wiring in verification gates, and maintaining keys and tooling is a sustained program.
User Impact: Low – Signing and provenance run inside the build and deployment pipeline; end users are not affected.
Lifecycle Stage: Build
Overview
Sign build artifacts and generate build provenance for every release so downstream systems can verify artifact integrity, source, and build context before deployment. Without cryptographic signing and provenance records, any system or person with write access to the artifact registry can replace a legitimate artifact with a malicious one.
Artifact signing attaches a cryptographic signature to each build output so consumers can verify integrity and signer identity. Build provenance generates a structured attestation recording which source commit triggered the build, which pipeline performed it, what inputs were consumed, and what environment was used.
GitHub artifact attestations provide native provenance generation for GitHub Actions workflows. Attestations are generally available for public repositories. For private or internal repositories on GitHub Enterprise Cloud, attestations use GitHub's Sigstore instance. Verify your organization's plan and licensing before implementing attestations as a required control.
GitHub artifact attestations generated on GitHub-hosted runners align with SLSA Build Level 2 because the provenance is generated by the GitHub Actions platform itself, not by user-controlled workflow steps. Self-hosted runners do not meet the SLSA Build Level 2 isolation requirement because the runner environment is under organization control rather than GitHub's provenance service control. Organizations that use self-hosted runners for sensitive builds should add controls such as ephemeral runners, hardened runner images, and external provenance generation to approach Level 2 assurance, but will not achieve the same default provenance guarantees that GitHub-hosted runners provide. For SLSA Build Level 3 and above, additional controls are required including hermetic build isolation and non-falsifiable provenance.
For container images and other OCI artifacts, use tools such as Cosign to sign artifacts and attach provenance metadata in the registry. These tools are relevant when the release process extends beyond GitHub-native attestations or when a common signing pattern is needed across multiple platforms.
In Azure DevOps, there is no native equivalent to GitHub artifact attestations. Implement signing and provenance generation explicitly in the pipeline using approved tooling and enforce verification before deployment.
Deployment pipelines should reject artifacts that lack a valid signature or a provenance attestation tied to an approved source repository and build workflow. Microsoft Signing Transparency (public preview) extends this model by recording every digital signature in an immutable, append-only transparency ledger backed by confidential computing — providing independent, auditable proof that a signed artifact exists and has not been tampered with, even in scenarios where a signing key is compromised. Organizations should evaluate Signing Transparency as an additional trust signal alongside SLSA provenance and container image signing.
This task also aligns with Microsoft's Secure Supply Chain Consumption Framework (S2C2F) Audit practice, which requires organizations to verify the provenance and integrity of consumed software artifacts. By generating SLSA provenance attestations and signing build outputs, organizations implement the verification mechanisms that S2C2F's maturity model demands at higher levels. Requiring a valid signature and provenance attestation before deployment is a direct application of Verify explicitly, ensuring each artifact's integrity and origin are proven rather than assumed.