Hello there! A quick note from me (Clint Gibler), the creator of tl;dr sec.

You may already be familiar with how tl;dr sec is a free weekly newsletter round-up of the best articles, tools, and general cybersecurity research.

This time, I’d like to introduce you to Francis Odum, who will be sharing a two part overview of software supply chain security.

Francis is the author of the software analyst blog. He teaches a cybersecurity & SaaS bootcamp on Maven. He previously led cybersecurity research at the venture capital firm, Contrary, and helped build Contrary Research. Follow him on Twitter @InvestiAnalyst or LinkedIn at Francis Odum.

This Report In One Minute

Companies are embracing open-source third-party dependencies to ship features to users faster.

Software supply chain security includes using third-party code securely as well as securing the development process from beginning to end.

This report focuses on the following three phases of the software supply chain. Across these phases, we discuss what constitutes software supply chain risks and processes for securing each stage.

By the end of this post, you’ll have a solid overview of the core components of the software supply chain, risks across the chain and how to deploy secure processes at each stage.

If you want to make sure you receive Part 2 of this report, in which we provide a comprehensive analysis of 12+ SSC vendors and their core differentiators, make sure to subscribe to tl;dr sec (if you’re not already), a free weekly update of the best tools, blog posts, and talks in cybersecurity across AppSec, cloud security, AI, supply chain security, and more!

Alright, let’s get into it!

Understanding The Buzz

The demand and supply of open-source tools continue to rise. Similarly, the volume of open-source downloads is accelerating, creating a massive increase in consumption. Across project versions in 2022, there was a 33% growth in downloaded projects to 3T across major open-source ecosystems. JavaScript npm (2M projects) and Maven.js (492K) remain the most popular.

This proliferation of open-source solutions in enterprises has created an opportunity for attackers to use open-source solutions as a means to inflict harm on companies. For example, known attacks on the software supply in 2022 grew over 633% YoY compared to 2021. There was over 742% average growth in these attacks. Similarly, in 2022, the number of malicious packages has continued to increase significantly, growing to over 88K instances.

Supply chain attacks are difficult to manage because of the multiple links, inter-dependencies and processes that make up current software development practices. This report aims to categorize the software supply chain attacks into three broad challenges that need solutions that may be intertwined in between them. These include source, build and deployment and package.

The problem of software supply chain is not entirely new. However, there has been a renewed focus on areas of the software development where traditional software security platforms never captured in the past. Many of the legacy providers missed on the following problems.

First, many of these companies focused on scanning for vulnerabilities within source code. That focus was only on one segment of the development lifecycle which created more noise, but never pointed to actionable feedback points for developers. Most of these past solutions focused on source code level compared to understanding the deeper intricacies of dependencies within the build and pipeline stages.

Secondly, many of the legacy players were founded long before the cloud evolved or before open-source became extremely popular amongst developers.

The Rise In Open-Source Software (OSS)

Today, open source is used in 98% of applications. According to the 2023 State of Open Source Report from OpenLogic by Perforce Software, and 80% of organizations increased their use of open-source software over the last 12 months. Open source has grown in popularity because they enable developers build and ship products faster. However, these open source packages have increasingly become a popular vector for software supply chain attacks, creating more risks for organizations. Packages are sometimes uploaded by developers into their registries with little to no security oversight, and are downloaded into codebases without scrutiny. Popular package registries such as JavaScript npm, Python PyPI and RubyGems have become easy targets used to distribute malicious packages.

To understand SSC security, we must first define SSC and clear up any misconceptions. SSC involves building and producing software, much like assembling ingredients for a burrito wrap or raw materials for a manufacturing plant. The software supply chain includes all the processes, steps and components you need to create an application. Just like a traditional supply chain where raw materials are sourced, assembled, and transformed into finished goods before they are distributed to retailers or customers. This framework applies to how software supply chain works as well.

Applying it to software development

