Resources Blog [Part 3] Code, Cars, and Congress: A Time for Cyber Supply ...

[Part 3] Code, Cars, and Congress: A Time for Cyber Supply Chain Management

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.”

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 last year.

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!

Last year, 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. Those 11,236 organizations are using the Bouncy Castle crypto component because their application requires secure communications, and yet the versions they are using provide no protection from of their application’s data from an adversary. There is a flaw in their supply chain processes and the integrity of components they are selecting, that has gone unnoticed for five years. They are sourcing bad parts when safer versions are available. 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’s DBIR), 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.


Back to part 1.

(image credit:

Picture of Wayne Jackson

Written by Wayne Jackson

Wayne is the CEO of Sonatype, a role he has held since 2010. Prior to Sonatype, Wayne served as the CEO of open source network security pioneer Sourcefire, Inc. (NASDAQ:FIRE), which he guided from fledgling start-up through an IPO in March of 2007, later acquired by Cisco for $2.7 billion. Before Sourcefire, Wayne co-founded Riverbed Technologies, a wireless infrastructure company, and served as its CEO until the sale of the company for more than $1 billion in March of 2000.