Enhance Your SBOM Success with SLSA

As a DevSecOps engineer, you are aware that software supply chain attacks are rapidly on the rise. Both business and security leaders have taken notice and are becoming increasingly concerned because the damage from this emerging attack vector can be devastating.

Cloud application development teams are under intense pressure to address the problem. Many are briskly shifting left in their security strategy by embedding security controls early into the application development lifecycle. For securing the supply chain at scale, they are adopting the best practice of verifying the software bill of materials, or SBOMs, to constantly evaluate oncoming risks.

However, the industry is realizing that SBOMs alone are not enough for software supply chain security because they don’t help users respond to the tampering of software artifacts. Consider these noteworthy examples:

1. The Gentoo Linux GitHub Repo attack (2018): The incident involved modifying GitHub repositories containing the open source Gentoo code, MUSL development overlay and Systemd to erase all files from the system.
2. The SolarWinds attack (2019-2020): The attack was orchestrated by breaking into the build pipeline and injecting a malware backdoor, known as SUNBURST, into the Orion update tool even though the software was signed. It then used that to proliferate Trojanized updates to SolarWinds’s customer systems.
3. The Copay attack (2020): Attackers injected malicious code into the Node.js JavaScript software package affecting Copay, a cryptocurrency wallet developed using JavaScript. The injection of malicious code in Copay’s software resulted in the theft of cryptocurrency from Copay wallets.
4. The CodeCov attack (2021): Hackers gained unauthorized access to CodeCov’s Bash Uploader script and altered it to eventually exfiltrate customer data containing keys, tokens, and credentials from CI (continuous integration) environments.
5. The PyPi Library attack (2022): Hackers infected the W4SP stealer malware into open source software (OSS) packages from the Python Package Index (PyPi), the official third-party software repository for Python, to pilfer sensitive data, browser cookies, tokens, and system metadata.

As you can see, software supply chain attacks are becoming so widespread that they are indeed a wake-up call for developers and security teams. To protect software artifacts from unauthorized modifications within the software supply chain, a new security framework — aptly called Supply Chain Levels for Software Artifacts, or SLSA (salsa) — has emerged.

The SLSA Security Framework

SLSA is an adoptable security guidance framework that serves as a checklist of standards and controls for safeguarding the integrity of open source software artifacts across the entire supply chain.

SLSA is an OpenSSF (Open Source Security Foundation) project established by industry consensus and based on code review concepts used internally at Google for all its software production.

The software supply chain, from development to deployment, is quite complex and riddled with numerous security vulnerabilities along the entire workflow. Before Google unveiled SLSA in 2021, only point products existed to detect and block specific vulnerabilities at any link in the software supply chain. SLSA, on the other hand, is designed to be a comprehensive end-to-end framework. It not only defines how to mitigate threats within all supply chain artifacts, but also provides security guarantees that prevent attacks on the entire supply chain in a security landscape that is ever-changing.

The Biggest Problems with Securing the Software Supply Chain 

Modern applications are created using software artifacts that include both proprietary and open source code, APIs and user interfaces, and various other components. Security issues at any point in this software supply chain create grave risks.

That said, the risks associated with closed source and commercially verifiable artifacts are, to a degree, easier to navigate. By contrast, open source software artifacts pose the biggest risks giving DevSecOps teams a much harder time.

Typically stored in online repositories, open source software packages are prone to being easily weaponized with malicious code due to their free availability and largely modifiable and unregulated distribution. Tampering or unauthorized modification of these code packages at any stage of the software life cycle significantly increases the attack surface with the power to compromise the software supply chain.

Consider these problems that have become endemic to software supply chain security:

1. Validating and verifying third-party software components, which are largely open source, before incorporating them into the CI/CD pipeline and later at runtime. As an example, making sure freely available Python packages that are updated using the Pip package manager have not been subjected to tampering at the source.
2. Validating and verifying that the actual build pipeline tools have not been tampered with, by means of malicious code running in the CI/CD process. As an example, ensuring that the open source Jenkins CI console has not been compromised, leading to exfiltration of sensitive data such as code backups, log files, or images from private S3 buckets.

How SLSA Has Stepped in to Solve the Problem

SLSA complements the wider security efforts being made to secure the software supply chain using SBOMs. It is mainly focused on preserving the integrity of the code you run: Preserving integrity in the sense of protecting against tampering at the source and the build stages of the life cycle.

The SLSA security guidelines were structured to solve the issues outlined above. For one, the guidelines ascertain integrity at source such that all modifications to the open source software reflect the original intent of the software’s author. Next, they ascertain integrity at build by ensuring that the open source software package is crafted from authentic unmodified sources and dependencies as defined by the software’s author and not changed between development stages. The guidelines also guarantee that open source software packages can continue to be built and maintained in the future and that all code and change history is available for investigations and incident response.

How do SLSA guidelines correspond to software bill of materials (SBOMs), you might ask. Briefly, SBOMs can be viewed as a subset of SLSA. SBOMs generated using SLSA attestations increase their accuracy manifold. Developers should sign the SBOM along with SLSA provenances that provide high-fidelity information about what went into the artifact during the build stage, then verify the SBOMs for security vulnerabilities. This will ensure all components included in the pipeline are the same as those seen at runtime. In short, the addition of provenance metadata makes the SBOM verifications more wholesome, taking away much of the guesswork from the CI/CD pipeline and runtime stages of the app development and delivery process.

This summary table provides a list of all requirements for an artifact to meet the four SLSA levels.

Panoptica – Cisco’s Cloud Native Application Security Solution

Panoptica’s security provides prevention, detection, and response automation across the entire application life cycle to secure the build, secure cloud infrastructure, and secure running workloads wherever they are deployed. Panoptica’s software supply-chain security addresses critical risks faced by DevSecOps teams like yours. It protects against known vulnerabilities in container images and configuration drift, as well as provides runtime policy-based remediation of zero-day attacks.

With Panoptica, you can automatically generate SBOMs during the build stage and get a view of all open source components that may be vulnerable to attacks and require patching using the latest standards for signing and verifying software using sigstore keyless, in addition to symmetric and asymmetric code signing.

To learn more about Panoptica, visit us here or sign up here to try it for free.