Lessons learned from Detroit to Deming by Derek Weeks

Editor's Notes

• #3: Its Detroit. 1982 The city was building 4 million cars annually. Line workers had a quota of 15,000 cars a day. Their incentives were focused on quantity, not quality. If they didn’t have the right bumper assembly, they would put it on the car, and push it toward the finish line. Quality of Japanese cars was 20% better US Manufacturers were operating at 50% capacity. 17 million autoworkers in the US. It never improved. Today 11 million. 20% of US GDP was manufacturing, today is is 10%. High was 30%. The auto industry was operating at 50% capacity. By the end of the 1970s, the Japanese automakers dominated the domestic producers in product quality ratings for every auto market segment, representing a formidable competitive advantage In 1962, import brands were 5% of the market and in 1982 were 25% Quality and defects were 20% higher than Japanese cars The Japanese would take 8% of the US automarket over the next 8 years. 70% of all small cars sold in the West (CA) were Japanese.
• #4: “Cease dependence on mass inspection.” Inspection does not improve quality. Nor guarantee quality. Inspection is too late. Harold F. Dodge: “You cannot inspect quality into a product” Automatic inspection and recording require constant vigil.
• #5: “Cease dependence on mass inspection.” Inspection does not improve quality. Nor guarantee quality. Inspection is too late. Harold F. Dodge: “You cannot inspect quality into a product” Automatic inspection and recording require constant vigil.
• #7: 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.
• #8: 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.  
• #13: Unfortunately, not all parts are equal... Some are healthy, some are not… …and all go bad over time (like milk, not like wine).
• #16: [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.
• #18: [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.
• #19: 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
• #20: 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
• #22: [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.
• #24: Unsafe at Any Speed: The Designed-In Dangers of the American Automobile by Ralph Nader, published in 1965, is a book accusing car manufacturers of resistance to the introduction of safety features such as seat belts, and their general reluctance to spend money on improving safety. It was a pioneering work containing substantial references and material from industry insiders. It was a best seller in non-fiction in 1966. Inspection does not improve quality. Nor guarantee quality. Inspection is too late. Harold F. Dodge: “You cannot inspect quality into a product” Automatic inspection and recording require constant vigil.
• #25: If you are passing defects downstream, you are ultimately liable. Which side of history will you be on?
• #26: “Cease dependence on mass inspection.” Inspection does not improve quality. Nor guarantee quality. Inspection is too late. Harold F. Dodge: “You cannot inspect quality into a product” Automatic inspection and recording require constant vigil.