Techstrong Gang – April 23, 2024

Hey, everyone. Happy Tuesday. You know, this open source insecurity thing is enough to drive a psychiatrist.

Crazy. We've also got Cisco jumping back into security in a big way and some news from the, uh, Linux Foundation about, uh, jumping under onto the AI bandwagon or trade. We've got all that and more for you.

We're live on Textron Gate. Hi everyone. Welcome back here to Textron Gang.

It's a fine Tuesday morning as we're heading into the home stretch of April here. It's gonna be a very busy couple weeks for us. We've got RSA network, uh, conference, or RSA conference streaming up, working with our friends of Futurum Group on their six five, uh, AI event.

And we have a bunch of virtual events and just so it's conference season, it's crazy, but we've got some interesting stuff to go over today. Before I jump into it though, let me introduce you to who we have on as our gang for today. Um, joining us as usual, from high atop the Rocky Mountains.

It's not John Denver, it's Mitchell Ashley. Hey, Mitch. Welcome.

Rocky Mountain High. No, good day. Good day.

Good day. Monday. Absolutely.

Tuesday. Sorry. It's Tuesday.

Yes. Yes it is. See, I told you about that.

Rocky Mountain High. He doesn't know what day it is. No.

Yeah. Uh, it's all good. Thanks, Mitch.

Glad to have you here. And joining us again from San Angelo, Texas back home after a couple trips on the road. Our own Amanda Rini.

Amanda, of course, is editor of Textron AI and digital CXO. Hey, Amanda, welcome. Hello.

Nice to have you here. And then joining me here. Live in person, uh, at Techstrong headquarters in beautiful downtown Boca Raton, Florida.

Can, like the old Johnny Carson Show was in Burbank. Uh, that would make me end McMahon. I'm not.

I would kind of make, well, yeah, kind of Beaver breath himself. I'll Be Doc Severance in. He could be Doc Mitch.

We're showing our age, but for those three of you who get all those references, thank you. But let me introduce you to Mike Bazaar, chief Content Officer here. Hi Everybody.

So week starts off with more news around open source insecurity. And I gotta tell you, as someone who's generally a big advocate for open source software, it pains me to see all of the headlines we've had recently around open source insecurity. I, I'm still a believer that open source is no more or less insecure than commercial software.

I I think all software to a certain extent is insecure. But, you know, with increased visibility and increased usage comes, you know, you, you're more of a target on your back and you're more vol, You know, It's gonna happen. Well, let's walk through the sequence of events.

So for those of you who have not been watching this, uh, slow motion train wreck kind of emerge, but it started out with discovery of a vulnerability that had been injected by a developer who had been working on this XZ utility project, which turns out was used by the Linux Foundation inside of the core operating system. And then last week, the folks over at the Open JS Foundation, I think on Tuesday or Wednesday morning, said that they too suspect that they have issues, but they didn't specify where or how exactly. And then the open SSF came out a day later and said, we think that there may be issues with every open source project.

'cause the bad guys have figured out that they can contribute. And part of the issue is, well, we need contributors to open source, but we haven't been able to vet these folks as closely as we want. So bad things happen.

Mitch, I know you were talking about this at the, uh, open source summit. So what's some folks, but what's your take on what's going on here? Well, I was fortunate to talk with, uh, Brian Fox from Sonar Type, and he's very involved, obviously, in a lot of open source activities.

And he had kind of a concerned look down his face when he came by and to do his interview and start talking about it. And he said, so let me give a little bit of background. So the, the what happened on XZ is kinda what I'm calling a sleeper cell kind of attack, where someone for a project that had been around for a long time, this XE is part of many Lennox distributions, is for a, a encryption, if I remember right.

Um, it was kind of in maintenance status, right? Not a lot act of things happening on it, the person, but they call a single maintainer project in this case, meaning one person doing it wasn't part of a, a foundation wasn't supported by a lot of other people. About two years ago, someone started using sock puppet email accounts and, and directly contacting and kind of getting some activity going, more requests coming in.

So over time, this person started to build up some trust, um, and at, at some point gained maintainer status, meaning he could commit code, uh, that would go into the distributions. And that's when, you know, nefarious things got injected into the code. So it wasn't, you know, it like said it's a slow motion car accident, right?

