Open-Source Security Challenges and Dependency Management with Brian Fox at Black Hat 2024

This is Textron tv. Hi everyone. Alan Shimel here, tech Strong tv.

Welcome back to our Black Hat coverage. You know, we're picking it up from, uh, this morning's sessions. We're really happy to be joined by, you know, what, 17 years.

Its Sonotype. He's a fixture in the security community. Big, you know what he, he's, uh, he's wears his heart on his sleeve in terms of open source and open source security.

Security. He's been a big contributor to so many different open source, uh, foundations, projects, and movements. I'm a friend, Brian Fox, CTO Co-founder at Sonotype.

Brian, welcome. It's good to see you here. It's Black hat.

Thank You. Yes. So, how many years of this, how many years of Black Hat is this for you?

Honestly, this is my second really? Might Not go to Black Hat. I don't know why.

I think it was always just not a good time in the summertime for the kids That first week. It's not a bad prime now at I'm hundred 12 degrees. It's 116 when I landed yesterday.

Yeah. No, it's cooled down today. Um, footprint.

It's crazy. But no, Mitch and I were talking, I think our first blackout was 2004. We were still secure then.

Right? Yeah. Co-founder, it still secure.

It was over at Caesar's. It was very different than it is now, but of course, it's, it's grown. It, it's, it's another show where by the security industry for the security industry and where, where it's a great time to meet up with friends and colleagues and, and really get a chance to talk security.

Um, but you know what, Brian, it occur me before we jump into Black Hat and what you've been seeing here. There might be folks out here who are not familiar with Sonotype. As I mentioned, you're a co-founder, CTO, you're at Sonotype 17 years.

This isn't a Johnny C*m lately Yeah. Company. But for those who may not be familiar with Sonotype, let's just take a minute Sure.

And give them a little background. Sure. So, Sonotype, uh, you know, we, uh, started some of the, the other founders and I, we were, uh, main contributors on the Apache Maven project back in the day.

Uh, Apache Maven is a build system for Java. Uh, not exclusively Java, but it started in Java. It's an Apache Software Foundation project.

And, um, and, uh, and, and we kind of built from there. We built products and, and, uh, and solutions around the ecosystem. So our first product was the Nexus Repository Manager.

Sure. Which was really the first commercial repository manager all the way back in 2009. Um, there's a open source version that, you know, that still exists.

And, um, you know, from from there, we, we also run the Maven Central repository, which is really, that's the repository where all open source Java components are. There is not another one. No.

So anybody doing Java is getting open source components. You can't really write Java without open source, which means they're downloading it from us In spite of what Oracle Says. Right.

In spite of, in spite of that. Yes. Um, you know, Oracle publishes open source projects in Central as well.

Yeah. And, and, um, you know, so running that repository for the last, you know, effectively longer than the company's been around, provides really interesting insight into the ecosystem and what people are doing, what they're downloading, um, you know, good and bad behaviors. And so probably around 2010 we recognized there was a pretty big gap in the behavior versus what you would expect.

So what do I mean by that? You know, some of the most popular versions of important libraries like crypto libraries happened to be the ones with level 10 known vulnerabilities that had been around for a couple years, and yet people were still using them. So that led us down the path of, you know, trying to understand what's going on here.

Why is this problem exist, and how can we help solve that? You know, and that led to, you know, a portfolio of products that, you know, the world would now refer to as, uh, software composition analysis. Uh, more recently SBO M capabilities, you know, but we've been doing these things now for what that was 14 years ago.

Um, you know, when, when, uh, most people didn't understand the, the importance of Open and Source in their portfolio, they had no controls for it. Sadly, the majority of industry still sits in that position. And I know you've heard me say this before, but you know, we've all heard of Log for J, log for Shell.

Mm-Hmm. Where, you know, in December it'll be, what, three years For Log? For Log for Shell Got it.

Log for Shell three years post. You know, one of the most significant vulnerabilities that, that, you know, uh, was impacting our industry. And, um, I last looked last week, 30% of the downloads of Log four J are still of those known vulnerable versions three years ago.

Wow. But I'll go one bit struts, another one that Sonotype was way ahead on. Right.

There were multiple, not even the struts that Struts two that got, um, that, that caught Equifax. That where there were some, uh, that proceeded that by three or four years at least. Yeah.

And, um, and, and, uh, so it's, it's shocking to see that, uh, consuming organizations are still by and large doing a really terrible job at managing their dependencies. So this brings up something, Mitchell and I discussed it at our last interview. You, when we started Still Secure in 2001, we, we came out with intrusion prevention.

