Steve Hendrick – Worldwide Software Bill of Materials (SBOM) and Cybersecurity Readiness

This is texturing TV. Okay. Thanks guys for being here.

So how many how many you have familiarity with us bombs? Just so I get a sense of okay. All right, that's bombs.

Okay, good good. All right, so so that's good. So I I arrived at the Linux Foundation.

I've been analyst for 30 years primarily with IDC. And then I arrived at the next Foundation a year ago to do run their research group together with Hillary Carter. So in my expertise is in doing quantitative research.

So this is a survey I'm going to show you today, but I'm gonna put it in some context first because The s-bomb issue is is just part of the storyline that we need to deal with when it comes to secure software development. So anyway, you're going to you're gonna get one small view of the world here about s-bombs and then I've got another survey that I've already read up and I'll be talking about that starting in June and that's more than development side of the equation. This is all about, you know, components and dependencies and vulnerabilities.

So, okay. So I like this idea of multi-agent systems. It's not a term.

I actually had heard very much. I had done dealt with complex adaptive systems back in my IDC days, but I think when it comes to systems that have lots of components that have to work together and you've got some diagrams here of what I what I mean. There are a number of important things that you have to remember the first is that open source is pretty much everywhere from a software perspective.

We're talking about 98% of companies use open source. Actually. I think it's 99% So it's it's pretty pervasive.

Microservices the sort of the approach that we use nowadays for doing software development. When you do microservices, it's really easy to use open source components because they're everywhere and there's lots of them and then you have to begin to worry about dependencies and you have of course direct dependencies you have transitive ones which are dependencies of dependencies. That components sprawl that's kind of the bane of the existence of doing dealing with microservices.

But the thing that hasn't really been addressed very well is the prominence of the different components that you end up using. You need to have knowledge of what the component is all about. And we need to have sort of extensive metadata so that you understand what the component is.

You have to make sure that you can use it and usability comes down to license compliance. And then you have to have trust in what the information is about the component so that you feel good about using it and you know what it is what it isn't and how much of this how much of security risk it can represent to you. So So those are the challenges that exist today?

The salsa framework that's pronounced salsa, but it's slsa salsa dot div is where you can get more information about it. And if you haven't been there, I suggest you go take a look at the salsa framework. And as you can see it talks about threats and it talks about the sort of the standard software development process and where threats creep into this process.

So this is part of the context for what my talk today is all about as you can see here. There's really two different concerns that you have from a security standpoint. You have a concern about secured development and you have a concern about knowledge and secure componentry to be used as part of your development activities.

As I said, that's probably more pressing from the standpoint of Open Source than it is from a closed Source standpoint, but it's the same time. We don't always necessarily know too much from a closed Source standpoint about you know, what the vendor Community is doing into what extent they have are using open source and how they have addressed security. So there's lots that's unknown at this point and this whole business of software bill of materials is a way to finally put it into the problems that we have there.

so I took that same diagram and made it largely not nearly as pretty but I did that because I wanted to talk about the role of s-bombs. So organizations will consume us bombs and they'll be producing us bombs. You're going to consume it.

If there are component tree that you want to use in your application development activities. So you need to know about those components to be able to make risk management decisions about what you want to use and what you want to build or what you want to buy and then from the standpoint of production. If you are a supplier to someone that is going to be using your components and your applications.

They're going to want to know exactly what's inside of them. Just like you want to know from your suppliers. What's inside of software that you're getting from them.

So everyone's going to need to produce this bombs and pretty much everyone's going to want to consume us bombs at the same time. Now when I think about s-bombs and I these words knowledge usability and Trust I mentioned in my second slide. I think those really kind of sum it up on the left side of the screen here.

You've got sort of selected fields that you find in s bombs s-bombs can pack a lot of information and they're only required to give you information about direct dependencies. But if everyone does that then you're never going to have a problem but realistically from the standpoint of who's producing us bombs right now. It's somewhat prop.

It's probably somewhat more limited than you think the survey data are going to see in just a few moments is going to show a much Rosier picture of it. And because this survey came right after the executive order back on May 18th of last year from the White House saying Federal government's not going to do business with you in the near future. If you don't provide us bombs if you're going to be providing software.

So the key to an s-bomb, I guess first starts with knowledge because it provides it should provide all of the important metadata to help you understand what the component is all about and what the component will do for you and that will include usability information so that you'll be able to look for look check for license compliance. So you don't have legal risk and it will include information and ways to demonstrate that you can trust the component itself. So cryptographic signatures that are non-faultsifiable, you know Sig stories an example of Open Source technology that addresses that very effectively hashtotals and the ability to reproducible builds and and understand what vulnerabilities have been fixed in the component or for any component is really key because then you Go out to one of the national databases that either provided by the government or by a vendor community and check to see if the current list of vulnerabilities is more extensive than the fixed vulnerabilities for the components that you're using pretty key activity.

