SLSA: A Novel Framework For Secure Software Supply Chains

SLSA: A Novel Framework For Secure Software Supply Chains

Software supply chains

The software supply chain indicates the formal workflow of how your software moves through the coding stages done by the developers to the final packages for the end-users. When an attacker breaks in between the process and modifies the source code with malicious ones, it is known as an attack on the software supply chain.

Software supply chain attacks are challenging to discover and mitigate if you do not have the proper verification and trail-tracking system, especially for large industries. So it is always an excellent idea to proactively keep the supply chain secure. That is where the SLSA or “Salsa” comes into play.

SLSA ensures the security and integrity of your software supply chain through a multi-level security framework built upon the industry standards. This article will introduce you to the basics of the SLSA framework and tell you how you can implement SLSA to secure your software supply chain. Let’s get started.

What is SLSA?

SLSA, or Supply chain Levels for Software Artifacts, is a software security framework that includes a series of checklists, protocols, and policies following the industry’s best practices.

SLSA’s ultimate goal is to improve the integrity of your software supply chain and make any changes traceable. As a part of the OpenSSF cross-industry collaboration, SLSA implements provenance or traceability at any point throughout the software supply chain.

Moreover, SLSA also aims to prevent unauthorized access to your software supply chain and unauthorized modification of any codes. The measures and policies are designed to tighten and update the supply chain security over time as the software scales.

There are four categories of SLSA requirements, which are:

  • Source requirements
  • Build requirements
  • Provenance requirements
  • Common requirements

How Does SLSA Secure Your Software Supply Chain?

The software supply chain comprises several stages, from code development to preparing the final package for delivery. Source, build, and dependencies are integral components of the chain. As you scale your software with advanced options, the supply chain gets increasingly longer involving many stages of coding and development.

SLSA

If security protocols are not closely followed at each stage, an attacker may exploit that and replace source code with malicious code. Afterward, it may go through the later stages without any obstacles or verification up to the final package and be delivered to the users as an update.

You will always want your end-users to receive the intended package of your software version that your developers have developed, not a version that contains malicious codes inserted by an external party. Therefore it is always critical to place verification methods when your source codes pass through each stage.

In addition, you must be able to track any trail of changes to ensure the authenticity of your codebase and dependencies. SLSA plays this role through multiple security checkpoints. Based on how tight the security protocols are, industry practitioners have developed four SLSA levels to specify the level of assurance or trust for a software system. Let’s quickly get familiar with those.

SLSA Levels

There are currently four levels of the SLSA security framework – Level 1 to Level 4, where Level 1 represents the minimal security mechanism that is easy to implement and Level 4 represents the highest of security standards.

SLSA Level 1: Build Process Documentation

Level 1 SLSA provides you with clear visibility of your software supply chain by requiring the developers to document the build process and provenance. SLSA Level 1 has the following characteristics:

  • The documentation includes the dependencies and top-level sources, allowing your risk-based decision-making process easier.
  • Provenance enables entry-level code source identification, helping you better manage any vulnerabilities.
  • It does not protect against tampering.

SLSA Level 2: Tamper Resistance

SLSA starts protecting your supply chain from tamper attempts while initiating guarantees for building integrity. The characteristics include the following:

  • Level 2 requires you to introduce version management and dedicated build services to verify provenance.
  • End users get greater visibility on the software’s origin.
  • There is a clear upgrade path toward Level 3.

SLSA Level 3: Extra Resistance to specific threats

SLSA Level 3 tightens the security measures compared to Level 2 and increases the trust further to different individual components. Some of the features are:

  • Auditability of the source and authenticity of provenance is ensured.
  • The build service must be isolated to prevent tampering.
  • SLSA Level 3 prevents specific threat categories such as cross-build contamination and provides a stronger overall protection.

SLSA Level 4: Highest Level of Confidence and Trust

SLSA Level 4 aims to achieve the highest level of trust and confidence for integrity and dependence management. Some of the characteristics are as follows:

  • The security system requires two persons to audit any modifications to detect problems and unintended changes.
  • A complete list of dependencies is required.
  • The level encourages but does not currently mandate reproducible builds to ease the audit process.

It is important to note that each of your software artifacts has an independent rating, and an artifact’s rating may differ from its dependencies.

What Are the Limitations of SLSA?

Despite gaining quick popularity and industry-wide adaptations, SLSA is not foolproof. It has several limitations that you need to keep in mind, such as:

  • Many components - It is not always possible or practical to identify and audit each component of software from a very large codebase. So your team needs to focus on the prioritized ones.
  • Risks from dependencies - An SLSA Level 4 artifact may come from a level 0 dependency. So risk factors will remain even if the primary artifact seems well protected.

The OpenSSF collaboration consistently works to improve the SLSA framework and mitigate the limitations.

Bytesafe Can Make Things Easy

Bytesafe can significantly ease your SLSA implementation with dependency firewalls, package management, composition analysis and license compliance. The free advanced dependency checker can identify potential vulnerabilities within your code in no time.

All of your team members can collaborate together in the Bytesafe workspace and keep your application safe. Trial your Bytesafe workspace today and effortlessly import and evaluate your current dependencies for vulnerabilities.