'cause we thought who would not want to just stop traffic? That's bad. Instead of just detecting and alerting, but we were wrong back then.

People were not into blocking traffic automatically because they were afraid they were gonna block the CEO's corner or whatever. Right, right. Or email, but yes.

Or well, the same thing. Right. Whatever.

Right. But the security industry's come a long way since then. Right.

We are into sort of automatically taking Yeah. Action. I would say that's the bleeding edge still.

It still is. Yes, it is. It's early.

But we're getting, we'll talk To crowd straight that way. Yeah. Um, with that being said, maybe what this said, what you just, you know, the, the idea that we're still downloading, I think with struts too, like 70%, four or five, six months later, we're still downloading the vulnerable Mm-Hmm.

Version of it. Maybe what it says is they need Big Brother to do it for them, or warning labels slapped on it. You know, I like your password manager says, this password's been compromised.

Yeah. Well, no, This, this component is out of date. Like when I go to Amazon now, and I look at the thing, it says, there's a newer version of this product.

Wouldn't it be great if we had that even, I'm sure you've thought about We have. And, you know, those are the, the types of products that we've been building for a long time. And you get to come.

Right. Uh, right. And, and, um, you know, it's, it's a little bit of a challenge because certainly the ecosystem pulling from Maven Central, it's not just Maven, it's Maven, it's Cradle, it's Ivy, it's scalable build tool.

It's all of the bespoke integrations that everybody has. You know, it's the defacto place, like I said, for open source Java. So anybody that wants to download that, whether they're using Curl or Wge or whatever, um, they're just doing it.

And that's where a lot of these, the these, uh, the consumption is going. And so it's not just a case of like, oh, just add a feature to Maven. Um, because Maven itself is built into many different tools like Jenkins and ides, all of those have an upgrade cycle.

We've been down this path before. Yeah. Trying to reduce friction.

It takes five plus years before, you know, bleeding edge features that we put into the core actually are deployed enough to really Yeah. Add a critical myth. Yeah, exactly.

And so, so that's not a reason not to do it, but that's sort of just the reality check on where we are. And I think the other problem is, many of the organizations that are still really exhibiting bad behaviors, they're also not upgrading their tools. So the people that most need the help aren't gonna get it by a new feature.

Right? Absolutely. And, and that, and that, and that in therein lies the problem.

And, and, you know, people ask me a lot of times, why don't you just take all these versions off of LI Central? And that's a really complicated thing. One of the, one of the benefits and the reasons why it is so embedded and popular is because it is intended to be immutable.

And, and it's an archive of all the things. Right. We can't just decide to disappear components because they affect some people.

And you know, the analogy I like to use is, you know, peanuts, peanuts can kill some beef. Yeah. Absolutely.

Lethal. If you're, if you're allergic to 'em, I can go in the super wagon, I can buy peanut butter, I can buy anything that has peanuts in it. It's labeled clearly.

Mm-Hmm. Hopefully. Um, and, and so most vulnerabilities look a bit more like, you know, uh, peanuts and somebody with a peanut alger, it affects some people maybe significantly, but not everybody.

Now, malicious components, that's different. That's more like a poisoned, you know, a component Of course. If there was a, a malicious component that's coming down.

Um, and so the log for J one is an interesting, uh, case that I use. I think it's a useful bellwether because it was so easy to exploit. It was so widely deployed, and frankly, it got so much attention that everybody was asking their vendors if they were affected, what they were gonna do about it.

So even if you were on the edge case where it didn't really apply to you, it was just easier to fix. It's like saying, I don't do business in Europe. I do GDPR doesn't apply to me.

That's right. It's, it's like, okay, but it's easier just to comply and move on with Bly. And so, so I feel like unlike most vulnerabilities where you wouldn't expect the community to get to a hundred percent upgrade because they don't all apply equally.

Log for Shell was closer to that. It's still not a hundred percent, but man, it's gotta be better than 60%. Right.

And it's critical mass stents, right? Yeah. To me it's that 70%.

I'm Curious, you're mentioning, um, how many things are out there using old versions of software, coming off of even, do you think automation things that are automated that people don't have to touch and upgrade, is part of the contributing factor to that? Or is it just pure, I think it cuts both ways. Hygiene.

I'm just wondering how much Well, I think it's, it's sort of, or worse. So it's, it's interesting. And I, I, I feel like I wrote on this, or maybe we talked about it at one point, but you know, there, there, there, there's sort of two different approaches.

If you look at the different ecosystems. Maven, when we de designed it, we preferred stability over, you know, auto upgrades for the dependencies. Right?