So, so anyway, so it all does come down to knowledge usability and Trust at the end of the day. Now so I did a survey. That had quite a few questions.

It was a long survey for the poor guys that answered it sample size ended up being 412 really good completes. I did data collection back in Q2 Q3 of last year and the report came out the very beginning at q1 of this year. And if you want to look at the report, it's free.

It's on Linux Foundation. org website. If you just put s bomb into the selection criteria this the search bar, you'll find links to the report and some are and there's there's one Lake out there that doesn't require that you identify who you are in order to pull the report down.

So so anyway some of the selected demographics up here. I'm not going to go through all those in detail, but there's one in the bottom right hand corner. This was worldwide survey as you can tell lots of senior people answering it.

Lots of experience represented in the answers that I got From a segment station standpoint all different company sizes, which was really good and then we have the notion of s-bomb maturity, which was something I derived from the data of a survey. So let me I want to show you how I drive that because it has a bearing on many of the ways that we slice and dice the data itself. So I basically wanted to separate the sample into three different categories the s bomb innovators s bomb early adopters and then procrastinators and so I did that based on this question on Readiness where anybody who said from a Readiness standpoint that they were, you know, just beginning or they were planning to do something or they haven't started.

Those are the guys with the procrastinators and then the guys who are the early adopters were the ones who were implementing sbalms in some number of places across their organization, but not pervasively and then the innovators were the ones who were doing Esperance everywhere and it was in some cases to standard practice for how they were doing business. Okay, so that's how I separated them out. And so I went through into the banner report against all the questions in the survey, you know using this as a notion of maturity and this is one of the questions actually it's two of the questions.

I had one question on consumption one question on production, they were structured identically so I could put them together here on a slide as you can see the the response is are similar for production versus consumption which kind of surprised me realistically because I think it's much harder to consume espombs than it is to produce them. Because from a consumption standpoint, you typically want to do that to support decision making and if you want to do that on automated way, I don't really know how you do it today. Now, I will say that the vendor Community is jumping all over this right now last year the sca vendors the software composition analysis guys.

They didn't message too much around espombs. I mean, it was creeping into their storyline, but they didn't have a lot to say this year. They're all over it.

And I think that's just a consequence of what happened with the executive order and the fact that this is a work in progress for them and I expect to hear a whole lot more from them as we go forward, but I think what's so anyway, so I'm surprised that the consumption numbers were as high as they are and then you can see the way I do the group gray bars here. There were only 20% of the sample really ended up being innovators 28 early majority and the procrastinators really were doing anything material. So that actually gave me enough information to a very crude of forecast of what was going to happen.

So notice that we have 20% plus 28% 20% innovators in 28% only majority. So I said, okay we have had a penetration in some capacity of about 48% of the sample. So that represents where we are in 2021 and then based on how they said they were going to grow whether it was the next six months or 12 or 24.

I was able to piece together what the penetration would look like assuming that nobody nobody defected from what they said. And this is what it looks like. So significant growth going to happen this year 2022 66% growth over where we were and then growth tapering off next year.

I think from almost the more recent survey did on software development processes. I think these are optimistic numbers. So realistically I suspect 2022 and 2023 are both going to be big years for us bombs.

Although some of that growth that should occur or was projected to a current 2022 will filter into 2023. it just takes organizations longer to get things accomplished than then, you know what it would seem like so anyway, so I used to say 2022 is going to be the year of the s-bomb and how I think it's going to be 2022 and 2023. So from the standpoint of what the expected benefits were for those people that were answering the survey with all these questions about us bombs.

It really came down to a couple of things and what I did was I drew gray sort of rectangles in this chart around what the innovators were saying and where the innovators diverged significantly from what everybody else said because the innovators have a lot more experience with us bombs, you know based on the more pervasive use cases that they have. So those are the ones that I said if the innovators are the ones that really understand what the esperan value prop is and to No Surprise what it comes down to is that It's easier to understand your dependencies, especially for complex projects. You can monitor components for vulnerability more more effectively and that you can understand what you're you know, how to meet your license obligations.

So it's all about dependencies and Licensing and s-bombs actually started out response has been around for 10 years back when sbom started they started out as a way to deal with license compliance. And then in the last four five years probably more like four years. The security crept in is an important issue s bombs, you know said we have to embrace this because there are important things that we can do here and it will add to the value that I sponsor provide.

Um at the same time a little bit lower down this idea of tracking component usage. So you can look at a you know, a reject list versus allow list. That's kind of interesting and probably something that many organizations are going to want to do obviously the threshold is going to be something the organization sets based on risk management policy and how they evaluate the componentry when they consume it.

