Software Supply Chain Risks: Intro Guide
Software supply chain risks are associated with the use of open-source software. Your overall global supply chain includes open-source objects and your internal reusable components. Software Supply Chain Management refers to understanding your cybersecurity risks when using open-source tools and dependencies across your digital landscape.
At the core, the purpose of this Software Supply Chain Management is to have a clear view of all open-source objects that your organization is using so you can easily know and 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. After all, even Microsoft .Net framework is open-source. According to the Linux Foundation’s “Software Bill of Materials (SBOM) and Cybersecurity Readiness” report, over 98% of their study’s sample reported using open-source software.
- What’s a Software Supply Chain (and Why Does it Matter)?
- What is Software Supply Chain Management?
- What’s the Purpose of Supply Chain Management Software?
- How do Microservices Impact the Software Supply Chain?
- Top 4 Software Supply Chain Security Risks
- Mitigating Software Supply Chain Risks
What’s a Software Supply Chain (and Why Does it Matter)?
Your organization’s software supply chain 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 Management?
Software supply chain 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 all of your software dependencies allowing you to define proper policies and practices to address all security threats. Supply chain management addresses the lowest level of security risk, which is 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.
- All Packages
- Secured References
- Declared Licenses
- Discovered Licenses
- Microservice License
- License Header or Full License Text
Once you know your low-level package dependencies, you can then scan them to determine your Common Vulnerabilities and Exposures (CVEs). Adding this process to your CI/CD practice hardens your cybersecurity and allows you the knowledge needed to determine proper mitigation policies and procedures.
What’s the Purpose of Supply Chain Management Software?
Supply chain 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.
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.
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.
Aggregation of Microservice SBOMs
Aggregation of microservice SBOMs and CVE reports up to the application level is critical. Without it, application teams have no insight into their complete supply chain. SBOM and CVE reporting, as well as knowing the providence and origin of the software, cannot be managed manually. 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.
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 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 many different 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 their exposure.
Every microservice is built independently and has its own 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 that 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 how we manage 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.
Service Catalog in the CD Pipeline
Top 4 Software Supply Chain Security Risks
To manage top 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 Providence (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 mitigate 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 security risk, repeatable builds across a build pool and minimizing scripted processes are needed. Check out the Solarwinds 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
Guardrails can prevent 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 ways to go around well-intended guardrail procedures. For more on this, check out the Equifax hack.
Mitigate 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 up to the application level. Unique to DeployHub is its methods of versioning microservice updates and automatically creating new versions of the ‘logical’ application based on the microservice changes.
DeployHub integrates into the CI/CD pipeline to continually monitor microservice updates, their ownership, SBOM, CVE, consumers, and inventory across the enterprise. DeployHub simplifies cloud-native architecture by governing your microservice supply chain in one place.
With microservices at scale, Developers, DevOps, and Security teams struggle to understand dependencies, SBOMS, vulnerabilities, impact, and microservice ownership. They grapple with microservice versions drifting across clusters, or the sprawl of redundant services.
DeployHub’s microservice catalog centralizes this level of information making what’s hard about microservices easy.
DeployHub Key Features
- Microservice Catalog – Explored
- Aggregated Application Level Software Bill of Material
- Microservice Version Management
- Simplifying Microservice “Logical” Applications
- Domain-Driven Design for Microservices
- Ship Microservices Safely – Know Your Blast Radius
- Improve Your Incident Response – Microservice Ownership
- DeployHub Microservice Dashboard