The Importance of SBOM’s in Cybersecurity with Pablo Quiroga | Qualys QSC 2023

This is Textron tv. Hello, and welcome back to the Qualys Security Conference Americas. We're talking with Pablo Quiroga, who's a product manager for, um, the software development side of the house at Qualys.

There's a lot of pieces in this company, so we're trying to sort through that, but right now we're talking about SBOs, otherwise known as software, bill of materials. Paolo, welcome to show. Thank you, Mike.

Uh, so I'm a director of product management here, uh, with Qualys. Uh, I've been with, uh, Qualys for over six years, and, uh, today I am really excited to see how our, uh, you know, platform has evolved from a vulnerability management solution to a cyber risk management platform that can not only help our customers measure and communicate risk, but also help them de-risk their business. And as you know, the first step of, uh, of on on cybersecurity is really to know all of your assets.

Um, and as part of your assets, you need to know your infrastructure as well of all the software and the components that are part of, of, of your inventory. A couple of years ago, I don't think most people knew what an SBO M was, but recently there's been a lot of mandates all around the world for you must have an sbo m how do I know what's listed in the SBO M is actually what's in the software because it seems like it's, it's like a list of ingredients. I go to the store and it says that there's a list of ingredients on a package of something I might buy, but I don't know for certain what's in there.

So how can we really validate that? How do we manage that? How do we operationalize sbo?

So the first step is like, what, what is an esmo? Right? The ESMO is the, is the list of ingredients, as you said, of a, of a software now across, you know, the enterprise.

It's very difficult to understand at runtime, where is your really, your software coming from? A lot of times it's coming from your own developers, building your own applications, supporting business services. And a lot of times it's coming from, you know, open source tools.

A lot of times it's coming from, uh, enterprise tools or, uh, uh, software providers. And so an SBO provides a transparency on how this, uh, how this software is packaged, what are the ingredients, and it also provides, uh, uh, helps, uh, uh, speed up the way vulnerabilities can be detected and remediated. Um, now as you, as you mentioned, SSON is really like a, like a contract.

It is just basically the list of ingredients in, in a paper. Mm-Hmm. Right?

So it is as good as the, uh, publisher of the SBO m has put that list together, right? And, but you also need to be able to validate that SBO m in runtime. Right now, a lot of, uh, uh, solutions have come up to help, uh, software producers or even enterprises that are building their own software to scan their code repositories and generate the S one.

Right. Now, on the other side, there's a lot of tools or fuel, actually much fewer tools that are helping customers understand what is the impact of those SBOs or those software in, in runtime. So there's a gap between when the SBO gets generated and the actual software running on on your enterprise.

Mm-Hmm. Um, so there's a need to close that gap, and there's a need to be able to understand the entire supply chain from the, from the SBO m to the execution of the software. On the upside, the fact that we have an SBO M seems to make it easier to figure out what to remediate, because if we go back to log four J, shell, everybody, you spent months, some people are still looking for instances of log four J.

So are we gonna get better at meantime through remediation because we have an sbo? Yeah. That, that's a, that's an interesting point.

And, uh, and quality, we did, we did a study, we, we researched, uh, the time it took for, uh, the, the average enterprise to detect and, and remediate log for shell. Exactly. And it was like over 30 days.

And the main issue was really understanding the scope of their assets. Like, where should I actually try to find this, this, this log for J, right? Because it is intrinsic on so many different software across open source and third party and first party software.

Um, the first task was, okay, what is the scope of assets? Second task was where could this, this, you know, software potentially be, and why? Because it is, it is really expensive and time consuming and, and, uh, resource consuming to actually go ahead and try to scan everything.

Try to scan every single asset, every single, uh, file system to find, find this library, right? So, uh, knowing ahead of time where this potentially could be is helping you narrow the scope, narrowing the scope, right? And then half of the time of those 30 days was really trying to figure out the scope, trying to create specialized scripts in many cases to scan those, uh, you know, first party applications to find the vulnerable version.

But then the, the, the, the around 10 or more days was, uh, spent by the teams trying to prioritize and understand what, what is the business impact really? Where is, where are these assets? What is the software or business application that is supporting?

And then actually working with those teams. So knowing the SBO ahead of time, you kind of know who owns that sbo, is it coming from my own team? Is it coming from a, from a vendor I have to basically reach out to MM-Hmm.

