It’s not all that often that specific technologies are standards are called out by the White House, but that’s exactly what happened with SBOMs. But while there’s a lot of chatter on SBOMs, many people still have questions about what they are, what they’re for and how to use them. Josh Bressers from Anchore joined us to answer just that question.

Rather listen to this conversation as a podcast?

 

Transcript

Stephen: Good morning, Good afternoon, Good evening – depending on where you are. I am Stephen O’Grady and I’m here today to talk with Josh. Josh, would you care to introduce yourself?

Josh: I would love to. Thank you, Stephen. So my name is Josh Bressers. I’m the Vice President of Security at Anchore. I’ve been kind of a security nerd for decades at this point. I’ve got some security podcasts. I am the co chair of the SBOM Everywhere Project with the OpenSSF. I’m on the OpenSSF TAC, which is the Technical Advisory Council and just kind of all over the place. And I absolutely love it. I’ve been doing this open source thing forever and it’s great.

Stephen: Wonderful. And you mentioned SBOM, and that actually is a subject of today’s particular conversation. So I was joking with somebody the other day that SBOM is kind of like Hansel from Zoolander, where it’s like Hansel, Hansel, Hansel. Everything’s — you’re so hot right now. That’s kind of the deal with SBOM. Everybody seems to be talking about it, but one of the things that we found is, is that not a lot of people know what that is or what it refers to or what it means. So can you could you define SBOM for us? Tell us what it is.

Josh: Yeah. Yeah. So SBOM — “software bill of materials.” And I will say it’s always amusing to me that we picked a word with “bomb” in its name because obviously, you know, you’re on a call at an airport or something and you say SBOM and you kind of get that look of like, what? What’s going on? It’s like, Oh, crap, But — software bill of materials. And the intention is that we’ve entered this era in software development where it’s not like the good old days where you kind of had a development team that built all your software. Now what you really have is you have teams that are taking in all this open source from all over the place, and then they’re augmenting it to build their own product or project or whatever it is. And so the question becomes, well, what is all this open source and dependencies and other stuff I’m using? And that’s really kind of the intent of the SBOM is to give you the ability to understand what is in your product. And this has been compared to like food nutrition labels. If you go to the grocery store, you buy a box of cereal, you can see what are the ingredients.

Josh: You know, I’m allergic to peanuts. Are there peanuts in this? And so the idea is SBOM is meant to be a way for an end user to know what’s in a thing, be it your cell phone, be it your web browser, whatever, any piece of software. And now that sounds very easy, but anyone who has worked with SBOMs knows it’s not easy at all because we exist in this world where there’s so many ways to package software, like depending upon the language you use, depending upon the build system you use. And so it obviously has lots and lots of challenges. And I’m not going to pretend that we have, SBOM figured out, I mean, it’s not a new technology. SBOMs have been around for over a decade at this point. But there’s a lot of new happenings in SBOM over the last probably 5 to 10 years, just because I think the explosion of open source has made people say, What’s going on? What do I have? What can I do about this?

Stephen: So that all makes sense. And obviously, as you know, like what’s offered these days is a complicated mix of lots of different pieces, some of which you build and some of which you don’t. How does this — how does this help us? Like what — how do we — what’s the “okay great, I know what’s in it.” Like, how does that — how does that benefit a user or developer or the business they work for?

Josh: So that’s the question, right? If you look at what’s going on with SBOM today, there’s an enormous focus on creating SBOMs. There’s not a lot of focus on what we actually do with these things once we have them. Like, for example, there is — the Biden administration released an executive order telling the federal agencies you have to request SBOMs from your vendors. But it doesn’t tell them what to do with them. Right. Just you need them. Go get them. And so right now there is a ton of focus on creating them. A ton of focus on, I guess, making sure they’re good. And that’s okay because that’s how technology starts, right? It’s the chicken and egg problem where we need good SBOMs before we can do a lot with them. So what we see today, the primary use of SBOMs is vulnerability scanning. Where I have a product, it’s full of dependencies and I want to say are there security vulnerabilities in this stuff I need to care about? You can be an end consumer. You could be the developer. It doesn’t matter where you are in the chain. And so like something we see is a customer of a product will get an SBOM. They often make it themselves now with, with a sort of scanner. They have their SBOM, they scan it and then they can say, okay, this has this security vulnerability in it. And then you contact your vendor. You say, Hey, what’s the deal? Are you fixing this? Am I affected by this? What can I do with it? And that’s the easy one, right? That’s the single easiest, probably most impactful use of SBOM today.

Josh: But we’re seeing more and more technology and ideas around this. Like a great example was Log4Shell which is almost a year old at our time of chatting, which it feels like it’s been a month but that’s another problem in itself. But anyway, so let’s say your infrastructure provider, whatever — a company that has a bunch of stuff, right, you’ve got hundreds, thousands of computers, who knows? You’ve got thousands of applications and you need to say, where do I have Log4j in my infrastructure? What a lot of organizations had to do was basically just like crack open the computers, crack open the applications and start digging for Log4j. And this took, I mean, weeks in many cases. Now I know some companies that actually had SBOMs generated for the vast majority of their software. So you know what they did? They went to the search box and they typed Log4j in and they were like, “Oh, here it is, uh here, computer security people, go look at these 12 services and come back later today and tell me what’s up.” That was powerful. And now granted, you’re still going to do your due diligence and look around a little deeper, but it gives you that kind of overarching ability to say what’s going on. And there’s obviously a ton of other research that’s happening in the space.