The, the thing started a couple years ago, and Brian came by and said, you know, we're finding this wasn't the only case. We kinda always worried about this as a possibility, but hadn't seen it. Now we've seen it once.

Maybe we've seen it twice or three times. We're we're really concerned about how widespread this might be. Not not, you know, it's not like every project.

It's not just one project, it's somewhere in the middle. They just didn't know enough yet, and they haven't announced any details about it. So I am sure you'll be writing more about this.

Mike will be Talking to a lot of people about it. Well, somebody's gotta do something about it. Right.

But what's your sense of this? Because, um, I caught up on, uh, some of the interviews with Linus Toal about this subject last week, and he was saying, well, it's concerning and troubling, but he also pointed out that the peer review process in the Linux community caught it relatively early. 'cause while the fellow was contributing a lot to xxi, it doesn't seem like he was poisoning that particular chain of code till later.

And so the amount of time between when the bad code showed up and it was caught when his opinion was relatively short, I'll be really honest with you, it scares the crap outta me. And I'm gonna tell you why. Yes, the Linux project has the peer review processes and people in place to do such a thing.

But the, the Mitch, you know, anybody know how many open source projects there are? There's gotta be tens of thousands if hundred No, the number now, it's so big. Yeah.

It's, I would guess 90 plus percent of open source projects do not have the, the infrastructure, the peer review, the, the, the depth of, of, of, you know, sustainability, that they're doing good code reviews for every piece of code that gets injected into an open source project. 88, 8 million of 'em don't have anything like this. And the issue is a lot of them are begging for people to contribute code.

And a lot of 'em, like this particular XZ thing, may find their way into some critical pieces of our infrastructure. Um, you know, I, I don't know what the right answer is, other than, you know, so let me back up. You know, I, I do a lot of, we all do, we all interview a lot of the CNCF projects, right?

There's 180 and CNCF for Loren and Summer are sandbox and some are incubated, and then some get graduated. Part of that process of moving up the pecking order is how many people are involved in the project? How, what processes do you have in place for code, uh, joining into the project?

How many maintainers do you have? How many downloads, how many bug trackers and, and so forth. I think, you know, when it comes to open source technology, it's kinda like, you know, I'll go all political science on you.

The more hands in the pot, the more people voting, the more people involved, the healthier the project is. But when you have projects that are just a handful of people, as the overwhelming majority are, and you don't have that peer review and that, you know, code review kind of process in place, it's, it's gonna be, it's, it's bad news. Mitch, what's your sense of how many people are kind of downloading raw bits of open source software versus relying on somebody to curate that for them?

And maybe if I'm your average enterprise, I'm leaning heavily on a Red Hat or suse or somebody like that to kind of fix all this issues. And maybe we should be doing more of that because of all the issues that he just described. One of the best practices is to rely on a few trusted sources, but even take it a step further and have your own repository that those go into from those sources and then go into your software cycle.

I think that's by far the, the vast minimum of projects most people are downloading. Now, is everybody downloading xz? That's a really small component in the Lennox operating system, but I think the issue, Mike, is it's, it's, it's, uh, software built on software.

Software built on software, right? How many commercial products are using a distribution of Linux that might have this in it? It isn't just a Linux, right?

It's the open source world and commercial products. 'cause I mean, I was looking at a piece of software they're crediting the open source they were using in a commercial. The list was long.

So I, I think that's a best practice to get to, but I don't think we're anywhere close to everyone. No, we're not. You know, there's another commercial for the whole SBO thing, right?

It would be great if you're an enterprise and you just found out that, uh, the XZ utility has some malware in it. Okay. I wanna know where I have XZ throughout my enterprise.

Well, let me run all my SBOs and see. That's right. Amanda, I'd like to get your take on this because maybe most people don't seem to realize, but a huge percentage of those AI models running around out there that you write about are built on this open source software and using those open source toolkits.

So this might just come and bite as harder than we think in the future. So, um, given how dependent we are on some of these AI models, uh, you know, how concerned are you? Oh, absolutely.

It's, everybody should be concerned because what are these attached to? Who's using them? Who has access?

