In This Lesson:
Do those words sound familiar? Software developers are being asked to release faster than ever, which means you need to find ways to work more efficiently and automate wherever possible. As you know, using open source components can be a huge part of your constantly accelerating development process, helping to prevent you from “reinventing the wheel” when known components are already available for certain functionality you need to use.
In fact, upwards of 80-90% of a modern application is comprised of components—most of which are OSS.
Say Hello To Software Supply Chain
A software supply chain is very similar to the traditional supply chains used in manufacturing today.
Suppliers = OSS
Traditional manufacturing-based supply chains have trusted suppliers who build components used in the final assembly of the finished product. In the case of a software supply chain, open source projects supply some of the most common components to be used in the application being developed.
Warehouses = Component Repositories
Traditional supply chains have also streamlined logistics and sourcing by using large, centralized warehouses to store and distribute those components with more security and efficiency. Similarly, software developers now often rely on component repositories like the Central repository that Sonatype manages (Java), rubygems.org, pypi.org, the npm registry, and the NuGet Gallery.
Manufacturers = Software Development Teams
To continue the metaphor, manufacturers are analogous to you, the software development teams that are sourcing and consuming open sources components used as building blocks in your applications.
Assembled Product = Software Applications
Finally, the assembled and validated product in a traditional supply chain are comparable to the tested final builds of software applications that you make publicly available to your customers.
How is Building Software Like Building Cars?
Let’s look at the automotive industry as an example. Toyota has a limited set of trusted suppliers in their supply chain. They know exactly where their parts are coming from, who created them, and what cars they are going into. Because of that knowledge, they can trace any defects or safety issues that arise back to the source.
But what if this well-established manufacturing process were more like the current state of software development? Just imagine if Toyota assembly line workers could pick whichever brake rotor they felt like, or the transmission that they were most familiar with. Toyota would have no idea which cars had been installed with a faulty brake line, where the cars were distributed, or ultimately who purchased the car at risk—leaving them with no recall capability.
But that’s basically the state of how we are managing—or, rather, not managing— modern software development.
For example, how easy would you say it is to answer the following questions for the current application your team is developing?
Who originally downloaded OSS components currently in use?
Who authorized those component for use?
Where within the application are the component being used?
In your current development process, you might not be able to answer these questions easily. You’re not alone. Fortunately, we don’t have to invent a new solution, we just need to enforce the solutions other industries are already using, and we can do this by using Nexus IQ.
State of the Software Supply Chain
In the latest State of the Software Supply Chain report published by Sonatype, based on our visibility into the downloads from the central warehouses, we found that 12.1% of component downloads which were known to be vulnerable were downloaded.
Furthermore, components downloaded to a repository—which is supposed to be a trusted “warehouse” for components—were shown to be vulnerable even more often, with 12.9% of those downloads known to be vulnerable. That’s scary stuff.
As you can see, there is a slight drop in the percentage of vulnerable components that actually make their way into the released software in “unmanaged” software supply chains—11.7%—which means developers are sometimes able to catch the issues before they find their way out into the wild.
But as you can also see from the graphic, that percentage of vulnerable components found in released applications drops dramatically when software supply chains are being managed—less than half of the vulnerable components originally downloaded ultimately made it into the application—6.1%. That’s a significant amount of risk reduction that will only continue to be reduced over time as managed supply chains mature.
What is the Problem?
Today’s development ecosystem is very complicated because of all those components out there. One component (with a direct dependency) that you use might introduce dozens or hundreds more dependencies that you and other developers might not even know are there. These are known as transitive dependencies.
And, this isn’t just a developer problem. Looking at the chart below, you can see that the number of OSS projects coming to market every day is sharply increasing each year. At scale, the task of researching each and every component that is brought into your application isn’t feasible. That’s why Sonatype has developed tools to automate this process, and help equip you with the component data needed to make informed choices. The value delivered by Sonatype tools is underpinned by years of data accumulation and curated from various sources by our Data Services Team. We understand the “release faster” mandate of most software development organizations, and the real problem is with the immature software supply chain processes in our industry, not with negligent developers. To ease the burden of this overwhelming undertaking, we’re helping you build security into your development process.
1,096 new projects per day
10,000 new versions per day
14x releases per year
3M npm components
2M Java components
900K NuGet components
870K PyPI components
Strengthening the Software Supply Chain
There are many challenges to solve in order to create and maintain a healthy software supply chain, including issues with visibility, component selection, and remediation. Nexus IQ enables you to close the gap on all of these issues.
Often times, even though you are alerted to issues with components, there is little to no visibility into specific details of those components and related issues. It’s not easy to know what components are being used, where they are being deployed, and where there is risk. Common Vulnerabilities and Exposures (CVEs) are often very difficult to map to a specific version of a component, for example. This results in confusion regarding what action to take to resolve those security risks. There may be no easy way to decide how to fix the problem. Nexus IQ provides this level of detail.
One of Sonatype’s customers, Salesforce, used Nexus IQ to reduce security reviews of open source and third-party libraries from 25 days to 5 minutes! Check out the video Securing Your Software Supply Chain, presented by Mary Lee, Director – Security Product and Program Management, Salesforce.
Activity - Test Your Knowledge
How is the software supply chain analogous to a traditional manufacturing supply chain? Select all that apply.
Open source components should be exempt from software supply chain processes.
Open source components are the “parts” available from software supplier “warehouses” such as the Central Repository.
Software Developers serve as manufacturers, increasingly using open source components in addition to writing proprietary code to release finished applications faster.
2. Open source components downloaded from popular online repositories (i.e., Maven Central, npm registry) are less likely to contain vulnerabilities than open source components downloaded from other locations.
3. How would the typical software development process need to change in most organizations to be more like the automotive industry?
A software development organization would assign developers extra responsibility of researching and approving OSS components themselves before using them in their applications.
A software development organization would make use of the supply chain principles used by other organizations and implement processes and tools around them to assist developers in knowing what OSS components can be used in their applications.
Check boxes b. and c.