Alex Kreilein on Product Security, SBOMs, and Strengthening the Software Supply Chain | ROCon 2025

Hey everyone. We're back here live at Qualys Rock Con Risk Operation Conference. I've explained it already a couple times today, so you'll have to go back and watch it.

But let me introduce you to our next guest. His name is Alex Kry Line. Hey, Hey, Alan.

Time new dad right here. Thank you. So let's give him a big hand.

Appreciate that. Congratulations, Alex. My, my kid is watching enthralled with excitement about our conversation.

Well, You know what we should do though? We should get you a copy, the MP four of this. Yeah.

Put it in like a time capsule. I like that thing. And when she's old enough, say, Hey, this is what your dad did when you were totally three months old.

Yeah. 'cause right now we're just working on keeping food down. It gets, you know, it, it progresses.

If You're telling me there's a maturity path, A lot a to understand. Well, it's a, it's a process. I'll, I'll say that.

Anyway. Congratulations. Thanks.

Seriously though, Alex, Alex, introduce yourself to the audience. Besides being a first time new dad, what else do You do? Yeah.

Uh, I run product security and public sector solutions at Qualys. So essentially I have three jobs. My first job is to make sure that what we ship is safe for customers to use.

The second is to make sure that when we ship something for customers, it materially protects them and aligns the compliance frameworks that they need to do their business. And the third is that when we deliver a solution, it raises the rents on attackers. Right?

Our best day is an attacker's worst day. And when we make it more expensive for customers to be exploited or for our platforms to be exploited, we end up realizing that goal. Absolutely.

Um, well, interesting you said all that. 'cause we're gonna talk a little bit about software supply chain security Today. Yeah.

A hard topic, You know, look, software supply chain security. First there was the, uh, SolarWinds and the, and the, uh, not JSON Oh, the log four J. Log four J Yeah.

And that, that really put software supply chain security kind of on the map. Totally. It stayed unfortunately on the map.

Right. And, and now we realize that look, so much, so, so much heartache, frankly, and, and in security incidents are because of not vulnerabilities in our servers or hardware or network of fig, though there's plenty that come from that. Totally.

But we're just not, we're not producing, we're deploying insecure code. Yeah, That's right. And so, securing our software supply chain, and there's a lot of things that are mixed into this.

It's open source, right? We, we live in a Franken code environment where most of the code that we are, when you get into the application, 75, 80% of the code is open source code that we've stitched together. Totally.

Um, so that's a part of the software supply chain that gives rise to this whole SO software bill and materials, which is now a requirement. The eu Yeah. With the Cyber Resiliency Act, the Cyber Resiliency Act has, has jumped into this.

Alex, what, what's Qualys doing? Yeah, So I guess like, there's, there's kind of three things that we should probably establish, like in the, what's your take question on SOM, right? I think the first thing is like, let's, let's establish like what it is.

Why is it useful? And we'll do that quickly. And the next piece is like, well, why is it also kind of a trap?

What problems does it cause? And maybe the last piece would be like, well, what, what are you we gonna do about it? Right?

So software bill of materials are essentially an ingredient list of like, what are all the third party dependencies that are in this product? And that can be for both software and hardware. Um, and it can also extend into things like cryptographic bill of materials, right?

Like, what is the cryptography that you're using for this application? 2 or higher or using something else? If you are doing that, what's the algorithm that you're using?

Is that a knowingly weak algorithm? Is it potentially a compromised algorithm? Um, illumination on the ingredients list helps people understand questions from like, you know, they could be real security questions that are kind of interesting in some ways.

Like, is my application post quantum ready? Right? That could be one question we might answer.

The other one could just be like, does my product actually have like 12 different logging libraries? And that's like super inefficient for developers. And we can make many more effective and efficient choices if we can understand what we're using.

So like, just like in the Center for Internet security controls, right? Control number one, identify all hardware control. Number two, identify all software.

The S bomb is helping us to identify. So that's what it does. And it does it well.

Where does it fall down? Well, it falls down because just because I'm using a dependency does not mean that I'm calling the function that is vulnerable. So, for example, um, if this dependency requires like some use of like, I'm just gonna say like, uh, like, you know, H-T-T-P-S invocation in a specific manner, but I'm not using that.

