The scale and complexity of delivering a piece of enterprise software compares to the assembly and manufacturing of a 787 airplane (Figure 1) with its 2.3 million parts. An airplane manufacturer will source components from a multitude of suppliers. The manufacturer will ensure the quality of parts, adherence to regulatory controls and compatibility between all the dependent components. Whether building a plane or an enterprise software solution, you can mitigate risk for such mission-critical applications by taming this complexity. Disruption from a supplier or a flaw in a component can be catastrophic for your business and your customer.
Risky Business
There are various attack vectors that can pose a risk to your software project and ultimately lead to an attack on the supply chain. Sometimes the most innocuous of activities can present unwanted issues. Some supply chain attacks are indirect such as the 2018 Node.js EventStream attack [1]. More often, unpatched software is the root cause of supply chain insecurity. It’s critical to keep up with updates and patches. Synopsys, an Open Source Software (OSS) compliance tool vendor, recently surveyed some major software vendor’s codebases. The data reveals some quick simple steps that your development teams can take to secure their software supply chain. Specifically, 82% (Figure 2) of the studied codebases had components that were more than four years out of date. An even higher percentage of projects (88%) used components with no development activity within the past two years. Outdated, unpatched components make your application vulnerable to potentially hundreds of preventable attacks. Additionally, you want an active community around the components you use to benefit from on-going discovery and innovations.
Mitigating Risks in the Open Source Supply Chain
With a little bit of preparation and careful planning, you can limit the threats on the supply chain. By adhering to some simple tenets and automating some best practices you can secure the software supply chain of your application.
- Know all the components that comprise your application. This requires a reliable and repeatable method to inventory and report all components that will comprise your application—including binary artifacts.
- Know the origins of your components. You should know the source of every component in your application. Tracking the provenance of every component will allow you to reconstruct the application for supporting customers and legal forensic purposes. Pinned component versions (ideally mirrored internally), reproducible builds and signed artifacts are examples of mechanisms that promote component provenance.
- Manage your dependencies. This requires discovering your dependencies (including transitive dependencies) and understanding the risks of those dependencies, such as vulnerabilities and licensing restrictions. When a new security vulnerability is discovered with a component, one must determine whether the application is impacted and whether the severity necessitates immediate remediation action.
- Monitor the health of your supply chain. While your application is in service, flaws will be discovered in components of your applications. New components introduced in subsequent releases may introduce new problem dependencies or legal license compliance issues. Developer and community support of your component may cease. More secure and performant versions of components may become available. The aforementioned necessitate active maintenance and monitoring of your software supply chain.
In my next post, I’ll reveal how VMware is continuing to implement best practices in this area.