And, um, as I was listening to y'all speak, I just wonder if there's some way for those projects that don't have a lot of people to watch over them and be involved, is there some kind of tool or technology that could be used as a kind of in place guardian that's constantly scanning them and alerting? Um, you know, maybe that's the solution. Well, to your point, the open SSF is trying to do that and work with a lot of these maintainers, but I don't know if there's enough money in the world to solve the problem.

No way. There's not enough money. 'cause most of these open source projects, they're just not open source.

They don't have commercial, you know, sugar daddies and, you know, they, they don't, I mean, there's not enough money. They're labors of love for most of these people. All right.

There's a phrase I, I didn't think I was gonna hear on this show anytime, but sugar daddies, okay. Hey Mitchell, sugar Mommies, you know, I, I don't discriminate Mitchell. So do we need more money from the people consuming open source software to help fund this?

'cause it does seem like there's a huge percentage of the population out there that benefits from it, but I'm not sure they're giving back. I, I think so, but I, I do think we need to support it more financially, but it has to be in an orchestrated way, right? Just giving money to whatever random project that you happen to, like, might be helpful, but that doesn't necessarily fix any of these issues.

Um, I, I think it's hard to know what the answer to this is. 'cause it may not be just one thing, but we've sort of ignored this problem right up until now, until open source has started to get a lot of press, you know, thank you. Meaning they've gotten the, the attackers have taken some very highly used, highly distributed and kind of core from Log four J on, et cetera.

But a lot of these, and that's what's getting the attention of this. And of course that just breeds more of, oh great, that's a great approach. Let's take a variant of that and do something else.

So we have to figure out a better distribution, you know, acceptance of software and distribution mechanism. And we can't just rely on the kind of bizarre to handle the any back to the Citadel Bizarre book to just kind of handle it organically and as, and as altruistic and as fortunate. We've been that that's worked pretty well for us.

We now see where it doesn't work and that it's not fully working for us. What is your take on that? I'd love to get it.

'cause we've been around this block a few times, and by gosh, that Log four J thing was supposed to wake everybody up. It was the ultimate wake up call and everybody rolled over and went back to sleep. So what's the deal?

Look, Mitchell and I had the same conversations for Code Red. Uh, what were some of the other big ones? I love you, Byron.

The I love you cold red there. There was more. You know what, this is the security business.

They're never going go away. But, and here's the thing. You gotta remember, the bad guys are as smart as us, or smarter in some ways, right?

And they're always looking and probing and finding a new vector and, you know, you can't build the wall. I think we found that out about immigration and software. You can't just build the firewall.

You can't build the wall. They're always looking for a new ingenious way to inject bad code into, into it. And look this open, the open source one.

I mean, quite frankly, this has probably been going on for decades. Yeah. Mitchell, aren't we our own worst enemies?

Because I remember, I think it was one of the universities was contributing bad code to Linux back in the day as some sort of test, and Linus and crew flipped out, and rightfully so. But basically they, we built a roadmap about how to poison open source software and handed it to the bad guys. And it seems like I wake up every day and there's some researcher going, Hey, I found some other great way to abuse something.

And you know, we, so we seem to be helping these guys more than we're helping ourselves. That's still open disclosure model, right? There's a way you're supposed to do it where you don't disclose it until you give people an opportunity fixed address it.

But that doesn't always happen. That's also, I don't think a, a big enough way to really solve what we're talking about. That's just, uh, it, it is kind of handing the guide, but you know, there's, there's things on the internet to build anything you want.

I won't go into what you shouldn't be doing, right? Not just software. And that's true for, for, uh, vulnerabilities and how to attack software too.

So I don't, just like Alan's point, I don't think that goes away either. Even if we said, let's clamp down on that, that, that it's not going away. It's why we can't have nice stakes.

But, um, but let me, let me end this discussion on this. Uh, though, for all of the issues here that we're talking about, and they're real, and as I said, they do scare me, let's not underreport or underappreciate the tremendous impact and open source software has had in allowing us to get where we are today in terms of how we build software. How much of our economy is based on digital.

You know, digital transformation and so forth would not be possible without open source software. So in many ways, open source software is a victim of its own success. Fair.

Don't throw the baby out with the bath water. Absolutely. Exactly.

Exactly. All right, let's take a break here on Textron Gang. We're gonna come back.