Modern ways of building applications can be categorized into three phases: source, build, and package stages. Each of these stages could be vulnerable to attackers. During the source stage, developers write custom code. The build stage is responsible for assembling the raw files of source code and transforming them into binaries (output used for deployment). Finally, the deployment and package stage gets the final software ready for deployment to production use.

Just as car manufacturers outsource many parts to suppliers or offshore teams to accelerate production, software development also involves using external tools from suppliers, which are open-source packages and libraries, to accelerate their delivery cadence.

The three most important phases of the software supply chain as it relates to software development are source, build and deployment and package. At a basic level, here are some explanations for each category.

After building upon a basic understanding of each of these areas, let’s understand how risks can be introduced at each layer.

According to the NIST guide, an SSC attack is when a malicious party tampers with steps, artifacts, or actors within the chain to compromise the consumers of a software artifact down the line. In order to carry out an SSC attack, an attacker needs to subvert, remove, or introduce a step within the SSC process to modify the resulting software product. The chart below shows the various areas where an attacker could launch an attack against the supply chain.

The Supply Chain Levels for Software Artifacts (SLSA) framework is another important framework used to understand each layer of attack. The SLSA (pronounced “salsa”) framework provides a checklist of standards and controls to prevent tampering, improve integrity, and secure open-source packages. SLSA breaks down the three categories (source, build and deployment) into eight distinct types of threats that could occur at each stage.

Using both definitions from the NIST and SLSA framework around the source, build and deployment/package stage. The rest of the report is built around exploring each of these areas in more depth.

Source Code Layer

Everything begins at the source code where developers write custom code using languages like Javascript, C++ or Python. This section discusses SSC risks that could occur at the source code layer as well as the three solutions used to prevent these attacks.

Source code review

Code is the first and core ingredient in the software supply chain used to build the end product, an application. This code can be developed in-house or from external sources. As code moves across different hands, there are a number of vulnerabilities that occur here.

First, as developers make changes to source code in a version control system (VCS) during code commit, there is always a risk that a bad actor internally could make modifications to the source code or the controls that host them in a code repository. Some of these issues could be resolved with companies implementing code reviews whereby one or more developers analyze a teammate’s code to identify any poorly written code, bugs, or errors. Code changes can be submitted as pull requests (or merge requests), and reviews can be conducted before the changes are merged into the main codebase.

In addition to code reviews, many companies leverage a static application security testing (SAST) tool that continuously scans all new code and existing code for vulnerabilities. You can think of SAST tools, when used properly, as scaling secure code review across every pull request on every code repository.

Historically, companies used heavyweight, legacy SAST tools to try to “find every vulnerability,” leading to large amounts of false positives and heavy operational cost for security teams and/or development teams. Over the past few years, some modern, engineering-focused security teams have been leaning into the concept of “secure defaults” (also called “secure defaults”, or to use Netflix’s term, building a “paved road”). The idea is that the build tools, libraries, and processes make it easy for developers to do things the secure way, and hard to proceed insecurely, thus eliminating entire vulnerability classes from occurring in the first place. See Figma Head of Security Dev Akhawe’s Modern Static Analysis blog post, this Global AppSec SF talk, and this BSidesSF talk for more.

Securing source code management (SCM) systems

Source code leakage has become a major issue, such as the attack in 2022 where Microsoft had its source code leaked by the hacking group Lapsus$. The group alleges they released source code for Bing, Cortana, and other projects stolen from Microsoft’s internal Azure DevOps server.

With source code management systems (SCM) like GitHub or GitLab acting as the central hub for the developer’s software development lifecycle, securing these SCMs has become paramount. Developers use these code repositories to store and organize their code while using version control systems like Git to manage and track changes to the source code. By compromising a code repository through unauthorized access, an attacker can gain access to the software’s source code, inject malicious code, hijack credentials, or even provision vulnerable infrastructure.

Managing access to code environments and IDE extensions

Integrated Development Environments (IDEs) and