In the era of digital transformation, software plays a crucial role in every aspect of digital infrastructure, from IoT devices and cloud services to complex systems in healthcare, the military, aviation, and power supply. Given its omnipresence, it’s no surprise that the software supply chain has become a coveted target for malicious actors seeking power and financial gain by breaching these systems.

 

The consequences of compromising a single software supply chain can lead to cascading attacks across industries, impacting companies with revenue loss, legal issues, and damaged reputations. Using open source components amplifies these risks due to the complex web of dependencies involved, many of which remain untracked.

 

Industry research shows that over 96% of code in applications comes from open source, making supply chain security a critical concern. This article addresses the challenges of securing a software supply chain, with a particular focus on open source projects. In the first part, we define a software supply chain, explain its stages and explore ways to protect the components, activities, and practices involved at each stage.

 

Understanding the Software Supply Chain

Defining the software supply chain

A software supply chain is a network of components, actions, and practices involved in the creation and deployment of application code. In other words, it includes everything that directly or indirectly affects the code throughout its entire lifecycle. This includes details about the code’s components, the infrastructure it relies on, the inventory of cloud or on-premises services, and information about the origins of third-party components, such as GitHub repositories, codebases, or other open-source projects, along with their contributors.

 

Although each software supply chain is unique, most follow a similar foundational model. This model typically includes four phases —create, build, deploy, and run—and illustrates how sources and dependencies are transformed into artifacts that are then either integrated into other software or deployed as standalone applications. It is important to understand that any of these phases is potentially subject to attack. Therefore, securing the software supply chain involves safeguarding the components, activities, and practices at each stage of the process.

 

The figure below outlines the phases of the software supply chain, along with the security measures at each step. 

 

Key components and phases

Create

The “Create” phase involves writing and reviewing sources – an essential content stored in repositories and used for building software. Sources include code written by the internal team or third parties, container images created by operations, build tools, configurations, and infrastructure as code (IaC).

 

During this phase, software architects and developers also incorporate dependencies – external components like open-source libraries, third-party middleware, and standard development frameworks. Unlike sources, dependencies are not produced or reviewed in-house, making it twice as important to assess their reliability and verify their authenticity.

 

Finally, security scanning and testing tools are employed to identify vulnerabilities in both sources and dependencies. Techniques such as software composition analysis (SCA), threat modeling, and various forms of application security testing (SAST, IAST, DAST) are commonly used in this phase.

 

Build

In the “Build” phase, sources and dependencies are converted into artifacts through the use of build tools and platforms. Artifacts may include compiled binaries, container images, documentation, Software Bills of Materials (SBOMs), Vulnerability Exploitability eXchange (VEX) documents, and other attestations. Once created, these artifacts are stored in artifact repositories and published in package registries, making them accessible for the deploy and run phases.

 

The implementation of the build platform can differ between organizations but typically involves several key components: compilers and tools for transforming sources into artifacts, attestation tools for generating provenance, functional test suites, continuous integration and continuous deployment (CI/CD) pipelines, and security scanning tools, often integrated into the CI/CD process.

 

Deploy

In the “Deploy” phase, consumers access published artifacts to either incorporate them as dependencies in their software development projects or deploy them as workloads. IT operations teams often leverage GitOps to automate the deployment of version-controlled software, which helps accelerate feature delivery, enhance collaboration between development and operations teams, and improve consistency.

 

Deployment configurations are defined using Infrastructure as Code (IaC) and committed to source repositories. Consumers’ CI/CD pipelines then automatically download, test, and deploy updated versions of applications and infrastructure according to these configurations, ensuring a continuous and efficient deployment process.

 

Run

In the “Run” phase, consumers operate the resulting applications in hybrid cloud environments. Ensuring a secure runtime environment is crucial, and IT operations teams must configure the security settings of the underlying software infrastructure, including the operating system and container management platform, to meet security standards. They should also keep the runtime environment updated with the latest security patches for the operating system and platform. Additionally, IT operations teams must monitor applications for any reported vulnerabilities and active threats from both external and internal sources.

 

Now that we’ve outlined the basics of a software supply chain, we can move on to part II, where we’ll discuss supply chain security risks and best practices for safely consuming open source.