So, but anyway, that's a really good that's a good story realistically and then you can also you know, the quality of what you produce becomes better because you know more about and you're more in a trustworthy way about what you're using. So some specific come consumption benefits here compliance and Reporting at the top of the list where certainly the innovators, you know, really felt strongly about that and then providing information to inform risk-based analysis. So those follow suit.

All right, we've already mentioned those things, but I would just want to call them out here because it was top of the list. Now how to facilitate Us by adoption. There are really two big issues here.

There's a lot of interest in s-bombs. The first thing has to happen is people want to understand. How do I integrate this into my ci/cd activities?

That's number one. What are the best practices I need to observe and and apply to be able to use S bombs effectively and the one right below it was how do I you know, how do I do the same thing? How do I integrate a sponge into my risk management activities?

So those are both important from a and they're both about best practices. So what I can say is that the next Foundation has worked very hard for a number of years on building out a set of best practices for secure software development. It's it's probably a list of that's between 200 and 300 best practices.

They are grouped across the development life cycle that was shown to you in the salsa diagram earlier David wheeler was the brains behind it. He's a Paul longstanding security expert and incredible the knowledgeable guy. So there's a course there's a certification process if you pass the exam and it's free it's now it's free and highly recommended so He once again if you want it's now it's actually on open ssf the open software security Foundation this website, which is part of their under the guy so Linux Foundation, but if you have questions about this who want to know more about it, you know, feel free to talk to me and I can I can get you contacted, you know linked into the right way.

All right from the standpoint of Key activities for securing the software supply chain, which is all about components and dependencies. What I did is I grew I drew gray bars here around all of the responses that were s-bombs specific ways that s-bomb adds value and I'm right at the top of the list as you as you can see vulnerability reporting was sort of was top and the idea of having s bombs of as a way to better understand what we're dealing with from a Content standpoint. What's number two globally unique identifiers about in the middle of the page here.

That's a work in progress very hard problem to solve if you're going to do it worldwide reproducible builds interesting to see that I don't know how much people are going to want to do that especially if you can trust the USB and you've got, you know, you've got hash code hash totals and like so that you can validate you know, what's in the ass bomb Formal processes for evaluating security of incoming software that's what esperans are all about. At least one of the use cases and then internal review of proprietary apps. Yeah proprietary apps are pushing back a little bit on this but I think the esp-bomb will win the day.

There's no way it cannot as a consequence of what the federal government has, you know has said so All right conclusions here. West bombs really are a foundational element of a strata any kind of strategy. They want to put together on secure software development.

They obviously have our comprehensive way to understand the knowledge of what you're using. It's usability and to have trust in what you're using as well. They obviously enable you to improve security but understand as I say here s-bombs are passive s bombs don't do anything.

They provide information that information has to be consumed in a way to add value. And once again, you have to produce it. So that others can consume it and drive value from it.

So s bombs are a foundational element from the standpoint of a software security strategy, but just recognize that it's it's important thing that has to happen. But you also have to look for other ways to be able to leverage that information. Um, they're very expensive very good at helping you manage vulnerabilities and risk and finally more s-bomb tools are coming online.

I see a lot more activity on the vendor side than I've ever have before. So that's good from a recommendation standpoint. If you don't have a software security policy in place make it a priority and I got to say this is really important because in the survey, I just brought out of the field 49% of the respondents had a software security policy in place that addressed open source, 34% did not and 17% couldn't answer the question which simply meant that they weren't in the right role to potentially know how to answer the question.

If your pro if you take those 17% that didn't answer the question you provided all up. It's about a 60/40 split. So 40% of organizations potentially out there don't have a security policy in place that deals with open source.

It's a little bit more cute for small companies with less than 500 employees and she would expect but a lot of the bigger organizations didn't have it didn't don't have this in place. And when I looked across vertical Industries, they pretty much were all the same the IT industry did a little better than all the others but there was really it wasn't like some Industries are really good at doing this problems and others are not Although I will say that device the healthcare device manufacturing space is probably one of the standouts in terms of doing things, right? so if you don't have a CSO, if you don't have an ospbo open source program office really suggest doing that and if you do it don't have a report into legal, which is where a lot of the osbos reported now because they all started years ago from a licensing perspective question.

No, that's exactly it. You know it us both a long time ago. We're all about license compliance.

That's not the case anymore. Um look to the sca vendors, if you want tools to help you with us bombs. That is probably the right functional Market to where you're going to see the most activity for how to address SB on both production and consumption.

And those SCA vendors some are open source, some are not so you have your choice. If you if you don't aren't getting what you need and you already are using some of these SCA tools go pressure the vendors Who provided to you work with them help them help them do a better job at providing the technology that you need this idea of an N minus one forcing function is also a really key what that means. Is that as an organization.