And so that means mavens not gonna fetch the latest version just because it's in the repo. That's actually an anti-pattern in Maven land. That unintended consequence of that is people who aren't paying attention to their builds, it's gonna stay where it was.

Right. Which 15, 20 years ago, that kind of made sense. Who preferred stability over instability?

Um, but now in a world where auto updates happen, that's a little bit of a, a challenge. But take the, the inverse. Um, many of the other ecosystems, NPM, Python, um, new get, things like that.

They prefer the latest unless you tell it not to. So their behavior is 180 degrees the opposite. Well, what's happening over there?

Massive amounts of intentional, malicious components being injected. Why? Because they have a ready audience.

As soon as it hits the repository, you've got millions of downloads. Yep. Right?

And so the, the attackers are exploiting that. So we're not seeing that on Maven, because you would have to, you'd have to, you know, fake the name, which is much harder in Maven because of the way we manage the name spacing. But also, even if you did, nobody's gonna download it right away.

Um, you have to then trick them into thinking this is a new Version. They don't mask. See this like, that's right in Doc, was it Docker hub with Docker Swar?

It was the Docker, uh, repo. They they did have that where they had people putting up bad container Right. Images that had a similar name and would fool people into des it.

That's right. But when it's automated, that doesn't work. Yeah.

But Brian, you made an interesting point here, and it's very nuanced. Nuanced. Nuanced, Nuanced.

Yeah. Right. So I got that bad New York accent, but it's very nuanced.

And, and that is this distinction and, you know, between vulnerability Mm-Hmm. And maliciousness. Mm-Hmm.

Right. One is sort of a precursor almost. Before you have malicious activity, there has to be a v almost a vulnerability or exploiting.

But just because you have a vulnerability doesn't mean necessarily this malicious, it's like The difference you, something could be exploited versus a scatter keystroke blogger built into the Yeah. Yeah. I mean, I think, uh, so, you know, I did a, that's a good example what you're talking about.

Uh, uh, we, we talked to very smart people in industry and companies, and they struggle with this, that, that they want to think about malicious components. Like it's a vulnerability and it's very different. And so I actually recently did a little bit of a series on LinkedIn where I was throwing up some images and trying to find a good analogy.

The one that seemed to, to resonate the most is, is this. So, uh, a a vulnerable component might be some food that's been out at a buffet for a while and not kept at temperature to egg salads. Been sitting around.

It might might make you sick. It might not. It Makes me sick.

I I've been there. Right. It's gonna make some people sick.

It might not make all the people sick. Cast aren't sounding good. Right.

But, but, but you kind of get your head around that. Like, okay, it, it wasn't intended. It wasn't when it was made, it wasn't a problem, but something went wrong and it, it, it could affect people with weaker immune systems.

It's a vulnerability. The malicious version of that is a food that's been intentionally poisoned. Tainted, yeah.

Right. And so, like, the problem is the way you need to think about this and manage and defend your infrastructure between those two different things is very different. Absolutely.

If, if you found out that your eggs salad was poisoned, you don't fix that by putting it in the fridge. Um, or another, you know, a sort of analogy you might eat around moldy bread, you know, or cut around the moldy cheese. Ooh, Hasn't done that out there.

College. Right. College.

But, but you wouldn't do that if the bread was poisoned. Right. And so, like many organizations right now are trying to deal with malicious components like it's moldy bread, and they're just going to eat around it.

And they're thinking, well, it's okay. As long as we do scans at some point before we ship our software, we'll catch it. Well, here's the problem.

Most of these intentionally malicious open source malware components are trying that they execute as soon as the developer downloads it. Because ecosystems like the ones I mentioned before, NPM, Python, Ruby, most of those execute something when they're downloaded. And so that install script is the thing that's delivering the payload.

So it's often a smash and grab style. It's hitting the developers, it's stealing credentials, it's dropping back doors, it's doing whatever that attack happened as soon as your developer downloaded the thing. If you then run in your CI build after they're done coding, they might not even see the malicious component because it might not have compiled, the developer might have realized, oh, I grabbed the wrong one and I fix it, not realizing they've been backdoored and then they check it in.

And the rest of the infrastructure never detects that that component was there. Or even if it did, it's too late. The attack already happened.

Yeah. And so this is, this is why I've been trying to really like drive attention to this, is that you might have a decent system for dealing with vulnerability. So I mean, like the Log four J thing, we talked about many organizations actually don't, but let's assume you do that.

Defense does nothing to help you deal with the intentionally malicious components. You need to be able to detect and block this upfront before your developers get it on their machine. And that's why this distinction is so important for people to understand because they actually have this gaping hole in their defense and they think they're covered.

