Securing Your Software Supply Chain

In one of our previous blog posts, we touched on the subject of Secure Software Supply Chains (SSSC).  We have subsequently discussed the relevant regulations, standards, and frameworks that have emerged in response to this threat.   In this post, we will continue exploring the subject, looking at how to secure a software supply chain, and your responsibility as a software producer. As with our previous posts, this doesn’t aim to be a comprehensive guide, one would need to write a book for that, but an overview of the field.

In the Navigating Secure Software Supply Chains post, we talked about the software supply chains being similar to moving a car along the assembly line. The analogy can be extended further - like a car on the assembly line, with many parts being produced by various suppliers, a modern piece of software moving along a software supply chain may include components, libraries, and frameworks produced by various 3rd parties, sometimes commercial, sometimes open source, and often both.

What this means is that all of us engaged in the process of crafting software play a dual role. We are at once consumers of software that is written by someone else and producers of software written for those who are going to consume it - our customers.

Much like incoming Quality Assurance for our hypothetical supplier’s auto parts, so too does the SSSC need to extend our validation measures to include those items our pipeline is consuming.  We should validate the provenance (origin) of the components and their attestations of reliability, much as we attest that our SSSC is secure and that what we have produced has not been tampered with.

Sample Pipeline

Where to Start

The best place to start is, as they say, at the beginning.

Two things need to be done to understand what (if any) changes need to take place. The first is an understanding of any regulatory or contractual requirements placed on an organization’s systems. This will inform decisions about what standards may apply and which level to target. (Hint: Start small and then add complexity)

The second is performing an assessment of the entire Software Development Life Cycle (SDLC) process of building, assembling, validating, and “shipping” your system(s). In our experience, conducting a Value Stream Map (VSM) of your SDLC is vital to understanding the existing landscape and processes.

Keeping with the automotive assembly line analogy, you can think of the software assembly process as containing stations (or stages) at which certain operations are performed. Sometimes those stations bolt things together, sometimes they test the components.

At each station/stage/step in the assembly process, it is important to identify several dimensions:

• What operation is performed?

• Who has access?

• What technology is involved? (When & How is it upgraded/patched?)

• Are other components (internal and external) referenced?

• What is done with the output?

Once this information has been assembled, we can begin to create a plan to address any deficiencies found in the process. As we have mentioned previously, you can’t just tool your way out of this problem.

Protecting yourself from your suppliers

Much like a car on a modern assembly line is built using components produced by trusted suppliers (for example, Toyota buys parts from more than 200 suppliers), the software that is built by your organization is built using code and components produced by 3rd parties. As an “owner” of that software assembly line, you have to ensure that the components that you use come from parties that you trust. As a starting point, you need to know what components are used, you need to be able to validate the integrity and provenance of the components, and you need to make sure that only approved components get into the “assembly line”.

“But that can stifle innovation!” someone will cry. To make sure that it doesn’t, you also need a flexible, robust, automated, and non-bureaucratic process for reviewing and approving both new components and updated versions of existing components.

Nobody is suggesting that you stop using open-source software. Tremendous strides have been made by leveraging the wider community to provide reliable features and functions. It would be nearly impossible to exist without them for most development environments. But that doesn’t mean that you are free from due diligence.

Make use of library caching techniques that provide rapid access to approved components and to block attempts to use unauthorized libraries.

In response to the emerging threats, the Open Source community is starting to embrace SSSC. Various bodies and standards described in earlier posts are addressing the need for Open Source projects to ensure their provenance and provide Software Bill of Materials (SBOMs). These add a layer of transparency for your build process and ultimately your customers. Because the SBOM standard focuses on communication between projects, it can be worthwhile to speak with industry partners about their choices.

Protecting yourself from yourself

After selecting the target standards and levels, performing an audit of the existing process, and securing your own supply chain, the next thing to focus on is your own “factory floor”. We need to make sure our build system is secure. We must protect our product from someone tampering with our code at a particular stage in our SDLC (like in Solar Winds).

First and foremost is to secure the actual pipeline. That includes properly managed access control, robust network security, and patched servers. In all everything that should be done to secure one of your most critical systems. Don’t expose it to the internet, if any remote access is provided make sure it is via VPN only, and implement two-factor authentication for access. If digital signing is used for attestation and to sign SBOM, private keys must be protected. There are a number of solutions for this, some of which are provided as a service, like Sigstore, but if you manage keys yourself, consider storing private keys on FIPS104.3-compliant devices.

In the assembly line analogy, each step contributes to the completion of the car. In the case of software, “the car” is often referred to as an artifact. At each step in the process, we need to attest that the artifact was at this “station” and that it passed all necessary steps. Additionally, each successive step must validate that it is using that untampered artifact and attest that it too has been completed successfully. This creates our chain of custody.

Let’s try to leverage this automotive analogy one more time. Like all new cars require a Monroney Sticker that lists vital information, our new artifact needs to have a Software Bill Of Materials (SBOM) associated with it. The SBOM is a comprehensive list of all the software components, dependencies, and metadata associated with our artifact. The SBOM functions as the inventory of all the building blocks that make up a software product. If we are using containers to facilitate the deployment of our artifacts, those images also need to have an associated SBOM that references the SBOM of the constructed artifact.

Given that you are unlikely going to be able to just buy and install a tool to address all the risks in creating your own SSSC. There will undoubtedly be process changes as well as the need for increased automation. One of the most important steps to take is the creation of a robust communication and education plan for stakeholders and staff as to the importance of a SSSC and the approach the company is taking.

The most important step is to begin.