You know, Cisco, which for many years was the largest security company in terms of revenue, is making some noise again in security. Let's talk about it. We'll be back on Textron Gang.

I'm Bonnie Schneider, sustainability contributor to the Textron Group. I'm excited to introduce you to a groundbreaking new initiative from Techstrong Research, the sustainability pulse meter. The pulse meter offers valuable insights into how environmental responsibility factors into tech purchasing decisions for key players in the industry.

Position your company as a leader in the industry and differentiate from your competitors with a sustainability pulse meter offered exclusively from Techstrong research. And we're back. And as Alan promised, we're talking about this Cisco initiative, which normally we might not call out one particular vendor, but it's interesting what they're doing here.

If you remember, I think at the beginning of the year or late last year, Cisco bought a company called ISO Valent. They make software that's generally used for virtual networking using EBPF. EBPF is a sandbox in the Linux kernel that lets you run software faster and more securely.

And now they've taken this to the next level where they're saying, we're gonna inject an AI inference model into the Linux operating system on any endpoint you want to put it on. So whether it's at the edge or in the cloud doesn't really matter. And then the next thing they're saying is that that inference model will create a digital twin of your application environment.

And then they will use that to monitor the security flow, including sending a patch that you wanna install. They'll run the test on the digital twin, and if it passes on the digital twin, then they'll upload it to the actual production environment. And this is a rather closed loop kind of play.

And not every version of Linux out there just yet is running EBPF. And someday Windows is supposed to run EBPF. But, um, let's start with Mitch.

I mean, what's your sense of what's going on? We've been fighting this patch battle for as long as I can remember and, you know, are we finally getting to some higher level of automation? If you step back for a moment, I love what they're doing here because o one of the things I talked about with many people at um, open, uh, software Summit is applying digital twin idea and also applying AI to it.

We have a whole code base in applications, whether it be a small, you know, single Python script or larger application that you could simulate, right? You don't have to run it in production. You could now simulate that, which is what this is doing because you've got EPF and some other capabilities and you could, you know, think about tabletop exercises we do in security to gain what are ways we might be susceptible to this kind of attack?

You could do the same thing with software before it goes into production, or maybe while it's already in production and not have to attack what's in running live, but you could do it against a digital twin. This is a teeny, teeny sliver of that idea. But I think that holds a lot of promise.

Um, just like we do canary testing, you know, with, um, with some performance testing on a certain slice in production, we could do this with digital twins. This isn't the panacea answer to everything of what Cisco's doing. I think it's an example of a, a really powerful idea that we can leverage.

You know what Mitchell and I have been trying to talk people into patching and remediating their vulnerabilities in real time for 23 years. Oh yeah. I got t-shirts and scars to prove it.

I hope we're ready for it. Is digital twin going to be the equivalent of the test lab that they used to test them in? Maybe?

Alright, Well I think the issue, Mitchell, as I understand it, is that the development side is hesitant to deploy those patches without testing them. 'cause they're afraid that the application will break. It's not the development, it's not the developers, it's, it's all the way up to the C level.

Mm-Hmm. You know, I remember Mitchell, you might have been with me, we went to New York. We met with a guy named Peter Fisher.

I remember Peter Will. Yeah, Right. Peter was one of the three global CIOs for Citigroup at the time.

It was still Citigroup, not Citi. And we weren't there to sell 'em. They, uh, the still secure vulnerability access and management program.

We had pro product we was had at the time. And we asked Peter, how long does it take him to do a patch, like from when the patch first becomes available? Or he said, well, not less than 90 to 120 days, sometimes more.

It said, this is common. I said, why? How, how the hell?

He said, well, look, Alan, you know, we're a big company and we've made the determination that we're better off being vulnerable no matter how bad it is than to breaking something that's mission critical to our business. We could deal with a, a vulnerability and the losses from it. We can't deal with certain things being broke.

Huh. Now to me, I, I'll be honest with you, I, I thought I was hearing things and I, I just, I, I couldn't believe it. But this wasn't mom and pop.

This was city group. And, and this was what their determination was. And that's when I realized we'll never get automated application security or vulnerability management until something's gotta get until something absolutely Changes there.