I, and part of it is, I don't know whether it's human nature or not, you would think people in the security business having been exposed to this, are a little wiser. But it's hard to wrap your head around someone saying, being intentionally malicious right now. But we live in a, a, a, this is why we can't have nice things.

Right? That's right. We live in a world where there are intentionally malicious actors.

That's right. Whether it be nation state or, or, or financial gain or, or hacktivist or whatever. They do intentionally malicious things.

And if you are almost 25, 28 years in security between us, we've been in security most of a century. Right? Right.

If you are not thinking about what an intentional attack, malicious attack is going to do, how it's going to do, where your vectors are, what your attack surface is, don't call yourself a security person. Right. This is, this is the world we live in, unfortunately.

And if, if that's, you know, even, look, Mitchell and I sold the product in 2005 van, that's still secure vulnerability assessment and management. And I, I used to call it not only I, when we'd go out and do customer, you know, reviews the, the, the security people would call it job security because, you know, it, it just generated a list of vulnerabilities and how about it? And you know, back then if you skinned once a quarter, you were way ahead of the gang.

Right? Right. That was after stuff was deployed, not before deployment.

Um, I think it's, so the attacks are evolutionary though. It's sort of like life finds a way. Well, the attackers do too.

I recognize that there was a wide open underbelly here, and now they're leveraging it against us. And, and that's the problem about that. Has it evolved to, it seems to me that kind of a approach where the developer downloads it and something executes is not only a good way for INTA to get malicious or something into the code that goes into your code.

It's also a great way for a supply chain. I may not need to touch your code after I've gotten that MI get into the, the CI/CD build process, or I go do other things in there. Or I'm, I'm part of PO that got put into the, into the whole thing.

Right. This, this whole idea, The sleeper cell, they're all over the place. We see some that are clearly designed to get into the product and then get shipped to, you know, downstream to, like SolarWinds is sort of an example.

Yeah. Not, it's not exactly the same. But the intent was the same that it, the goal is to get after your company's customers.

But, but the real risk is most of these are after your company's developers and your developer infrastructure. Right. And in a modern world where everything is in the cloud, somewhere in that system has the keys to one of those online databases probably.

Yeah. Right. Those secrets in the code, in the code or in the environment.

Yeah. You know, and that's the risk. And so we've seen for, these are old examples at this point, years now, uh, years ago now, we've seen examples where people got into, um, there was one, uh, it was a camera company that had, uh, surveillance, uh, for Tesla factories, hospitals, uh mm-Hmm.

Leased in interview departments, you know, the, the closed circuit. Um, they got in through, um, through the development infrastructure and then moved laterally. 'cause they picked up something from a developer machine that then got them into the database, and then they went from there.

And this is the point, you know, if your defense is only set at focusing on securing the, the product, you ship out the door, you're missing the new war, which is after the whole Left Part of it, the whole left part of it. And that's why I want people to understand that they're really not defended against this. Yeah.

I, I, so I, I did a, a little bit of work, you know, and I'm not blaming any company, any company can get hacked. So I'm not badmouthing every company gets every rehab company just question they have. But you look at like the Okta Mm-Hmm.

Breaches. And there've been several. Yeah.

JumpCloud another company similar to Okta. Mm-Hmm. Uh, also had a breach.

Was it Snowflake? Snowflake Snowflake, recently. Right.

Even after all that, they, they got into that build, but not to go after Snowflake, not to go after Okta. Okta works closely with Microsoft. It got them into the Microsoft piece of it.

Mm-Hmm. JumpCloud. There was, uh, they were real, really just targeting out of a hundred thousand JumpCloud customers, there were six customers that they were targeting large companies over in Asia.

Mm-Hmm. Or just a delivery system to get to those they just used Right. As a transit point to get into those customers.

And I mean, that's almost the very definition of malicious. I'm, I'm reminded, you know, 15 years ago, guy named Giddy Cohen, I don't know if you know Giddy. He started Skybox Security, if you're familiar with Skybox.

I, I had the same discussion with him then, because his skybox back 15, 18 years ago, they would draw like an attack back showing you, here's your vulnerability, here's how a malicious actor can exploit it. How, how they're gonna reach it and exploit it. And it, that's when the light bulb went off guilty to me on this.

Yeah. Right. You know, that this, that is the difference between just a pure vulnerability versus an exploitable.

Right. A malicious actor and all this. But, but again, that was 15 years ago.

You gotta smarten up, Man. Yeah. I mean, I've see, I, I wrote about this recently.

