State of the Software Supply Chain Report 2017
•Download as PPTX, PDF•
1 like•193 views
Where Nuts and Bolts Meet Bits and Bytes (and Equifax)
Recommended
Recommended
More Related Content
Similar to State of the Software Supply Chain Report 2017
Similar to State of the Software Supply Chain Report 2017 (20)
Recently uploaded
Recently uploaded (20)
State of the Software Supply Chain Report 2017
- 1. 2017 State of the Software Supply ChainWhere Nuts and Bolts Meet Bits and Bytes (and Equifax) EVP and CMO, Sonatype @matthewjhoward Matt Howard
- 2. Detroit in 1982 • Building and shipping 4 million cars annually • Line workers had a quota of 15,000 cars a day • Incentives were focused on quantity, not quality • Any part would do – as long as it kept the line rolling
- 3. 3 Japan in 1982 • Incentives focused on total quality • Quality built in from the start – not inspected • Vehicles were 20% better than domestic competitors • Controlled 25% of the domestic market - up from 5% in 1962
- 4. 2. Use only the highest quality parts. 1. Source parts from fewer and better suppliers. 3. Continuously track the location of every part. How?
- 5. Just imagine making software the same way Toyota makes cars. Automated quality standards Automated inventory controls Built in Security Orderly recalls as requiredHigher quality and lower costs Five star safety
- 6. Just imagine how much simpler his life would be today.
- 7. Apache Struts Project: Popular open source framework with long and well documented history of securing, hardening, and maintaining the software that it produces. Struts Vulnerabilities: Last week, Struts team publicly disclosed two different remote exploit vulnerabilities. In both cases, fixes were released prior to disclosure. Equifax Disclosure: Separately, Equifax announced a massive breach between May and July 2017. The hack was discovered July 29 and disclosed Sept 7. Reports suggest a vulnerable version of Struts was exploited. Facts Matter: We do not know for certain what happened at Equifax. We do know that Struts has a tremendous track record for finding vulnerabilities and making fixes available in a timely manner. Responsibility: Organizations who leverage open source to accelerate innovation are themselves responsible for practicing software supply chain hygiene when vulnerabilities arise and fixes become available. Perspective: Equifax serves as a stark reminder that perimeter defenses by themselves are insufficient to protect critical data when in fact hackers are increasingly attacking open source vulnerabilities that exist in the application layer.
- 10. Utilizing billions of parts from open source communities... 80% to 90% of modern apps consist of assembled components.
- 12. Say Hello to Your Software Supply Chain… @weekstweets
- 13. 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 Supply is Exponential
- 16. NOT ALL PARTS ARE CREATED EQUAL @sonatype
- 17. 233 days MeanTTR 119 days MedianTTR 122,802 components with known vulnerabilities 19,445 15.8% fixed the vulnerability TIME TO REPAIR OSS COMPONENTS @weekstweets
- 19. 125,701 Java component downloads annually 7,428 5.8% with known vulnerabilities 7,500 ORGANIZATIONS ANALYZED @sonatype
- 20. DEFECT PERCENTAGES FOR JAVASCRIPT @weekstweets
- 21. 83% system calls in the native Docker runtime are open for attack.
- 22. 6-IN-10 HAVE OPEN SOURCE POLICIES @sonatype
- 23. TRUSTED SOFTWARE SUPPLY CHAINS
- 24. THE REWARDS ARE IMPRESSIVE 90% improvement in time to deploy 34,000 hours saved in 90 days 48% increase in application quality @weekstweets
Editor's Notes
- Here’s Chapter one. Anyone want to guess what this picture represents? It’s Detroit in 1982. Now, I know what you’re thinking. How in the hell is this relevant to modern software development? Well, let me share a few facts about Detroit in 1982:
- Here’s Chapter Two – anyone want to guess what this is? It’s Japan in 1982.
- Now sit back – close your eyes – and just imagine if you could build software applications the same way Toyota builds cars.
- Now sit back – close your eyes – and just imagine if you could build software applications the same way Toyota builds cars.
- Now, if you can imagine building software the same way that Toyota builds cars – then ask yourself this question… Are we already there?
- There's a tremendous productivity boost, but there's also risk, as you'll see in blind consumption practices. We'll get into that later. [00:07:00] In the report this year, we were able to do a deep dive on 3000 high performance software development organizations to understand what were those organizations consuming? How many components were they consuming? What are the quality of those components? Again, we're going to share that with you, and there's more detail shared in the report, so that you, as an organization can use some of this data to even benchmark your own performance or behavior as an organization. We also took a deep dive in looking at 25000 different applications, and to look at the components that were used within those, to get a sense of how components are used within applications, but again, what the quality metrics around those were. I'm going to share and reveal some of those findings with you today.
- Say hello to YOUR software supply chain, not “the software supply chain”; personalizing it more for the audience. For those of you that are unfamiliar with a software supply chain, it's really an allegate to the traditional supply chains used in manufacturing today. Those supply chains have suppliers that are building components. In the case of software development, that is the open-source [projects 00:07:53] that are building components, and making them freely available to developers around the world. [00:08:00] They're able to store and distribute those components in the large central warehouses, like the central repository that Sonatype is responsible for managing, but also repositories like rubygems.org, [pipi.org 00:08:16], thenugetgallery, etc. This is where the components are stored and available to the manufacturers, that are really the software development teams, that are consuming these components and downloading these components over the years. Those components are then used to create the finished goods, or the software applications, that organizations are then delivering to their customers. We'll continue to use this supply chain analogy for the software supply chain, then compare and contrast what's happening in traditional manufacturing, is to what's happening in software today.
- There's a really interesting site out there called moduleaccounts.com. It has a simple value, it keeps track of the number of different components, or packages that are available across the different development languages, from pipi, to nuget, to bower, to maven, components, etc. And it shows the increase in the number of these components that are available to the developer ecosystem, or the developer population, over time. We used some data from that site to see that over a thousand new open-source projects were created each day. People delivering a new kind of software, a new kind of component. Then, from the general population of all open-source projects worldwide, we were able to estimate that ten thousand new versions of components are introduced every day. There's this huge supply of components entering the ecosystem, and available to our software supply chains. When we look at the central repository that Sonatype manages, of maven style or java open-source components, we looked across 380 thousand open-source projects, and found that on average those projects were releasing fourteen new versions of their components every year. That's great from a supply chain aspect, that the suppliers are very active, actively releasing new software, actively releasing new innovations, and actively improving the software that they're making available to developers worldwide.
- Unfortunately, not all parts are equal... Some are healthy, some are not… …and all go bad over time (like milk, not like wine).
- [00:14:00] One of the things that we measured year over year, and we do do some year over year comparisons throughout the report, is that 6.2% of the downloads from the central repository last year out of the billions of downloads, had a known security vulnerability in them. This past year we saw 6.1% of the downloads had a known vulnerability. That's about one in sixteen of every component download has a known vulnerability in it.
- [00:14:00] One of the things that we measured year over year, and we do do some year over year comparisons throughout the report, is that 6.2% of the downloads from the central repository last year out of the billions of downloads, had a known security vulnerability in them. This past year we saw 6.1% of the downloads had a known vulnerability. That's about one in sixteen of every component download has a known vulnerability in it.
- The native Docker runtime has made significant improvements over the last year, including the ability to invoke out-of-the-box Seccomp (secure computing mode) profiles. These container profiles can disable 52 system calls by default. But you still have 313 system calls on x64 machines. Do the math; that leaves 261 system calls still open for attack
- [00:18:00] Part of those practices are how much hygiene are we building into our software supply chain? This year's report allowed us to get visibility from the downloads from the central warehouses, being 6% were known vulnerable, to components that were downloaded to repository managers. Imagine a local warehouse, if you will, for component parts used by developers. 5.6% of those downloads were known vulnerable. Then the finished goods, across the 25000 applications that we analyze, 6.8% of those components were known vulnerable. That means that the components that were downloaded ended up in the finished goods, or in the applications that are being shipped and shared with customers. Meaning, there's not enough vetting taking place from where we're sourcing components and bringing them into our organizations to what's ending up in the final products.