I think the calculation on that is changing though, because there's more writing on software than ever. And the risk levels are higher now. And we're seeing more ransomware attacks today, and that ranches up into the billions.

So do we need to just get smarter about what we're patch and when Mitchell, because not all patches are equally risky, right? So there, there's two ways to look at this. Just to be really simplistic about it.

There's kind of the normal, let's test, let's make sure it doesn't break anything. Let's deploy it. Let's go through that cycle.

Right? That's what we've been doing since then. And before the days of talking to Peter Fisher, right?

The the other way to look at it is, hold on just a minute. Maybe it's your ability to respond if it doesn't work, as opposed to your ability to test it before you deploy it. Right?

So deploy it. If you have an issue, back it out. If you could back it out instantaneously or in a few minutes, and you're not gonna have the production line on the manufacturing of a new car, go down for an hour while you, you know, because of some problem, it can be back up in seconds or minutes or whatever it might be.

That's, that's a powerful capability. That's a different kind of defense that's a defense because of your response to it. So I, I think it's not better, harder, faster let's, you know, get the patch out just that much quicker.

Um, I think there's other strategies to address this. I Think he just said there's this DevOps thing that might help us here. Oh, did I say that?

And, and, and look, not to be, you know, woe was me. I forgot what the right Henny Penny or whatever guys fault you guys are talking about. Pre-deployment vulnerabilities, right?

Vulnerabilities in code that we found kind of, you know, as part of that, well, in Theory you could update something as part of a DevOps platform. Yes, you could. But, you know, post-deployment patching is, is not even a real thing yet for most people.

Uh, you know, and, and it is a real thing for most people. Automated post-deployment, patching being a real thing for most people now, it's changed. I think the biggest change, quite frankly, has been the nature of the applications we built, right?

We're all very used to our apps on our iPhones and Google phones, Android, whatever being updated in the background continuously. Now, I will tell you that 75 to 85% or more of those updates are, are bug related. You wanna call 'em bug or security vulnerabilities.

They're, they're vulnerability related. And, and so we've gotten used to that and I think that has made us more desensitized Mm-Hmm. To doing more updates automatically.

But, you know, a big enterprises, it's still very much, what is this gonna break? I also think part of the issue is developers don't really wanna spend a lot of time writing patches. 'cause that's not nearly as interesting as writing new business logic and new applications.

And we don't reward them and call them heroes for creating the patches. We kind of treat it like it's maintenance activities and sometimes we get the most junior developer we can find to write the patch and it takes longer. And, um, frankly, you know, that whole SecOps to application development thing we've talked about in the past's just broken.

Well, and I think that companies are looking at what's the level of risk being POed to the user and the company, and is it worth the time and effort being put in with some of these fixes? And that's always the way it's been. Look, I remember talking to a big retail company Mm-Hmm.

5% loss, breakage, shrinkage, whatever. 5% we could live with that. And they do.

And, and that's the way it is. I wanna bring up another point though that we haven't hit on, and that adds, this is Cisco talking about this, right? Cisco, as I said in the promo leading up to it, Cisco was for many years the top cybersecurity security vendor based upon revenue.

Now, a lot of that was when network security was king, right? Cisco firewalls, Cisco, I-D-S-I-P-S, Cisco n Cisco, you know, endpoint, well they had an endpoint, but the, uh, unified UTM wasn't that it Mitch? Mm-Hmm.

Unified Threat management. Yep. You know, that was the bread and butter of Cisco.

Now you have Cisco who's bought duo security, right? And most recently Splunk. And so you're gonna start, I think, seeing them move into this DevOps shift left kind of app SEC mode where before that, you know, the, the, the bread and butter was network security, the old source fire stuff.

And well think We're talking about Alan, this is a, this is software security they're talking about. Yeah. Not network security.

Mm-Hmm. This is whether it's network code or not, they're talking About No, that's what I'm saying. So this, for Cisco, this is a big push into this, you know, different area for them, It's part of the Splunk app dynamics, rolling all that stuff together.

Do what duo's in there. That as well now, but I think it also talks to follow the mud. Cisco is recognizing, you know, network security isn't the king of the hill and hasn't been for a while now.

