Some sobering statistics about open source software components

 If you're looking for my pandemic posts, go here.

The software development tool company Sonatype publishes an annual “State of the Software Supply Chain” report, which you can download here. This year’s report had some interesting statistics about software components – i.e. snippets of either open source or third-party software that a supplier includes in their own code, including:

1.      90% of software components are open source, as opposed to being from commercial developers. I didn’t realize this percentage was so high.

2.      11% of open source software components included in software packages include at least one vulnerability.

3.      There are an average of 135 components in every piece of software. This was a good deal more than the figure from 2017 that I included in this post: 73.

4.      Some software products include between 2,000 and 4,000 open source components.

5.      A 2020 DevSecOps Community survey of 5,000 developers found that 21% had experienced an open source component-related breach in the past 12 months. This is down from 31% in 2018, but it’s obviously still very high.

The takeaway from this is that open source components are an important source of risk in software, including the software running on your BES Cyber Systems. What can you do about it? Can you simply not purchase any software from a supplier that includes open source components? I’m sure there are a few of those, but you’re suddenly going to greatly restrict the options available to you.

Obviously, if the average piece of software has 135 components and 90% of them (i.e. 121) are open source, you’re going to find few software packages to buy that have zero open source components. Using components in general saves a developer a huge amount of time – since otherwise they’d have to re-invent the wheel by writing those components themselves. And of course open source components save developers a lot of money vs. commercially available components (although my guess is there’s not a lot of overlap between the two. If you want specific functionality, you usually won’t be able to choose one or the other – it will be available in only one format or the other).

So if you can’t avoid this problem altogether, what can you do? You can do your best to make sure the supplier takes steps to mitigate risks due to open source components. I have identified ten risks that arise due to third party open source components in your supplier’s software. If you agree with me that these are serious risks, you need to ask your suppliers about this type of risk in your questionnaires. For example, a question based on item 2 is “Upon downloading an open source component, do you scan it for vulnerabilities before incorporating it in your product? And if you find a vulnerability, do you patch or otherwise mitigate it before you incorporate the component?”

And here’s another question: “Will you furnish a software bill of materials for your product, and will you update it as the product is revised?” 

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.

Are you wondering if you’ve forgotten something for the 10/1 deadline for CIP-013 compliance? This post describes three important tasks you need to make sure you address. I’ll be glad to discuss this with you as well – just email me and we’ll set up a time to talk.