An Insider's View: Analyzing Software Supply Chains

July 12, 2016 By Samantha Mayhew

6 minute read time

I recently sat down for a spell with Bruce Mayhew, Director of Research and Development at Sonatype and co-author/project lead for OWASP WebGoat, to discuss his perspectives on the data revealed in this year's 2016 State of the Software Supply Chain Report. Here, he not only speaks about why the data within the report is so incredibly compelling, but also about how his team's research has come together in a way that surprises him, and might surprise you.


Bruce: My name is Bruce Mayhew. I run the data pipeline at Sonatype. The data pipeline is the system that collects component intelligence on all of the open source components (e.g, Java, JavaScript, NuGet, npm, etc.). We perform the security, license and other research on components to determine the hygiene attributes about how good a component or a project is. There is a lot of processing to collect data from all the different open source repositories out there and basically run it through a whole bunch of different algorithms to derive intelligence about the open source components.

 

Screen_Shot_2016-07-06_at_7.25.55_PM.pngListen to the full interview with Bruce Mayhew here.


Samantha: 
Given your role in the company, was there anything in the software supply chain report that surprised you?

Bruce: Lots of things surprised me in the report. One of the first ones that surprised me was the staggering growth and consumption of open source software and how prevalent open source components are in modern-day applications. Another thing that surprised me was the lack of visibility and control that security, legal, and architecture teams have over their consumption of open source components. I think the last thing that surprised me were that some of the public open source repositories are mutable in that they allow changing of the bits for a specifically versioned and published component, or that they allow the removal of published artifacts. Those were the three big surprises for me.

 
________________________________
“Another thing that surprised me was the
lack 
of visibility and control that security,
legal, and 
architecture teams have over
their consumption 
of open source.”
________________________________
 

Samantha: 
Why do you think the information in the report is relevant to the people that build the software that's running the world today?
 
 
Bruce: Open source components are everywhere, across all languages. Ecosystems that house open source components sometimes have very little control over the software within their own repositories. If you were building a swing-set for your kids, would you want the generic bolts from the Dollar Store or would you want a higher grade bolt from the hardware store?


It's hard to say which one's better without knowing some basic quality facts like sheer strength, or will they rust apart after two years? This is the type of information that we all need about our software components and today people just don't have it. I think people have to come to grips that open source is good for software development. It helps us be more innovative in what we build because we don't have to reinvent the wheel with every single application that we build. As our applications become more complex and our choices become more vast, we need to get in front of helping developers and enterprises make better decisions on the risk of what is being used. This report clearly articulates the scope of consumption, the tooling used to help consume open source, and that there is risk in blind consumption of these components.

________________________________
“As our applications become more complex 
and our choices become more vast, we need
to get in front of helping developers and
enterprises make better decisions on the risk
of what is being used.
________________________________

 

Samantha: What else would you like have like to seen in the report and why?


Bruce:
 I think the report does a good job comparing software manufacturing to software supply chain management. It does a fantastic job at making you understand the vastness of the problem that we have today and the lack of visibility and control that we really do have inside our software supply chains.

What are some of the things that I would have liked to have seen but I understand that in the context of the report they're probably not applicable? I would have liked to seen a deeper dive into how an enterprise can implement or adopt the Deming principles. How does one pick fewer and better suppliers? How do I integrate picking those components and suppliers into the way that I build software? I would have liked to have seen a breakdown of more of the attributes that make-up good and bad components, projects and/or repositories. But these are all probably outside the scope of this particular document. 

________________________________
“[The report] does a fantastic job at making
you understand the vastness of the problem
that we have today and the lack of visibility
and control that we really do have inside the
software supply chain." 
________________________________


Samantha: Excellent. Thank you, Bruce.


If you enjoy this interview and want to dive into the 2016 State of the Software Supply Chain Report yourself, the full report is available here.

Screen_Shot_2016-07-06_at_7.49.02_PM.png

 

 

 

 

`

Tags: Known Vulnerabilities, Software Supply Chain, open source governance, Application Security, Devops, DevOpsSec

Written by Samantha Mayhew