On December 4th, 2014, U.S. Congressional Representatives Ed Royce (R-CA) and Lynn Jenkins (R-KS) introduced H.R. 5793, the "Cyber Supply Chain Management and Transparency Act of 2014." The legislation will ensure all contractors of software, firmware or products to the federal government provide the procuring agency with a bill of materials of all third party and open source components used, and demonstrate that those component versions have no known vulnerabilities.
"As a house is only as strong as its foundation, it's no wonder cyber attacks are on the rise with reports showing 71 percent of software contains components with critical vulnerabilities," said Rep. Royce in a press release from his office. "This bill protects our nation's cyber infrastructure by ensuring the building blocks that make it up are secure and uncompromised.”
In light of this new legislation, I thought it would be worthwhile to revisit a set of discussions I started earlier this year focused on changes in software development, the prolific use of open source components today, and our need to embrace software supply chain management principles.
Part 1: It’s Just the Way Software is Made
Today software runs the things that run our world. In fact, I’m starting to see the pundits talk not just about securing and protecting our applications, but about embracing software supply chain management. With software so deeply embedded in every aspect of our lives, the companies running the software are accountable for protecting the consumers using it. In fact, it is just a matter of time before software liability becomes a reality (but that is a topic for another day).
Just like automobile manufacturers, software “manufacturers” need to apply supply chain management principles for both efficiency and quality. They need to be prepared to conduct a rapid and comprehensive “recall” when a defect is found. And today’s modern development practices make this, well, challenging to say the least.
As U.S. Representatives Ed Royce (R-CA) introduced the Cyber Supply Chain Management and Transparency Act of 2014 last week, he stated, “It is precisely because of the importance of open source components to modern software development, that we need to ensure integrity in the open source supply chain, so vulnerabilities are not populated throughout the hundreds of thousands of software applications that use open source components.”
Bear with me a moment, as I take you through a quick history of Toyota’s supply chain innovations … then I promise to bring this back to your own software supply chain.
Toyota Transforms and Outperforms (Laying Agile Foundations)
In 1926, Sakichi Toyoda founded Toyoda Automatic Loom Works. From the start, he obsessed over efficiency and automation. He invented and ran the most advanced looms in the world – delivering dramatic improvements in quality and a 20-fold increase in productivity. Perfection and efficiency were so ingrained in his production processes, his looms stopped automatically whenever a thread broke, for example.
When Sakichi’s son, Kiichiro, decided to move from textiles to auto manufacturing, the apple did not fall far from the tree. Kiichiro set about optimizing everything conceivable in the production of automobiles. His production innovations, eventually called the Toyota Production System (TPS), gave rise to Lean Manufacturing and Supply Chain Management principles.
Today, the effect of these principles on Toyota’s efficiency is remarkable. Company-wide, Toyota has a total of 226 suppliers while GM has more than 5,000. Toyota produces only 27% of the content of their vehicles while GM produces more than 54% of theirs. That means GM has twenty times the suppliers but still produces twice as much of their vehicles. The result? A Chevy Volt sells for nearly double the price of the Toyota Prius while the Prius outsells the Volt nearly fifteen to one.
The First Wave: Toyota’s Principles Drive the Innovations in Agile
Toyota’s principles not only improved auto manufacturing, but also extended to many other industries including software development. As early as 2000, Fujitsu Software Technologies -- desperate to improve productivity and overcome IT budget deflation in the post-bubble economy -- decided to experiment with applying TPS Lean Manufacturing to software development. This effort led to a wave of innovation in agile software development. A success that, in hindsight, is not at all surprising.
The Second Wave: Agile Meets Component-Based Development
Where Agile methods were based on iterative and incremental development (embracing Toyota’s lean manufacturing principles), Fujitsu did not do a whole lot with Toyota’s supply chain management innovations (sourcing reliable and thoroughly tested “parts” that serve your people and processes). This is where another transformational change in the software development ecosystem is just beginning to come into play: the use of open source and the embrace of component-based software development. That is, where agile software development must meet supply chain management.
Today, 90% of a typical application is composed of open source and third party components. The open source community is the dominant supplier of software building blocks, the components they develop feeding virtually all software development “supply chains”. These components are sourced within the software supply chain by development organizations, usually from public repositories.
To give you a sense of the scale of operations in today’s software ‘manufacturing’ supply chains, the largest source of Java components known as the “Central Repository” clocked in 13 billion downloads last year alone – more than 35 million components every day (and that dramatically understates real usage because more than a quarter of the download requests came from local component repositories -- such as Nexus – that are in turn accessed by teams of developers locally).
Today’s reality: software assembly (together with agile) is just the way software is made.
In the next part of this blog series, we’ll take a drive down the software supply chain to help you understand where your software has really come from. As we continue the conversation, we will also discuss the implications of cyber supply chain management and transparency related to protecting your applications from attacks leading to breaches.
You can find Part 2 of Wayne's blog series here.
(image credit: http://bit.ly/1wFt6qW, http://bit.ly/1vUvGq8)