Understanding Software Supply Chain Risk Management
Managing the Risk of Open Source in the Software Supply Chain
What is Software Supply Chain Management?
Software Supply Chain Management is the process of having a clear view of all open-source objects and internal shared dependencies that your organization is using so you can easily mitigate risks and vulnerabilities. If you believe you don't use open-source within your organization, you might look again.
Most development environments rely heavily on open source. According GitHub's Octoverse, 97% of companies use open-source. That number lines up with the Linux Foundation's "Software Bill of Materials (SBOM) and Cybersecurity Readiness" report, indicating over 98% of their study's sample reported using open-source software.
Defining Risks of Open-Source Software in the Supply Chain
Software supply chain risk management is the process of identifying, assessing, and mitigating risks associated with commercial third-party software, common internal components, and the open-source packages they consume. Software supply chain risk management involves identifying, assessing, and mitigating risks associated with consuming open-source software components into the software delivered to end users. Managing the risks of using open-source software involves exposing what packages are used, even when developers don’t always know the transitive dependencies they consume.
Exposing Open-Source Usage Across Your Landscape
Software supply chain risk management starts with understanding the inventory of open-source running across all environments, from development through production. The overall global supply chain includes open-source objects, commercial third-party components, and internal common code components. Software Supply Chain Risk Management refers to understanding your cybersecurity risks across all components used by IT teams to create the software they deliver.
In December 2021, we learned a hard lesson when a severe vulnerability was found in a version of one of the most popular open-source packages, Log4J. Once discovered, organizations struggled to quickly determine if they were using the offending version of Log4J. Between December 9th and 21st, 2021, Symantec’s intrusion detection system blocked more than 93 million Log4j-related exploitation attempts on more than 270,000 unique machines. (Source: VMWare Security Blog)
Software Supply Chain Risk Management in a Decoupled Environment
In a decoupled architecture, hundreds of shared ‘feature’ components are developed to create the building blocks of software systems. The concept of a monolithic application goes away. In its place is a logical application that is comprised of a collection of common components, along with application specific components.
In this type of decoupled architecture, SBOM data is spread across hundreds of independently deployed components. Creating an SBOM for a logical application can be difficult, if not impossible. Aggregating component SBOMs and CVE reports up to the application level is critical. Application teams cannot produce an application SBOM similar to traditional monolithic SBOMs. Instead, they rely on spreadsheets in an attempt to aggregate the results manually. Adding to the complexity is the speed at which independently deployed components are moved across the pipeline. The result is that the logical application of SBOMs becomes highly dynamic. Statically managed spreadsheets become out of date every day.
Supply chain management software will revolutionize how we manage software risks by providing automation that continually reacts to known vulnerabilities as soon as they are discovered and continuously associates that information with all the consuming applications.
How Does a Decoupled Architecture Impact the Software Supply Chain?
In a decoupled architecture, your software applications comprise many independently built and deployed functions that talk via APIs at run-time. With a software supply chain, you no longer run a monolithic build that creates your application ‘version’ and your application’s SBOM. Components can be written in various languages such as Java, C, .Net Framework, Go, or Python. Therefore, a decoupled application may be composed of many components written in different languages, each with its own unique exposure.
Every component is built independently and has its own SBOM for every release version. When a new component version is released, a new version of all-consuming applications is ‘logically’ created. So the question is, ‘how do we track when an application has been impacted and know if new dependencies with new vulnerabilities have been introduced?’
Open-Source Software in the Supply Chain
Open-source in the software supply chain starts with the operating system and ends with the common components created by software developers. The open-source software supply chain spans all levels of this landscape and includes:
- Open-source operating platforms -Linux, Kubernetes, VM, Docker.
- Open-source tools and languages – .Net Framework, Python, Jenkins, Tekton, Ortelius.
- Open-source code libraries – D3S.js, reactJS, or jQuery.
- Open-source transitive dependencies – Log4J, Lang 3, Spring 5.
Not all software supply chain risks are obvious. Hardening internal cybersecurity requires a close look at how open-source is used across the organization. This hardening requires some digging down into the weeds. The most vulnerable aspect of the software supply chain is what cannot be easily seen. These are the lowest-level transitive dependencies that open-source packages depend on.
What IT Teams Need
In a decoupled architecture, a higher level of organization is needed to track SBOMs and vulnerabilities at the application level. Application teams are ultimately responsible for the software system they deliver, even if it consumes components they did not create.
For this reason, IT teams need to do the following intelligence to mitigate risk:
- A map of the component versions that the logical application version consumes.
- Component SBOM reports automatically aggregated to each logical application version.
- A continuous CVE scan for all logical application versions based on the SBOM aggregated data.
- A central dashboard for viewing a component’s SBOM and CVE data to continuously monitor potential exposure.
- A DevOps workflow that can continuously generate application security data and aggregate the results up to all consuming logical applications.
Moving to a decoupled architecture will require some tweaks in managing DevOps pipelines. Tracking component updates, their impact on consuming applications, and aggregating data so information is easily exposed will be critical for application teams to remain aware of potential risks and vulnerabilities before a release to their end-users. A software supply chain management catalog that stores and aggregates this level of data will be necessary to simplify the complexities of a decoupled architecture.
Top 4 Software Supply Chain Security Risks
To manage top software supply chain risks, a coordinated approach is needed to address threats. Here are the top software supply chain security risks:
- Lack of Provenance (no identity)
- Hacking the Build
- Guardrails that prevent a fast response
- Unknown and Problematic Package Dependencies
|Software Supply Chain Security Risks||Description||How to Mitigate This Risk|
|Lack of Provenance (no identity)||Knowing who is making changes and where they are coming from is critical to the software supply chain. This lack of identity allows an anonymous code ‘hack.’||To manage this risk, code and package signing should be required for usage.|
|Hacking the Build||Most open-source objects are built by individuals or CI systems that rely on uncontrolled scripts. One-off scripts make it easy to inject nefarious objects into binaries, component images, or release packages.||To mitigate this software supply chain risk, repeatable builds across a build pool and minimizing scripted processes are needed. Check out the Solarwinds hack.|
|Guardrails can prevent a fast response||Once a vulnerability is identified, the time from an update to release must be condensed. Tight control of the release schedule can become a problem when a known vulnerability needs to be addressed.||The release process should have emergency procedures to go around well-intended guardrails.|
|Unknown and Problematic Package Dependencies||Visibility into shared packages is core to managing the supply chain. Without visibility into shared packages, you have no idea of your risks and vulnerabilities until it is too late.||SBOMs and CVE reports mitigate this condition and should be automated as part of the CI/CD process. Check out the recent Log4J vulnerability Learn about Ortelius.io, an open-source microservice catalog.|
Exposing Software Supply Chain Risks with DeployHub
DeployHub is a software supply chain management catalog that continuously gathers application security intelligence to expose open-source package inventory. A simple search based on the package name can quickly provide a list ofwhere the package is running and what the package is impacting. This view can be seen from the component, application or environment perspective.
In other words, DeployHub can easily answer the question, “Where is log4J running?” A simple query against the DeployHub data store will provide the answer:
Collecting and organizing evidence is required for a comprehensive view of your organization’s supply chain and risk. Learn how a software supply chain managment catalog can aggregate this level of data across organizational siloes serving IT teams with different data requirements.
- Software Supply Chain Management Catalogs Explored Whitepaper
- Federated Application Security Intelligence
- Aggregated SBOM Reports
- SBOMs and Cybersecurity
- Supply Chain Versioning with Historical Trends
- Component Impact and Blast Radius
- Logical Application Views in a Decoupled Architecture
- Federated Software Composition Analysis Data
Signup for Free and Get Started Today
Signup for DeployHub Team, the free SaaS supply chain management catalog. You will need a Company and Project Name to get started. The Company Name you enter will be created as your company’s private domain, referred to as your Global Domain. Your Project Name will be used under your company Domain. You will also receive an email from DeployHub. The email will contain your unique user ID and client ID, links, and useful information. Learn More