Right. So, so that is a, a good baseline. Uh, you can't solely rely on SBOs, but it's going to help you accelerate, you know, those 30 days, you know, to reduce that by, you know, five, five of the five days or so, to basically be able to understand what is that scope, and then from there, go ahead and, and, and start scanning and assessing.

And I would have a better understanding of whether or not that application is even internet facing or whether it is actually using that code, because not all that code makes it into the production environment. So it gives me, um, a guide. Yeah, yeah, that's correct.

Like, uh, as, as any, you know, uh, good security program, the first step is really knowing all of your assets, whether they're on-premise in the cloud, which ones are inter internet-facing assets. Um, I'm actually leading our attack surface management solution, uh, and we help customers automatically identify what are the assets that are internet facing, uh, what are the pores that are exposed, right? So having a platform that combines all of that information in a single platform makes your life easier.

Can I pass that information on the developers as they're building applications? And I asked the question because developer A might have built something and added some vulnerability inadvertently, developer B then goes to a different registry and downloads the same vulnerability, even though I fixed that vulnerability two weeks ago, I have it back again. So how do I kind of close the loop on this system a little bit?

Yeah, of course. Uh, so of course, developers will have their favorite tools that they're used to. They, uh, those tools need to make their life easier.

It needs to be a tool that helps them, you know, deliver the software securely and fast. Uh, so this platform needs to be able to integrate with those other solutions, uh, natively, right? So integrate with those solutions so that developer understands in their own interface, in their own ui, what are the issues that they need to fix.

They get notified, but this other platform, which is unified platform to managing all of your SBOs and software supply chain needs to also be able to manage the lifecycle of that sbo, understand the different versions, understand if you have different exceptions that you have to, to be able to give to developers, uh, and so on. We've been talking a lot over the years about DevSecOps workflows. A lot of times, you know, it's focused on the software supply chain, but there's all this stuff in production environments that are run by IT teams.

Are we moving towards kind of narrowing the gap between these teams and kind of getting them to work a little more hand in glove? Yeah, exactly. Exactly.

Um, so there is the, it is really difficult for teams to track the drift that happened between, as you mentioned, like some, not all, all of the code makes it to, to, to production. Sometimes in production things change. Also, uh, creative developers put some logic to load other packages, other software, and sometimes in runtime the environment looks different than in development, right?

So, so with all of that, there is, there is definitely the need to close that gap between what happens in DevSecOps and, and runtime. Do you think that this will make it easier for security people to have this conversation? Because we've lived for so long where it was basically, you know, here's my spreadsheet, I'm throwing it over the wall, and you guys go figure it out.

And those guys would get down to the third one and say, none of this is relevant, and then they'd skip the next 10, but the eighth one was probably killer. So can we get to the point where, um, you know, we're not viewing security people necessarily as an obstacle, sometimes even the enemy, and sometimes the security people view the developers as the root cause of all evil. Can we get to this kinda middle?

Yeah, yeah, of course. I, uh, uh, this is what we are helping, uh, our customers achieve by providing a platform that, uh, serves different, different, different users and different personas, uh, and their enterprise to, to, to use a single source of truth. Uh, that, that is the, a single language of communication between the, between the teams and then, uh, developer also able to understand what is the impact of the, the, the software that they're building, uh, in, in, in, in runtime.

Do you guys think that, um, we have enough of this SBO m capability in place right now? I think it's just folks are sitting there going, I think I'm supposed to do this as a mandate, but it's not clear to me that, you know, they have thought through the process. Yeah, I, I think, uh, um, definitely, uh, a lot of, uh, publishers or software providers that are being asked, especially by the government, they, they have to provide these SBOs as a, as a requirement in order for them to actually have business with the, with the government.

Um, but I, I think we have to shift our, our mind. It is not really, like we, we, we don't need to see it as a, as a mandate, as a requirement. We really need to, to see it, how it can help all the organizations, uh, understand the, the risk better.

All right, folks, well, you heard it here. If you want to get where you're going, you need a map. The map in the case of software was an sbo.

So start with the sbo and then that gives you the visibility to start this larger conversation. And before you know it, some good things will start to happen. Pablo, thanks for being on the show.

Thank you, Mike.