I wrote an article called The Ostrich Effect and Survivor Bias, trying to look at other 'cause I think it's, it's humans are, are wired to try to, you know, procrastinate. It's like genetic Yeah. Benefits that are conveyed.

And so it, it pervades our thinking. And so I, I looked at different examples and I, and I wrote about this recently because of this problem where I talked to very smart people and they're in denial that there's an issue here. And we even, you know, we, we analyze, you know, repositories and we've gone to organizations that we, we look at their repository and we're like, not only is this a theoretical problem, you have 15 malicious components in your repository right now, which means those attacks already were delivered somewhere in your organization.

Those things didn't get there by themselves. A developer, at least one downloaded that, or it wouldn't be in your proxy. Yeah.

And people look at that and they go, eh, and it's sort of like, uh, you know, the vulnerability is, It's the cause and effect. That's right. Because it's not close enough to the Well, it, that's, that's the survivorship bias where they're like, well, it might have happened, but I guess we survive.

No, no. It's a meteor coming my way. Call me when it's about an hour out.

Well, It's more like you found bullet found bullet holes in your walls and like, well, nobody died. It's August. I shouldn't, God, I didn't get Shot.

Well, I shouldn't be comfortable with people shooting at my house just because nobody's been hit yet. Yeah. But, and, and don't Get a different zebra tomorrow.

That's right. And that's a, that's always been the problem, right? That's right.

We're all zebras in the herd. And today's not my day. It's a good day.

I just, I don't gotta outrun the line. I just gotta outrun the zebra next to it. That's right.

That's, and, and that's, yeah. But that's human nature. You're Right.

It's, that's, that's what's happening. So, you know, I think we'll get there eventually, but man, it's, it's, um, it's hard sometimes. We, we saw the same trend educating the market around, you know, the SCA and the reason that you needed to manage this.

I mean, like I said, we, and that Was a Long time coming decades. It was, We were all about das and SaaS and I, SaaS and not paying attention to the dependencies until, and It's This Right. Trojan horse that came in on 99% of the organizations that are using open source software.

Right. Right. And now all of a, but now it's accepted.

It took, it took 10, 15 years. 15 years it took, and, and like everything else, it took some high profile attacks. It took struts a couple of times, uh, Equifax.

Yep. That, you know, the, the, the man on the street understanding, you know, some aspect, it took SolarWinds and Log for Jay was really the thing that finally, you know, and, and everybody was freaking out kind of saying, you know, like, oh my gosh, all our critical infrastructure is dependent upon open source and nobody pays these people and nobody. And I'm just sort of like, welcome to the party.

Where have you guys been for the last 10 years? I'm glad you're there now, so let's, let's move on. But, you know, by then, by the time, um, there Was a lot of suffering.

There was a lot of suffering. But Log For Shell was, uh, 2021, I believe. You know, the intentionally malicious components that I started seeing and tracking and talking about and writing in our state of the software supply chain report started in 2017.

So, you know, it was sort of, it was four years. And so like, everybody woke up to fight last decades war four years after the new thing was already taking off. And we've seen it, you know, we've reported it time and time again that since 2017, these things have taken off.

Um, it's doubled again in the last year. We're looking at over 350,000 intentionally malicious components, um, that are, that are out here. And those are our, our Minds to avoid Do up every year.

Every day. Yeah. Every day.

You're right. Every Day. So, and, and look, I hate to come up here and do the FUD thing.

Right. I'm not, and that's not, I know you, you're not doing, you're not doing that for that reason. No.

But the fact of the matter is, you need to understand the difference between vulnerable and malicious. You need to acknowledge that. I don't care who you are.

'cause that's the other thing people say, oh, I'm not a target. I'm not a target. When do they want for me?

I just have No, I mean, these things look more like an automated phishing attack on your developers is what's really happened. Right? Right.

They're putting these things out there and helping people download, and then they exploit from there. You know, and they Look for weaker Sleep. That's right.

And we've, we've seen some people that we work with that didn't have, you know, our data and our tooling. So this was largely invisible to them. They rolled it out and they found, even to my shock, you know, uh, you know, dozens and dozens of malicious components already in the infrastructure.

And some of those were deployed on tens of thousands of actual production systems, which is all The, which is no walk in the park fix. Right. And that's a pretty significant thing when all of a sudden you, you have visibility into this problem and realize it's been there all along and you have no idea what it's been doing.

Talk About rolling. But to my, I was gonna say though, but to put ourselves in the shoes of our audience out here, who the hell wants You mean? I gotta update 10,000 machines.

But wait, you can't do it automated. You gotta blue screen and death. You have To, it's worse manually.