Um, and, and they want in on, on AppSec. AppSec is where it's at for, you know, that's the dynamic part of the, of the, of the food chain right now between software supply chain and SBOs and so forth. So this is a big vendor saying, Hey, I want my share of the pie.

Is there enough? Is there enough room for everybody? Or will we see some consolidation in this space you're Talking to?

There's always enough room it seems, you know, I remember going to RSA 20 years ago and having a conversation with, do you know there are 800 venture backed security companies and we could probably only support 300 half of these people are gonna disappear. Then a couple years later is, do you know there's 2,500 or 3,500 venture backed security companies? We can't support more than a thousand or so.

Two thirds of these are gonna disappear. I was talking to someone a couple weeks ago, I think I was with you, Mitch, I'm not sure, but there's something like 7,000 and more venture backed security companies right now in a field that could probably hold, I don't know, maybe 1500, 2000. They're all the next unicorn too.

So Yeah. And everyone, well, and we're hearing stories about that, right? Where they didn't make texture on gang.

But you know, it's amazing when you have a company that could go from eight and a half billion dollar market cap and talk about being sold for 150 or 200 million with supposedly a hundred million of a R right? At one and a half, two times revenue. Man, it's a crazy world out there.

So I don't know, is there room probably, will Cisco make room for themselves? I suspect so they bought some quality assets, right? Didn't it?

You know, Cisco's one of these companies, they don't necessarily, and and this has been, and I'm not calling out Cisco, but this has been the, the ML in security for a long time. Companies like Cisco don't innovate. They buy innovation, right?

Right. Whether it was Symantec and McAfee back in the day, or Cisco or Checkpoint or, or so many other of the big guys. Most recently Palo, we've seen Palo be a huge acquirer.

Uh, they've brought quality assets. Cisco, they paid top dollar. Somebody from Cisco will be writing you an email shortly.

But other than that, it's Mike, You know, one things I wanted to bring up is, this is not, I don't have official data point other than kind of Mitch's finger taking the temperature in the wind, but last year at, at, uh, RSAC or just a month or so away from N Now, um, was the first year where in my observation, we were actually talking about AppSec in any meaningful way. I mean, most of the interviews we did on Broadcast Alley, now maybe half of, were talking about in some ways software supply chain AppSec, not just network security stuff, the latest, you know, zero trust approach or whatever, all valid stuff. But to your point, you know, maybe Cisco is the next, next DevSecOps company.

I don't know. You, they'll, they'll become that, um, like, like Splunk was a security company, but I I I think the networking and security side of networking has to become software security driven, period. I think you're right.

Um, application security was the redheaded stepchild of security for as long as I can remember. And part of the issue was the security people spent money on stuff that they could control so they can control a firewall. So that's where their budget went.

And they thought the development community was gonna do something about application security, and the application development community thought the security people were doing something about it. So not surprisingly nobody did anything. Is that changing?

Pretty Much, much. Oh, I, I think AppSec, I'm king of the hell these days. Uh, AppSec is your biggest, you know, whether we're talking about the traditional AppSec of SaaS DA scanning and all of that stuff, or, or SCA software composition analysis or, you know, some of these other things around patching and remediation.

And it's, it's, it's where the action is. And it has been, I feel a lot of this is gonna get rolled up into what we're calling DevSecOps platforms now. I mean the, the flavor of a modern CICD where security's just part of the, it's another gate in the flow.

Well, It's quality and that's what we've said. It's synonymous with quality. But the thing, the lesson we've learned through DevSecOps and you know, all the years that I've been involved in DevSecOps, is don't just give it the name DevSecOps and assume developers are gonna be your security guys.

They're not. You need the security people involved in your CICD process. You need automation in AI as Cisco is saying, uh, as part of that to do it at scale.

But don't, don't fool yourselves into thinking that your developers are going, you know, uh, developers', mamas don't let their sons grow up to be security people. Yeah. I think we've somehow let DevSecOps get absconded into shift left and developers do security.

I think the, the real definition that we are in now or moving towards is DevSecOps is security end to end. Not just the SDLC, but also into production. It's also vertically all the stuff you're building in the layers of software you're using to the tool set and the workflows and the work tool change you're using to work across all of those.

