What’s a Software Supply Chain (and Why Does it Matter)?
Your organization’s software supply chain risk management starts with your operating system and ends with the low-level open-source packages your software consumes. Your software supply chain spans all levels of this landscape and includes:
- operating platforms (Linux, Kubernetes, VM, Docker).
- open-source tools and languages (.Net Framework, Python, Rancher, Jenkins, Tekton, Ortelius).
- open-source code libraries that you consume to develop your custom applications (D3S.js, reactJS, or jQuery).
- open-source transitive dependencies which are the packages that your open-source code depends on (Log4J, Lang 3, Spring 5).
What is important to know is that not all of your software supply chain risks are obvious. Hardening your internal cybersecurity requires a close look at how you are using open-source and digging down into the weeds.
The most vulnerable aspect of your supply chain is what you cannot easily see, the lowest level transitive dependencies that your software systems consume, even if you don’t know it.
What is Software Supply Chain Risk Management?
Software supply chain risk management is the process of exposing all of your hidden objects and dependencies. Your software systems consume hundreds, if not thousands, of open-source components. If you are unaware of these components, you cannot protect your systems from security issues and cybersecurity threats.
Supply chain management mitigates risk and exposes your software dependencies allowing you to define proper policies and practices to address all security threats. Supply chain management addresses the lowest security risk level, the open-source packages your software depends on.
In a supply chain practice, a process of scanning is completed during your software ‘build’ step. The result of that scan is an SBOM (Software Bill Of Materials). There are many different levels of SBOMs, from hardware scans to full Application SBOMs with aggregated data.
SBOMs expose:
- Packages
- Provenance
- Secured References
- Declared Licenses
- Discovered Licenses
- License Header or Full License Text
Once you know your low-level package dependencies, you can scan them to determine your Common Vulnerabilities and Exposures (CVEs). Adding this process to your CI/CD practice hardens your cybersecurity and gives you the knowledge to determine proper mitigation policies and procedures.
What’s the Purpose of Supply Chain Risk Management Software?
Supply chain risk management software is heavily focused on exposing package dependencies (SBOMS) and vulnerabilities (CVE). Recent events have spotlighted the supply chain discussion with investments in new methods for managing all aspects of the software supply chain.
Service Governance
As software systems become more complex, the need for service governance becomes more obvious. A core issue with SBOM and CVE data is accessibility. Sure, an SBOM may have been generated during the build, but where is it now, and where is the corresponding CVE report? SBOMs and CVE reports can also be difficult to manage and read. Both types of reports contain critical information buried in lines of raw data and stored in build directories across the DevOps Pipeline.
The introduction of service governance catalogs will be necessary to unify supply chain data and automate security policies removing the need for humans to perform this work. Service catalogs are particularly important in a microservice architecture where an update to a single service impacts multiple consuming applications.
SBOMs in a Cloud-Native Environment
In a cloud-native environment, SBOM data is spread across hundreds of independently deployed microservices. Creating an SBOM for a complete solution delivered to the end user can be difficult, if not impossible. Aggregating microservice SBOMs and CVE reports up to the application level is critical. Without it, application teams have no easy way to produce an application SBOM the same way they may have in traditional monolithic builds. Development teams try to track SBOM and CVE reports manually using spreadsheets. 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 associates that information to all the consuming applications continously.
How do Microservices Impact the Software Supply Chain?
In a microservices architecture, your software applications are composed of 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’ along with your application’s SBOM. Microservices can be written in various languages such as Java, C, .Net Framework, Go, or Python. Therefore, a microservice application may be composed of many microservices written in different languages, each with its exposure.
Every microservice is built independently and has its SBOM. A new SBOM is created each time the microservice is built. When a new version of a microservice 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?’
What Application Teams Need
In a microservice architecture, you will need a higher level of organization to track SBOMs and vulnerabilities at the application level. Application teams are ultimately responsible for the software system they deliver, even if it consumes microservices they did not create.
For this reason, application teams need to do the following to mitigate risk:
- A map of the microservice versions their application version consumes.
- SBOM aggregated data for each application version.
- A CVE scan for all application versions based on the SBOM aggregated data.
- An easy method of viewing the SBOM and CVE data of a microservice to determine potential exposure.
- A CD workflow that can aggregate the service level data up to their logical application – continuously.
Moving to microservices will require some tweaks in managing our DevOps pipelines. Tracking microservice 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 ‘global’ catalog that stores this level of data and performs the aggregation will be necessary to automate the process.
Top 4 Software Supply Chain Security Risks
To manage top software supply chain risks, you need a coordinated approach to address threats. Here are the top software supply chain security risks and how to mitigate them:
Lack of Provenance (no identity)
Critical to your software supply chain is knowing who is making changes and where they are coming from. This lack of identity allows an anonymous code ‘hack.’
Mitigating this risk:
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 your binary or release package.
Mitigating this risk:
To mitigate this software supply chain risk, repeatable builds across a build pool and minimizing scripted processes are needed. Check out the Solarwinds hack. Consider using a decentralized package network such as Pyrsia.
Guardrails can Prevent a Fast Response
Once a vulnerability is identified, the time from a developer update to release must be condensed. Tight control of your release schedule can become a problem if you need to address a known vulnerability.
Mitigating this risk:
Your release process should have emergency procedures to go around well-intended guardrails. For more on this, check out the Equifax hack.
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.
Mitigating this risk:
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 microservice catalog that provides governance around the software supply chain. It centralizes SBOM and CVE information for each microservice and aggregates this data to the application level. Unique to DeployHub is its integration into the CI/CD pipeline to continually monitor microservice updates, their ownership, SBOM, CVE, consumers, and inventory across the enterprise. DeployHub simplifies supply chain risk management in a cloud-native architecture by collecting supply chain intelligence in one place, including a listing of all open-source packages. A simple search based on the package name can show you who uses it and where it is deployed. This view can be seen from the microservice perspective, all applications, or all environments.
With microservices at scale, Developers, DevOps, and Security teams struggle to understand open-source dependencies and CVEs. DeployHub’s microservice catalog centralizes this level of information, making what’s hard about microservices easy.