You should go to your supplies. You should demand s bombs from your suppliers if they're not giving to them to you right now and likewise your suppliers are going to be turning your customers will be turning around and asking you for us bombs, too if you're selling software. So what's cool about the in-14 function is that when one company stands up and does this, you know, all the suppliers have to get in line and do it and then those suppliers will turn around to all their suppliers and it will Cascade like that and we'll get the problem solved really quickly because everybody will have to be working on If you're a customers aren't asking for us bombs produce them.

Anyway, they're going to be asking for them because probably some of your customers are doing work with the federal government. They're going to need them. And then finally one of the things that's true is that in my more recent survey, which I have a slot on but I don't only if we have time to show it I think we do actually so I am going to jump down.

Well, let me do the recommendations and also share their slide. There are about 10 different functional categories for security tooling the most popular ones are sassed for the static analysis SCA as I mentioned already. And then the IAC tools infrastructure is code.

Those are the ones that are probably the go-to tools for dealing with s bomb issues. But there's a lot of other tool categories and S bombs will be creeping and being leveraged by a lot of them. For instance.

I didn't mention dashed the dynamic stuff and I didn't mention the the IAC scanning or fuzz testing. Well that's part of to ask. But anyway, there's not enough use of tools in the security space in general.

So I recommendation here. Is that look Beyond just fast and SCA and IAC. If you really want to deal with security issues and you're probably going to have to because Cloud vendors have security specific tools coming out that can be very helpful as well.

And best practices already mentioned best practices really key open ssf is a big project inside of the Linux Foundation. That's where that courses it's a self-guided course probably take about 20 30 hours to go through it and you can get a certification that's good like a year and a half. Once you take the course.

It's outstanding content. I can't say enough good about it. So I'm gonna stop there and I can show you the slide on other functional tool categories.

If you're interested in you know, kind of what the popularity of they are, but if not, let's go. Let's flip the questions first just because we're close on time. Yes.

well Yeah, you know it's that's a really good question. And that's one that I have I've written about extensively in the in the brand new paper that's coming out in June and the fact of the matter is is that we don't have a good closed loop system from the standpoint of how to deal with vulnerabilities when vulnerabilities become known. You know, I don't know how people are doing it right now, certainly from the standpoint of in the development process.

There are it's a gated process and you'll be looking to check out all that information. But once you've got something running in production, the question is, you know, what's the trigger that tells you that some component you're using has a brand new vulnerability and it's a very important one if you have to make sure it gets resolved. I don't think there's a good answer right now for how that happens, but I'm certain that the Scavengers are working on it.

I mean, they monitor closely all the national feeds like from sisa and nist and probably there are some others guys like first that do more of a global vulnerability database. Um, so that's a work in progress, but it's a very important one because I think you want either real-time or near real time knowledge of what's changed and so that you can understand how it will impact you and then you can make decisions about you know, how you're going to sequence it from the standpoint of getting it done. So great question.

Not a good answer at this point. other questions yes back to the room. Oh, yes almost in the back of the room over.

application so in terms of all like looking Oster speaker. Yes. Yes, the Linux Foundation well standard as of yet not so sure.

I mean there are standards for aspects of how for s-bomb formats but the secure software development course and certification is really so that when you think about that salsa diagram where you have, you know source code and build and package and deploy that you understand all of the dimensionality that security plays into that and you can make decisions about you know, how intensely you want to manage the security for each one of those activities so and the idea of a certification there which should have proves that you understand the content becomes I think invaluable in today's world. This is a course that also was is offered to edx which is a partner the next Foundation very big educational outfit for thousands of dollars and it's now available in a very similar form for free. So definitely, you know can't say enough good things about it.

Yeah the bachelor room Oh. Well, the Linux Foundation does a big business in training and certification and education and a lot of courses being offered right now. The number of courses in the security spaces not as strong as I would like to see it and I suspect that's going to change significantly because there's so much demand and so so I'm not exactly sure how to answer your question.

Yeah, I find. I've worked here in financial services and I would not use the phrase to build a materials in the financial services department because they have absolutely no idea. Yeah manufacturing firm.

Absolutely rightful Services. No has that. So you're remarked that across Industries.

It's pretty much all the same. There are no real leaders. No real language.

Everybody's a lager. Yeah largely right from the standpoint of of having a security policy. That's the that's the caveat as I would as I did say Healthcare is a little better, especially if I'm sbama adoption because lives are at stake and the same thing is true and Automotive, you know Automotive.

It's getting a lot of play Toyotas crawling all over this. Yeah. Yeah.

Yes. Well, I mean the physical Goods these days cars, they're all about software, you know and and realistically from a self-driving standpoint like it was being discussed a bit earlier. I wouldn't want to be trusting components that I didn't have us bombs for I got to tell you I want to make sure that you know from a legal and financial stand and reputational standpoint.

I wasn't putting my customers at risk because I'll get wrecked if I do so All right. Well, thanks guys. Appreciate it.