SBOM Manifests Database – Eric Allard, SOOS

This is texturing TV. Hey guys. Thanks for the throw.

We're here with Eric Allard who is CTO for suse and we're talking about s-bombs also known as software bill of materials for the uninitiated and Eric and his team have created a public database of no less than 54 million of these so we'll get into what that means and what you can do with that Eric welcome the show. Thank you, Mike. What prompted you guys to go do this?

It doesn't seem like it was a small effort. So what's the thought process behind it? I think our core competencies are in.

You know, if we're gonna have a tech discussion, it would be software composition analysis and it dawned on us when we were talking to some open source maintainers they said You know when log4j happened a couple of years ago now. It'd be really handy if somebody could just come and find my project and click a button and see what's in my software. We have some connections to folks in some well known Olas projects and They were effectively doing a lot of unpaid work for these businesses that relied on their tool just a testing that hey we don't believe we're vulnerable to this and here's why and they were under a lot of pressure to release a patch that had an updated version of log4j just to reduce that noise.

So on some of those discussions, they said it would be great if people could just get to this natively and that was when we realized well, We could do that. We have we already had these public research Pages for vulnerabilities and packages and licenses and we figured out that we could actually generate s-bombs for any of those. Packages on the fly.

So we now have that capability. It's I like to joke that it's the IMDB of ass bombs you kind of look up something there's a public page and there's some resources you can get to there and one of those is the s-bomb in a couple of different formats. How does that get updated as the open source projects evolved is somebody do that as an automated?

What's the process? Yeah, great question. Um and s bomb is only as up to date as when you last got a fresh copy that had all But let's be honest.

The list of the dependencies is interesting. The list of associated known vulnerabilities for those dependencies is really the powerful part. So Again, our core competency of software composition analysis means we're constantly calculating that anyway, so as a public service every time you download an s bomb from our public site, it will be the most recent information.

We have if you're a customer of our tooling or use for instance subscribe to use our commercial apis, there's lots of ways you can get that data in effectively real time, but you're correct like if you go download an s-bomb. In two months, it's probably a stale document. There's very well could be new CVS associated with the dependencies listed in that s-bomb.

It seems to me at least when I talk to people these days everybody wants an s-bomb, but I don't get the sense that they figured out how to operationalize all the inputs that they get from the S bombs and they wind up being overwhelmed. So how are people going to take all this information and turn it into something that allows them they're effectively. Do you know Red Light Green Light do not update because this vulnerability exists.

You are correct. I just came back from a very big conference in focused on medical vendors and their biggest question was. Well, we can get some of these how do we make vendors provide these?

And that kind of leads to the next question. Well, why aren't vendors providing them? Is it like you said because it's really hard.

It's not insignificant, but it's definitely doable. Now. There's lots of tools that can Empower people to create these.

I think it's a mix of availability of effective tooling and willingness to know I mean, I I don't want to single anyone out, but I am I believe there's probably some people that don't want to know yet. They could they do have the capability to discover this but it's in their interest until they're compelled through regulatory requirements to make one to not do it and I don't know how I don't agree with it, but I understand why some businesses are probably making that decision. I do think that's going to change we've I was recently speaking with a team.

Connected to Health and Human Services and they effectively said look. We've tried a lot of carrots, but at some point we're coming with sticks. Like I don't think they didn't say it's like him play.

anything to onerous, but the point is they're gonna start putting more things in place that really force you to do this and as recently as December of last year 2022 section 3305 of I believe it came as part of the Omnibus Bill, but it's called ensuring the cybersecurity of medical devices. So if you are trying to achieve. pre-market approval with the FDA for example like these are going to be must have documents so everyone in that space Is aware of the need for s-bombs and trying to figure out how they're going to pull these together from all of their vendors.

I'm open to talk to those vendors if they want to make one and they don't think they can surely there's some hurdles but it's doable. It's a doable thing. So.

I think that time is changing. it also seems if I look in the National cybersecurity strategy document that there is more call for liability at the very least than not overly prescriptive about how that will be accomplished but seems to me S bombs are going to be at the core of that and That is going to be a large stick. You think or This is not my own research.

But I someone with more I will I will be clear. We as a company we were. With all Industries not just health care.

