What can we Learn from Google’s SLSA to Prevent Software Supply Chain Attacks?

Eran Orzel
Jun 30 · 5 min read
Prevent Software Supply Chain Attacks

As the wave of software supply chain attacks continues to rise, Google released a set of guidelines to ensure the integrity of software packages, with the aim of helping prevent unauthorized code modifications that affect the software supply chain. The new Google SLSA framework (Supply Chain Levels for Software Artifacts) provides recommendations for companies to achieve a more secure software development and deployment process, by identifying and mitigating issues in CI/CD pipelines.

In this blog we will discuss the SLSA framework, 8 common risks to the CI/CD pipeline process that can compromise its outcome, and how Argon can help prevent such risks.

Google’s SLSA Framework

SLSA is an end-to-end framework for ensuring the integrity of software artifacts throughout the software supply chain. The requirements stem from Google’s internal “Binary Authorization for Borg” that has been in use for the past 8+ years and is mandatory for all of Google’s production workloads.

SLSA focuses on the following two main principles. All software artifacts should be:

Non-unilateral: No one person can modify the software artifact anywhere in the software supply chain without explicit review and approval by at least one other “trusted person.” The purpose is prevention, deterrence, and/or early detection of risky/bad changes.

Auditable: The software artifact can be securely and transparently traced back to the original, human readable sources and dependencies. The primary purpose is for automated analyses of sources and dependencies, as well as ad-hoc investigations.

Though not perfect, these two principles provide substantial mitigation for a wide range of tampering, confusion, and other supply chain attacks.

The CI/CD Pipeline Process

CI CD Pipeline process

A software supply chain is a sequence of steps resulting in the creation and release of a software artifact. Represented below as a graph of sources, builds, dependencies, and packages. Each source, build, and package may be hosted on a platform, such as Source Code Management (SCM) or Continuous Integration / Continuous Deployment (CI/CD). Note that one artifact’s supply chain is a combination of its dependencies’ supply chains plus its own sources and builds.

Google’s SLSA framework describes 4 security levels.

The higher the level, the stronger the security controls enforced, making it more difficult for attackers to compromise your code:

SLSA 1: Requires that the build process be fully scripted/automated and generate provenance

SLSA 2: Requires using version control and a hosted build service that generates authenticated provenance

SLSA 3: Requires that the source and build platforms meet specific standards to guarantee the auditability of the source and the integrity of the provenance

SLSA 4: Requires a two-person review of all changes and a hermetic, reproducible build process

For more information about the SLSA framework

Taking Supply Chain Protection to the Next Level

Google’s SLSA framework is a step in the right direction of raising awareness and building standards that will help companies take control over their supply chain risks. Looking at the CI/CD process (diagram above) and SLSA recommendations, we can define the following three stages for integrity risks:

Code-stage Integrity:

  • Bad code commit – Uploading vulnerable code to the company’s source code management system that might include vulnerabilities or compromised code packages.
  • Compromised source control – Misconfigurations or vulnerabilities in your source control system that can lead to exposure and theft of your code, secrets and user information
  • Compromised dependencies – Compromises that might allow unauthorized access to your pipeline or exposure/leak of your code and system variables (i.e. Codecov)

Build-stage integrity:

  • Bad code injection – Injecting bad code and triggering a build process outside the legitimate pipeline process and without the proper reviews and approvals.
  • Compromised build server – Leveraging vulnerabilities or misconfigurations to get access to the build server and manipulate the build process and its outputs
  • Compromised dependencies – Use a compromised or vulnerable dependency to get access or manipulate the build server.

Distribution-stage integrity:

  • Bad upload – Upload contaminated artifacts to the antifactory, bypassing the CI/CD process and exposing customer to malicious packages
  • Compromised package repositories – Change system’s process to get access to the artifacts in order to upload, replace, or steal artifacts

Protecting Your Software Supply Chain

Protecting a complex and dynamic process such as the software development process against supply chain attacks requires a holistic security approach; one that takes into consideration the various risks being faced in the code, build and distribution stages across the tools, source code, and process.

As highlighted by the SLSA guidelines, enforcing strong security controls increases your pipeline security posture, making it difficult for attackers to compromise your infrastructure, process or code.

Over the last months we saw various incidents resulting in source code leaks, compromised assets and breaches in DevOps environments that are a direct result of weak security measures over the CI/CD pipelines. Companies like Microsoft, Rapid7, Monday.com, Codecov, SolarWinds and many others fell victim to attacks against the software supply chain, some as a direct target and others that were compromised as users of the originally compromised software.

As we see development environments becoming a focus area for attackers, who recognize it as an easy and highly-exploitable attack vector, applying strong security measures over those environments becomes a must in order to stop these sophisticated software supply chain attacks. It takes a holistic approach to security that provides end-to-end visibility and control over the CI/CD pipeline and is integrated as part of the CI/CD process itself to achieve real protection and provide the security measure identified under the SLSA framework.

How Can Argon Help?

Argon’s first-to-market holistic security solution is designed to protect the integrity of the software development environments, eliminating the risk from misconfigurations, vulnerabilities, and preventing software supply chain cyber-attacks.

Argon takes a proactive approach to CI CD pipeline security providing actionable insights, automatic remediation of vulnerabilities and misconfigurations, and real-time attack mitigation in all stages of the process.

The Argon solution integrates with the pipeline tools and provides multi-layer protection covering the pipeline infrastructure, process, code and artifact. It is the only solution today that protects the code, build and distribution stages, and adheres to the SLSA framework principle.

The solution provides unified visibility, security enforcement, and code integrity across the entire CI/CD pipeline, enabling DevOps and security teams to secure their entire software delivery process from the minute the code is committed until it is deployed in production.

DevOps, DevSecOps, Supply Chain Security, Software Supply Chain, CICD Security, CICD Pipelines, SolarWinds, Codecov

Eran Orzel
Jun 30 · 5 min read

Related Articles

21 Top DevSecOps Tools

What is DevSecOps? DevOps is now the default approach to agile software development and deployment in most tech companies. With…

Nurit Bielorai
Oct 11 · 9 min read

8 Fundamental Steps to Secure Cloud Data

The COVID-19 pandemic forced the world to rethink not only their lives but also their business operations. There was a…

Eylam Milner
Oct 06 · 10 min read

5 Common Risks for Supply Chain Cyber Attacks and What to Do About The...

The year 2020, despite the coronavirus pandemic, was an opportunity for hackers to create major upheaval. As the world dealt…

Eran Orzel
Sep 19 · 7 min read

End-to-End CI/CD Security Platform

open source vulnerability scanner