Part 3 of 3 in our Blog Series.
Part 3: Where the Rubber Hits the Road – Bad Parts Make for Bad Software
In part two of my blog 'A Closer Look at Today's Software Supply Chain', I discussed why human-speed supply chain management can’t keep pace with today’s agile software development practices and why high quality software components are not simply a given. In this final segment, I will share a real world story on how thousands of organizations sourced one “bad part” named Bouncy Castle in 2013.
Vulnerable Applications are the Hacker’s New Attack Vector
It is widely held that the transparent nature of open source makes for better, more secure software over time (a principle with which I agree). The more eyes and hands that have engaged in the community efforts, the more that community has delivered innovations and updates. The average open source component is updated four or five times per year. At the same time, community involvement has also led to the identification of countless security vulnerabilities and other defects within components, and where possible, the delivery of new versions of those components – making for more trustworthy software all around.
But those new releases do nothing to help those still using ‘parts’ that are out of date or applications that are nearly (or are) un-maintainable. A new release does not initiate a recall of all past, vulnerable components that are being used in software development organizations today. There are no community–wide protocols or policies to prevent developers from downloading components with known, publicized vulnerabilities from shared repositories.
And what about the components already released into production applications? That is where the rubber meets the road. Where the hackers can cause real trouble. Unfortunately most organizations struggle to keep an accurate inventory of their components – including the 10’s or 100’s of component dependencies – in each application. So when a new vulnerability is announced, and resolved in a new component release, they don’t even know if they are impacted.
They’re Using Bouncy Castle – And That’s Not Good
Let me provide a real example of this behavior impacting the software supply chain. In March of 2009, a severe vulnerability (CVSS Score: 10) was disclosed in an open source component named Bouncy Castle used for encryption and decryption that can lead to complete loss of system protection, with very little knowledge or skill required to exploit it. Ouch!
In 2013, that same Bouncy Castle open source component continued to be downloaded. According to Sonatype statistics gathered from the Central Repository, since March 2009 11,236 organizations have downloaded Bouncy Castle 214,484 times. This is still happening five years after the vulnerability was disclosed. Double ouch!
The weaknesses in communications, policies, and practices in today’s software supply chain are quite visible to those who would seek to exploit our vulnerabilities. According to multiple research reports and publications in 2013/14 (e.g., Cisco, Cenzic, Verizon), web applications are now the number one hacking exploit vector.
So, how should we in the software development community be thinking about leveraging Mr. Toyoda’s supply chain innovations?
The good news in all of this is that applying these principles to software development is really pretty simple, boiling down to four words – awareness, empowerment, governance, and monitoring. Applying those principles with the goal of continuous optimization will make for a much better software world and the kind of efficiencies that Toyota enjoys to this day.
More than ever, it is important to develop trusted software applications and for us to keep them that way over time.
---