I get a true positive on the detection of the vulnerability, but that doesn't mean it's applicable. So the problem is that the intersection between, yes, I'm detecting something that is real, but it is not actually risky because of my choice of how I've implemented it. Right?

Like I'm not enabling macros on Excel means that macro based attacks are no longer applicable to an a disabled macros field. Right? Okay.

So the problem is that it gives vis the, the opportunity is visibility. The problem is noise, right? Then the question is what are we gonna do about it?

Because we still want transparency and we still deserve information, but we needed to be at the right signal to noise level. So there are a number of organizations, call us included, who are focusing on the kind of the next step in the asbo, which is a question on the attestation of risk. There is a project, uh, called the vulnerability Exploitability exchange, or vex, which I'm very involved in and very interested in.

And what this asks the question of is, is the vulnerability applicable in your product? Yes or no? So every week, many of our enterprise customers ask this question, right?

They ask, uh, Hey, Quas cloud agent version, whatever, CVEX applicable, yes or no. They don't care about vulnerable, they care about applicable. Because the question they're asking is, do I need a patch?

Right? If it's a non-applicable vulnerability, I won't dip into my 10,000 hours bucket, right? I will, I will then reallocate my time to higher order things.

Right? The problem that SBOs bring is that they cause support cases to get answers to questions that developers should be able to answer. But it's hard to, without a framework, VEX is that framework and CS a F or, uh, which is a open standards framework, is the method that we'll use to report.

So the full scope opportunity is identify all your ingredients, be transparent about it, be prepared to respond to questions in machine readable standards based formats that answer the real question of is this applicable yes or no? Right? And at the end of the day, you know, this is something that always kind of vexed, no pun intended.

Nice pun. Yeah. That vexed me about sbo m which is the dependencies of dependencies of dependencies.

Totally. You know, how far do I gotta go back? What's reasonable?

Yeah. What's the, what, what's the orders? Right?

And then some things, and, and remember, sometimes there's more to remediation than patching. That's right. Not everything needs a patch.

Sometimes I, I shut a port down or I, I, I, you know, make a network change or, or what have you without actually, you know, patching software. And so I, I see a disconnect a lot of times. And, and here's the other thing, it, you know, it's the, it's an event horizon deployment is the event horizon.

Yes. And we do all of this security kind of stuff, pre-deployment without recognizing, well, what's the real physical infrastructure that this is gonna run in post appointment? Oh, totally.

Because post appointment, it's a different reality. Yeah. Also, like the, I think you're, you're indicating two interesting points.

I think the first is, hey, if prod doesn't model pre-prod, then your testing isn't really effective. Right, right. Uh, or there's limits to its efficacy.

Exactly. The, the second one is a, is I think, a differently interesting question, which is, are you even looking at the right things? So like, if you're an application security analyst and you're only looking at the application layer and you're not looking at the configuration of the container or the configuration of the Kubernetes node, it's, it's on, or the master helm that is powering and enforcing policy.

Like you're, you're not even, it's not that you're getting an incomplete story, you're getting a wrong story. Right. Right.

And, and, and that could be expensive. Right? Now, to me, this is like the use case for digital 20.

Yeah. I, I, I, you know, I was introduced to digital twins from a security point of view. Oh, that's cool.

Yeah. And look, I know sometimes it could be expensive to recreate your fraud environment and, you know, and, and run all your testing. Totally.

But if in my mind, if you're not doing it, you're not doing justice. Yeah. There's a lot of, well, it causes friction, right?

Unnecessary friction instead of flow, which is what we really want to get to as organizations. I also kind of see SBOs as, as something similar, which is like, they are good opportunities for flow because you can help developers share information amongst each other, identify opportunities for more investment as opposed to kind of balkanization. But it also does introduce a lot of friction because now people are really worried about should I share?

Should I not, I can't patch it, but it's not actually vulnerable. Well, it might be vulnerable, but it's not exploitable. Right.

So then the risk equation changes. So to answer the real question, I think the thing we're doing about it at Qualys is we're helping people get business context to real, uh, intractable problems in information security. People just walk by here.

It's all good. Yeah. It's all good.

Well, welcome, welcome to a conference. Should have this guy on. Yeah.

We should have stopped him. Yeah, totally. A man in the street, Which to take on s bombs.

Yeah. But, but you know, the law's changing too though. And I think maybe that's another piece, which is we're gonna be made to do these things.