That's what DevSecOps really needs to be. But if you're not addressing that, you know, shift left Okay. Helps a little bit, but there's a lot more to work to do if You talk to lot of developers.

Sorry, sorry, Amanda. Oh, no, I was just gonna say it's about the tool set. I'm hearing more about the digital twin technology, and I think we're gonna see that being utilized a lot more in across every industry.

There You go. But to Mitch's point, um, Schiff left, there's a lot of people who say that just means s**t left. Because the developers look at it and go, you're giving me all these alerts, I cannot make heads or tails of it.

It's just noise and you're making Me, you giving me more work. Yeah. Making me accountable for stuff I can't control.

Yep. It's shift everywhere. You know, the guys at our friend Larry Ma, who's speaking with Mitch at, uh, the RSA DevSecOps, uh, AI thing we're doing, you know, that's what they call it.

Anyway, you gotta take a break here. I don't think we're gonna solve the AppSec conundrum today, but we'll keep working on it. We'll be right back with more, maybe some Linux Foundation news here on, uh, Textron Gangs.

Stay tuned. All right. And we're back.

And as promised, we're talking about a new consortium that the Linux Foundation has launched. It's got this awesome name called the Open Platform for Enterprise ai. I think that's op, I'm not entirely sure how to say that, but, um, Amanda, I know you've been covering this space on Techstrong ai, but I'd love to get your impression on this.

I have lost count of the number of consortiums that have been launched in the AI space, so I'm not quite clear what one does and what the other one doesn't do. Well, there are a few, but, um, they have partnered up with some pretty big companies, um, and they're promising that this is gonna allow for a lot more innovation, um, utilizing open source. Um, we'll, we'll see where it goes, but I mean, it, it does seem to be, um, getting the attention of a lot of business leaders, I think calling it anything but open AI probably didn't have the ring to it, but it sure sounds like this is a effort to kind of maybe contain those proprietary platforms.

What's, what do you think? Well, I, I don't know if you can contain, so it's funny, if you ask the AI platform people like Open AI and, and some of the others, they'll tell you, what are you talking about? We're open, we're based, we're big believers in Open.

We, we, we, you know, we support Open, I applaud the Linux Foundation for doing this or trying to do it. And it's great that they've got some big names in here, which is kind of their always mo they'll get some big names. I think that what we're going need to see is talk to me in six months to a year, whether this is just someone's grand idea or there's really a, um, enough will within the market within, you know, these big guys and little guys to actually do something about this.

And, and, and then quite frankly, is the Linux Foundation the place to do it? Well, Mitchell, I'd like to get your sense of the, the word open means a lot to a lot of different folks and, um, when I hear folks throwing that around is they have an open API that doesn't mean that the backend is open, and it doesn't mean that it's replaceable and easily swapped out. And I think that's what this foundation is trying to get at.

But frankly, I also go the other way on it. I'm kind of with you on this. I think most enterprises have figured out that I need open source software so I can swap components out so I don't get locked in.

So I'm not quite clear that there's a role for a consortium to kind of tell me that maybe what I already know. Well, um, by the way, the I'm open, use my APIs, that means I'm open, that that's a sin that's been repeated way back, you know? Mm-Hmm.

The open systems, you know, initiatives of the nineties. So that's not a new argument. We've seen that, that story in that movie before.

I almost think like this foundation is about addressing the confusion of all the places you go to and all the models you can get access to, and all the tools and all the open AI is this and that, and trying to coalesce that together into something a little bit more structured or, or understandable and adjustable by enterprise organizations. Can you imagine being in, in a very large enterprise, you know, somebody like Citibank or a really large insurance company and, you know, all the fiefdoms are trying to run off and do their own AI thing, and where are we getting this from and what's that latest thing that popped up there is sort of a bubbling up into we want to use these set of tools, um, or technologies or LLMs or whatever it might be. And, and when they talk about frameworks in this foundation, I almost think that that's what they're going after, is let's try to just at least coalesce it at little bit and simplify it so that enterprises can, enterprises can say, this is where we're gonna kind of work from as our base.

I could be wrong, we'll see where it evolves. Right. But to, to your everybody's point, this will evolve over time and kind of prove out what it's gonna be as it grows up.

But that's my sense right now. I would disagree. I I agree with Mitchell.

