Since President Biden issued an Executive Order on Cybersecurity (EO 14028) in May, the topic of securing software supply chains has increased in prominence, and public scrutiny.

Nearly all software is created from a vast ecosystem of open source and third-party components, each of which represents one supplier in the supply chain for that application. The software supply chain for most applications operates at a level of complexity that rivals that of any manufacturing supply chain. In fact, the 2022 Synopsys Open Source Security and Risk Analysis (OSSRA) report shows an average of over 500 suppliers in a typical commercial application.

As impactful as EO 14028 is becoming, it’s important to recognize that it isn’t the first set of guidance from the US government on cybersecurity, and that the US government isn’t the only government to issue cybersecurity guidance. What’s changed and made EO 14028 more impactful are the actionable items presented in it. As a result, software producers are rushing to comply with anticipated requirements that may be placed on them by multiple government entities and standards bodies, and their respective customers.

Since we’re in the early days of requirements related to EO 14028, it’s reasonable to assume that current processes may not meet the eventual contractual requirements. For example, the industry attention now given to a software bill of materials (SBOM) -- a requirement for medical device and automotive suppliers for several years and is now featured prominently in EO 14028 -- has spurred a lot of market activity to efficiently manage software patching.

Therefore, there is increasing activity surrounding software supply chain risk management (SSCRM) and SBOMs. To better understand this problem space, we surveyed the motivations for SSCRM and the market response. Our findings are gathered below.

To demystify SSCRM, we’ve created what we refer to as the 12 elements of an effective software supply chain strategy. These elements don’t focus on responsibilities solely within software producers, but instead recognize that everyone from the software creator to the user operating the software has a role to play when it comes to securing software supply chains. The 12 elements are shown in Figure 1, and it’s important to highlight that the order of these elements isn’t hierarchical, but adjacent elements are related.

Figure 1

The first grouping of elements deal with the asset inventory, SBOM, and provenance of the software. IT and operations teams are ultimately accountable for processes related to these elements. IT has a responsibility to properly patch any software that it manages, regardless of how that software was produced, or who the supplier was.

Since you can’t possibly patch software that you don't know you are running, these elements require that an inventory of software assets is maintained. Each piece of software will have its own set of dependencies, and an SBOM listing those dependencies aids in any impact analysis for a security incident such as the disclosure of a vulnerability within a dependency. In an ideal world, there is a patch for each disclosed vulnerability, and that patch must originate from the author or software producer. After all, using a patch found on the internet instead of an official patch is far more likely to introduce problems than solve them.

The second grouping of elements cover securing development environments, attestation of the integrity of the released software, and an understanding of any quality or security issues that might be present in the software. If these sound like the responsibilities of an application development team and their usage of DevSecOps or secure SDLC processes, you’re right. For example, if an organization hasn’t fully secured their development environment, there is no way that they can confidently attest to the integrity and functionality of any artifacts that such an environment produces.

The third grouping in the list covers regulatory and licensing noncompliance of software, along with unexpected functionality contained within the software. Each of these present problems for the team that buys or procures software, but they should also be front of mind for anyone downloading or using software. Non-compliance is a key concept here, as determining compliance requires an exhaustive review of software while non-compliance requires just one attribute to be out of compliance.

The final two elements relate to governance policy and reporting. No software is perfect, and over time even weaknesses in the best software could become exploitable. Proper policy definition and associated implementation of business controls allows for improved risk management of software supply chains. Such controls will naturally impact any of the first 10 elements and will be specific to how the application is used. Importantly, the usage context of the application should be factored into any approvals for a given software supplier, service, or library.

Properly managing the risks within software supply chains is more complex than simply creating an SBOM or requesting one from a supplier. By creating a software supply chain risk management process and workflows, it becomes easier to identify when risks within business-critical software change and how best to reduce the impact of changes in risk. Since risk flows between teams and processes within any business, the use of these 12 elements can help identify risk boundaries.