Right. There's now a, a shifting belief, especially in democratic governments across the world, that they wanna, With that word, Supposedly democratic governments across the world that are trying to align to transparency frameworks. Right?

Right. And there's good reason for that. You know, in a, in know, mission critical system or a life safety system, I absolutely need to have the transparency, the sbo.

Yeah. And it's hard to tell the line sometimes. Yeah.

No, I agree. I agree with you. And, and so I think, I think we're still wrapping our head around the whole SBO M thing.

Yeah. How to use them effectively, how not to overuse them. Yeah.

And I also think, you know, back to your democratic government thing, we we're, we're definitely seeing, um, not a bifurcation, but a, a difference of opinion Totally. Of what the role of regulatory compliance should be. Yeah, that's true.

It maybe more of a laissez fair, you know? No, that's, that's Really true. I mean, look, the, I I think something that's interesting is like, if you're following the space, you're looking at vulnerability management, you'll come to know that the national vulnerability database is an amazing repository, but it's almost entirely critical and high rated vulnerabilities, That means everything's high.

Nothing's high. Yeah. Right.

So it's not useful anymore. So if you apply that same understanding to software bill of materials, it means that everything is gonna be bright red right on, on, on the chart. So then the, that brings us to the friction issue, right?

The resolution is in going above what the CVE says and getting the attestation from the developer of the product. And that's where VEX and the cybersecurity advisory framework come in. So Thi this gets also to, you know, with the government shutdown here in the US Yeah.

We've kind of kicked the can on whether we're gonna fund CS a Yeah, totally. Going forward. And CSA had undertaken to maintain the CVE vulnerability database.

Absolutely. Because they had already kind of cut money from NIST and Mire and all of this. I was talking to a gentleman, uh, it was a tech bro who sold this company for a billion something dollars.

That Sounds nice. Yeah. He started, I, I forget his name.

Nice enough, guy. You should Try that sometime. I wish I could.

Yeah. Um, he, he, the University of South Florida, he started their cyber and AI school. Cool.

And I asked him about this, Alex, and he said, well, you know, seaside had a big budget and they weren't always using it more efficiently. Maybe we need a different mouse trap. Maybe we need a different infrastructure.

Maybe something like, you know, you're, you're, uh, cyber risk exchange. The, uh, you know, maybe we need more private public cooperation. Sure.

Fair. I don't pretend to know the answer to that. To tell you the truth, I Had a, I had a great opportunity early in my career to work at the Department of Homeland Security.

I worked at CSA before it became csa. Okay. I would never expect a arm share quarterback on budget decisions at an agency that complex.

I just don't think that's fair. But I think it's a fair call to say that like, we all have to use these frameworks and these kind of utilities, right? So what's the user feedback on them?

And I think generally we have positive user feedback on, uh, NVD and on, uh, MITRE CVE and cw. I agree with you. I think they're indispensable.

I also don't think that they are solving the problems that now users expect. And the difference isn't are they doing a good job? They're doing a good job.

They're Doing a good job for what they're designed to Do. Right. But now we have these different Questions.

The missions changed. Yeah. We have different questions.

I agree. So, but that doesn't mean we can't adapt this to the new missions. I agree.

I, you know, you don't throw out the baby with the bath water. I would like to see, I would like to see the, the government consider how might you enhance and enrich the scoring, not necessarily in NVD, but possibly elsewhere in other programs to take in new intelligence information, like from producers like VEX or cs, a, the cybersecurity advisory framework to say, I get that we have this vulnerability, but here's what it really means. I am really proud to work at Qualys because we give our customers that context.

Right. Um, I'd also like to see more context for people who, uh, aren't Paul's customers. They should be, we'd love them to be sure that's fine.

But like we live in a real world where like operators have to work across lots of stacks. We're not selfish enough to think that anybody or everybody's just gonna use our product. Maybe they should find whatever.

But I think the real point is, uh, we have a shared understanding here that risk eats vulnerability for breakfast. Right. Let's get everybody on that train so they can manage risk and not just be fearful of everything.

The fear doesn't help. What a great way to end this interview, Alex. Exactly.

I can't think of anything else to say beyond this say, smart guy here and a dad. We're gonna take a break on, uh, texture on tv. We're gonna come back with more Qualys Rock on in just a moment.