How naive do you think the average enterprise leader is these days? It seems to me that they've been around the block. Yeah, but they have stars in their eyes.

You know what I mean? Look, this is a, and I'm, I'm part of it, right? And I have been part of it.

But this is a, an industry that, you know, revolves around shiny trinket syndrome and AI is the shiniest trinket to come down this way in a long time. So you just tell me, I put AI between two slices of bread and I'm ready for lunch. Right?

Um, you could put ai, you could spread it on anything. Mm-Hmm. And it makes it taste good like the candy man or something.

So the supernova of shiny objects, Right? Yeah. That's, that's, that's the, so until that hype, you know, burns down a little bit, I, I think we're gonna be naive.

We're gonna be starstruck, we're going to be, you know, everybody has to have an AI story. What's your AI story? Are you leveraging ai?

Oh my god. A lot of fmo There's a lot of fomo Going on. Absolutely.

You don't wanna miss out on this AI thing, then it's gonna cost you your job. Amanda, let's pull it back full circle here through the first block. So we have a consortium that's promoting a lot of use of open technologies that we just discussed earlier, might be vulnerable to people injecting malicious code in it.

And so maybe proprietary platform sound pretty good all of a sudden. I don't know. What's your take?

Yes. Well, and we were having this conversation a couple of days ago that while open source is certainly, um, the most effective way, uh, to innovate more quickly and more companies are using the open source, but the closed models are still a lot better. And, um, they're more, uh, they're working better and they're more, um, uh, effective.

So, and they probably have a lot less risk attached with them than the open source. So I don't know. I don't know what the solution is.

I think time will tell. We'll find out. Well, well, that's been the history of it, right?

I mean, open source eventually catches up, Mitch. So, I mean, back in the day you could have said that, uh, windows was a better operating system than Linux. And now after all this joint innovation, Linux is probably a little more robust.

So does open source just eventually catch up anyway, Is that a trick question you're trying to Get? That is because I, you know, Lenox, I, I won't fault for that, Mike, I always, always told Lenox is a better os especially for servers, has been right. 51 had just come out, when was that, Mitch?

Maybe 96, 97. 7 96 or seven. Yeah.

And we were using, of course, uh, actually we were using so, uh, Soliris, but many people were using Linux already. And Apache and the Windows NT of course had Windows information server, their web server. And the guy at Microsoft was really pressuring me to change my hosting company over to a Microsoft platform.

And I said, windows sucks compared to Linux or Unix. He, and this is what he told me, I'll never forget, he said, Alan, today it's not as good. Give me three releases and I'll be better than that.

And that was when I grew up in the industry. That was the mantra, right? It Windows was not what Unix and then Linux was.

And then somewhere along the line, you know, if you had one of those memes that you see that would, over time the graphs, you know, windows became defacto standard, especially for desktops were for most of the server market too. And then of course Macintosh, you know, the OS 10 for desktops. And now, you know, Linux is pretty dominant.

Um, but you get these, you know, these things, I think they're fluid. They have been flow. I think one of the things that I, I to you, I have a similar story, Alan, I remember downloading and using Slack ware, which is kind of the early distributions of Lennox and NT and saying, in this ecosystem, yeah, int makes sense.

And this ecosystem, this makes a lot more sense to go kind of a Linux route. And it, it, it has its own place. So in some ways saying one's better than the other is kind of, well, what's the context, right?

Yep. So that's my Mishy Meshy middle of the road answer to Mitch's Mitchy. That's a tongue twister there, Mitch Mitch's way she answer.

Good way to end though. Hey, we're overtime here. We've got a full day of text strong TV stuff for you.

Stay tuned for it. Uh, we'll be back on Thursday with a fresh text, strong TV show. Got great stuff tomorrow as well, and a Fresh Tech strong gang.

Until then, on behalf of Amanda and Mitchell and Mike and I, be well, everyone, stay tuned for the rest of Techstrong TV. Cloud Native now is the Web's leading resource for the growing cloud native ecosystem. com is your destination for news, thought leadership, features and webinars on cloud native architecture, Kubernetes serverless, cloud native application development, microservices, service mesh, cloud native security, and more.

Stay on the cutting edge of modern application development at Cloud Native. Now.