This series of articles aims to identify the best practices to implement in order to secure your delivery process and your CI/CD pipelines:
0. DevSecOps & CI/CD Pipelines: understand the fundamentals.
1. Version Control System Security
2. Secure Continuous Integration (CI) Pipelines
3. Secure Continuous Delivery (CD) Pipelines
4. Securely Managing Secrets in CI/CD Pipelines
5. Securely Managing Artifacts in CI/CD Pipelines
“Artifacts” are the byproducts generated via your Continuous Integration (CI) pipelines during the build process. These artifacts are compiled code (binaries) or packaged in the shape of a container image that is ready to be deployed to a server.
Given the recent surge in attacks exploiting supply chain vulnerabilities (SolarWinds or Codecov), securing artifacts is now more important than ever. Building upon the insights from our previous discussions on “Secure Continuous Integration (CI) Pipelines” and “Secure Continuous Delivery (CD) Pipelines,” this article focuses on a central aspect of the secure management of software artifacts.
The security challenge we face with the artifact is to achieve perfect traceability. For each artifact, we would like to issue a certificate that verifies the source and origin of each of its components and transformations.
In this article, you will learn about the SLSA (“Supply-chain Levels for Software Artifacts”), a security framework designed to provide guidelines around the integrity and security of software artifacts. Then, we will look at the key points to harden the security of your artifacts.
SLSA— Supply-chain Levels for Software Artifacts
The SLSA framework is structured around three progressive levels, each designed to provide a higher degree of security assurance.
SLSA Level 1: Focuses on basic documentation and automation to ensure the build process is consistent and secure. At this level, the requirements include automated builds that produce a list of provenance, such as a “Software Bill of Materials” (SBOM).
SLSA Level 2: This level introduces the notion of signed artifacts. This ensures that the artifact cannot be tampered with after the build process.
SLSA Level 3: This level introduces the notion of a “hardened build platform.” The goal of such a platform is to ensure that an artifact was built from the official source and using the official build process. Builds are fully reproducible and traceable.
SLSA aims to become a global standard that all build processes should adhere to. Ideally, each dependency you use should have a certified SLSA level. This certification reflects the level of trust you can place in their software component. Obviously, you should aim to achieve the highest SLSA level for your software components. We could imagine in the future only accessing third-party software with SLSA 3.
Hardening Artifact Security
Let’s take a more detailed look at what is required to secure our artifacts. We will look at four key points to each contribute to achieving SLSA levels from 1 to 3.
Dependencies
Tracking dependencies and publishing a report are the main requirement to achieve SLSA level 1. The list of dependencies called the Software Bill of Materials (SBOM), provides more transparency. This practice enables better risk management and helps prevent potential vulnerabilities arising from compromised dependencies because when new vulnerabilities are discovered, you can quickly identify impacted software without scanning.
Stamping Artifacts and Validating Stamps
To achieve SLSA level 2, the main requirement is to implement a stamp in the form of a digital signature. This signature is generated using a private key that is accessible only to the build platform component responsible for generating the provenance attestation. By using the corresponding public key, the deployment target (server, Kubernetes, etc.) can ensure that the artifact hasn’t been tampered with after the build process. This digital signature provides a strong and tamper-proof validation, giving users confidence in the artifact’s integrity and protecting against some supply chain attacks.
Source Code
The first requirement for achieving SLSA level 3 is to be able to validate that an artifact “was built from the official source” and “using the official build process.” Source code, pipeline scripts, and pipeline manifests are all stored in the code repository (GitHub, GitLab, etc.). The build process must validate and add those references to the provenance attestation. In addition, we can require all commits to be signed by developers to certify their origin.
Hardened Build Platform
The second requirement for achieving SLSA level 3 is the “certification” of your build platform. The build workflow must be able to prove its identity.
This is where things start to be more technical. To accomplish build platform certification, your build platform needs a security control plane (such as Sigstore) that provides an ephemeral signing key generated for a runner using workload identity. Workload identity is a concept that refers to the assignment of a unique, verifiable identity to applications or workloads by a cloud provider.
The metadata of the build platform is then added to the certificate of provenance and can be validated against our build security control plane.
Conclusion
We discuss the importance of securely managing artifacts in our software supply chain. There are various angles of attack that we need to protect ourselves against, and to do so, we want to be able to verify a tamper-proof certificate of provenance for each artifact.
We introduce the SLSA framework for ensuring the integrity and security of software artifacts, which consists of three progressive levels of security. We delve into the process of hardening artifact security based on SLSA recommendations, which include tracking dependencies, implementing digital signatures, validating source code, and certifying the build platform.
In our next and final article, we will conclude this series by focusing on observability, setting up automated alerts, and prioritizing critical threats.
Don’t miss this opportunity to deepen your knowledge in DevSecOps. Stay up to date, improve your skills, and secure your CI/CD pipelines with our practical guides. Contact us for a personalized consultation.
By Gologic, in collaboration with Alexandre Couëdelo