We have clients in all kinds of different places real estate era Aerospace fintech, but my understanding is that some of these new FDA requirements. If you follow enough of these regulatory documents, there are significant legal pennant penalties for people like me in senior sea level. business positions That you could go to jail now.

That's again. That's I did not. Determine that myself but my understanding is there's potentially significant penalties.

For not doing the right thing and trying to figure this out. And it's also interesting. There's a draft document.

I'm happy to share this after I have it on my desk scissors putting out a procurement guideline for for departments who are responsible for procuring. Technology and it effectively it's a draft but it's you know, it's pretty fleshed out. It effectively says hey, here's what you need to do to ask your vendors for an ass bomb and if they say no.

there's like six different things that tells you to go back and beat them down on price timeline even as much as rights for reverse engineering their tools, like it's pretty prescriptive and it tells you it makes it clear how important an s-bomb can be and it gives you actionable things to do if someone's not providing you with one so aside from just sticks It's different government agencies are empowering your buyers. To know what to say to ask for one of these so I expect if you haven't heard about it yet and you make software of any type or you maybe you don't even make software as your main line of business, but you pull in software to put in some other product. Um, you will be expected to provide these and maintain these Are there any parents to go with these sticks that people should be thinking about?

Oh gosh. Yeah. Yeah, that's funny.

Um, I was at a developer. It was Dev week out in Oakland a few weeks ago and I gave kind of a very different s-bomb talk. It was for engineers, and it was to talk about Hey, here's all the great empowering things if you're doing the work.

You know now in love for Jay happens. Yeah, and a number of ways you can find out all of those introduction paths for example, and Significantly simplify your life it and even forget a zero day like the worst case just from a planning perspective an engineering team. There's a lot of things that goes into those.

You know, let's pretend you're running some sort of agile scrum setup and your running in two weeks sprints. She know you're gonna look in your imminent roadmap and try to figure out gosh. What are we gonna work on where we gonna focus our efforts and our testing and your information about the composition of your your application and maybe where you need to do some work to upgrade some things.

You have a lot of that visibility with these tools. Our tool and others will tell you here's some non-vulnerable upgrade paths for these libraries. So there's certainly benefits there from an engineering perspective as well and other business benefits other than just we don't want to get sued.

How automated can all this get we've been talking about software composition and s-bombs for a long time. Now, it seems like maybe the process was a little too cumbersome. So can we take a lot of the friction out of this?

Yeah, and you're right 10 years ago. I think some of it's a maturity of the industry that generates s poems and I think some of it's a maturity of the software industry quite frankly. things like package managers make a lot of the stuff much more achievable Legacy Solutions were essentially like crawling your network looking for certain file patterns that understood and trying to figure out what you were using that way.

Um, and you still may need to do that for some things but nowadays. there are a number of build Integrated Solutions so you can be doing this analysis on every commit you can know, you know, I Shift left isn't my favorite buzzword, but you can get pretty far left, you know, someone can bring in a new dependency or attempt to and you can be warned or explicitly prevented from doing that. If it's not of an acceptable license type for your business if it has no vulnerabilities if the source has only one maintainer You know whether or not you agree with the person who corrupted the colors JS and vicar JS node packages there last year.

Maybe you just don't even want people bringing in those types of projects when there's a very limited set of maintainers. You have that decision and capability in a pretty automated fashion. And you have the ability to write policies based on these sorts of things.

So, It's rather frictionless once you set it up, it's just another thing that runs in your build process like linting or other analysis tools. You probably already use. As we go along you mentioned ship left who's in charge of all of this because it's not clear to me that every developer wants to be in charge of it.

So is there some Central function emerging or we shifting left and right or what's going on? Yeah. Yeah who's in charge?

well I'll tell you this when we talk to our customers. It's usually The reason they're looking for what we do is driven by. A decision maker.

That's either a sizzo. Possibly a CTO the implementers are almost exclusively someone in the engineering department in my experience and we've done. You know many many many of these at this point.

I think that's honestly not an unnatural place for it to be because Engineers are the ones deciding to bring these dependencies in as part of the building of the applications. Right? Like who's including an open source package.