Josh: You have the ability to understand your dependency tree. You can ask questions like “How much of this software is old?” Just because something doesn’t have like CVEs, for example, doesn’t mean it’s safe because you might have a dependency that hasn’t been updated in seven years. Like, that’s scary. And so there’s — now granted, we need the tooling to do this. Also, I should also add the really truly important part of all of this is humans cannot do this work because there’s just too much stuff. If you take a typical node application, it has like 1000 dependencies. Humans can’t even comprehend what 1000 is. I have a great story about that actually. So my daughter was part of a this — it was DI, Destination Imagination group and they were fundraising and they said we’re going to sell hot cocoa. And they put together these like little cocoa cups and they went and sold them for a buck and they said, “We’re going to make 1000 of them.” And I said, “I don’t think you know, how many 1000 is.” They’re like, “oh, no, it won’t be that bad. We’ll do a thousand.” And once they made it to about 300, they said, “This is horrible! We have 700 more to go!” And so I think that’s part of the power as well with SBOM, is it’s — we are creating an environment where we can start using robots to help us do this work, which is really cool.

Stephen: Right? So so given all that, what what can/should people be doing with them? Right. So in other words, we have sort of the guidance from the Biden administration. We have existing crises like the log4 fiasco. So in other words, like as we think about this, like what is your recommendation? Like, what should people be doing with SBOMs as we sort of move forward?

Josh: Yeah, I mean, so there’s a couple of pieces to this, right? There’s the generation aspect I just mentioned, which there’s a lot of focus on and there’s a lot of guidance for if you need to make an SBOM, it is not hard to find tools and write ups and instructions to do that. And so I would encourage if you are a software vendor, create SBOMs and make them available. You don’t have to like force them on anybody by any means. But it’s one of those things that having them, I think is an easy signal to your customers that like “we’re with it. We have a plan, we have a team in place.” And then there’s the consumption piece which we you can break this down into a couple of pieces and there’s actually some misguidance around this. There’s the SSDF, the Secure Software Development Framework where they — that just came out a couple weeks ago at the time we’re chatting and it talks about some of this. Like for example, you have to have the ability to acquire an SBOM from somewhere. You might make it yourself, you might get it from your vendor. Another favorite is you can take the SBOM from your vendor and you generate an SBOM and you compare them and say, What’s going on here? Like is there something in there you don’t know about?

Josh: And that’s always terrifying as well. I remember back in my early days there’d be times a customer would say, Oh, hey, this product has this thing in it. What do you what, what are you doing about it? I’m like, What? No, no, it doesn’t. And you look like, Oh, crap, it does. Like, how did that get there? Because, I mean, developers do that all — And I remember the developer was like, Oh, yeah, I found this on the internet and I threw it in there. I’m like, “you can’t do that!” But anyway, so. Oh my goodness, I bet we have stories. But, so as a consumer, now I’m going to take my SBOM and you need to find something to do with it. They’re generally JSON or XML documents. You could throw them in like a Google Drive folder or something. But the real power becomes when you start putting it into a system that lets you do things with it. This can be things like you can imagine there’s observability systems, there’s SBOM management systems now, there’s things like I used to work at Elastic, there’s elastic search, it loves JSON documents, right? You just have to put them somewhere you can do something with them. And it’s not that you’re going to necessarily do something immediately. I mean, I’d recommend vulnerability scanning them because you can and it’s easy and fast.

Josh: I mean, so a good example, there is, at Anchore, we have these two open source tools, Syft and Grype. Syft generates SBOMs. Grype is a vulnerability scanner and Grype can like scan a container, but that might take, say, 10 seconds. But if you make an SBOM of that container, now you can scan the SBOM in like milliseconds. Right? And so that’s a huge difference, obviously, when you have lots and lots — yeah, yeah, exactly. So anyway, you need to store it and then you can start asking questions about your data and we can start making decisions based on that data. Right? Because, I mean, as a data nerd, I want everything in a searchable format so I can ask questions. I can look at what’s depending on this, what’s using this, what are the vulnerabilities I see in this. And then once you have that data, you can start making informed decisions. And I think that is where we’re at today. But I also see a lot of people paying attention to this and a lot of people with some really cool ideas around how we can take SBOMs and really use them into the future to do some wild things with our software and our supply chains and understanding what we have. And that’s really cool. I’m really excited for that.

Stephen: That sounds great. Well, this has been super helpful. And I’m sure folks who are essentially on — trying to struggle and process what an SBOM is and what it’s for, will find this enormously beneficial. So, Josh, I just wanted to say thanks so much for coming on.

Josh: Thank you so much, Stephen.