Signed releases / SLSA provenance
Demonstrate that all production software releases are cryptographically signed, accompanied by verifiable SLSA provenance attestations, and that deployment processes enforce signature and provenance verification before execution.
Description
What this control does
This control ensures that software artifacts (binaries, containers, packages) are cryptographically signed by authorized build systems and accompanied by Supply-chain Levels for Software Artifacts (SLSA) provenance metadata. SLSA provenance provides tamper-evident attestations documenting the origin, build environment, dependencies, and build steps used to produce each artifact. By verifying signatures and provenance before deployment, organizations prevent the execution of tampered, backdoored, or counterfeit software components. This control is critical for supply chain security, particularly in preventing build system compromise, dependency confusion attacks, and malicious code injection.
Control objective
What auditing this proves
Demonstrate that all production software releases are cryptographically signed, accompanied by verifiable SLSA provenance attestations, and that deployment processes enforce signature and provenance verification before execution.
Associated risks
Risks this control addresses
- Execution of unsigned or tampered binaries due to compromised build pipelines or man-in-the-middle attacks during artifact distribution
- Deployment of counterfeit packages created by threat actors impersonating legitimate publishers or maintainers
- Injection of malicious code into artifacts through compromised build environments or stolen credentials without detection
- Dependency confusion attacks where internal package names are hijacked by public repositories lacking provenance validation
- Inability to trace the origin or build process of deployed artifacts during incident response or supply chain investigations
- Loss of non-repudiation for software releases, preventing accountability when vulnerabilities or backdoors are discovered
- Bypass of code review and testing requirements through direct artifact substitution in deployment pipelines
Testing procedure
How an auditor verifies this control
- Obtain the organization's software release policy and identify all systems, repositories, and registries used to store production artifacts (container registries, artifact repositories, package managers).
- Select a representative sample of recent production releases across different artifact types (containers, binaries, packages, libraries) and retrieve their metadata from build systems and registries.
- For each sampled artifact, verify the presence of cryptographic signatures by inspecting artifact metadata, registry tags, and signature files using appropriate verification tools (cosign, gpg, sigstore clients).
- Retrieve SLSA provenance attestations for each sampled artifact and validate the attestation structure conforms to SLSA provenance schema specifications (builder identity, build invocation parameters, materials, steps).
- Verify cryptographic signatures on provenance attestations themselves to confirm they were issued by trusted build infrastructure and have not been tampered with post-generation.
- Review CI/CD pipeline configurations and deployment automation scripts to confirm signature and provenance verification gates are enforced before artifact promotion or deployment to production environments.
- Interview build engineers and review access controls to confirm that signing keys are stored in hardware security modules or secure key management systems with restricted access and audit logging.
- Examine audit logs from artifact registries and deployment systems for a recent deployment to confirm signature verification occurred and no unsigned artifacts were deployed to production.
Where this control is tested