Ultimately, it's probably. A software engineering team can that be informed or influenced by other parts of that sort of devsecops group? I'm not going to say that it can't or shouldn't be I just think what I'm witnessing right now is it is It is often an engineering responsibility at the end of the day.

We have some clients who only use this for. license for instance licensing and maybe there's more of a compliance group that's involved at that point, but Even there the person that I know that that company and multiple of those companies are still. software Engineers or Architects by title, so All right.

Somebody else may be paying for it. But the end of the day the software Engineers are the ones implementing at least it at least implementing again. You know, once you've done the analysis and I'll be quite Frank with you and esbom is a trivial thing to make it's just a text document that conforms to some standards.

It's the intelligence behind it that's hard. But you know, you can integrate these tools with the SIM or solar and you you know, you you may be able to push results and Sarah if that's the tool set needs that fine. You can do those things.

Um, That's all pretty. Trivial stuff once you've the crunch of the dependency intelligence and what's there and what's vulnerable has been completed? How automatic can this get in terms of artificial intelligence you cannot walk down the street these days without somebody leaping out telling you about their generative AI platform.

Are we going to use this to kind of discover vulnerabilities and will that compliment or existing engines or how that all come together in your mind? I don't see how it can you know, I certainly have we have some ideas of how to use that and apply it that I won't disclose but I it's easy for me to see some of the big players also that are our competitors and I can think of ways that they're gonna have awesome capabilities around some of this stuff. Like it's let's not pretend that there isn't a lot of capabilities there at the end of the day.

If you have a way to analyze a lot of these signals and patterns. They're there and a machine can can pull those out quite readily especially when it comes down to. static analysis of code and so forth, but in the meantime, there's a lot to be found even without machine intelligence just from the very explicit dependency data that everyone has in their applications because they included someone else's piece of software and the the magic today is not just looking at that one thing but it all the transitive dependencies below it as well or that makes sense.

Are we developing software too fast for our security capabilities to keep up with and maybe we all just need to take a breath. Maybe I don't know. I don't really think so.

I think it's like people need to see the value. And sometimes unfortunately, you have to be forced to do something to see the value. I'm gonna give them maybe controversial example of that.

I occasionally talk to people and they still get Kind of grossed out by this term, but I remember when I was first getting into software engineering the concept of test-driven development or writing tests writing code to test your code was sort of like, why would I do that? I just want to write the application and see it work and as I had some of my early jobs and we were having these complicated applications with all these business rules. It quickly became apparent the value of doing that type of development and I came to find it to be extremely helpful.

Not only is a way of validating you were doing what you were supposed to but as like a kind of a documentation of the expectations of the code without writing a bunch of other documents. So I'd like to think it's the same like in 10 years. I can talk to a new.

and what at the time was a new software engineering student and they'll say oh, I remember when doing software composition analysis and understanding of the dependency Tree in s-bombs were new and we thought it was a pain in the butt but now I get the value that's that's what's in my, you know, magical Fairyland I guess is that's where we could be. So what's your best advice to folks right now? It seems like everybody's kind of scratching their head is about what to do.

Where should they get started? Where should they get started? Um, I often give a talk with a person with their head in the sand.

I mean do something it's not hard to learn quite a bit quickly. Will it will you be able to cover everything in all of your applications or some very niche? languages perhaps not but I bet you're probably using doing engineering using some of the modern package managed languages that Austin my competitors support and I would say there is no better place to get started than with Zeus.

We are specifically built. To be accessible and that when I say accessible, I mean small businesses can set it up very quickly easily and affordably and it can grow with your business. And if you're already big, it's probably much less expensive than anyone out there that does what we do.

so and it's free trial. So there's no excuse and I will say if you are a maintainer of one of those public. Repositories you can use our SCA capabilities for free.

And you can even put attestations using our tool that will then get put in your s bomb. So if you're in the position someday of you know, log for J2. You can already have a tested to why you're not vulnerable and have that be on our public page.

It makes our data better and it makes your life easier and you don't have to pay anything for that. So I would encourage anyone to try that out if you're into open source software. All right, folks.

Well, if you're seen to be doing something about it, you're perceived to be responsible. If you're doing nothing about it, you might be deemed reckless in any lawyer will tell you being Reckless is very very expensive here. Thanks for being on the show.

Thank you, Mike. All right back to you guys in the studio.