Hi, I'm Matthew Clark. This is less than 5.6 i o t. Bill of materials, part one. In this lesson, we're gonna identify software statistics. We're gonna take a look at the software build materials, will introduce software supply chain and also introduced software licensing.
Let's take a look at the 2019 suna type state of software supply chain report. I have no idea why all these reports seem to have such incredibly long names, but they do.
This report found that there had been a 71% increase and the number of open source related breaches over the last five years. This report took a look at organizations that attempted to manage their supply chains and ones that did not manage it all.
And it found that in the manage supply chains that 9.3% of the time component releases were vulnerable within the applications versus those that did nothing about their supply chain. They found that 20.7% of the time component releases were vulnerable. The report found something else that was really chilling.
It found that 59% of components
used in software have had at least one non up to date or known vulnerability dependency at the time of the release. Thes statistics really underscore how difficult it is. Toe have a properly managed vulnerability program.
I think that these numbers are revealing. So let's take a look at the Equifax breaches. A quick example. Most of us are aware of the Equifax breach and if not Google it because it's an amazing story.
The company was breached because of vulnerable version of Apache struts that was not patched.
And since this was one of the largest breaches of all times, and Congress even held hearings over it, you would think that most organizations would know not to use that version of struts. Or at least someone in management would have asked the question, Hey, are we covered from whatever happened in Equifax and us? So you think that people would know better? But,
ah, year after the breach occurred,
monthly downloads of that vulnerable version of Apache struts had actually increased by 11%. I think that that story and that statistic really underscores how difficult it is for organizations to properly perform vulnerability management,
and we're gonna talk about some of the tools and techniques that organizations can use to address these issues,
especially in the i o T sector, where we're developing code and reusing other people's codas. Well, so let's talk about software building materials. I saw a statistic at one point that estimated that nearly 80 to 90% of an application
may consist of code written or influenced by someone else. I don't know if that's true. That seems like a pretty large
and I'm not a programmer. But I once did have programmers. They're reported to me, and I remember sitting down and doing a annual review with one and where he let me in with his secret. He said that the best programmers never write their own code, So why reinvent the wheel when you could just copy what someone else has done?
And I thought that was a really interesting comment, and you're kind of stuck with me.
Eso. Let's just say that even 30 or 40% of an application is someone else's code. Well, how do you keep up with that over time?
Well, that's where software build materials comes in,
and a software bill Materials is a list of all the open source and third party components present and a code base. And this could be done manually, which could be very, very difficult to do, depending on that code based how big it is. And, of course, their commercial software solutions that will try to do this for you.
But generically, a software bill material listing such as the versions, the licensing that govern those components, modules and components used in the code base, the patch status, any back ports that may exist,
and you may not be familiar with the backcourt. We'll use that term a few times. But a backcourt is the process of updating someone else's software module when the owner of the module doesn't provide a patch for the version that you're using. So the Wikipedia definition is basically the action of taking parts from a newer version of a software system,
our component, and porting them over to a new, older version of the same software.
so let's use our real life example to try to make this a little bit mawr understandable.
Think about a software building materials as a list of ingredients on the back of a box of crackers. For example, my daughter has a peanut allergy that so severe that if she consumes even the smallest trace of a peanut that her body will react violently, go into an if lactic shock, and she'll eventually die
Now. I never knew this before, but they're peanuts everywhere in this world. Even if the food doesn't have peanuts at listed as an ingredient, it can still be contaminated from other foods prepared in a factory,
whole foods or not even immune from this. When my daughter was little, we served her frozen green beans. Just nothing else. Just whole uncut, frozen green beans. And she had a major reaction
well later looked at the package, and we found, Ah, label. That said, this product may have been processed in a facility that also processes peanuts.
Um, and this is on the back of a bag of frozen green beans, of all things. So we learned early on toe, always read those lists of ingredients on every food item that we purchase and consume.
When we go out to eat somewhere, we have to see asked to see the labels on the products on the red that the restaurant uses because most people just don't understand that just because peanuts aren't actually physically in a dish that the food ingredients haven't been contaminated by the peanut protein in some way.
And for my daughter, who's allergy is so severe, it's literally a matter of life and death for her.
And, you know, it could be, in some ways considered almost that same way for your business.
If you really don't know what's inside your code base and what what's inside that quote unquote list of ingredients. You don't know what you're dealing with.
So let's take a peek inside the Apache two server code.
I ran the command listed above, and it's a long command toe list. All the first level dependencies for Apache two. It's hard to believe that there's so many different dependencies, and they're all part of this one program.
Now. Keeping Apache two of to date is rather straightforward, at least in the desktop distribution, like a bun, too.
But imagine all the other software that is used, particularly in the i. O. T. Development environment. How do we get all of this? Updated when vulnerabilities, air discovered
and in walks, our old friend Mr Supply chain he keeps showing up almost in every lesson, kind of like that old college buddy that comes over and sleeps on your couch and drinks your milk straight out of the carton and uses your wife's toothbrush. Because it would just be weird if he used yours
until that faithful day, when he acts, surprised that your wife makes you choose him over her or her over him.
So he moves out of your hall closet and purchases the house next door. Not that that's ever happened to me personally. So let's talk about licenses free can still have string that's attached. The OM needs to ensure that software developers have a clear understanding of the licenses that they're using
in the ramification of those license types,
because nothing is truly free, you may not have to pay much for the software upfront, but you do have to factor in costs like development costs and ongoing maintenance. And don't forget features because you get what you pay for. Commercial software may already be tested and loaded with usable features,
but free software may only have a basic framework in place
and in oh, am has to know their sources as well as it management is something that many enterprise risk organizations are struggling with. So why would it be any different for I o T product development
and few procurement departments, or even looking at open source software in their contracts
and maintenance? Don't forget maintenance. Ongoing costs can be expensive. You still have to manage security updates and patches, whether from a commercial product or Emanuel creation. There are three basic types of licenses that we're gonna talk about. Copyright, public domain and open source
copyright. It's the most restrictive license type where all rights reserved.
So it restricts the right to use, modify or share creative works without permission.
Public domain is the most permissive license type. You can basically do whatever you want. It's just important to realize that code snippet you find on the Internet are not automatically in the public domain.
Open source is kind of the middle ground between copyright and public domain, and there's two types of open source licenses will talk about permissive and copy. Left
Permissive has minimal requirements on how the software could be modified or redistributed. And so it's really the most popular license. Cite an example. This include BSD m. I T or patchy. Two licenses.
Copy left. This is a restrictive license. It allows you to modify the code and distribute new works based off that code as long as your new work falls into the same license. For example, if the licenses for personal use and you modify the code and release it, then your final work has to be for personal use. Only
examples of this include GPL or L G P l and the Brazil public license.
Well, that's it for this lesson. So what do we cover? Well, we took a brief trip into the mysterious world of software bill materials, and we also took a peek inside Apache two.
We reviewed software supply chain and we discussed the software license types. I'll see you next time.