It's worse in a malicious environment. Hear that. That's evidence that there was an some kind of attack.

You now have to understand what did that component, do you got work to do and, and did it, did it infiltrate that machine? Right. It's not just like I have to update the software.

You still have to do that because it's in your software, like a vulnerable component. Except now you don't know what damage it may have done. Where else.

And you have to, you have to declare an incident and try to go figure out if, if there's been more damage. I Like your food analogy. You know, you were talking about egg salad before.

But think about it as well, we could Near lunchtime, uh, There's no food here in Vegas. Spoiled egg salad is a way to skip. No, I was, It's kind of like, okay, well let's step back.

It's really about the cleanliness of the kitchen. Mm-Hmm. The software development process and the tool chains and all things that sources into that are Very much, well, if you handle your food correctly, you don't.

Yeah. Why we wash our hands is what do food and, but importantly, it's that tainted somewhere in that Process. That's right.

But those things won't stop you from somebody who's trying to poison True. Right. Washing your hands and, and keeping stuff cold.

Those are like basic hygiene Self-inflicted. Right. But, but if somebody's coming into your kitchen and poisoning your ingredients or Delivered bad Ingredients Right, then, then that's a very different problem.

That's right. And, you know, to take it to Deming, like we talked about Deming forever. Sure.

Right. Like you think about the auto manufacturer, it's like demming principles largely are about producing better, safer cars. Right.

The product that comes out the end of the factory. That's great. You need to do those things.

'cause there's lots of benefits also. It's not gonna stop somebody trying to blow up your factory. Right.

It's not gonna stop a malicious act. That's right. Exactly.

That's right. Or selling you defective tires that you put on the car that causes That's right. Intentionally defective.

Again, that's another thing. That's right. Guys, I wanna pivot though, if it's okay, Brian, I'm gonna ask you to put your Sonatype hat on now.

Okay. You can leave your security advocate hat on too. But from a Sonatype perspective, you guys got some interesting things going on with SBOs.

Mm-Hmm. One of my favorite, you know, kind of the granddaddy of, uh, of, uh, DevOps virtual events all day. DevOps is October 10th this year.

Yep. You got some stuff rolling out there as well. Tell us.

Share. Yeah. So all day DevOps, that's the, as you know, the, the 24 hours of multiple channel around the world.

Around the world live streaming, um, stuff. So I'll be, I'll be leading a panel with some other industry experts talking about this year's state of the software supply chain report. This is the 10th year.

Absolutely. Um, so I'm, I'm personally writing the 10 year look back. Uh, oh really?

The chapter to kind of look at how all of these trends have, have changed. Not all of those trends have gotten better as we've talked about, but, you know, I call it like I see it. Um, and so we're gonna be talking about those findings.

I don't have all the findings yet, but you can imagine there's a lot of these trends we've been looking at that we didn't just wake up as an industry and get better overnight. No. But that's part of this evolutionary thing.

You said it's e evolution's not linear. No, it is one step backwards, two step forward, one step sideways. It's very slow.

And then all at once. Right? Yeah, exactly.

So, so, um, so yes, we'll be, we'll be launching the report. Uh, we'll be talking about some of the key findings and, and what, what to make of that, uh, on all day DevOps Yeah. Coming up.

com Com. Yep. Um, I, I don't know, you can register right now.

They probably have at least your session and other speakers up there. It's usually amazing. It's 24 hours.

Follow the sun, as we mentioned. And it's, look, I, I, I think I sponsored it was one of the co-sponsors of the first couple ones. Mm-Hmm.

Um, media sponsors. com. Yep.

And, um, so always happy to see that doing well and, and having a good all day DevOps. And it's important Mitchell, just, we're just gonna be releasing finally the, uh, got DevOps report. Yeah.

DevOps, which kind of looks, you know, where DevOps is gone and where it's going and all day. DevOps is kind of like that as well. And in register you get access to all the recordings.

You don't literally have to sit there 24 hours and watch five channels, that's thing. Yeah. Unless that's just, you can, uh, but you don't have to.

You can watch 'em, but your lecture Yeah. And, you know, you can try to follow the sun. Yeah.

Anyway, um, so we've got that. What about SBOs? Yeah, so I mean, we, we launched, um, you know, a product called SBO Manager.

We announced that when we were together in Paris. Absolutely. No, that was Right before the Olympics.

All the way back in March. Yeah. Uh, forever ago now.

Um, and so, you know, that's the, the, the reception on that's been really good. I think organizations are, you know, it, it's still early. People are still, you know, trying to figure out what to do with SBOs, what they're expected to do with SBOs.

