With recent software supply chain attacks on the rise, CISOs being held personally liable, and the United States government requiring minimum security software standards for any products and services they procure, the development industry is refocusing on software development strategies that make security a priority. But with so many reputable sources creating guidance, which is the best? This blog helps weigh the important components of both SLSA and CIS guidelines to help you develop the best secure development strategy.
First … What is Software Supply Chain Security?
Developing software begins with the codebase which is built through a series of stages that comprise the Software Development Lifecycle. Each stage in the process represents a different set of interactions and software artifacts which are a potential entry point for vulnerabilities to be introduced or attacks to occur. If a compromise is successful at any point in the software development lifecycle and software is released to end users, those clients become affected as well. These attacks, known as supply chain attacks, are methodically carried out. They are increasing because of the wide range of entry point opportunities and high impact they have when successfully executed. Meanwhile, DevOps teams are facing a tough battle to prevent these attacks because security is often not holistically incorporated. Adding to the challenge is the broad adoption of open source. Attackers have recognized these deeper levels of dependencies are even harder for teams to maintain security over and have begun to leverage them as a main pathway to mount attacks. Some recently observed ingenuous attacks were carried out by:
- Injecting malware into commonly used libraries, such as npm
- Automating the exploitation of open-source vulnerabilities, such as Log4J
- Exploiting weak access controls to tamper with code
- Tricking developers into downloading malicious code through practices such as typosquatting
To prevent software supply chain attacks, organizations are being held accountable for incorporating security best practices throughout their process and development pipeline. During the various stages in the development process, developers import packages from third-party code, proprietary code, and open-source code, building packages that interact with CI/CD tools and then release it to end users. This requires developers to consider security strategy from both a producer and end user standpoint as they leverage dependencies within their process or code. Delivering proof of this security comes in the form of a validated Software Bill of Materials (SBOMs). Prime examples are the requirements delineated in US Executive Order 14028 as well as EU’s Cyber Resilience Act regarding software supply chain regulations.
How SLSA and CIS Software Supply Chain Security Help
SLSA (Supply chain Levels for Software Artifacts) and CIS Software Supply Chain Security both focus on improving trust between end users and producers by weaving security throughout the entire modern software development process to reduce vulnerabilities, protect the process, and produce inherently secure software. They both recommend the same key points like scanning your code for secrets, tool and cloud account misconfigurations, vulnerabilities, and infrastructure as code security issues. However, each guidance dives deeper into different aspects to provide valuable security insight.
SLSA as a framework is a base structure from which recommendations can be met with support from the open-source community such as CNCF and OpenSSF.
CIS Software Supply Chain Security is a detailed guide focusing on the enterprise development cycle and considers new industry standards like SBOM and other secure development best practices.
Let’s expand on the main components and compare the key features of each approach.
SLSA
Supply-chain Levels for Software Artifacts, also known as SLSA, is a security framework for achieving software supply chain integrity. Originally used internally by Google, it evolved into a cross-industry collaboration, and was later maintained as part of the Open-Source Security Foundation (OpenSSF) to help the industry and open-source ecosystem secure the software development lifecycle.
The path for applying the framework is represented by levels of graduated maturity. Higher levels indicate a better application of security practices. The controls are focused on the source, build, provenance, and commons. SLSA Levels are designed to protect against tampering or unauthorized modification during the package build process in the software lifecycle.
SLSA Tooling
The SLSA framework develops a set of tools to achieve robust SLSA levels in your software lifecycle process. You can find more details about these tools such as the slsa-github-generator, which supports both GitHub-hosted runners and self-hosted runners.
Together with other community initiatives from Gitlab, Jenkins, Tekton, and others, they implement the SLSA levels and create the provenance, a.k.a. the attestation of what was built and where, in the builder.
In any given pipeline, artifacts such as containers, libraries, and more are built. The SLSA provenance is a manifest based on in-toto which records the build process.
The SLSA provenance is a predicate type. Details regarding this specification provenance can be viewed at the SLSA Provenance page. This artifact describes how a “builder” tracks the package build process with all the dependencies and details of the build environment. The “builder” is trusted to create the provenance containing all the build process details.
The slsa-github-generator will create the provenance from the build process with support for artifacts such as containers, go, bazel, java, rust, and Haskell. In the next phase, the slsa-verifier then corroborates the provenance.
CIS Software Supply Chain
The Center for Internet Security (CIS) has developed a CIS Benchmark for Software Supply Chain Security and includes generic guidelines divided into five main areas including Source Code, Build Pipelines, Dependencies, Artifacts, and Deployment.
Below, we highlight important features in each category:
1. Source Code
Code changes must be validated with at least two strongly authenticated users. Inactive branches and branch protection rules are checked which ensures verification of signed commits for new changes and that linear history requirements are met.
Source code management (SCM) will validate controls for private and public repositories controls like the SECURITY.md file. This confirms that rules are met regarding authorization and authentication in the SCM including user creation and deletion as well as admin users and inactive users. It also ensures Multi-factor authentication (MFA) within the organization, that email notifications are restricted to verified domains, that the organization provides SSH certificates while limiting Git access on IP addresses, and that anomalous code behavior is tracked.
The guide also requires that third-party source code is approved and limited to the least privilege needed, and that scanners are used to identify sensitive data, infra as code misconfigurations, and code vulnerabilities (SCA) in your source code.
2. Build Pipeline Integrity
You must take steps to ensure that the build environment is immutable, including the pipeline infrastructure, configuration, and access to this environment. The build worker should be single-used, isolated, or with minimal network connectivity and automatically scanned for vulnerabilities and enforced runtime security.
Pipeline instructions should be defined as code and the changes in the pipeline need to be tracked and reviewed. Pipeline instructions scan for sensitive data, misconfigurations, and vulnerabilities.
For pipeline integrity, on the release all artifacts should be signed, and external dependencies locked to produce a signed SBOM and ensure that the build pipeline has created a reproducible artifact.
3. Dependency Integrity
To maintain dependency integrity, you must validate the respective SBOM from all third-party suppliers. To ensure trusted package managers and repositories for open-source components, the dependencies should be pinned and no older that 60 days. Also, you need to enforce policies to validate packages for vulnerabilities, license implications, and ownership changes.
4. Artifact Integrity
Artifact verification ensures that they are signed by the build pipeline itself, encrypted, and follow the best security for distribution. Access to artifacts is limited and, using MFA, ensures best practices for management and access to the package registry (gitlab, github, cloud-based registry, jFrog, etc), validating webhook integration.
5. Deployment Integrity
Deployment configuration files are separated from the source code. The changes are tracked, and the artifact is scanned for sensitive data including misconfigurations in the infra as code. Deployment environments are automated, reproducible, and access is limited.
CIS Supply Chain Tooling: Chain-bench
Chain-bench follows the CIS Guide to audit controls related to SCM, source-code, dependencies, pipelines, and artifacts.
It has also added support for the SLSA framework.
Chain-bench: chain-bench scan -r https://github.com/my-org/my-repository –access-token xxx_my_gh_access_token
SLSA and CIS Supply Chain
The table below shows an overview of key features of SLSA and CIS Supply Chain Guide.
| SLSA | CIS Supply Chain Guide | |
| Origin | Initially created by Google, right now cross-industry collaboration, maintained as part of the OpenSSF https://openssf.org/ | The Center for Internet Security |
| Target audience | Developers and Open-source community | Enterprise Organizations |
| Categories | 1. Source 2. Build 3. Provenance 4. Commons |
1. Source Code 2. Build Pipelines 3. Dependencies 4. Artifacts 5. Deployment |
| SBOM | Not mentioned as SBOM, included as Part the Provenance at the level 4 as “Dependencies complete” | Pipeline integrity section, validate SBOM generation with tools like billy trivy, syft, spdx, cyclonedx, jake, etc. |
| Builder metadata integrity | SLSA Provenance: Details about artifact build process | Build integrity section |
| Attestations | SLSA Level-3: a public facing “transparency log” would be available for client organizations to review the responses by either self-attestations or third-party audit | ** |
| Pipeline as Code | None | Pipeline integrity section |
| Static Scanners | None | SAST, secret scanning, Fuzzing |
| CI-Tests | None | Yes |
| License | None | Dependencies section |
| Vulnerabilities | Not mentioned | Dependencies section |
| Dependencies and third parties | Not mentioned | Dependencies section Best practices like check pinned dependencies |
| Package Registry | None | Part of the section |
| Release integrity | Provenance signed Attestation |
Signing artifact |
| Tooling | SLSA Level 3 + provenance for Github Action | Chain-bench tool based on the CIS Software Supply Chain benchmark |
| Track anomalous code behavior in the builder | None | Considered |
| Controls | Around 35 | +100 |
Aqua Supply Chain Security
Aqua participated in the development of the CIS Supply Chain Security Guide and used that experience and expertise to develop the Aqua Supply Chain Module. The open-source Chain Bench project helps you validate certain aspects of the CIS and SLSA controls. With Aqua Enterprise, you can integrate your SCM, CI/CD, and artifact repository management to apply and analyze best practices across all phases of building the artifact including Code, Build, Deploy, and Release.
The SBOM manifest contains a list of dependencies related to the artifact (container, library, package, etc.). However, you need one more step to find the vulnerabilities of these dependencies. Trivy helps with this step, and Aqua prioritizes the risks from source code to runtime, the vulnerability management, policies, and runtime protection, helping you manage risks in your workloads. Integration with your SCM and CI/CD allows you to track and validate the integrity of the build process as well as pipeline integration, a key component inside supply chain security.
Advanced supply chain controls such as detecting anomalous code behavior in your build tool (CI/CD) can be achieved using runtime security tools that are integrated into the artifact build process. Supply chain best practices recommend a shift-left approach in the pipeline to scan for misconfigurations in infrastructure as code, find vulnerabilities in code, and scan for sensitive data and licenses. Many of these controls can be accomplished with Trivy. For more details, check out our blog Trivy: The Universal Scanner to Secure Your Cloud Migration.
Aqua helps you address new security supply chain challenges, developing a next generation SBOM, pipeline security, vulnerability management, and more. For more information, read about Aqua’s approach to Full Lifecycle Software Supply Chain Security.