We are excited to announce the release of a powerful tool designed to help companies achieve SLSA (Supply Chain Levels for Software Artifacts) compliance in Azure Pipelines CI/CD systems. With Cimon, organizations can easily generate the required provenance documents necessary for SLSA compliance, ensuring the integrity and authenticity of their software artifacts.
The Importance of Software Provenance
To establish trust and enhance the security of software artifacts, organizations are increasingly adopting SLSA (Supply Chain Levels for Software Artifacts) compliance. One crucial aspect of SLSA compliance is the generation and management of provenance. Below, we will explore the significance of SLSA compliance, the importance of provenance, and how you can achieve SLSA compliance in Azure Pipelines using Cimon.
Provenance refers to the historical record and origin of a software artifact, providing transparency and auditable traceability. It allows stakeholders to verify the source, modifications, and interactions of software components, ensuring trust in the software supply chain. These documents also include metadata and cryptographic signatures, ensuring the authenticity and integrity of the document.
Furthermore, the recommendation for provenance generation goes beyond the SLSA standard. Under Executive Order 14028, the National Institute of Standards and Technology (NIST) has developed a set of best practices and security requirements called the Secure Software Development Framework (or SSDF/NIST SP 800-218). SSDF includes several requirements for generating and maintaining provenance documents. For example:
PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release
According to NIST, provenance has been defined as:
The chronology of the origin, development, ownership, location, and changes to a system or system component and associated data. It may also include personnel and processes used to interact with or make modifications to the system, component, or associated data
Eventually, organizations willing to comply with the SSDF will implement tools to generate provenance documents.
In the context of SLSA, we adhere to the latest v1.0 standard, which you can learn more about it here.
The Importance of SLSA Compliance
SLSA compliance is essential for ensuring robust supply chain security in software development. It is based on distinct tracks and the focus in the latest v1.0 standard is on the build track security:
Build L0: This level doesn’t have specific requirements.
Build L1: At this level, the focus is on generating provenance, which refers to tracing and documenting the origins and history of the package. The goal is to provide clear visibility into how the package was built, helping to identify and rectify mistakes and improve documentation.
Build L2: Building on the requirements of L1, L2 introduces the use of signed provenance generated by a hosted build platform. This level enhances security by ensuring that the package’s integrity is maintained even after the build process. It guards against tampering or unauthorized changes to the package.
Build L3: The highest level of SLSA compliance in the build track involves a hardened build platform. In addition to signed provenance, this level provides enhanced security against tampering during the build process. Utilizing a hardened platform minimizes the risk of compromise and strengthens the overall security posture.
Even the basic SLSA level (level 1) guidelines emphasize capturing and maintaining provenance information. Cimon aligns with the SLSA specification and enables organizations to meet these compliance requirements effectively.
Why Azure Pipelines
Azure Pipelines is a popular CI/CD system used by many organizations for their software development and deployment processes. One of its essential features is the availability of hosted runners, which are virtual machines managed by Azure Pipelines that come pre-installed with popular development tools and software. While Azure Pipelines offers robust features for building and deploying software, it lacks built-in tooling for SLSA compliance and provenance generation. This gap creates a need for a dedicated solution like Cimon to help organizations achieve SLSA compliance within their Azure Pipelines workflows.
Gettings Started with Cimon in Azure Pipelines
To get started with SLSA generation in Azure Pipelines, you can use the Cimon extension that is available in the Visual Studio Marketplace. Follow these steps to install the extension:
- Sign in to your Azure DevOps organization.
- Navigate to the Cimon extension on Visual Studio Marketplace here.
- Click the “Get it free” button to start the installation process.
- Select the organization where you want to install the extension and click Install.
- Wait for the installation to complete. Once installed, you will see a success message.
- Edit your Azure Pipelines workflow and add the
CimonAttest@0task after creating the desired artifacts. Use the following workflow snippet as an example:
steps: - task: CimonAttest@0 inputs: subjects: | dist/artifact1 dist/artifact2 signKey: $(signKey)
Detailed installation instructions and examples of usage can be found in the Cimon documentation.
Cimon as the Go-To CI/CD Security Tool
Recently, we released Cimon, the ultimate CI/CD runtime security tool that is able to detect and stop software supply-chain attacks, including those targeting SolarWinds and CodeCov, through easy onboarding and a developer-friendly experience. Our knowledge and expertise in the fields of securing the integrity of CI/CD led us to expand Cimon’s capabilities with attesting software artifacts.
Hardening the build and generating attestation go hand in hand and are core capabilities for organizations that want to build secure products.
If you want to dive deeper into the attestation capabilities or help your organization to achieve SLSA compliance in your Azure Pipelines CI/CD system, take Cimon for a spin today!