But, um, regulation is coming, you know, next year. 0 standard, has some requirements, uh, for that. So a lot of banks are sitting up and paying attention.

Of course, the government has been, you know, increasingly requiring that, uh, across, uh, the US government, the, in, in Europe, you have the Cyber Resiliency Act, which is basically, you know, not by the exact same terms, but effectively saying you need to have, uh, bill of materials. Yeah. You know, and, and there's still a lot of conversation.

There's a lot of naysayers in the industry about, well, SBOs aren't gonna solve all the things and they're Right. But, but you can't start an, uh, solving a problem without the transparency, without the visibility of what's actually in your software. And You know, that one of the things we've all been, as I said, we've all been a security award type stop looking for magic bullets that solve everything.

There is no such thing. That's Right. I've found one yet.

But this is a solid what? Stop looking for it. Right.

This is a solid, it's not even, I want to call it technology for it, but it's a solid way of really getting a handle on things and helping. Does it solve every quarter case? No.

No. But sunlight, it's better than what you got. That's right.

Sunlight is a good disinfectant. Being able to see what's inside the transitive hall of the products you're using. Yep.

You may not like what you find as a vendor. You may not like what your customers find. Well, what are you gonna do about that?

Hiding it is not the answer. No. That's where we are today.

And Just sitting here and waiting for some perfect solution that's gonna solve all of life's mysteries for you is ridiculous. I mean, it's just unrealistic. But It also follows the general principle.

Every security same team starts out with I have to know about things in order to That's right. Secure things. That's right.

So this is what gives that Visibility. That's right. And, you know, some people argue like, Hey, look, this dependency take log for J it's at the bottom of the stack.

It's 10 levels deep. I didn't choose that version. Um, that's okay.

Now, you know, in some cases there are mitigating controls, like in the log for Shell, you could have blocked the J and DIL app anywhere else. Yeah. Right.

If you knew you needed to. Right. So while you may not necessarily be able to affect the upgrade of the dependency until your whole supply chain does, it doesn't mean you should sit there and be a completely unaware and b completely defenseless.

Most of the time you can have some mitigating controls, and it starts by that visibility. So if nothing else, having that visibility, um, is, is there. And you know, you see vendors that are like, but I don't want all my customers calling me and asking me to upgrade.

It's like, well, I mean, But they're gonna want information sooner or later. Right. 'cause this is gonna be Really nice though.

I mean, didn't get outta the kitchen. Yeah. That's kind of my point.

Like, yeah, if, If don't cook All, all of the excuses not to do it are not the kind of excuses you would typically tell your customers. I mean, I, I literally, I was in a, in a, in a session, uh, on that, uh, two years ago where everybody was kind of in denial and really upset that they were being kind of forced to provide, uh, transparency. And I sat there and listened to all the arguments.

And then, then I got up there and I was like, think about everything you just said. None of you would say that to your customers. Absolutely.

None of you would say, I don't actually know what's in my software because it's too expensive and it's too hard to do. Yeah. Like, really you're gonna say that.

So take a step back from a society perspective and ask yourself, what's the right thing to do here? Put Yourself in your customer's Shoes. Exactly.

And if that's not a good place to be, then something's wrong. That's a pizza. That's right.

Right. That, that's the Bottom line. And, and that's where, that's where a lot of the pushback on SBOs is coming right now.

Because I think organizations are prepared, like we talked about, to actually, you know, uh, show what's inside and ultimately it's gonna be painful, but it's necessary. What do you, where Do you think we need to, what, so to the naysayers, right? And you acknow it's not the silver bullet.

What do you think the next evolutionary step is for SBOs? Where do we need to go next with it? Well, I think obviously organizations need to have good ways to, to collect them from their suppliers.

Right. Um, you know, to transport that data, to be able to analyze the data, understand it, you know, of course in the early days, s bums aren't gonna be complete. They're not gonna be accurate.

'cause not everybody has SCA tooling that can, you know, precisely generate them. Um, unless of course you sonotype customer, then you do, um, that's Less than a setup. No, no.

I, I made it one for view. Okay. A ball and run.

Right. But, um, you know, so organizations are gonna be able to, to, to validate that DS bombs are correct, that the data in there is useful, have an opinion about the, the stuff inside, and then be able to respond. I think that's going to be the next evolution.

Um, once people grapple with, I don't like what this SBO is telling me, then I think that will lead to better architectures. It will lead to better selection of components. That's the sunlight being a good disinfectant kind of thing.

Yeah. You know, if, if you have a terrible unused unmaintained dependency in your stack and your customers start seeing that what's gonna happen, you're probably gonna make a better choice. And that's gonna lead to better, better security outcomes, better software outcomes in general.

