Key Concept
Defining 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.
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.
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)
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.
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 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:
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.
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:
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.
To manage top software supply chain risks, a coordinated approach is needed to address threats. Here are the top software supply chain security risks:
| 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. |
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.
In a cloud-native microservices architecture, your SBOMs are generated and managed at the microservice level. Microservices are pushed across your continuous delivery pipeline independently and frequently. Every time a new microservice is updated, all of the consuming ‘logical applications’ have a new version with a new SBOM and CVE report. Developers, DevOps Engineers, and Security teams struggle to keep up with the changes and cannot easily provide SBOM and CVE reporting for all impacted applications.
The result is the absence of governance or a historical audit trail of the changes pushed to end users. DeployHub’s SBOM automation tool solves this problem by centralizing the ‘evidence store’ data and continuously aggregating the information to the critical level, the ‘logical application.’ DeployHub provides you with a working federated SBOM report every time a new application ‘release candidate’ is created.
DeployHub provides the insights needed to harden the security of the software your end users consume.
Put Your SBOM Data to Work. Signup for DeployHub Team, the free SaaS software supply chain security platform. DeployHub Team is based on the Ortelius Open-Source project incubating at the Continuous Delivery Foundation.
Mailing Address:
30 N Gould St Ste 36977 Sheridan, WY 82801-6317 US
Phone:
505.424.6440
