Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.
Elements of an Effective Software Supply Chain Strategy
Get a handle on your organization's software supply chain not only to comply with federal regulations but also to tighten security throughout that supply chain.
Jo Panuwat D via Adobe Stock
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.
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.
Read more about:Supply Chain
About the Author(s)
VP of Cross-Portfolio Solutions and Strategy, Synopsys Software Integrity Group
Anita D’Amico, PhD, is the former CEO of Code Dx, Inc. an application security orchestration and correlation company acquired by Synopsys. She currently serves as the Vice President of Cross-Portfolio Solutions and Strategy in the Synopsys Software Integrity Group. Her roots are in experimental psychology and human factors, and she has built a career of leading technology development to enhance human performance. More recently she has focused her attention on enhancing the decisions and work processes of software developers and AppSec analysts to make code more secure. Anita was named as one of “100 Fascinating Females Fighting Cybercrime” in the 2019 book “Women Know Cyber.”
Head of Software Supply Chain Risk Strategy, Synopsys Software Integrity Group
Tim Mackey is the Head of Software Supply Chain Risk Strategy within the Synopsys Software Integrity Group. He joined Synopsys as part of the Black Duck Software acquisition where he worked to bring integrated security scanning technology to Red Hat OpenShift and the Kubernetes container orchestration platforms. In this role, Tim applies his skills in distributed systems engineering, mission critical engineering, performance monitoring, large-scale data center operations, and global data privacy regulations to customer problems. He takes the lessons learned from those activities and delivers talks globally at well-known events such as RSA, Black Hat, Open Source Summit, KubeCon, OSCON, DevSecCon, DevOpsCon, Red Hat Summit, and Interop.
You May Also Like