So I think that's where that goes. It's going to take some time and it's gonna be a little bit painful because we've all been kind of developing in the shadows for a long time. Very.

And coming out into the sun's gonna be painful, but it'll be okay Just working in a world of con not that everybody's doing it, but continuous deployment where software is updated, You know, very Frequently. Yeah. Well that's where you need the tools.

It's gotta have Automation. You've gotta order Stuff it into a Database, so, yeah. Or exactly right.

That's right. I'm, I'm usually not a big fan of government intervention in security, for instance, or in technology in general. 'cause they, whether it's the EU or the us, we, you get a lot of politicians who may not have much technical background.

Their intentions are good, but the road to hell is lined with them. Um, but that, that being said, I think the way to shorten that timeframe to get critical mass adoption in use, so things like SOM is to have government regulation mandating it and, and kind of forcing the issue. Yep.

Um, you know, you mentioned PCI, well, you know, PCI was great 'cause everyone takes credit cards, so it became sort of a universal thing. But I I I do think we don't have 15 years to wait for SBOs to become Karma. We don't even have five years to wait for SBOs to become carbon.

Yeah. And I, I, I don't see, I, I think that's the best catalyst to doing this, is having like csaw and, and I, I will tell you, not getting into politics, but CSO over the last three to five years, so even predating the pre the current administration has been almost a breath of fresh air. Mm-Hmm mm-Hmm.

In, in saying, Hey, let's work together, government and industry. Yeah. In the last two years, Two, it's gotten a lot better.

They've Got no doubt About it. They've hired a lot of, a lot of good people there. They're doing a lot of good work.

They've engaging, you know, I'm, I'm talking with them all the time. And, and that happens never, you know, five years ago. Well, there's chorus, nobody to talk to, right?

No, do, yeah. No doubt about it. But this is a case, as they said from Vincent, this is a case where they could, could really help us.

We lost a decade. I mean, you probably remember this, but it was in 2013 that the language that ultimately came out in the executive order, um, that that led to all the SBO work came from a bill that was before Congress in 2013. Yeah, absolutely.

They didn't get anywhere. Um, so we lost a decade on this. Who's the flip side, right?

You look at all of C's, you know, proclamations or whatever you wanna call 'em, they don't come with congressional approval. And so they're very subject to administration, to administration, how they're gonna be a force to whatever. We still don't have the political will in this country, but That's, we're just one country in the world.

And pretty much every software vendor's a global vendor and, and you know, like it or not, that's where, you know, some of the European regulations pushing the ballot, they've At least have exhibited the will to do something. That's right. That's right.

And more power. So, so, you know, it's going to be, you know, the least common denominator, you know, most strict kind of, kind of regime that we're all gonna have to follow. The harmonization of those, those regulations is going to become a key issue.

And I know, you know, I was just speaking to, uh, to, to Alan, uh, Friedman Friedman last night talking about some of this. And, you know, global harmonization is a thing that, um, is, is on their radar and trying to figure that out because yeah. If we, if we end up with incompatible global regulations from a software industry, how do you deal with that?

You can. And, and so, you know, um, whether, whether our government gets, uh, you know, together and, and moves it forward or another one is almost irrelevant. It's going to happen.

It's happening. It's happened. Some of the legislation has passed, So I forgot what the term is.

But past, present, and future are altogether That's right. The same. That's right.

Continue. Singular. Yeah.

Singularity. Um, anyway, Hey, before we drop off, Brian, quick plug here. A little tech strong plug.

We're working with you and ica ICA from Sonatype. We're gonna have a special text on TV series that Brian's gonna host. I am tickled pink about this.

This is gonna be really cool. Looking forward to working with you on that. We'll also be doing a series of learning round tables.

Um, so Brian, we're gonna see each other a lot. Yeah, well probably in Salt Lake City too for uh, Q Con. Yeah, I'll be there.

That'll be, it's just a couple months out. Maybe It won't be so hot there. So Salt Lake City, probably not in October.

I don't think it's early enough to ski or anything. There'll be snow, but, but yeah. Yeah.

Um, yeah, we've got that. We've got all day DevOps again, October 10th all day. com.

That's about it, man. Thanks for popping up and taking time outta your black bat days. Yeah.

This is the kinda conversations we need to be. Yeah, Yeah. It's great.

I love, love. Cool you guys. Check it out.

Brian Fox, CTO co-founder at Sonatype here. Well, I live at Techstrong TV from Black Hat. We're gonna take a break.

We'll be back with more coverage.