How SLSA Can Secure Your Software Supply Chain

The Case for Software Supply Chain Security.

A couple of days ago, on Oct 22, 2024, the Securities and Exchange Commission fined millions of dollars for mislabeling the risks of the SolarWinds attack as “hypothetical.” Four companies Unisys, Avaya, Check Point, and Mimecast were fined $7 million. In 2020, the SolarWinds attack affected major organizations when malware gave backdoor access to its Orion software.

Supply chain attacks have only grown in both quantity and magnitude since then. Though companies continue to downplay the impact of Supply Chain security, on average, less than 50% of the code base in your organization is written by your employees. Supply chain security controls mitigate risks coming from the “external” software that ships with your product.

The Cure to Make Robust Software Supply Chains.

Google has invested heavily in insider risk since 2010 and has been building multi-layered security controls to defend against advanced attacks. Around 2019/20, Google Chrome started developing a framework that applies to a broader community, starting with Chromium. Collaboration across the company led to the formation of the supply chain levels for software artifacts aka SLSA.

Since then, Google has donated this project to OpenSSF, one of the largest open-source software foundations. SLSA version 1.0 was launched earlier this year and it provides an incremental solution to gradually improve security posture from development to deployment for the software supply chain.

SLSA Threat Model

Let’s take a look into how malicious actors exploit weaknesses throughout the process right from build systems to the artifact distribution level. The SLSA threat model states that issues like inadequate code review, misconfigured build systems, and unverified third-party code-introduced risks, etc. can cause significant security breaches.

The successful attacks on SolarWinds where the hackers injected malicious code into the build process require strong controls. Knowing your dependencies and preventing unilateral access remains crucial for ensuring malware can’t be inserted.

Applicability of SLSA in Real World Scenarios

There are three major use cases for SLSA, First Party, Open Source Projects, and Vendors. In First Party, since there is no need to transfer trust across organizational boundaries, this makes it the easiest use case. SLSA can be used entirely within an organization.

In the case of Open Source Projects, SLSA uses a canonical source repository approach where users of open-source software need to only trust a handful of build platforms instead of trusting thousands of developers who have upload permissions to many packages. SLSA would simply reject an upload if it was not from a canonical source repository.

And finally, for users of vendor-provided software, SLSA would require a vendor to be certified by a third-party auditor. This would make it easier for consumers to trust vendor software products.

Also, provenance is the main aspect of using SLSA, it would provide traceability and verifiability of where the software originated. The goal is not just to prevent tampering but also to trace who was involved and where the exact origin of the software was. Since it facilitates transparency, companies can easily adapt to regulatory restrictions while ensuring that their business operations are sound.

Hardening the Chain of Trust

The core of SLSA is provenance, which documents the origin and security of artifacts. SLSA can pinpoint tampering or any other malicious behavior using cryptographic validation and automated attestation. Since it verifies that each step from creation to distribution of the software is indeed secure, the chain of trust is therefore solidified.

The majority of well-secured development environments apply the principles of provenance including Google. One of the innovators of the SLSA framework at Google is Akash Mukherjee. He discusses how Chrome ensures verifiability in its builds in this article Chromium Chronicle #23. The article focuses on the fundamentals of the framework and the four pillars that we see today in SLSA.

Meeting Government Mandates With SLSA

Another advantage of SLSA compared to other security libraries is its ability to meet U.S. government regulations. The National Institute Of Standards and Technology aka NIST plays a crucial role in cybersecurity by creating frameworks, guidelines, etc. like the Secure Software Development Framework (SSDF). SLSA is able to help companies meet these requirements.

Following this framework will also align companies with the Executive Order 14028 directive which has a higher standard for cybersecurity along the entire software supply chain.

Also in highly regulated defense, healthcare, and finance industries, SLSA is reliable enough to be the security blueprint for organizations that can help generate evidence of compliance even when it touches critical cybersecurity concerns.

The Future of SLSA as a Blueprint for Secure Software Development

But this journey does not stop here; it continues evolving the industry. With the flexibility in its structure, SLSA allows organizations to enhance their security step by step while preparing for future threats.

As SBOMs become central to software development, experts focus on securing development practices in general, “SBOMs can help lift security health from the status quo, but frameworks like Supply-chain Levels for Software Artifacts (SLSA) and Secure Software Development Framework (SSDF) must be used to improve security as you’re building new packages.”, Akash Mukherjee, an early developer of the SLSA framework in his recent post on RSA conference.

By integrating the best practices from SLSA with development insights gleaned from resources such as Chromium Chronicle, an organization is well-equipped to design secure software. At its core, SLSA revolves around provenance, providing cryptographic assurances and compliance with regulatory requirements, making it an extremely important tool for securing the global software ecosystem.