Techstrong TV – March 21, 2025

Hey, happy Friday. The outlook for DevOps today is cloudy with a chance of AI in some heavy CICD. You are watching Textron Gang.

Hi everyone. Alan Shimmel, tech Strong here for Textron Gang. Wow.

It's Friday. It just seems like yesterday was Monday and today's Friday. And it's not because we record these a week at a time.

It's just that kind of crazy week. We've got a lot to go over, including some new DevOps reports and research by one of my favorite DevOps analysts in the world. Um, some new Java is, can Java be 25, 24?

I don't know. It seems like it's been around that long. And, uh, we've got a little Star Wars.

May the droids be with you? All kinds of good stuff, good people to talk about it with. Let me introduce you to our gang members today.

We're going out west again to, uh, start things off with our Silicon Valley contingent, the the king and queen of the valley. Uh, we've got Lisa Martin. Hi Lisa.

How are you? And great Alan. Great to be here.

Okay. And the King John Schwartz, our Silicon Valley editor. Hey, John.

How are you doing? Hi. It's good to be here.

Happy to be here. Busy week again. Yep.

So what's the sweatshirt today? Oh, we can't really see it. California Golden Seals.

Do you know much about the history of that team? Say NHL? Sure.

California Golden Seals. You remember who owned them? They're goalie.

Yes. Well, I'm, yeah. No, I used to play hockey.

I didn't play hockey. I watched hockey. Hockey.

They were, they were an expansion team in 1967, I believe, along with the flyers and penguins, et cetera. And they were owned by Charlie Finley, Who Yes, they were, they had the same as colors, gold and green. You just stole my thunder.

Exactly. They were terrible. They were the opposite of the A's.

But, uh, they were an interesting team. I got to see 'em play when I was a kid. Didn't, didn't it?

They moved to Vancouver and they became the Vancouver. They grew Cleveland. They moved to, became the Cleveland Barons, I believe.

And then, ah, Yeah, the Cleveland Barretts, The Nor that, that was merged with the Minnesota North Stars, if you remember them. Sure. Anyway, it's a long painted history and, um, you know, it, it, it was, it was, they played in the Oakland Coliseum when the A's and the Raiders and the Warriors were all I remember, I remember though, we're all old enough to remember, you know, I play, I did play hockey, I played roller hockey.

I was a goalie. And what I did is I, you know, we used to have those ball bearing kinda wheels, and I smashed them square so they didn't roll, and I could just walk. And as a goalie, I didn't have to walk too far.

So I very rarely fell. And I, I, I was a good goalie like that. Nice.

Anyway, moving on. Moving on to Colorado. We've got our, uh, future VP research, DevOps, Mitch Ashley.

Hey Mitchell. We've got full on guitars today. You changed the angle there.

Yeah, we're getting, we're getting a little up the upshot on the guitars, by the way. The only seals we have in Colorado are the seals on mason jars we use for canning vegetables and fruits. Yeah.

So This's, as close as we would imagine's what a seal means to you. Okay. I guess that's why it's so regional.

Speaking of regional, let's go to a different region north representing the northeast bating left-handed throwing Right. Getting ready for baseball season. Chief Content Officer Mike Ard.

Hey, Mike, how are you? I'm good. One week opening day three o'clock Thursday next.

Yes. Yes, it is actually. So the game's going on in Japan now.

They're still preseason. Yeah, no, tho No, those are regular season. The the dogs are two and Oh, Yeah.

You might take a week off or, or so to recover from Japan, but yeah, everybody else starts on the 27th. Right. Oh, okay.

Very cool. Very cool, huh? Well, I could talk baseball more, but we've already gotta get going here, Mike.

We've got some new, uh, research coming out of our, uh, friends from futurum. What's going on? Yeah.

The research is on what's happening with DevOps in general. And, um, there's actually two reports. One is kind of a survey.

The other one is a market analysis where we're seeing, I think the number was a 9% compound annual growth rate for the next few years on DevOps tools and platforms. Mitch, I'm gonna let you dive into it, but, um, you know, we've heard all this noise over the years about DevOps, especially in the last two or so. And yet looking at the data things look pretty vibrant.

It, it's interesting, you know, it is kind of, once things have been around for a while, you say, well, is that sort of passe? Or, you know, what's really happening with it? And, uh, as you mentioned, we did both.

We have our own market analysis, the growth of the market, you know, nine plus percent cagr, uh, over the next several years. Uh, but we also correlate that to buyer decision maker data. So we have a very comprehensive, not just looking at DevOps, but really across the entire software development life cycle, considering DevOps and Agile, but also software development, uh, platform engineering, uh, testing, um, application security, uh, ai, AI ops, things like that.

IT ops, let's kind of think about the whole life cycle. And, uh, we had 855 responses to this. com and I'll be having some more stuff come out.

But the themes of it are, when it comes to DevOps is, is we have very high levels of people who see themselves in the kind of three quarters of the game. If you wanna think of a football game or in the fourth quarter of kind of very mastering DevOps or in the, you know, standardizing it across the organization, over half of, of the respondents and, and very few, it was like 14% said they were in the beginning stages. So we're in a pretty far down the maturity stages.

The interesting thing is, we, we kind of divided the, the analysis up into people who were doing dev DevOps, who were doing development, people who were doing platform engineering. When we asked the platform engineering folks, they weren't quite that far along, but not too far behind. They, they saw themselves as pretty mature in their platform engineering efforts probably 'cause they were doing some of that stuff before.

Maybe they're getting more attention and, and funding to that. Uh, a couple of other interesting things is, uh, we had both 41, 40 3% range of people both in platform engineering and in DevOps and in development saying that they're using AI as part of their n aid to their tools. Now, that can mean a lot of different things.

Could mean we're using cursor. It could mean they're just using chat to, to do, you know, code, code lookup or whatever, or get ideas for code. There's a wide range of things, but the fact that, you know, almost half, close to half are saying that they are using AI today.

And the two, the last thing I'll kind of add to that is the two biggest, well, I have my budget for 2025, but I'm planning to spend even more this year and even more in 2026 software security and ai. So those are the, those are the key themes coming out of this. And nowhere really did we see, well, I'm cutting back in these areas.

Almost, almost all of it was kind of full steam ahead and this was late 2024, early 20, 25 data. So we're not, you know, we're talking, not talking sometime last year. This is pretty recent stuff.

Hmm. Interesting stuff. So I, I'm not surprised at the maturity findings, Mitch.

com now for a couple of years, is that, you know, DevOps certainly crossed the chasm, certainly penetrated that, you know, 35% of the main of the, uh, the early 35% of the mainstream right. And is clearly going after the, the other 35%, you know, the, the second half of the mainstream, if you will. Um, what I, what I am pleasantly surprised 41% plan to use AI with it, right.

That, that shows you, I think, you know, almost half half of folks are trying, are gonna be, you know, trying to use AI in, in their software development pipelines. Um, I think the other thing is though, that as part of this DevOps maturation, we've seen DevOps, you know, you know, general Douglass MacArthur said, old software never dies. It just fades into the woodwork.

And I remember that. No, he didn't really say that, did he? But he said something like that.

But, um, He was up to his ankles and water on a beach, right? Yeah, Yeah. Trying to figure out those Right.

Or something. And I don't know what was in that pipe. But anyway, um, DevOps has kind of gone into the woodwork itself, so to speak, along with things like ITSM along with things like Agile, which is kind of the precursor, right?

Agile is 25 years old. And so, and then you have new things like platform engineering, which is really, you know, still very closely aligned. It doesn't replace DevOps works alongside it.

And so, and you things and other new things like s re maybe and, and stuff like this. So we cloud native I should mention as well. So you have this whole echo system of which a frameworks and, and ways of doing things and so forth and, and DevOps is, has taken its place.

Kind of like when you look up at the stars, right? And you see all the, the past rulers of Pride rock and, um, DevOps is up there. So It is, you know, and interesting too, Alan, um, a couple other thoughts.

One is when we asked, so what do you see is, is the most important technology or investment areas to invest in to, um, getting software into production, uh, faster, more consistently? Top of the list. The, the top things we're gen ai, uh, A IML for dev, DevOps and test.

Um, and also software security was up there at the very top. So e even looking at just kind of, what are you using? What are you spending, what do you see as critical, you know, kinda look, you, oftentimes you look at different ways of analyzing those questions.

So you are, you kind of triangulate, are we saying the same thing? It it's very consistent. And these are decision makers, these are buyers, and these aren't, um, you know, just folks reading about it on, on, uh, you know, Udemy or something, taking a course on it.

Mitch, I'd love to get your opinion on this. 'cause when I talk to people, I get two divergent points of view. One is says that with the rise of AI coding tools, the pipelines we have are too brittle and we're gonna need to replace all our DevOps platforms to accommodate for that volume of code.

The other says that AI agents will just pull the data from all the existing platforms and AI agents will manage in those workflows without having to replace any of the, the DevOps platforms. So I don't know what your sense of how that's gonna play out, but right now I can line up 20 people and they'll split evenly on that conversation. Well, I think there's multiple trajectories.

One is moving to platform solutions, that kind of, a lot of the pre-integration done for you, instead of development teams being, being in the tools integration business. That's one path of helping to reduce that problem. Uh, another, and, and it is an issue, especially around CICD.

'cause CICD sounds like one thing, but if you really understand what's going inside of it, it could be 50 or a hundred different types of CID for CSED pipelines going on for different apps, different versions of apps, all kinds of things. So the complexity in that is very high. And oftentimes there's a few folks that will touch it to go resolve it.

'cause it is, it does take some real skill to do that. There, there's a belief that we can put AI on to that task, at least to analyze it and give us more people accessible to be able to resolve issues with CICD with AG Agentic. Then maybe starting to address it, the, the kind of wild card factor is now we have a whole different path of doing development, you know, whether it's through cursor or, you know, Gemini code or whatever your latest, uh, flavor of the day of generating code through, uh, natural language as opposed to writing it.

And how does that flow through into, you know, a DevOps. So in a way, we're making it more complex as we always do, kind of things that get more complex every time. But AI is one of the, one of the potential solutions for it.

But I think there's others platforms are definitely a part of that. com. We, we have an article on there with links, and if you go to futurum group, uh, dot com did research, it's there and there's, and there's also been a huge refresh in the, uh, FUTURUM intelligence portal that incorporates a lot of this and some other DevOps, uh, research Mitchell that you have spearheaded.

And, and, uh, if you're not familiar with the futurum intelligence portal, go check it out. It's, it's actually a really, really nifty tool. If you wanna stay on top, depending what you wanna stay on top of, they have, I like data.

That's the place to go. We do all kinds of analysis. Good stuff.

All right, let's take a break. We're gonna come back here, we're gonna talk Java. What could nothing new in Java is there.

Stay tuned. You're watching Textron again. Discover Textron Group, the epicenter of tech innovation.

We are your go-to for reaching IT, leaders and practitioners worldwide. Our secret impactful content that sparks awareness, engagement, and top quality leads with us. You'll access editorial websites, streaming videos, virtual events, custom content analyst research, and more.

Join our satisfied clients. Let's revolutionize your tech journey. Contact us today and tell your story to the world in the most powerful way with Textron Group.

Hey folks, we're back and we're talking about Java that got a new edition. I think it's number 24. And this one is being driven largely by Oracle, but it has everything in it from, I don't know, post quantum cryptography support to AI capabilities.

And it looks like, you know, Java, the venerable language we're using that word again, is, uh, getting a significant update. And Oracle seems to be driving this despite the fact that Java was supposed to be this whole open source community thing. So Lisa, I know you're out on the west coast, but is Java cool yet?

I think it is, it's hard to believe it's almost 30, but I was doing research on this, I thought, really? 30 and, and the scary, I think it's what's scarier is, I can remember 30 years ago, and it was, was, it doesn't seem like it was that long ago, but yeah, at the event Java 1 20 25 up up the, the shore here in Redwood Shores, they announced the availability of Java 24. The latest version reportedly some of the things they talked about in the press release, thousands of improvements they said to help developers really maximize their productivity drive innovation.

We just talked about the DevOps, um, momentum going on that future machine, that's what organizations of every industry want is to accelerate that business growth. The pedal is to the metal. And it really, I think what we're seeing from Java is it's continuing to really expand its tool set to meet developers where they are their evolving needs.

And I think considering we just talked about the DevOps momentum when the pedal is to the metal, I think this is a good thing. Absolutely. You know, I I re do remembers the little Java logo caricature, the little black and white guy looked like a Star Trek kind of a kind of thing, you know, uh, energy wave or whatever that really is in Star Trek world.

Um, and of course, look, if you're gonna call out Java being 30, you gotta pay homage to sun, right? I mean, for those of us of a certain age, what a golden era of, of computing Sun ushered in with Solaris and Java and Spark servers and all of the great innovations that that came out of there. Um, it's interesting.

It, you know, Oracle or Java is the language Oracle loves to hate or hates to love. I, I don't know. But, you know, they keep improving it.

And, and excuse me, this one really does seem to be a major upgrade, right? You've got AI integration in here, you've got post quantum cri cryptography a little early. Certainly though, look, we're here so much quantum stuff.

I'm, I'm looking for quantum in 2026. Um, and, and of course developer experience tools, which has always been at the heart of Java. The, the other interesting thing is, you know, we are, we go on year end.

We, we, we argue whether, you know, is his line is correct in letting us in, in, in pushing rust over C sharp for colonel and, and what's the latest, greatest languages we're using and do we really care about languages? But you know what, 30 years later, Java still rocks and rules the roost, right? I mean, is there any language that is used more today?

I mean, it, it's a lot more of a fragmented world in terms of languages than it was, let's say 30 years ago. But it's still a dominant, a dominant force. You can't kill this beast.

That's, Yeah, that's what, that's just what's so remarkable about it. 30 years later, it's still relevant. And then they did really did do a push.

I mean, I talked to an executive at Oracle about this. So the only, the only unfortunate thing is that they made the announcement at the same time as Nvidia and the, the monster conference that they had. But, um, you know, kudos to them for, for keeping this alive and making it relevant and adapting, which is something that Oracle has to do as well as companies like Salesforce and C3.

They, they've just gotta continue to foster and, and move along. Mitch, it seems like the appetite for learning new programming languages is not all that high, despite the fact that there's more of 'em than ever. But if you go into your average enterprise, it's Java, Java, Java.

Well, really good point. There's such an embedded base of Java, right? That's part of one of the, kinda like DevOps, right?

It's part, it's embedded within the organizations, right? Once you start developing applications in Java, you're gonna be using Java for, for a long time. And, you know, I have to remember, remember when Java's introduced, it was very revolutionary because that was, the days of the languages were things like c and C sharp and c plus plus, and really, you know, more complicated languages to learn.

And Java was seen as much easier, though it has its own complexities too. But I think the support from Oracle, you know, you called out a couple things, uh, Alan and Elisa about what they announced. I think one of the big things too is the backward compatibility, two versions of Java itself that are included in this new version, because that's always the hassle.

As things mature and mature and mature, you get bigger and bigger embedded base of code of different versions of things. Some things get sunset or grandfathered, whatever, and it's hard to upgrade. It's, it's a, that's that technical debt.

And so I think them by investing and trying to give as much backward compatibility as they could, you know, something's embedded in our, in our software stack, when the people we're talking about app modernization are talking about how do we migrate from Java to something else? And that's, that's part of that conversation too. So it's not going anywhere.

It's, it's gonna be with us for a long time. I think from a marketing perspective, John, you nailed it. It's relevance.

It's 30 years later, it's still relevant. And one of the things that they did here, I I think, again, from that marketing lens is they really nailed what is important to their target audience, which is developers. They're really working on improving the onboarding experience, making this mm-hmm.

Kind of paving this on ramp, as they said. And so I think they're really getting to maintaining a community that's healthier and healthier. The ecosystem is there, but getting these, uh, developers onboarding much more easily, more easily is a, is an a plus.

Remember, Allen, we all thought job was gonna be dead when Oracle took it. We thought, uh, oh. That's the end job, everybody.

Yeah, exactly. I would just like to point out that everybody on this call has been doing this for longer than 30 years and is hopefully still relevant, so. Well, that's In my case, but, uh, I'm not so sure well are, yeah, I'm not so sure.

I try to stay relevant, but, you know, I'm out here quoting Douglas MacArthur, who the heck knows who he is out there's, uh, so anyway, all good. Happy birthday to Java and, uh, good to see it out there and thriving and staying current. Uh, you know, and I'm glad to see post quantum CRI cryptography being used.

Great. We're gonna need it. All right.

We're gonna come back and do our C block in, in right after this break. And I'm not sure if those are the droids we're looking for. com is the leading resource for news analysis and education on challenges facing the cybersecurity industry.

com covers all aspects of cybersecurity, including data security, DevSecOps, cloud security, application security, network security, security threats, and more. com has the largest selection of security content featuring breaking news, blog posts, podcasts, and more. com to learn more.

com. Home of security bloggers network. Hey, folks, it's, John alluded to earlier, yes, there has been this massive conference involving Nvidia all week long, and one of the things that came out was Disney and Google, DeepMind and Nvidia are gonna go build some actual droids, you know, the ones from Star Wars, and you go to the, uh, amusement park there, and you'll be able to interact with these actual droids, whether it's R 2D two or not.

I don't know, probably. We'll see. But John, I'm telling you, this is a conspiracy right now.

And here's how I'm viewing this thing, right? I could dragged into the amusement park, the kids drag me into the gift shop, and the next thing you know, I'm taking home joys. And that's how they get into my house.

Yes, go for, yes. It's, it's like, it's you, you are channeling George Lucas. You're channeling Steven Spielberg.

It was always about the merchandising and the marketing in addition to great movies and great creative creative contents. It was also about, that's where the real money comes. And I think, um, I think beginning next year we're gonna see these Star Wars inspired BDX droids at, uh, theme parks for Disney.

That's the plan. At least. There's a, uh, guy named Kyle Laughlin, who's the senior VP of, it's called Walt Disney Engineering Research and Development.

And he basically said the BD are just the beginning. They're committed to bringing more characters to life in ways the world hasn't seen before. And that's the plan.

And, and, and in fact, I think at South by Southwest, there was a demo of one of these prototypes that was shown. I saw a video of it, it was actually pretty interesting. Um, but again, these are entertainment robots, and I think we're gonna see various iterations of different types of not just droids, but animals.

And the same story I mentioned, um, this new dog that's being developed in Europe called Luna, that, uh, can be trained. It is very strange. There's also, at uc, Berkeley, there's this, a robotic squirrel that's being developed that can leap and, and land on ledges.

So this is the world we're In. He's not rocky, is he? He's, no, you know, there might be a Bullwinkle in the future, but Well, He has a moose friend.

Yes, he does. I wonder if the dog will chase the squirrel. That's what happens in our neck.

You know what? They should have developed that they should have developed the, the Rocky robot at what's the matter? You right.

Not For Yeah, that would've worked. But in any event, um, it's a, it's a very Strange rule. Oh, John, that was, that was, That was a, I I got that from my Brother.

I'll give you, I'll give you a, I'll give you a few bonus points. All right? Okay.

Thank you. Thank you. This is like an ESPN show, right?

Pardon the interruption. But, um, but anyway, that's where the, that's where, uh, Disney's going. And Jensen, it's really weird.

He, he made this presentation in the midst of a 90 minute fire hose of news. So it didn't really get a lot of, they got coverage. I mean, obviously Reid wrote about it and others wrote about it, but he kind of like tucked it into this larger presentation.

And I wish he kind of spend more, a little bit more time with it. There was also, maybe the reason why he didn't spend more time was, there's a bit of a glitch during the demo, so that could have explained it. But Brave New World.

So Alan will Paramount respond with the Commander data as it droid. Is that where this is gonna Go? Well, come on, we're scratching the surface.

First of all, let me say this, and I'm speaking on behalf of Mitchell and myself, I can't wait to go buy one. All right? I guarantee you I am buying it as soon as they're out.

I'd like a C3, uh, CP three more than R two at first, but I'll take anything they got. And then, you know, you know, it's Disney. Who wants, who doesn't wanna buy a princess?

Right? For your little girl, her own, her own Snow White or Cinderella, or, or any of the princesses. But let's go.

And why stop at Disney? Why can't we get data? And why do we have to get drives, you know, make 'em, make 'em animals, make 'em, anything.

This Is so a little secret. I I, I've got my agentic AI agents already on the task, and they are already cornering the market on all the supply coming out of China. Yeah.

Or more. These are being, well, No, there's gonna be a har a huge tariff on this. Huge tires.

Oh, Geez. Tires. Oh, no.

Do you think that Bob, I Seriously, I mean, Bob, Bob Iger must, his eyes must be lighting up at the prospect of this, or whoever, whoever becomes a CEO of Disney eventually. I mean, because they've been struggling with the theme parks. They're overpriced, they've had issues with weather, et cetera.

But this is an opportunity to kind of build a new product line, a new Monet monetize something. And maybe they do it ironically, through robotics. I don't know.

One of the things that stuck out to me is, I was just on iHeartRadio an hour or so ago talking about giving them kind of an update of what, you know, this big AI conference in Silicon Valley is all about with the, with GTC and I talked about the humanoid robots. And there, in the consumer space, there's a lot of fear of, of what a humanoid robot actually is. So I wonder, when I saw this partnership with Walt Disney and Google and Nvidia, is this gonna help start to get the general population more comfortable with robots and show mm-hmm.

How they're able to be used from an entertainment perspective? I think some of the fears out there might be dialed down by something like this. Yes.

Like a kind of cute and cuddly approach versus they're not gonna steal your job. They're, they're gonna entertain you. They're gonna be your friend.

Like I went to, when I went to Carnegie Mellon, we, we had the, the humanoid ro robot there. It was a crude implementation, but nonetheless, it had a personality and almost felt as if it was a, another person in the room. And it, it had a bit of a, a little bit of weird, I hate to say this, but charisma, and it reacted to you.

And I think that is Lisa, you're right. That is part of probably the mindset. I got one.

You got one dude. We're all getting at twice. Okay.

Mitch. Pre tariff. Pre tariff right here.

Um, but come on, this is a no brainer. Will this be the killer app for ai? It could be, or Robots or recreational robots.

And, and, and you know it, and it'll grow from there, right? Because today the robot will do stupid tricks. But tomorrow the robot will, will, will continue to get smarter and start doing your homework with you and Everything.

I'd see your laundry for you do the dishes. Yeah, they'll set up the table. Yeah, there you go.

Might be a little backroom bedding on two robots Having a battle. You never know. Woo.

Spoken like a real Bronx guy right there, man. I, that never crossed my mind. What, what was that?

What was that movie? Not street Rock and Suck Robots will Become Thing. No, no.

Yeah. Well, that would, that would be pretty cool. Crazy.

Anyway, Hey, what a great time to be around. We'll, we'll put, what's his name again? That's not R 2D.

D-B-A-D-B-A, right? We'll, we'll put it to the side for now. Where was, I've had him sitting here all this time.

He was just, he wasn't smart enough. Now I just, I could put a chip in there. Um, anyway, what a great, what a great story.

What a great way to end our Friday on Textron Gang. We wish you guys having a great weekend. There's a lot going on in, in, in the world this weekend.

You know, a lot of us are starting to get a little better weather right now. You know, April is coming. Um, so good stuff all around.

We have a full text, drunk TV lineup, of course, following our gang show today. So do check that out, Mitch. Congratulations on this DevOps research, by the way.

That was a nice piece of work there. Thank you very much. A lot of folks contributed and made help make that happen.

So thanks to the team, everybody. Yeah. Excellent stuff.

But for now, on behalf of our gang and all of us here at Tech Storm, have a great weekend, everyone. We'll see you Monday. We're out.

This is Textron tv. Hi everyone, it's Alan Shimmel back here on Techron tv. My next guest is Lynn Sun.

Lynn is the director of open source for solo solo io and is also serving as A-C-N-C-F-T-O-C member and ambassador. And with cla, uh, CubeCon just less than two weeks away. What a great time to have her on here.

Hi, Lynn, welcome to Textron tv. It's great to have you. Hey, Alan, thanks so much for having me.

Not a problem. So, Lynn, as I told the, uh, audience, you're director of open source at solo solo io, as well as a TOC member and ambassador for CNCF. But you know, there's a lot that covers up a lot of history.

Give us a little of the history, a little bit of your journey. Yeah. So I'm, uh, immigrant to the us.

I'm the person that carries $100, come to the us gosh, 25 years ago. And I started my job at IBM. Um, I've actually worked at IBM for 19 years, uh, before I joined solo, right in the middle of covid.

Um, I actually was thinking about retiring at, um, my job at IBM 'cause, uh, I was working on, is still open source, you know, something I'm really passionate about. Um, but when the founder of Solo I Lavin reached out to me and said, I want you to lead up the Open source team at Solo, I started looking at what is solo? So SOLO is in right in the business of cloud connectivity down, right?

Um, connect microservices, how people expose their services outside of their Kubernetes cluster. So SOLO is right in the domain of service mesh, uh, which is where my expertise was. So I decided to, you know, jump onto the, the hype of the startup hype.

I, I feel like I would regret for not joining solo, you know, take the chance, uh, when one day I retire. So that's how I ends up, you know, being the number one employee doing open source at solo. And, uh, I'm having a blast at Solo.

I love it. So it is a friend of mine, and I do tell her, send my regards, maybe I'll see her in London. Um, you know, it's a great story, right?

'cause you mentioned Istio and IBM and Service Mesh, and of course, you know, Istio though now is part of CNCF was not always right. There was a little history there with Google and how to that was going to be dealt with and everything else. Yes.

But Solo is, has, has always had, I mean, for as long as we're doing, covering the Kubernetes space, which is probably going on seven or eight years now, right? The cloud native space solo has always been a, uh, a player when it comes to Service Smash and all of the things that service Me Mesh brings to it. And, you know, our audience is a very technical audience and they're cloud native savvy.

But for people maybe who aren't familiar with, like, where service Mesh fits into the Cloud Native Stack, Lynn, how, how would you describe it? That's a great, really great question. So, service Mesh is a term, I guess we started about eight years ago when we started Istio.

Uh, there's other projects out there in the market. Linker D is another player. Service Mesh essentially is trying to solve the connectivity problem for microservices, right?

Um, instead of having developers solving connectivity, uh, problems of microservices as libraries, um, in their application service message, solving the connectivity problem, uh, for microservices as part of the framework. So as a developer, when you develop microservices, you don't have to worry about how your microservices connecting to each other, how to have the connection, uh, secure through mutual TLS. You don't have to worry about, uh, rotating your keys and your secrets.

You don't have to worry about how do you observe your microservices consistently. So that's what Service Mesh is trying to solve. Istio is a really interesting project in the domain of service mesh.

Uh, not only we are the most, uh, popular and most, uh, uh, deployed in production service mesh out there in the market, but I always view Istio as an innovator in the service mesh market, right? So two, almost three years ago, we launched, uh, Istio service mesh in ambient mode. What ambient is really driving Istio me is towards being the mesh being totally transparent to the user, right?

That's the word, uh, ambient combo. So when we started HDO seven, eight years ago, we always view service mesh as part of the infrastructure that user can run and forget about it. But we couldn't accomplish that vision of service mesh with sidecars, because with sidecar, with every single newer version of Istio, it could be a minor version or a fixed bag.

You always have to restart their sidecar along with their application. They always have to worry about the downtime, the operation complexity. So, fast forward to ambient.

Uh, by the way, we just announced ambient outreach GA in Salt Lake City, uh, at North America last year. So with Ambient, we really have the opportunity to provide a service measure without sidecar that's, uh, totally transparent to the user on the layer for layer, which provides mutual TLS and, um, and simple policy authorization policy on the layer seven layer with, uh, service measure, we're talking about retry timeouts, we're talking about traffic shifting on the edge. TT P layer, uh, we're talking about reach authorization policy that you can configure authorization policy based on method, based on whether it's GA or post based on certain particular paths, right?

We're getting really rich on the HT DP layer. That's when, um, waypoint come in. And what really interesting to me of is still ambient is we're bringing the vision of, uh, Waypoint as a gateway, um, but serving, uh, interservices traffic inside of the mesh, right?

Essentially, we're bringing the ingress and egress gateway into ambient also as the gateway, uh, for interservice communication inside of mesh as Waypoint. I believe this is also following the Kubernete gateway, API lead, right? Uh, for the audience who are not familiar with the Kubernete Gateway, API, it's the new networking API for Kubernetes.

Uh, people view it as Kubernetes ingress V two, while it not only allow users to control traffic for ingress, but also expand to mesh, uh, with East West. So I'm really excited about eio ambient to, and the, particularly the architecture and the innovation with Ambient. Love it.

I want to talk about K Agent, though, so I'm gonna shift gears here a little bit. Um, give us, give us the low down on that, Lynn. Yeah, totally.

Um, so as I mentioned, SOLO is in the business of Gateway and service mesh, right? So we support hundreds of our customers running, uh, service mesh, uh, using SCO and also Gateway. Uh, our gateway is Glue.

And we recently donate the glue open source gateway to, uh, CNCF as a cn, uh, as A-C-N-C-F Sandbox project called K Gateway. Um, so we have, uh, hundreds of customers running these, uh, projects and or enterprise offering, um, in, in their, uh, data center or public cloud. And what we find out is our customer facing engineers often, uh, when they working with customers, um, they sometimes couldn't, most of the time, they were able to solve, uh, the issues with the customer, whether it's configuration management or figure out how to configure policy across, uh, different cloud, uh, in service mesh, or whether it's troubleshooting, uh, pinpoint, uh, when there's multiple connections in the hub, which of the connections may be causing the problems.

Um, we find out sometimes we had to bring in, uh, the top expert as solos. Certain people like, uh, John Harvard, uh, we have to bring them into help troubleshooting problems. So as our company was scaling to a larger scale, we started thinking about how can we free up our top developers from jumping to customer cause troubleshooting with customers to let them focus on writing new features for, for open source or for our enterprise offering so we can innovate faster.

So, uh, we started to develop through leveraging a agent ai, we started to develop a couple of, uh, agents based on our domain knowledge, which is, is still, uh, observability 'cause we always need to think out observability for Gateway and mes, uh, which is Kubernetes, uh, which is, well, our control plane and data plane mostly runs, uh, helm. We use Helm a lot and our customer team. So we started to develop these sample agents and, uh, use it internally to, uh, help our customer facing engineers when they diagnose or help our customers.

And when they, we started thinking about why not just open source, uh, the agents we develop, uh, 'cause not only we develop the agents, we also develop the framework, um, by leveraging the Microsoft Auto Gen, uh, agenda AI framework. We bring in UI and CRI for Kubernete and have the framework more integrated nicely with Kubernete. So we have the whole framework stack, uh, kind of developed alongside with the sample agents, along with, uh, a, a couple dozens of tools where these agents consume.

So this is where key agent come from, right? Uh, we decided to having something internally useful for us and, uh, open source, the whole thing. And, uh, we want to be able to benefit the broad ecosystem.

Certainly we couldn't make the agent successful by all itself because we only sampled, um, seeded the agent with a couple of sample agents. We develop internally. What we are really hoping for is, uh, in the next, uh, few months, um, we can bring the vision of K Agent Live.

Uh, what we really wanted to have is having every single CNCF projects out there in the CNCF landscape. I'm sure you look at the landscape before, right? It's 200, 300 project.

It's a picture. Yeah. It's quite a picture.

Yeah. It's quite a picture and very, very hard to figure out how to navigate. And once you decided a few projects you want to use, it's also very hard to get started and troubleshooting when anything goes wrong.

So what we had a vision, if Okay. Agent is we are hoping it can serve as an inspiration for the CNCF community, um, that we provide the simple framework, the simple, simple agents and tools, and having the ecosystem, uh, help us to build the rest of the, uh, agents that we don't necessarily have the expertise. So we're hoping to have Project Ance willing to join us on the journey of key agents.

We're hoping to have, um, developer engineers, uh, platform engineers who have a lot of cloud native operation expertise. Uh, many of these, uh, cloud native projects join us and help us make key agents better, help us making key agents, uh, produce agents in the catalog with every single CNCF projects. So people can navigate the landscape a lot easier by having agents sitting next to them when they explore any of the projects in the CNCF landscape.

Got it. Lynn, we don't have a lot of time left, but for people who are listening and saying, wow, K Agent is something I'm really excited about, it's what we need. Excuse me, in the cloud native community, what would you recommend for people who want to get involved in the K Agent project?

Yeah, so we would definitely recommend the checkout K agent do Dev. So that site is already up live since yesterday. Uh, we also have, uh, GitHub.

Uh, so you can go to the GitHub icon on the website. It's k agent dev slash k agent. Uh, we would love to you to check out the project.

They all get started guide on our website. So you can play on K Agent, like what I've been doing for the past few weeks myself. And you can interact with our sample agents, um, using natural language so you don't have to remember some of the commands or look up the project manuals.

Uh, so we would love you, give us a star on the GitHub. Uh, 'cause once the project reach, uh, 500 stars, we are really serious taking it to the next level, which is, uh, donated to CNCF as another sandbox project. That would be great.

Lynn, congratulations on K and congratulations to all the folks at Solo. I know you know it, and the rest of the team has worked so hard at, at Solo and it, and it shows. Um, we will see you in CubeCon at London.

Yeah, thank you so much, Alan. I really appreciate the chat. io booth if you're interested in you to chat.

Uh, more about Key agent. Thank you so much. Thank you Lynn Son, director of Open source solo io, as well as C-N-C-F-T-O-C member and Ambassador here on techstrong tv.

We're gonna take a break. We'll be back. Remember, we will be live all week streaming from Cube Con London.

Should be a great time. We'll be back in a moment. This is Textron tv.

Hey everyone. We're back here with our continuing coverage of Scon 25 in, uh, sunny Orlando, Florida. We've had some great weather this week.

Um, our next guest is, uh, Brett Schroeder. Yep. Brett is chief of the office of CTO.

I head the office of CTO, head, head, the office of CTO at SUSE Worldwide. And, uh, joins us here today after, I guess you've had a busy three days of speaking to customers. Very busy.

Which, which is exciting. It's, I think this is the most exciting, uh, sussan that really we've had since I've joined seven years ago. So yeah.

Good for You. Yeah. You know, I'm trying to think.

I've been to a previous Sussan over in Europe. Was it? I don't know if it was Berlin.

Berlin might Have been Berlin. Yeah. Um, you know what, what I loved about this event this year was, look, it wasn't one of these mega events with thousands of people where you feel like you're just, you know, on the subway or something.

Um, it was a place where you really had a lot a chance to really have great discussions like that hallway session. Yeah. You know, the water cooler sessions were really val for me anyway, I had a chance to meet and talk to a lot of people.

Brett, a big part of your job is meeting and talking to people. Yep. Right?

Yep. Why don't, well, I don't want to describe your job. Okay.

Why don't you describe your job? Yeah. So as office, as head of the office as CTO, probably 75% of my time is spent talking to customers in, in one manner or another.

Um, so that's why I'm on the road. I pick up mail in Austin and, and, uh, the rest of the time is on American Airlines. Yeah.

But, um, so it is, is about that, right? And, and, and how I start off almost every conversation is tell me about you. Mm-hmm.

What are you experiencing? What are you trying to do? What's holding you back?

Um, because I need to learn, right? Um, what are their problems so that then we can apply technology and, and, you know, hopefully bring them the biggest value, uh, the customers, the biggest value from our portfolio that we can possibly deliver. So that's my role is, is really gonna, I love It.

Um, you know, one of the things that I've been, I, I actually wrote an article on Cloud Native now about it, and it, I've been talking to the people. I was very impressed with this DevX design Yeah. That they, they showed us over in the solution showcase the other evening.

I was, I got a hands on tour with it. Um, it's very exciting because I think as, as we were talking kind of off camera, I think one of the issues around cloud native adoption, especially at scale Yeah. Right?

It's that could do science experiments all you want, but at scale is, it's almost like drowning in a sea of opportunities. Mm-hmm. There's so many different solutions for every single facet of a cloud native deployment.

Yes. That I think people are almost, you know, paralysis by analysis that Yeah. No one wants to make the wrong choice.

Everyone wants to pick what they perceive as What's their tool set of Right. Favorite tool set, tool set of choice, and why it's better than the next one. Yeah.

Yeah. But you know, this, this Dev x, uh, uh, framework to me was so comprehensive uhhuh, and, you know, and it really showcased all of the different pieces that Zu has assembled here. Yeah.

And to pull it all together into a platform. Yeah. Truly a platform like that.

Yeah. I can't wait to, you know, I gotta imagine the market's gonna just love it. Yeah.

I'm wondering what you are hearing, see. Yeah. The, um, you know, this really comes back from our two to our discussions with customers, right?

Mm-hmm. As I go out and talk to customers, there is no one model. There's no one IDE, there's no one language.

Uh, and so as we sit back and think about that, it's, you know, us coming out with another, you know, hard opinionated, this is the way you must do things, would not resonate with the vast majority of of customers. And so, and, and going back to your point on scale, you know, I think many customers are now wanting to pass that point of the science experiment, the departmental, um, you know, initial trial, right. And scale.

And so customers are in running into not technical issues so much, but organizational issues in productivity issues in scaling. Mm-hmm. Uh, you know, how do they grow from 100 developers to 2000 developers?

And if you ask every developer, you know, Hey, do you want to go program some, uh, some infrastructure? It's not too many of them that are infrastructure. Well, because they're, they're not busy enough.

Yeah. They, yeah. They're, you know, waiting for somebody to send 'em some more requirements, right?

Yeah. Yeah. They wanna focus on the business.

Absolutely. And they wanna focus on code. You know, one of the things I, I remember I couple of conferences last year, the average developer spends about 25%, 27% of their time actually Coded.

Exactly. Yeah. So it's telling them they've gotta be the security person, they've gotta be the platform person.

Yeah. Ops guy, the tester. Yeah.

That's not what they wanted. No, it's not what they're paid to do either. Right.

A lot of them, that's all fine and dandy, but their manager says, how many lines of code have you Yeah, exactly. Committed. Yeah.

Yeah, yeah. I see a very stark, uh, contrast between companies that have adopted some form of platform engineering Yes. Versus those that there's an operations team, but the, the infrastructure as code falls on the developer.

Yeah. Um, they run into the challenges of how do I educate them? I get inconsistent implementations.

Yep. Which lead to inconsistent security, uh, practices among the developers. And so the platform engineering really helps, uh, unify the approach as it transitions from what the developer needs to do and is trying to do from a business standpoint.

And how do you put that into operations, uh, and therefore helps scalability from the organizational standpoint. I get it. You know, so just a quick plug.

Yeah. com. It's our newest site.

It's been up there now for about four or five months. org community, and Luca and Ente and those folks. We, we were, we are a media sponsor.

We'll be a platform con, but that you, you hit the nail on the head there. Right? com too.

So we're obviously we're bullish DevOps, but we saw the same things happening in DevOps. I used to call it the bubbles of DevOps. Uhhuh.

You would have a little team here, a little team there like bubbles. Yeah. Within a bigger organization.

And this one was on Ansible. That one used chef, this one used Puppet, this one used Jenkins. That one used harness that unused Git or GitLab or what have you.

And then someone at the enterprise level would say, Hey, we gotta consolidate. Yeah. They say the mess.

Right. And it was kinda like, you know, when your kids play with bubbles, when they're little and you put two bubbles together, you gotta bigger bubble. And they, until eventually the bubble bursts, but DevOps had a problem putting all those bubbles together because They don't fit.

Right. Well, just for what you said, everyone wants to use their favorite tool. Everyone has, you know, their way of doing it can't just keep shifting left and throwing it on the developer.

Right. I think platform engineering is a great Yeah. Answer to that.

Exactly. It's not that it replaces DevOps, you still have the whole DevOps thing. Still do the, the, but you need a platform that's gonna bring together the developer, the tester, the DevOps guy, the SRE mm-hmm.

All of these people that work in this, you know, software factory mm-hmm. That we enterprises run to. Right.

Um, so I I, I agree with you a hundred percent. What's the feedback then? Um, I think it's going to, it's, you know, we're just releasing debt back now, right?

Yep. I think it's gonna be fantastic for the customers that I've talked to, and particularly the ones, uh, the ones that are like a couple years down the road on platform engineering. Yes.

They're gonna love it because it's gonna give them, you know, the prescriptive, how do I just do the next thing faster? Um, how do I get more consistency between, um, you know, differentiated teams, uh, et cetera. Those that haven't, it's now gonna give them part of the recipe for how to get started on platform engineering.

And that's really, you know, what we're doing with DevX benefits both communities, the platform engineering teams and the development teams. I agree. Uh, and platform engineering then can say, okay, here's some best practices that I want you to follow.

Here's the tool sets that are pre-integrated and, and, and blueprinted on, on how to follow them and how to use them. So it it, you know, trying to kinda bridge that gap of I need my tool set that fits the problems I'm trying to solve. You know, I might wanna use a different language if I'm doing video, um, applications and gaming Yes.

Versus if I'm doing ERP programming. Right. It's, those are different tool sets.

Sure. And so how do we give them the choice to do that? Um, you know, by giving them best practices and pre integrations with some of those tool sets, but not dictating which one they use.

Choice happens. Yeah. Choice happens.

Right? And, and I think that is the key. Yes.

There are a lot of choices and no, we're not here to dictate mm-hmm. This is a complete set. I think one of the nice things I like about the whole DevX thing is here's the complete A to Z, you wanna substitute a different letter C mm-hmm.

And, you know, substitute a black, you want to use that over there. Go ahead. Yeah.

You do have choice. You're not locked in. Because that's another thing we hear Yeah.

From enterprises a lot, is they wanna stay away from lock in Yeah. As best they can. Yeah.

Right? Because things are changing and happening so fast. Yeah.

It helps you evolve faster, right. Is is if something new comes along, Gotta have your Options that has a productivity boost, you wanna be able to take advantage of that and not be in a five year transition. Exactly.

Plan Or, you know, like what we see going on in the, uh, in the hypervisor VMware world now where we're at sort of a generational juncture where people are actually saying, Hey, maybe this is a good time to modernize. Maybe this is a good time to go to, uh, not multi threaded microservice architecture. You know, I'm, I'm looking at maybe going from on-prem to cloud, private, public, whatever.

I'm changing hypervisors. It's a, it's, no one wants to be locked in at that moment in time. Right.

You gotta have your options. Yeah. Speaking of innovation though, and changes ai Yeah.

Whether we're talking generative ai, agentic ai, I'm sure you, your, your customers that you're speaking to are grappling with, is it real? How much is it real? When is it gonna be real?

How should I make it real? Yes. What are you hearing?

Yes. Um, I'm hearing that, and I'm gonna break it down into two, two aspects because Gen AI and agentic ai, I think are, man, this next wave that's gonna open it up to so many more people. Uh, the interesting thing that people have forgot about is that you, machine learning has been around for a while.

Yeah. And we already have, um, hundreds of customers that have employed, um, AI in, in just astounding ways, in medical, in, in retail, in manufacturing, et cetera. Well, I think this now opens up is probably the, um, a new wave of how to apply it.

Um, but I think, and, and everybody's looking for it, right? And, and the, the headlines you hear every day are, where's the ROI? Right.

And I think the key thing to remember in, in the Gen AI space is it solves a specific set of problems. Just like the PR last ai or the still there ml, um, solves a specific set of problems. Don't try to apply it to every problem that your business has.

So my guidance is, you know, really study the business processes, um, the workflows that you have, um, and does it fit and optimize it? Right? I use Gen AI every day.

Mm-hmm. Um, and it is absolutely a productivity boost to my day. Uh, and I love using it, but there's other tasks that it may not benefit, right?

So, you know, knowing where to apply it is key. And then as we move to Gen AI or a Gentech AI Gentech, Now, I think that opens up another whole Can worms opportunity. Opportunity, but it can worms too, And yeah.

Issues that you need to grapple with from a governance. And, and yeah, there, and this is one of the things that, that, um, it becomes so important in ag agentic ai, uh, your gray areas of how the quality of your data, um, is no longer an option. If you're doing a agentic ai, your data must be clean.

Uh, hallucinations are not a good idea in an agent AI workflow. Did You imagine? Right.

Probably not safe to say. Safe To say. Yeah.

Huh. Should we launch this direction or the odd direction? Right.

You think To know. Uh, so I think that's the exciting part of agen ai is, is what it opens up. But again, okay.

Do I have the problem understood and do I have good clean data to, I think that's gonna be, that, that is a key piece of it. But I, I think the other thing, you know, we've discussed this on text on gang in a lot of our videos and interviews, is we, we can't go hog wild and have a hundred agents running, you know, doing, you know, how many agents are enough agents? Do we need an agent orchestrator at some point?

Yeah. Do you have a master agent? Do you, you know, what's the right mix?

Yeah. Because everybody's rushing out. I mean, SAP's coming out with a lot of AI agents, gen Z framework, obviously.

Yeah. Everyone is. Yep.

And so, And kills coordinate with each other. And how do you get it? They, They're gonna have to, otherwise they're gonna start colliding, like, you know, bits on the internet.

Right. Um, there's going to, you know, just the way you have this Dev x, uh, platform or framework, we're going to need sort of a framework to deploying and managing agents Yeah. At scale cloud native infrastructure or whatever your infrastructure is.

Yeah. You know, that because these agents are gonna be constantly, I think fine tuning, Fine tuning and tweaking. And, and, you know, you bring up a good point, and I, and I think this is where agents have an opportunity to be disruptive.

'cause we've in it, you know, if we apply automation to it, right? Yep. It's been the holy grail forever, right?

Automation is always a good thing. You never hear them say, oh, no, automation's not good. Um, And the challenge with automation is, uh, you know, what's the quality of your information?

And I given an example, um, you know, and not picking on it, but just an example, like, uh, VMware, DRS right. Automatic, um, load balancing and re uh, positioning workloads, et cetera. Yeah.

And it operated on an incomplete information, uh, information set. Yeah. And so in the early days, it was as dangerous as it was value at your book.

Right. Uh, I remember those days. And that's the thing that we're gonna have to watch as we progress with agent to out As good as your information.

Right. So it's very easy, like, you know, you can think you're optimizing something and yet incomplete information. Um, and it was the wrong way to drive the workflow.

Uh, yeah. So that's, we're gonna need some guardrails around You look at the world through a, you know, a door hole, a pinhole. Yeah.

And you don't realize what else is out there, you wouldn't know. Right. Exactly.

Excellent. So, well, Brett, thank you for stopping by. Absolutely.

Talking with us today. Yes. Enjoyed continued success with Susa.

We're gonna watch all this. We're, we're Excited. It's the most exciting time.

That's why I said it is, it's the best Suan I've been too, because the, the bringing the portfolio together in a way that we've never done before. Absolutely. You know, things that are on the horizon are, You know, as, as a media press person, I've, I've seen the acquisitions.

I, I was good friends with Shang from, uh, yeah, From Rancher, from Rancher. I, uh, Andreas, that's another good friend of mine. I knew the new Vector people pretty well too.

And, you know, they're assembling a nice, stable, I don't know how this all fits together, but now you see how it all fits together. It's coming together. Excellent, man.

Excellent. Appreciate it. Appreciate it.

Yes. Greg Schroeder, head of the office of CTO at SUSE here at SUSE Con. We've got more Susa uh, coverage coming up.

Stay tuned. Hello and welcome to the latest edition of the Techstrong AI video series. I'm your host, Mike Azar.

Today we're with Baik Hojat, who's CTO for AI at Cognizant. And we're talking about this whole shift to Agentic AI and how we got here. 'cause it started all the way back with things like Siri, and it's a continuing journey.

Baik, welcome to the show. Thank you. Thank you for having me Put some perspective around this.

I think everybody kinda understands Siri or whatever, uh, the folks in Google and Android provide, I think it's Bixby, but these things were the precursors to AI agents that we see today. And it seems like there's a straight line here, but I don't think everybody appreciates how exactly these things are all connected. Yeah, well, uh, AI agents have been around, actually even before Siri.

Um, uh, they are conceptually the same thing. When you ask Siri to call your wife and it actually dials a number and gets the call done, that's an agent working on your behalf that understands natural language. Um, the difference today is that we actually have these Gen AI models, uh, to help with the understanding of the natural language and to help with the reasoning of the agents.

So they're much more powerful than what we used to have in the past. But even before that, you know, AI is, is really, really hard. So having a single AI system that does everything and is generally intelligent, has always been very difficult.

So in the late eighties and in the nineties, people started, uh, thinking, okay, what if we simplify the environment within which the AI is operating? And let's call that an agent. And back then we did have a pretty simple environment.

It was the web, it was much simpler than it is today. Uh, just some texts and hyper texts and, and links. Um, and so that's kind of where it all started.

Uh, but you know, the, the aspect of, uh, agents that's really interesting to me, which also started in the nineties, was multi-agency. So you have one agent, and it might be collaborating with another agent or communicating with another agent to get something done for you As we go forward. As I look at it right now anyway, it seems like there's gonna be, I don't know, hundreds, thousands of these agents.

How will we kind of connect them all together to kind of drive something and will the agents know of each other? Not to mention who, not only am I, but who am I working with, or who's part of my extended family? Exactly.

That is, um, a very important question. And I think it's something that, in my opinion too, is inevitable, uh, with people, marketing agents right now for various different tasks. Um, you would want these agents to know of each other and actually collaborate and talk to each other.

And so we do need some way to make these agents interoperable. We do need to make sure that when they're aligned, we're, we have less of a problem when they're not aligned with one another. How do you deal with that?

How do they negotiate, uh, you know, to get something done for you? These are all problems we will be running into the future, running into in the future. And, uh, I, I think we are already seeing that.

Uh, so companies have been starting off by creating these knowledge extraction chat bots, uh, using genai. And, uh, they've created them, you know, large companies like ours have been creating them for various different use cases. And very naturally, uh, it just doesn't make sense for you to talk to one agent and the agent saying, well, I can't really help you here, and you gotta go talk to this other agent.

And then for you to actually repeat yourself to the other agent that's responsible for it, because you started off talking to the HR agent. Um, and so that interconnectivity, that interoperability is really important. And many companies are actually bringing in agents from third parties.

You know, we have agent force, we have, um, uh, you know, SAP has its own agent. You know, the various different companies are coming up with their own agents. There's agent space by, uh, by Google that, um, in fact has adapters into many different backends.

And, uh, so yeah, I think the, the future, the way we see it is this, um, uh, coming together of agents representing various different functions in an enterprise. Uh, you could think of it initially as really looking very similar to the microservices that we've created and even the organizational structure of, of a business. Um, and you should be able to, uh, get stuff done, uh, as long as you have authorization for a task, uh, across multiple agents.

And in fact, have agents talk to each other and work out collaboratively, um, and consolidate their responses. So you're only dealing with one, uh, interface. But in the background, you have a team of agents working on your, on your behalf.

Um, I think we need to make that this can't be created in a centralized manner. So we have to come up with a way to actually nurture this organic, uh, emergence of these multi-agent systems. So, for example, I want to see business units be able to create their own agent sub networks and have a process for, you know, sandboxing them, validating them, and then being able to plug them in into a larger organizational network.

And by virtue of doing that, expanding the domain of discourse, uh, and and capabilities for, for that particular organization, Will these agents negotiate with each other? And, and how might that be accomplished? Because sometimes I wonder if I have an agent that is optimized to go buy something at the lowest cost, and you have an agent that's gonna have something that is optimized to sell something at the highest margin, won't they kind of just meet in the internet somewhere and beat each other up to a standstill and then call us for help?

Yeah. In fact, that is something, uh, I I think that will happen in the future. It's not the case right now.

So we're really building from the ground up, and we're only at the stage where the assumption that the agents are all working for the same organization, uh, is, is, is probably gonna work for us for a while now, but we will very quickly get to that world, Mike, that you're, uh, you're describing where, for example, I have agents that on my behalf might want to broker some, uh, uh, you know, uh, service from a third party. And that third party, um, has created an agent, uh, to receive orders, for example. Um, and, uh, and, uh, you know, there might be a negotiation going on.

In fact, um, we did a research, um, uh, with Oxford economics just recently that showed that while consumers like you and I, um, are not comfortable with having AI agents actually, you know, do the transaction itself, we are comfortable with them giving, you know, do the, doing the research and giving us the options. And so that inspired me to create an agent network that helped a consumer like myself make decisions. And it was a number of different agents that came together to help me with various different decisions from, you know, what hobby to choose, to financial decisions, to, you know, buying stuff.

And then I actually had a few agent networks that represented different, uh, third party, uh, B2C kind of businesses, uh, for example, for, um, uh, you know, hotels and, and accommodation and so forth. And I had more than one. So I actually had a lot of fun, uh, having the agent that is responsible for, uh, you know, uh, coming up with my vacation, uh, agenda, negotiate and talk, and, and I would tell it like, you know, yeah, I wanted vacation, uh, and I have a budget of whatever X dollars and see it go back and forth, uh, with these third party agents and in fact do a negotiation.

And as part of their prompt was, don't trust the other side, the other stride is not fully aligned with you. So it would actually get some results and go to the other hotel provider, for example, or accom accommodation provider and say, Hey, I have a better deal than you, and can you beat this? And, um, it was amazing just to read the transcript of how these agents were kind of trying to, uh, uh, you know, meet their own KPI, uh, while trying to, you know, close the deal on something.

And ultimately, the, the agent representing me came back with some a list of options like, here are the options that you have with these different providers. So the final decision is up to me, uh, the user. But a lot of that negotiation, the headache of trying to, uh, check and find these things out, uh, took place, um, without me involved, uh, it takes a while.

These, these systems might, uh, run for a while. One of the things that might be an issue, again, this is a future state we're talking about, is that these, uh, large language models are fine tuned to be very kind, uh, you know, very positive, very, uh, ethical, moral, uh, systems. So when you actually follow the dialogue between two agents, they tend to agree with each other very, very quickly, much quicker than you would like actually in these types of situations.

So that might call for a different kind of fine tuning when it comes to non-aligned agents talking to each other, for example. So there's, there's a whole world of research that has to go into, um, uh, kind of, uh, uh, coming up with that kind of world, uh, that, that kind of setup. Um, I must say that, um, again, currently the, the, the overarching assumption for everyone is that we're building agents or multi-agent systems that are all aligned and in the service of either our company or our consumer.

So that's an easier problem than, you know, we have a bunch of agents that might be talking and negotiating with some other agents that are probably not aligned with us. I've been trying to figure this out and, and I imagine, you know, the answer, and maybe it's not, uh, obvious to everybody, or maybe the techie folks understand it, but, so Siri more or less ran on my phone, tablet, whatever, is there enough horsepower to run these AI inference engines out at the edge because we're trying to create an interactive experience. So the round trip to the cloud, the latency might be too long.

So yeah. How much of the AI runs locally and how much of the AI runs somewhere in the network, and how much of it runs in the cloud? Well, uh, let me correct you, uh, on, on the premise here.

The initial Siri was a hosted system. In fact, it was one of the first, uh, when, when Siri got acquired by Apple, they actually built the data center for Apple. Apple didn't have a data center before that.

I mean, uh, so, so that was actually hosted, but for the processing capacity back then, that was required, um, uh, not anymore for that, uh, type of, uh, Siri, um, system. So you're very right that, that, uh, kind of, uh, processing didn't require what we require today, like our most powerful large language models have to be hosted. They actually run in very large data centers and take a lot of processing capacity.

Today, we cannot even, uh, start to imagine what it would look like to run a GPT-4 oh on your phone. That just doesn't, it, it won't work. However, having said this, you could today think of systems that are running in a hybrid mode, where some, um, it, you, you even see that actually today in Apple Intelligence.

Uh, when it came out, I was thinking, okay, they have the right idea here because, um, much of Apple intelligence is actually running on your phone, and that is for data security purposes and so forth. It's actually really, really good. Um, but it's, it's not that powerful, like what it does, what Apple Intelligence does on your phone.

It's a small, uh, large language model. So it's not that powerful and there's not a lot of functionality. You can, you can run just on your phone alone, uh, for agents that can understand natural language, do reasoning, and, um, be kind of a higher order type of agent, you will still today need to, uh, run them on the cloud and data centers.

But you could imagine a hybrid model where some agents are hosted and some agents that are much more specialized and therefore don't need a large, that large, uh, uh, a large language model to be running, uh, locally. And what that does for you is it, it, it does, uh, save money, uh, um, um, uh, because it kind of, depending on the use case and depending on the agent, you're using a different, um, model that, that might not have the same, um, processing capacity requirement. It also gives you some data security aspects for those particular, uh, parts of your multi-agent system where it's closer to the data.

Just imagine if you have an agent sitting in the cloud that generically knows what you're talking about, and then defers it to the agent that's sitting on your phone that is actually responsible for the data on your phone. That way your data isn't really moving off of dear phone. Uh, and that functionality, um, is, is resolved through that, um, interaction between the agents without the cloud agent even getting that data.

So, um, that we can do, even today, the general trajectory of the technology today is, uh, these large language models are getting smaller, uh, at the same time, more powerful, um, deep seek an obvious, uh, example of that, where a much smaller, large language model could do things at the scale, uh, that wasn't possible in the past. You can run a 14 billion parameter, um, deep seq model on your, um, M three laptop and, and, and it will work. And it's at, you know, it's, it's on par with the GT four oh mini, for example.

So it's actually pretty powerful, and it, in my mind, for many agentic use cases, it pa it passes the bar. Um, and so, you know, we're, we're still in the early days, but I think in general, we will move to a point where these, um, uh, running more and more of these agents, uh, locally is gonna be viable. The other thing people seem to be struggling a little bit with is, is an agent, should we just treat them like digital labor or are they essentially a new type of employee, or is it just software that we're using and we just need to invoke it through an API, but we don't need to think about it any differently than we do any other application.

There is a distinction in that the moment we talk about an agent, we are assuming some level of autonomy, because if there were no autonomy needed, then, you know, it doesn't need to be an agent. It's just pure software. You just write, write some code and some rules, and you have it do whatever, um, it needs to do.

But the reason why you're using an agent beyond the fact that it understands natural language, is to defer to it, to make a decision as to what, uh, which one of its tools it needs to use and in what order, and synchronously or asynchronously, and perhaps in some cases, just go off and use its tools and review and go back and, you know, so to maybe make multiple calls and then come back to you. So I don't know if we can treat them exactly like software for, for starters, we have to accept a world in which systems do exhibit some level of autonomy. So we have to design for that and make sure it's responsible, uh, in its operations.

The second is we need to get used to a world in which things are not deterministic. Uh, you know, the same inquiry is not gonna get you the exact same response every single time. Um, and it takes some getting used to, uh, but, uh, yeah, I, I, I don't know if I answered the question, but generally I'm just, just kind of highlighting the distinctions here.

As you look forward and now that you're working over at Cognizant, you're touching more customers, um, at least among the early adopters, what do you see them doing right, that you kinda wish other people would kind of crile a little bit? Yeah. Yes.

Um, I think, uh, uh, those who do recognize the fact that, you know, identification, AI enablement is not a one-stop shop. You're not looking at a single be all end all model that will do everything for you. I think that that is the right kind of thinking, uh, those who are actually making interoperability a requirement for the agents that they, um, utilize, uh, I, I think are taking the right steps.

And also recognizing the fact that this identification is an incremental process. It's not a lift and shift. You don't have to go off and, uh, you know, say, okay, I'm not even gonna embark on this 'cause my data shop isn't in order.

Or, oh, it's a huge undertaking, like identifying my entire, um, business is gonna take forever or culturally, I'm not ready for that. Actually. I think because of the nature, the modular nature of multi-agent system, you can start small and grow.

And as long as you set the framework in a manner that allows for that kind of incremental, uh, adoption, um, you're in a good place. So being an early adopter, uh, in this case doesn't mean being completely disruptive to your, to your business. It's, it's actually a smoother, um, less painful process than, for example, I don't know, back when we were migrating to the cloud, uh, for instance.

And, um, so those of our clients that recognize this, those early adopters that are doing that, I think, I think those, uh, that, uh, I'm just highlighting what, what, um, I think keeps them ahead of everybody else. And I've been surprised that, uh, some of our clients who are from domains that are traditionally quite conservative, um, are recognizing that and are actually taking, taking steps there. So it's unlike what we've seen in the past where, you know, a conservative bank or an insurance company that would say, yeah, we'll wait until that, that this new technology is, has been out there in the risks admin, um, uh, mitigated.

Um, no, many of them have embarked because they recognize the incrementality and the, the importance of, um, endorsing and managing this in a safe, uh, manner versus just letting it happen organically because it's happening organically and you just don't want that. It just, uh, it's not the responsible way to go. We haven't talked about security, and we are struggling with just securing the humans who are a part of our environment.

And if we have all these agents and they're essentially entities, uh, endpoints, much like people, how will we secure thousands and thousands of agents that the bad guys are gonna go try to steal the credentials and manipulate? Yeah, that's a, that's a really important question. I think, um, uh, I think it's important for us to, uh, recognize that if an agent is hosted by a commercial entity and it's a complete black box, especially if it's hosted by maybe a third party country, um, you know, that, that, that there's a trust element there that has to be, um, you know, taken into consideration.

Um, I always say if, if, if the functionality, uh, that you're, um, so delegating to this agent is sensitive or it's dealing with sensitive data, I think it makes sense for you to, um, host it, uh, and run it internally and secure it. Um, but there are ways, there are mitigations, um, uh, uh, around authentication authorization. Uh, and agent by definition is not just a la large language model, it's a large language model plus code.

And the code is actually superseding the large language model. The code is what is making the calls. The large language model only takes input and, and, and, uh, output, uh, produces output.

It's the code outside of that, which is, uh, a deterministic human design code that decides what to do, like, which tool to call, what API to call. So if you want to secure your agent, that's where you have to be writing your code. And, um, the other thing is this acknowledgement that the agent is going to have some level of autonomy means that we have to always think very explicitly about what is the line that we draw.

We're like, okay, up until this point, with this sort of level of certainty, with this kind of functionality, we allow the agent the autonomy, uh, because it give, makes everything more efficient and productive and everything. Um, but here's the line below which I'm gonna take over. I'm gonna write the rules, I'm gonna make sure there's a deterministic methodology for what happens.

And we always talk about a fallback, like if all hell breaks loose, I want to be able to, you know, disconnect all LLMs in my enterprise and fall back into a rule-based model or a human-driven model. So having that in mind, I think is, is very important, especially with critical processes. Um, yeah, I, I think, uh, you're, you're touching on a very, very important point here.

All right, folks, you heard it here. As you listen to this conversation, it becomes pretty apparent that despite what AI agents may automate, the missing ingredient is still gonna be human intelligence. Hey, Baik, thanks for being on the show.

Thank you very much, Mike. And thank you all for watching the latest edition of the Techstrong AI video series. You can watch this episode and others on our website.

We invite you to check them all out until Lynn, we'll see you next time. Hey, everyone, it's Alan Shimel, and this is another episode of Shimmy Says, you know, I'm really excited to do, shimmy says this week, because we actually have a story that's not necessarily AI related. AI takes up so much of our Headspace these days, whether it's generative AI or agent AI or what have you.

But today I want to talk about just good old fashioned, hard earned green cash, like in $32 billion worth of cash. You know, the big story this week was that Google coughed up 32 billion. That's with a b billion dollars to buy the Israeli, uh, security startup, the Wiz.

Now, couple of things, if you're not in the security space, you may not know The Wiz, the Wiz, uh, originally founded, I believe in 2020, so just five years old, grew really quickly. You know, they came out during covid, which they'll even admit, probably help them to get some traction early on. And they got to a hundred million dollars in annual reoccurring revenue really quickly.

I think they're up close to six or 700 million in reoccurring rev annual reoccurring revenue right now. Um, what do they do in security? Well, they've made a few acquisitions, which has expanded their portfolio, but basically their cloud security, cloud security, uh, CMAP, cloud Native Security, uh, they do do some SOM software, bill of materials, supply chain kind of stuff in the DevSecOps space a little bit via a, an acquisition they made.

Um, but it, it's more generalist cloud security. But they did a really good job. I think also what they did really well was they, they really made inroads working with the public cloud providers, all three of the major ones here in the west, uh, AWS Google and Microsoft Azure, their AWS marketplace product is probably one of the biggest drivers of revenue for them.

So, you know, a real poster child for that kind of success now. And that very success with the cloud providers is sort of what helped with, uh, making them as attractive to Google. Uh, and, and make no mistake, this is Google Cloud is, you know, as much as Google, uh, they wanted that strong cloud security product in their, in their portfolio.

Now, were they better off buying it for $32 billion or just partnering? Well, that's a question one might ask, but clearly they wanted it. For those who may not have been following this story, Google offered them $23 billion, oh, maybe six or eight months ago.

And there were rumors that that deal was getting done, and then the Wiz turned it down, they walked away from the altar, they walked away from $23 billion only to come back here at 32 billion just six or eight months later. Why did they take 32 now and they didn't take 23 before? It's a good question.

Well, first of all, you don't have to be a mathematician and know that it's an extra $9 billion and, you know, a billion here, a billionaire, before you know it, you're talking about real money. So $9 billion is maybe reason enough. But on top of that, I think the world was different six or eight months ago, I think the stock market was up, interest rates were coming down, inflation's coming down the market for IPOs, looked like it might pop.

And I think what we've had over the last, you know, month or two months, certainly here in the US, has been a lot of uncertainty. And businesses do not like uncertainty. So with this uncertainty, the market has reacted.

We're seeing inflation in up, we're seeing unemployment, interest rate pressures, all of the above. And so that money started looking better and better. Also, from what I've read, Google has been pretty much in constant communication.

The corp dev team has been in constant communication with the folks at the Wiz talking, continuing the dialogue, not giving up on this deal, and they sweetened it to 32 billion. And, and that, I guess, you know, they say every man has its price. So does every company I mentioned early on, the Wiz is an Israeli based startup.

It's actually three co-founders, and this isn't their first startup. They sold a, a security, I think, cloud security startup to Microsoft prior to starting The Wiz, maybe in 2017 or 2018 for about $320 million. So they've made great liquid liquidity events in the past.

Of course, this one pales in comparison to compare, and speaking of comparison, $32 billion based on their present run rate and revenue is about 45 times revenue. 45 times revenue's a lot. That's a huge, huge multiple.

To give you a little context, last year, or maybe it was the year before Cisco bought Splunk, and Splunk was a great company, public company. Cisco bought Splunk for I think $27 billion, and that represented about seven, seven and a half times revenue or value. So you could, I mean, the difference between seven or seven and a half times to 42 times revenue, that's, it's not even in the same universe.

And, you know, people thought Splunk wasn't bought cheap, so certainly the Wiz wasn't bought cheap. Now, I mentioned before Google bought 'em to be in cloud security. Did Google buy them to, to deprive their biggest competitors, AWS and Microsoft Azure of using the Wiz?

Or do they expect AWS and Microsoft to continue using the Wiz and contribute to Google's bottom line? I, I don't, I'm not quite sure what the answer there is. You know, as a security partner, Wiz had NDA and access to roadmap and feature sets with, with AWS and Microsoft, and I'm not sure those companies are gonna be comfortable with knowing that Google is their parent company going forward.

It's gonna be interesting to see if Google and the Wiz is able to still maintain their relationships with AWS and the Azure folks, uh, Azure folks at Microsoft, or do AWS and Microsoft sort of shun them, push 'em away and, and start looking at other, other products. You know, if, if that happens and the Wiz loses a lot of their revenue base based upon that, is that still, you know, how's that look for Google at $32 billion out the door? I think that's gonna be the biggest question we need to watch going forward.

Do do the other cloud providers still have whiz as sort of a favorite partner, if you will? Another thing to think about is, hey, Google had $32 billion laying around to just spend on this, and they've got a lot more, you know, all of the tech hyperscalers, all the giant tech giants are sitting on literally barrels full of cash and they're just waiting for the right things to buy. Whether it's an AI related thing, maybe it'll be Quantum or in this case, security.

Um, but that's an awful lot of money to have laying around $32 billion. Who else does this affect? I mentioned the cloud providers, but we also have companies like Palo Alto.

Look, Palo Alto is probably the W's biggest competitor, and this could go one of two ways for them, right? Does the Wiz with Google behind them kind of really dominate Palo Alto because they have deeper pockets and broader distribution, or do does AWS and Microsoft is yours? Say, Hey, maybe we should shift to Palo Alto more.

Maybe there's a tremendous opportunity for Palo Alto to pick up business from companies who don't want to deal with a Google owned wiz. Another interesting thing that I think we'll have to see how that plays out. I should mention that though, this is an all cash deal.

It is not consummated yet, right? It'll have to be approved. I imagine the EU maybe even more than the US will have some, uh, antitrust, uh, review process in place.

Interestingly, if for some reason this deal doesn't happen because of regulatory or another reason, there is a 3 billion, that's 3 billion with a BA $3 billion, uh, breakup fee involved in the deal. So if this deal doesn't happen and Wiz doesn't, you know, join Google, they still wind up with $3 billion of Google's money. Um, as someone who's been in the security industry for going on 30 years.

Now, I gotta tell you, at, at some level, I am thrilled to see that security is valued this much, that someone would pay 45 times revenue, $32 billion in cash for a security company. That's a long way, long, long way away. I remember the first big security, uh, m and a deal I saw was ISS being bought by IBM, and I want to say that was for a couple of hundred million dollars.

And everyone thought, I think ISS had 60 or $70 million in reoccurring revenue. And, you know, it was a little under 10 times revenue. I think they paid for it, and we thought that was just crazy.

And who would pay that much for a security company? Congratulations to the Wiz and their founders and their, all their employees there. This is really a, a high watermark, I think, to this point for security companies.

And it bodes well for the rest of the security companies out there. You know, we're coming in RSA season, we'll be seeing more and more security. Uh, we'll see if this sets off a whole frenzy of m and a and security and tech in general.

But until next time though, hey, man, $32 billion in, in cash. That's a big, that's a big number. Congratulations.

This is Shimmy. We'll see you next week on Shimmy says, Hey everyone. I'm Alan Shiel, and this is Jonathan Singer, and you are watching The DevSecOps Show Cracking the Code.

You've never heard of that show. Well, for good reason, this is the very first episode of it. We're just starting it.

And thanks for joining in. Um, we're going to take today's show to just kinda give you a what to expect and what's coming here and introduce the whole concept to you. Uh, DevSecOps Show Cracking the Code is a joint production between us here at Techstrong Group, tech Strong tv, as well as check marks, our partners check marks.

We partnered with check marks for many, many years. They've been a leader in the AppSec space, DevSecOps coming down into platform engineering as well. So I'm thrilled to have check marks co-producing this with us.

And my co-host I mentioned, his name is Jonathan c Jonathan's with check marks. Hey, Jonathan, nice to have you co-hosting with us. Welcome.

Um, thank you. You know, you are the new guy on the block. Tell people a little bit about you.

Sure. So, uh, it's nice to virtually get my face out in front of everyone, and thanks again for the warm welcome. I am very much looking forward to doing this series with you.

Uh, my background, I've been with check marks for a couple years now, and, uh, I've spent a lot of the last 20 plus years, sadly. But yeah, it's, it's been a long time. You don't look adult.

Well, uh, you know, I'll, I'll take it, I'll take it, but yeah, no Good living. Uh, yeah, what can I say? Good skincare.

It's, it's great. Mm-hmm. Uh, but I've been in cybersecurity and, and some adjacents work in telecom for the last 20 plus years.

Uh, and I, uh, I'm current in my current role at Check marks. I'm doing a lot to help the organization shift our focus into the realm of developers. And we've done a lot of work, uh, as a company over the last four years, like really making our platform developer friendly, good for developer teams, good for huge like development organizations.

And so we wanna take an opportunity to sort of get the word out, uh, as a company. Um, and I am, I'm sort of leading that effort, so that's why I'm here. We've got a lot of fun topics to talk about.

I've been talking a lot recently about DevSecOps maturity and, uh, about what that really looks like and, and how you advance as an organization. So lots, lots to dig into. Absolutely.

I want to dig into some of those topics, kinda pre-announce them here today. I'd like to go into a little bit more about check marks in their history, though. You know, like you, I've been in security, well, probably longer than you to tell you should, I've been in security now about 30 years.

And, um, you, I've seen a lot of water under that bridge, right? I've seen us move from a predominantly network security type of world where we put big boxes, you know, at the, at the drawbridge with the moat surrounding the castle to the advent of the cloud, to the advent of DevOps, ai now platform engineering, SRE, so many, you know, subsequent waves. And each wave has brought new innovation, new techniques, new best practices.

So over that time, I would say one of the biggest Innova, not innovations, but shifts in security, was the shift to AppSec, right? Even before DevSecOps, the shift to AppSec, the idea of we are going to secure the applications, whether they're in the cloud or in a data center, or on your phone. We need to make sure our application code is secure.

It's free of buffer overflows and cross site scripting and SQL errors, and, you know, all of those kind, kind of common things. You know, obviously, uh, OAS top 20 kind of, you know, uh, of, of, uh, vulnerabilities. And that's when I first became aware of check marks, right?

Check marks was a pioneer in AppSec, right? And we, you know, the idea of, of static code analysis, dynamic code analysis. Then of course, later on came, um, uh, open source scanning, and I always forget what we call it now.

Secure code analysis, SCA, right? Basically scanning our open source code. Um, all of these things really, I think they made a huge difference in the quality of the code that gets released.

And, you know, that's in our applications. At the same time, things like DevOps and agile man change the way we develop software. The biggest change is what, you know, I call the shift to a software factory, right?

Where it's not, I used to think of software as like, you know, like mid 18 or mid 18 hundreds Germans, craftsmen, fine craftsmen making furniture or iron metal workers, or, you know, the guild where you had apprentices and, and lifelong, like, you know, that real craftsman kind of role. But I think we sort of shift to the factory, right? Much like we did in automobile production, right?

From bespoke automobiles to assembly line. And we saw the same shift in software. Uh, we also saw the advent of repos and open source software where people, I, I, you know, it's like Frankenstein software people stitched together a whole bunch of different components right?

From different places. And that's 85% of the code in today's applications. Um, these are all big changes.

And then of course, the biggest one for us here on this show is the whole start of DevSecOps, right? All of a sudden it became cool to say, Hey, did you know, hey, developer, we know you want to develop quality code, even though we're not those old, you know, mid 1800 craftsmen anymore. We still have pride in our work.

We still have pride in the code. We're publishing. We want, no one raises their hand and says, Hey, I feel like putting out some crappy code today.

No, everybody likes good code. And, and so that was a revelation for security people, Jonathan, right? We, we, we spent 20 years, we always said, nah, no one cares about security but us, we're the only people.

But no, they care about security. Let's give them the tools to do it. And, and again, check Marks led the way there, I think, right?

With, uh, well, the most recent is the advent of check marks one, that whole platform. So that was a long-winded intro for you to discuss check Marks one and what that is. Well, uh, there were a lot of things in there that I'd love to address, but since you asked me directly about what check marks one is, I mean, uh, you know, I I think check marks one is our response to everything that you said.

And yeah, like, I mean, we can go back to the Toyota production system and, uh, and, and, and, you know, con Bond and, and how that's, you know, grown up and influenced agile development and, and the kind of march from DevOps to somewhat argue back to DevSecOps. Um, and, and I'll say that I was, I was talking to someone recently and he said, you know, I spent years as a DevOps leader, and I always thought DevSecOps was just a marketing term by security vendors, because we always knew that DevOps had to, it was, it was supposed to be everything, and security was a part of it. Yeah.

So, you know, as, as a guy who's out there now talking about DevSecOps, I think I'll, I'll at least, uh, say, yeah, like we're, we're, we know. But, uh, check marks one is still the response to this, right? It's the response to that need that, uh, maybe security folks felt like, uh, well that's nice that you included it, but we're not talking about it enough.

Um, and you know, your reference to, you know, coders as, and developers as originally kind of craftspeople, I, I think they still are. And I think that what all the open source stuff and the kind of Franken code that people put together is because we're trying to refactor people's time on doing the craftsman stuff, where it's really, really important. Uh, and we want security to still be a part of that, right?

So we want security to be a part of your software supply chain. So everything that you pull down from the internet, we wanna make sure that, you know, that code is secured when you build new code and you get time to do that. Craftsman, like work, we wanna be there.

Uh, you know, doing the analysis of that code before it gets into production and, and check marks. One is the response to those needs of taking all of these different types of analysis, right? Fast, SCA Ds API security, uh, container security, and, and building those engines, not separately, but so that they work together and that they can fit into your production pipelines, right?

Because if you're gonna do this effectively at scale, which is, which is really what large businesses need, they're trying to get all these developers, all these craftsmen who, you know, work on these little individual things to really, to make a big outsized impact. Um, we wanna fit into all of those production lines, integrate with everything that you need, and make sure that we're securing as much early as possible so that when things get to production there, you know, there are as few critical vulnerabilities as, as there need to be. So that's check marks one, is the response to that need for that to happen in the cloud for that, to make it easy for everyone.

Love it. So you opened this can of worms. Let's go back to the birth of Jeff SecOps.

com in, uh, when we first published it in March of 2014. We started in 2013, you know, planning and getting everything done like September, October, 2013. And, um, let's be clear back then.

So I came from the security world. I thought, what a tremendous opportunity DevOps represents for security. There wasn't a thing called DevSecOps.

There was, there were proto like proto humans, you know, not Neanderthal, but Africans and some of the proto humans. There were things like Rugged DevOps. My friend James Wickett, who's now a runtime or drive run Securities, is his new company.

Uh, he started something called the Rugged DevOps Movement, right? And there was, you know, rugged as DevOps making it resilient. org.

Maybe we'll have Shannon on a show going forward. I, a good friend of mine, um, and she actually wrote the Manifesto for DevSecOps, right? 10 years ago.

This May was the very first DevOps DevSecOps Connect that I did at the RSA conference in partnership with my friends at RSA. Um, and the idea then was when we first did this 10 years ago, again, DevSecOps, it was funny, the security people thought it was full of crap. John Jonathan, right?

Because they said, oh, nonsense, no one cares about security. And the, and the developers thought it was full of crap too, which is a marketing term, the true DevOps people like my friend John Willis and, and Patrick dubois, who coined the term DevOps and, you know, uh, uh, Andrew Clay Schafer, and, you know, the Damon Edwards, the, the, the founders of DevOps. They felt, of course, security was part of DevOps.

DevOps encompassed all of that. But what kind of needy, whiny individuals or security people that they feel it necessary to stick check right in the middle of the dev and the ops, and they resisted it, right? And when we first started doing these events at RSAI, that was my mission, to bring the security community to the, and the dev ops tribe together, kind together.

It's kind of mixing peanut butter and chocolate. And there was a lot of resistance. Go ahead.

I, yeah, and I mean, let's, let's be honest. 'cause we're, we're gonna talk, we're gonna have a whole conversation on culture later, but like, yep. From my perspective, that what you just said, oh, everyone thought it was, everyone thought it was bs.

Like both sides. Both sides, kind of, that's, that's kind of part of the problem, right? And that's why we needed to have it in there in the first place is because you can say DevOps always included security, okay?

But DevOps started in 2009. It is 2025, and there is still a massive culture clash between security organizations and development organizations. I was talking to my friend who, uh, you know, she was recently a senior staff engineer at an Amazon based company.

And, and, and now she's often a, um, uh, in a, in a startup again, uh, you know, but, but they were saying like, you know, the security people want it so secure that like, well, we're just gonna unplug everything, right? Right. And developers like, well, I still need to do my work.

And that requires things to be turned off, right? And, and if we're still there where we have this, this big culture clash, which is fine. And again, and I say this all the time, like, developers move fast and break things.

Security people don't ever let anything break. And if we can't start coming together as, as distinct disciplines and working towards the goals of the business, not just our own individual metrics of like, I've tracked this many vulnerabilities so that I can buy more of this software and secure this, right? And developers saying, well, I'm not meeting my development milestones, so I'm gonna skip this step and I'm gonna meet my development milestones.

If, if we can't work together and have the business align us on goals of what producing secure software at a rapid pace looks like, then we still need to be talking about DevSecOps and talking about DevSecOps maturity and where you are. 'cause like that the, the cultures have to find a way to come together. Absolutely.

We can't just have security being the department of No. And we can't have developers being like, oh, they're all 20-year-old yahoos. And it's like, they're not like, these people have been doing this for 30 years.

Like, come on. So Absolutely. So let me, let me give, let me spread the good news today, like it's Sunday and I'm selling Watchtower or something.

Um, the good news is we've made a t tremendous amount of progress Agreed Over the 10 years I'm doing this thing in RSA, which we're doing again this year in RSA in May, check Marks is a sponsor of it. They'll be there, I think they're on one of the panels even, uh, uh, uh, Toby, the chief product officer at Check Marks is, is on one of the panels, um, co. But anyway, people recognize that DevSecOps is a real thing that you need.

The second DevSecOps even more than that, when you look at the leading DevOps platforms in the world today, companies like GitLab and Jfr and Harness and CloudBees to name a few, they don't even call themselves DevOps platforms. They call themselves DevSecOps platforms because they recognize how important security is. So we have made progress, I have a more nuanced view of it today than maybe you, Jonathan, or what you've said so far in that I think what we're seeing is under the maturation of DevSecOps, we've learned some lessons.

Developers are not against developing quality code, but they're never gonna be security professionals Soccer. Agree. Yep.

And I think one of the mistakes that our DevSecOps industry has made is giving security tools to developers. We need to give developer tools to developers that help them do better security, right? Because they're never gonna truly understand the, the nuances of the CVSS rating system or something like, you know what I mean?

One of these kinds of things. And that, so again, we talk about Check Mark Swan, bringing it back to that. That's one of the beautiful things about that is, right, creating a, a platform that developers can use and feel comfortable in without having to be a security pro, but also having an aspect of it that the Security pro can use to get their job done as well.

And again, these are things we're gonna explore. I wanna explore shift left. Have we over shifted?

I want to explore how platform engineering has kind of come in on top here and said, Hey, let us work with security to set up the guardrails so that those developers can just go faster. We, we do do the platform engineering show, right? Of which you, you've been od guest on there and Check Mark, sponsor.

We'll be discussing more of that on there. But we, you know, we'd be wrong if we didn't include it in, in here too. Um, and I think, here's the other thing.

This whole, uh, software pipeline security, right? Software and supply chain security, that's part of DevSecOps too, right? It's a huge part.

The SBOs, everything else. And here's another thing I'm seeing, John, and I'm wondering if you see this too. We're starting to see people say, Hey, we gotta extend, extend DevSecOps, pass the deployment horizon right up till now.

DevSecOps, it, it was like it hit a black hole when we deployed, right? No light escaped to the other side. Well, no, there's life after deployment, right?

For apps, and there's security after deployment, and that has to be tied into your DevSecOps two. So I, another thing that I'd like to see us discuss, what else would you like, think we're gonna cover, Sean? Well, um, let's see.

We're gonna talk about culture. We're gonna talk a lot about security education because, you know, while you said that, so look, everything you said about making security tools into developer tools, I completely agree with you. I think I even said it at Techstrong Predict, uh, that, you know, that's, that's the goal.

Um, but I wanna talk about security education. I wanna talk about how it's working, uh, because it is, we just a, a survey of 1500 developers. Yeah, sure.

Working or not, but at least the developers who are out there seem to feel like it's working, and maybe security needs to change the way that it speaks to the market, and stop complaining that they don't teach security and secure coding in as part of, you know, a university degree and say, okay, well, amen. We're, we're, we're doing it. So let's start speaking differently to developers about security.

Right? I agree a hundred Percent. And again, that, that ties back to culture.

So like, I think that the overarching conversation that we're gonna have across every single one of these meetings is the culture. And it's gonna be like the culture around integrating properly, around metrics, around security education, around matching the velocity of security to the velocity of development. Um, you know, about security champions programs, all of these things that we're gonna wanna talk about throughout the course of this show.

Uh, I, I think it's, it's all gonna tie back into culture and how we learn to continue working together and, and agreed, you know, security goes beyond deployment. That's why check Marks one partners with, uh, with folks like Wiz and, and, and with Cystic right Runtime partners. So agree.

Like we need to be looking at the whole software life lifecycle as developers look at the software lifecycle. Agreed. Agreed.

Hey, you know, what else though, for people watching this, are you a dev set ops person? Are you a DevOps person? Are you a developer?

Are you a security? Would you like to be involved? Perhaps be a guest?

You have a point of view. It's not just going to be you and I talking every week, Jonathan. We're gonna have hopefully a panel every week of at least 3, 4, 5 people.

Not every week, every other week. I think we do this. Um, but every show, and we're looking for people.

So if you have some thoughts and opinions, everybody has an opinion on, uh, DevSecOps and DevOps, write to us. com or reach out on LinkedIn or wherever you can reach me. I'm pretty accessible, so you could reach out to us there and we'll, we'll entertain any and everyone who'd like to come on here and, you know, have a thought on, on what we're gonna say.

You know, what else, Sean? I'm really proud of us. We're on now.

Oh, a good 15, 25 minutes. We haven't mentioned ai. What about AI at DevSecOps?

We'll, we'll talk about ai and you met, you mentioned, uh, Patrick Debar earlier, but he and I had a, had a long conversation about AI that you can find somewhere online, probably on our website, uh, as well. Um, but yeah, you know, ai, uh, we're gonna talk about AI in a bunch of different ways, right? 'cause there are, there are lots of different ways of looking at, which is like, how does it help developers code faster?

How does it help them do security faster? How does it help se security engineers to, you know, tune their products faster? Um, and then what does it mean for the software supply chain?

You, earlier you were talking about, uh, code and, um, and, and downloading other people's code and how that needs to be scanned. Well, but now there's hugging face and there are all these LLM models. And you know, we've got a guy on at our company, ez, who's one of our lead researchers, and he's done a demo of like, here's how you poison an AI model, and here's what it looks like, right?

Gimme a recipe for, you know, pasta Alfredo and one of the ingredients that gives you a rat poison, right? When he, when he does that, well, he's got poison this model. So there's, you know, if, if, if companies are building their own LLM or they're looking to build off of an open source, LLM, what's the security of that?

Who's gonna scan that? Who's gonna know whether or not your model is poisoned? So like, there's, and, and I don't mean to ramp up the fear factor 'cause that's obviously what security folks typically are, are known for doing, or at least accused of doing.

But it's, it's a concern. AI is now a supply chain concern in addition to all of the ways that it can be helpful. So what's totally tough?

I like everything else. It's the duality, right? Light and darkness.

Uh, it's always there, man. Every technology, you, you get it, it's new. It does something cool, and there are risks, and that's just life.

I always say this is why we can't have nice things on the internet. Um, but we do have nice things on the internet in spite of all. And, and, and, you know, again, I I I want to take a positive view of this as a result of DevSecOps, our code today is much more secure, like the apps you're using today.

And even though you may be updating them daily, weekly, monthly, whatever, they're much more secure today than they were before DevSecOps. I, I think we have made tremendous strides in, in releasing much more secure code. Yeah, so, agreed.

That agreed? Mm-hmm. Alright.

Hey, that's gonna wrap up our very first version here of the DevSecOps Show. Cracking the code. We're gonna be back in two weeks with a full on panel.

Jonathan, let's tackle culture right outta the bat and talk about the DevSecOps culture on that show. Um, you can catch this show on Tech Drunk TV and the Tech Drunk TV network. So it'll play on Tech drunk tv.

It'll be streamed to LinkedIn and Facebook and x and YouTube to our tech Drunk tv, YouTube channel. It'll be available on the Techstrong TV website. com, security Boulevard, cloud native now, tech Strong, AI tech, strong it, and digital CXL.

Um, additionally, audio versions of this will be available on Apple Podcast, uh, uh, Spotify podcast, Stitcher, and all of your favorite podcast platforms. So if you prefer listening to audio while you're running, exercising, whatever, driving, you'll be there for you too. Um, Jonathan, I'm, I'm pumped.

I can't wait to get cooking with this. Yeah, I'm, I'm excited too. I think it's gonna be a great series and I appreciate you and the organization for hosting it.

Looking forward to It. Absolutely. Absolutely.

All right, until next time, then that's a wrap on episode one of the DevSecOps. So DevSecOps show, little tongue twisted there. DevSecOps Show cracking the code.

We're out everyone. Thanks very much. Thank you.

Hey everyone, it's Alan Shimmel here from Techron Group, and you're watching another episode of the CD Pipeline. The CD Pipeline is a, uh, partnership between the CD Foundation of the Lennox Foundation, and here us here at Techstrong, where about about once a month we try to bring you some of the latest topics regarding or germane to the CDF audience, to the CD Foundation. For those of you who're not familiar with the CD Foundation, we usually have someone here from the CD Foundation.

Um, but for those not familiar, the CD Foundation, as I mentioned, is a daughter foundation of the Linux Foundation, but it's responsible actually for the management upkeep running of several of the largest tools in the CD universe, CICD universe, including Jenkins, uh, Spinnaker, um, Tracy, one of yours Or Orus. Um, I think there's eight or nine different pro programs that fall under the auspices of the CDF, but it's more than just managing those, it's, it's working groups around the security of them, of operating them best practices. It is the community for CICD.

And so this show, CD Pipeline tries to capture that. Um, this week's show is challenges and wins in integrating security tooling into CICD workflows. Let me introduce you to our panel for today, and then we can jump right into the topic.

First of all, I think it's her first time on, and if I am mistaking right, Kate, it is your first time? Yes, my First time. Very cool.

And I'm gonna try not to mess up her name, but I forget. Thanks from one second to the next, uh, Kate Scar, Almost Scarcella. Scarcella.

Yeah. If my eyes were better, I'd be able to read it up there because my, they didn't put it on my prompt here for me like they're supposed to, but they try. All right, Kate, beyond Scarcella, what else can we learn, learn about you here today?

So I am a cybersecurity architect. Uh, I got my Master's of Science and Information security and did my thesis on securing the electrical grid in North America. And I graduated way back in 2006.

And I tell people this because there was only four people in my graduating class, so nobody was really talking about cybersecurity, even though it was coming up in, um, in some products. You know, you had av, you had networking, security, and dare I mention the start of identity and Nexus management, which was like, ah, but anyway, so that's my background, and I did it for Very cool. Yeah, so very, For long, that was the electrical grid without Texas.

Very good. Mm-hmm. So, um, I'm not gonna touch that one again, but I, I've been in security about 25 years, myself more now.

And and you're right. Back then it was, it was network security or endpoint secure host security as we called it. And, uh, it certainly has changed over the years, though.

It's become more important than ever, obviously. Are you still working in the security field today? I am.

I took a short sabbatical for about a year, and I'm just, uh, coming back out of that sabbatical, um, connected with Tracy, who has, um, who has, you know, full speed here this year. So, yes. Um, well, It's great to have you on here.

Thank you. Thank you. I'm, I'm very happy.

Appreciate it. Looking forward to, to hearing more. Um, next up we've got Ryan Ware, as in software.

Ryan, welcome to CD Pipeline. Tell us about yourself. Hey, thanks, Alan.

Uh, I'm really happy to be here my first time as well. Uh, uh, I, I appreciate Tracy dragging me, uh, uh, to come on here. Um, so, uh, I've been doing security in one way or another for 27 years, uh, or so.

Uh, I'm a software developer by, by nature. But, uh, uh, you know, early in my career, uh, I first started at Intel doing, uh, implementing security features into digital rights management stacks. Uh, later I did offensive security research into, uh, Intel's products.

Uh, later I was more of a security architect and then, uh, worked in, uh, the realm of open source for quite some time, uh, on one. Uh, how do, uh, uh, product teams incorporate open source in a secure way, as well as how do you securely, uh, uh, make and contribute to open source externally? Uh, Intel has a, uh, uh, uh, a large presence in the open source community, uh, these days.

Uh, I work for Carrier, where I am Deputy Chief Product Security Officer, uh, focusing on security tooling, uh, CICD training, uh, secure development practices, uh, and, uh, I'm also in the, the Open Source Security Foundation where I am the chair for the security tooling working group in that organization. Very cool. You mentioned Intel's commitment to open source.

I think it's very fashionable today to, to crap on Intel, right? They're not, they're not Nvidia and you know, how the mighty are phone, but I, I think people have never given Intel enough credit for their commitment to open source, open source communities, open standards, and, you know, kudos to them for the work they do. I know they work very closely with the Linux Foundation, C-N-C-F-O-S-S-F, you know, a lot of the, the foundation.

So Absolutely try not to, they do, they do an amazing job with that and still do even, uh, with all the troubles they're having right now. com/intel. So, Absolutely.

So shout out to them. All right. Our last panel member today is our friend Tracy Reagan.

Tracy, of course, CEO of Deploy hub, uh, Aurelius, one of the products under the CD foundation came out of Deploy Hub and, and their, their efforts. Tracy's also, I mentioned she's a host on our Techron gang, and, you know, she works, she has a hand in a lot of different Linux Foundation, open source, uh, projects and, and boards, including OSSF, open Source Security, OSSF, and the, uh, ED Foundation among others. Tracy, great to have you on today.

Well, thank you. Yes, I am, um, a busy girl. I kind of have one foot in the security world and one foot in the DevOps world.

I am on the board of the Technology Oversight Committee at the CD Foundation. I've, uh, served in that role now for, uh, several years. And I'm also on the board of the open SSF.

Um, so I'm keeping kind of my thumb, um, on the heartbeat of both sides. And we re at the CDF, we recently started a, um, special interest group called CICD Cybersecurity, which, which Kate is the chairperson of. Uh, and it, the reason we, I felt we needed to start it was because there isn't a strong enough handshake between what the security side of the business is doing and what the dev, what the DevOps side of the business is doing.

So it's time that we have that, uh, conversation. It's a really critical one. Um, most DevOps engineers, you know, even just putting in, uh, the scanning of a SBO m is a major undertaking, and there's so much more to do.

So it makes me a little nervous that we are so far behind the eight ball. Uh, I wanna remind everybody that it takes us about a hundred days to respond to a vulnerability. It takes a attacker less 10 days to exploit it.

So we are, um, at a major disadvantage here, and there has to be a discussion on how to improve that time. And so we're hoping that we can do that with this, uh, the, the new SIG at this, uh, CD foundation. So I'll use CDs out there, which I call you, please.

CDs. I want you to join the, uh, the CICD cybersecurity SIG and start helping us with really defining what that looks like in the pipeline. And I hope we can have a deeper conversation around that, considering we have two security experts on the call today.

Absolutely. So, as I mentioned, I've been in security 25 plus years, right? com was I felt that DevOps and the whole CICD pipeline model was a way to get like a second bite at the Apple for security.

We could correct a lot of past wrongs by moving further left, shifting left into the development pipeline to fix security problems that by the, by the time we saw them pop up in production, they were a lot harder to fix. It would be much easier to fix them further left. It sounded great, right?

com devs, the whole rise of DevSecOps, as we call it, right? Uh, we made a lot of progress over those 10, 11, 12 years, but most recently there's been a pushback where have we shifted left too far? And by that, have we put too much of the onus on security on the developer who's not a security person, right?

And, but nevertheless, you know, we, we've made them the, the focal point for our security efforts and, you know, pre-deployment security where instead of, let's say, maybe building it holistically into the whole pipeline process right from left to right. And, and so, you know, there's been pushback. Hey, instead of shift left, we should shift everywhere.

We, we, we need to build security into testing. We need it built into the pipe, not onto the developer's shoulders. Now, Kate, you've got your master's degree in, in all of these things, and, and you're, you're the head of the sig.

What can we do to it? It can't just be, let's make the developer our security or make the dev our security person. He's, he or she is not.

What, what can we do? What are we doing? What should we do, you think, in, in terms of integrating security into this workflow?

Well, I think, and when you, um, go out, uh, to the specific page that, that we have, one of the areas, security is very complex, as you know. Um, cybersecurity is very complex, and it has becomes, the complexity in itself has, is also a vulnerability. So we need to make things simple.

So yes, are we putting too much on the developer and should we have it throughout the pipeline? Absolutely. But we also need to have, um, bite size, you know, these, these, you know, Lunchable type of, of packages that we can say we're gonna do, you know, we're gonna secure in the, in the, you know, free deployment phase and how, what does this look like?

And I think this, the more simple that we have the tools, because as, you know, to introduce a new tool, um, is, is just a headache for our developers, and yet another tool and another tool and another tool. And so I think we need to have, um, tools that are, and they're very expensive. So tools that are, you know, open source that can be used, that can be used easily, and so that it doesn't take a master's degree to go out to try to figure out, well, how am I gonna secure this?

I think that's, you know, something that we have talked about, um, with the sig. Um, and just, it's so important to keep it simple. I mean, it, it sounds, you know, ridiculous, but we have made it so hard.

We have made cybersecurity so difficult to consume and so expensive. I mean, think about the tools that we have developed. I worked with IBM for over 20 years, and it's not just, you know, it wasn't just one tool.

It wasn't just, you know, um, static, you know, analysis, coding, it became, I mean, you just, everything just grew and grew and grew, and we just would keep adding and adding. So I think we need to do more with less. So, you know, the one tool can take on this pipeline from left and throughout.

I dunno, Tracy and Ryan, what, what do you guys think? Well, I, you know, I, I preach simplicity all the time. Um, part of the problem With the CD pipeline, if I just put my DevOps hat on and not my security side, um, the problem with the, the CD pipeline is it's so brittle.

Um, everything's based on, uh, a script. So we have to go update all those scripts. And that is not an easy task, folks.

It is really not easy to manually update so many thousands of scripts, thousands and thousands of workflows. Um, so it becomes a challenge because we don't wanna touch those workflows. They break easily.

So then maybe we have to have a security workflow that the, that our workflow calls. So, Kate, as you pointed out, we've made everything so complex. Everything, not only just not security's complex, but so is our workflows.

They're complex too. So we've dug ourselves in a bit of a hole, and we're behind the eight ball. So how do we get out of it?

Now, many people know from my discussions that I have been a big fan of CD events. Let's rebuild and redefine how this, the, the pipeline works. But that e, even though IBM has done a great job, and that some of the team on that project has done a great job of defining what those EV events look like.

And even, uh, Jenkins has an event, has a CD events plugin. We, I don't see, uh, the, what I like to call the giants, the Microsofts, and the, um, the, the intel, even though they've been doing a great job in some areas, I don't see them understanding why events are important, why it's important to re uh, to disrupt how we do pipelines. So as long as we have this, uh, this difficulty updating pipelines, I think we'll have difficulty implementing tools.

So what we have to be able to do is define the low hanging fruit. Let's at least get started with getting a, a, a software bill of material generated and make that a, a, a common mantra that we can really expose to the DevOps pipeline and the DevOps engineers to say, this is one way we can get started. At least let's start there.

So, simplicity, I think, will be critical. Yeah, I, I agree with that, Tracy. Um, I, I would like to go back, uh, uh, uh, to what Alan was saying for a minute though, and, and just push back slightly on the idea that developers need to be security experts.

I, I don't, I don't think developers need to be security experts, but developers do need to be capable of writing quality code. If, if, if we don't think that there's an expectation on them to, to write quality code, uh, um, then I, I, I think there's something fundamentally broken in, in the system. 'cause, uh, they're the ones that are writing the code.

Uh, and security in a lot of ways is, uh, you know, the many, many security vulnerabilities are just engineering 1 0 1 quality issues, uh, buffer, overflows, uh, uh, uh, null point or de references, things like that. Uh, that said, I, I, I do, uh, uh, like what you're just saying, Tracy, uh, about events, I, I, I think one of the, the problems with how we have incorporated tooling into, uh, pipelines is, you know, it's all about, okay, how do we get this tool in here and get results out of it? And, and that's not the focus it should be on, it should be on what's the activity that the developer is doing right now, and what's the information that we can get from our tools that would be helpful for the developer to have during this activity?

A great example is pull requests with, uh, on gi. Uh, for example, uh, uh, you know, a lot of, a lot of organizations use, uh, a static application security testing tools, uh, traditionally called static code analysis. Um, which by the way, uh, there's open source tools that have been making great strides in this area.

GCC fourteens, uh, static analyzer, uh, functionality is, is way improved over previous versions. Um, that's said, you know, the right time to be able to show a developer about flaws in their coal code using a SaaS tool is during poll request time. And, and ensuring that, that, you know, when a developer needs the information about the quality and security of their code, it's important for 'em to have it at the right time.

Uh, traditionally we've told developers, Hey, yeah, you have to go over to this of the place over here where, where, uh, the results for, for all those scans are stored. Developers hate doing that. They won't do it, and we're never gonna win by share doing it that way.

So let me weigh in here. I bet you if we did a survey of developers and said, how many of you want to develop low quality code? Not a lot of them are raising their heads.

Every software developer I've ever met just about has a tremendous amount of pride in, in what they do and the code they develop. You know, it used to be before we got into the age of DevOps and pipelines and the software factory that we have today, software development was very much sort of like a, a guild, right? Ancient, uh, not ancient, but you know, like old German guilds where there was a lot of pride in craftsmanship and stuff like that.

When I was a security guy, I used to think, boy, those people don't give a hoot about security. And if they did, we'd be better off. But then when I, the more I got into DevOps, the more I learned that they do give a hoot about security quality, right?

Because security is synonymous with quality, and they do give a hoot. And then early on in DevSecOps, a lot of security companies said, you give a hoot about security, Mr. And Mrs.

Developer, here's a tool to use. Use our tool. Use our tool, use our tool.

And you know what? And that's where it went off the rails. You, they don't, they're not going use a security tool.

When you start telling a developer, Hey, wait a second, we wanna do a static analysis scan of your code. And that's not enough. Hold on.

I wanna do a dynamic scan analysis of your code. Wait, there's more. I see you've been using a lot of that open source stuff.

We're gonna do an SCA software composition analysis scan of your code, and whatever the, and I just bought this latest company's greatest new, you know, ICAS or whatever the heck, they're calling the next one to the developer. They just, Hey, can you just tell me if there's bugs in my coat so I could fix it? That's all they wanna know A hundred percent.

Right? And, and we've, I think we lose sight of that. And, and in a perfect world, that's where, and along this pipeline, these things get done and it makes its way back there, right?

And the code gets fixed. And look, here's the good news. We live in a wild time right now with AI and automation and everything.

A lot of these things could be fixed on the fly like that, right? I mean, you know, stuff we dreamed about Yeah. In 2006, right?

The, the ability to do automated remediation. I, I was selling vulnerability management in 2006, you know, no one wanted it, it, it took 90 to 120 days to remediate code that was code in production, not code in, in, in development. So, I mean, have we Gotten any better at that?

And still that? No. We, we have, because I'm gonna tell you, the problem I had back then is we were able to identify vulnerabilities, and we built workflow into our product that pointed to the patch, and we had the ability, 'cause we also developed a NAC product network access control.

We had the ability to remediate on the fly. No one would let us, yeah, yes, no one would let us because they were afraid to patch without first testing to make sure that it didn't break something else. It might break your stuff, Right?

But we can't, I'd rather be insecure than have broken stuff. I don't necessarily agree with that logic, but nevertheless, that was the prevailing logic. Have, have we changed?

Ryan? You've been around. We're trying.

Yeah, we're trying. But that means we haven't changed. Is that what you're saying?

Yes. I, I would, I would say there, there are areas in the industry where, where it hasn't changed and changed is hard. Uh, um, and, and to be honest, I I work in one of those industries right now.

Uh, um, one of the things that blew me away when I came to work for Carrier is the support life for some of our products. I, I mean, I, I used to work on automotive stuff where they're talking about support life of eight to 10 years. Uh, we have to support software stacks in our products for 25 to 30 years.

And, and because of that, the interesting legacy implications of some of the software we have, uh, uh, just are, are an interesting challenge for us in, in the new ecosystems. And, and a lot of people are resistant to change because of that. Agreed.

Right? You're talking about critical infrastructure. I mean, right, Brian?

I mean, you know, You, you know about it. Kate, Windows XP baby, you know, good luck. Um, you know, the one thing that I think would help us, and it's the antithesis of when we think about cybersecurity, but you know, the, the bad actors are doing this.

And that is, you know, when we talk about open source, you know, they actually, the, the bad actors actually do it, right? They collaborate, right? The reason they're able to get their stuff done so quickly is they have such huge collaboration tools.

And I actually think they're doing it right. I mean, it's a, you know, crazy idea. But I think we need the, you know, that the, the, those who are trying to make things better, that we really need to, to be, you know, have open source, you know, from, so from, you know, coming from all these, you know, companies that were, you know, doing proprietary stuff, you know, I've been like this new open source, you know, let's collaborate.

Let's, I think it's gonna be one of the most important things because when we have this discussion about, you know, the pipeline and can it just be on, on, you know, the, the, the shoulders of, of the very beginning person, you know, when we talk about cybersecurity, one of the things that we would talk about is, is everybody's, you know, everybody has to know about cybersecurity. Everybody has to understand it from the user with their, you know, digital user interface with their, um, mobile phone, uh, which has become a human machine interface to so much to, um, you know, to, to the worker, because we are one in the same, right? You know, the, the, the home user is also the one who's going into the office, who's also working with the, you know, we all need to think about cybersecurity differently, um, in order to help things to become, I mean, it, it sounds, you know, somewhat esoteric, but we really, we need to, to do it.

So it's not so scary, right? Because we sell based on people being scared. And we need to, we need to really back up from that and think, what are we gonna do to make it better?

I think, and, you know, to, to Tracy's point about, you know, low hanging fruit, Boy, How much can we, I I, how much can we do with just getting the low hanging fruit? You know? I mean that, I, I think I, I think it could be like a 70% type of thing.

I, and, you know, maybe there's a crazy percentile, but, you know, low hanging fruit, I mean, that's a, it's a great idea. There's definitive WIS there. Absolutely.

There's a whole bunch. If you could just, you know, just take those, you know, we've got a few minutes left. Let me bring up another kind of push pull that I think really affects us.

And that is, and this has been going on, bro, as long as I'm in security, which is what's my tolerance for security slowing things down? Yeah. Well, right, that's a good Question.

That's, that's a little question, You know, because that same survey where I asked the developers, do you like making low qual or, you know, crafting low quality clo uh, code, the next question is, you know, why don't you do security better? And it's always because the pressure is on, and I get paid based upon how many lines of code I publish, and I don't have enough time to write and test. We don't have enough time to write and test the code thoroughly, because we have deadlines to meet.

And so when security becomes the people who say no, and puts the break on going faster, we very quickly get kinda shoved out to the side, pushed to the back, you know, stay outta the way of this. You're, you're standing in the way of progress. Um, how do we, and, and again, this was one of the things about Def SecOps that I thought we would do better.

How do we overcome that perception and move at the speed of business? I like to say moving at the speed of DevOps, Right? Okay.

Moving at the speed of DevOps. So we have a weird, there's a, you know, there's a, the cultures between the DevOps people and the culture between the security people could not be more different. Um, if we think about v uh, a new vulnerability that's been found in production, the mindset of security is don't tell anybody.

Go through a, uh, event management process. Notify the people, only the people that should know. Because if we, uh, tell everybody and let the development team who's being impacted know that they may have, we may have some kind of internal attack to it.

So there is a hold this, you know, hold the cards close to the chest mentality inside the inside on the security side. It just is there. They don't, they lack the trust.

They want the control of managing it. This slows everything down. The, the, our, our culture there has, is, is just wrong.

Now remember, it may have started back in the, in 2000, Alan, when you were trying to solve the problem. And what they were doing is they were, you know, if a, a, a bug was found, uh, uh, if a hacker found a vulnerability that impacted Microsoft or IBM or the government, or Hewlett Packard or anybody else, they got, they were purchased. So we had a zero day market and nobody told anybody about them.

So that's where we begin our story in security. Now, on the other side, we have DevOps engineers who have been preaching agile development and releasing fast for the last 10 years. And we have gotten really good at it.

And on top of that, we have Kubernetes, which means everything's decoupled. Everybody use, it builds their own container. So that one production vulnerability could be living in hundreds of containers across our endpoints.

So now we find ourselves having to fix some really big problems with a culture that doesn't want anybody to know about it. And another culture who says, you guys are way too slow. We need to continue pushing new innovation across the pipeline, because that's what we're being told to do.

And we're trying to build the best quality code we can. And we're trying to manage DevOps pipeline so that they're getting code out as quickly as possible. Because that's what the business demands and security sitting there and saying, well, we don't want anybody to really know about this.

Let us try to mitigate it and go through the process and only tell the teams that need to know that this problem happens. It doesn't work. Those two cultures are, are conflicting.

So somehow we have to create that handshake is kind of what I began this conversation. Security has to be more willing to open up the door and let more people know about it. Security has to be willing to have those fixes pushed across.

And Alan, you were just way before your time. In our world, what we're trying to do, you know, for Intelius and Playup, we or we, Ortel has the information right now to be able to push out a remediation. So we have discussions about discovery and how to remediate.

We wanna shift the focus to how does DevOps fix it? How can we use DevOps information to at least create, update a, a helm chart or a, a Docker file, and at least create a pull request for a high security vulnerability that's impacting certain teams and get it to them as quick as possible so they can make a decision if they want to move it forward, they can do the analysis and they can accept or reject that pull request. But to do that, we have to get the security teams to say, yeah, that would work.

That would be okay. But at the moment, they may not be saying that. 'cause they're saying, no, we wanna manage that response ourselves, and it slows everything down.

And the world just keeps turning while security figures out what they need to do. I, I think that's beautiful. Uh, you're right on.

Yeah. I, I mean, we, we, in the cybersecurity, um, Alan and Ryan, I mean, right? I mean, we, it we need to change this mindset that we have.

And I really do believe that we need to be more open about the vulnerabilities that we have, or we're not, we're not making it the way we were doing it. We know that. So it's about time that we switch things up and say, okay, let's try something different.

Yeah, I, I, I agree with, with what both Tracy and Kate were saying. Uh, I, I'd also just add to, uh, uh, taking a, a, a little bit of a, uh, uh, uh, perspective change. I, I think security folks, a lot of times new sites of what developers really need, uh, to, to do their jobs right, and, and do their jobs the way security folks think they should do their jobs, uh, uh, uh, and, and a lot of the things that, that security professionals ask teams to do without thinking about it, uh, uh, dramatically slow development down.

And, and, uh, like I was talking about static code analysis results and pull requests earlier, well, that works great if you're doing, uh, uh, for example, writing code in Python, uh, or JavaScript, uh, uh, you can get results pretty quick out of there. 5 times the build time. And building the Linux kernel is not a, a small event anyway.

So you can't ask dev teams to, to wait for, for 2, 3, 4, 5 hours for results on tools until a pull request before they can go accepted. Uh, uh, you, you know, you, you have to figure out what's the right balance, uh, uh, to be able to, uh, uh, bring the bar up from where teams are doing it right now, to, to, uh, doing it in a way that, that they feel is acceptable use of, of their bandwidth and their time. Agreed.

Agreed. Hey, guys, we're, we're about outta time here, unfortunately, you know, we didn't mention the CDF. You mentioned the, uh, STIG that you guys started.

org, isn't it? Chay, the website for the CDF, Uh, CD Foundation, Excuse me. CD Foundation.

CD Foundation, yes. And the SIG is new. It just started in January.

And our first exercise is we're going through the, um, secure software development framework. We're looking at every single task that relates to the pipeline, and we're associating open source tools that can be used to, to accomplish the task. I love it.

Can you get to the sig off of CD Foundation? Yes. Page.

We should be able to go to the, um, uh, community page and find it. All righty, Kate, congratulations on leading this Zig there and getting your hand into this open source security world. It's going to, we, we can all use the help.

So thank you for your, for your efforts there, Ryan. Same to you, right? It sounds like you've been involved in this for a while now, whether it through Carrier or Intel, what have you.

And thank you for all you are doing. Thank you. I appreciate it all.

I just have one more, I just have one more thing before we sign off. I wanna shout out. Shout out to Sasha, uh, Wharton, who is one of our, uh, top or like Ortel contributors, and he was recently nominated to the, uh, the CDF, uh, governing board as a open source representative.

So we're super proud of him. Congratulations to Sasha as well. Alrighty.

Righty. That's it for CD pipelines. foundation.

Until then, is Alan Shimmel for Techstrong. Thanks everyone. Bye-bye.

Hey, happy Friday. The outlook for DevOps today is cloudy with a chance of AI in some heavy CICD you, you're watching Textron Gang. Hi everyone.

Alan Shimel Textron here for Textron Gang. Wow, it's Friday. It just seems like yesterday was Monday and today's Friday.

And it's not because we record these a week at a time. It's just that kind of crazy week. We've got a lot to go over, including some new DevOps reports and research by one of my favorite DevOps analysts in the world.

Um, some new Java is, can Java be 25, 24? I don't know. It seems like it's been around that long.

And, uh, we've got a little Star Wars. May the droids be with you. All kinds of good stuff, good people to talk about it with.

Let me introduce you to our gang members today. We're going out west again to, uh, start things off with our Silicon Valley contingent, the, the king and queen of the valley. Uh, we've got Lisa Martin.

Hi, Lisa. How are you? I'm great, Alan.

Great to be here. Okay. And the King John Schwartz, our Silicon Valley editor.

Hey, John, how are you doing? Hi, it's good to be here. Happy to be here.

Busy week again. Yep. So what's the sweatshirt today?

Oh, we can't really see it. California Golden Seals. Do you know much about the history of that team?

Say N Hhl? Sure. California Golden Seals hockey.

You remember who owned them? They're Goalie Hockey. Yes.

Well, I'm a, yeah, no, I used to play hockey. I didn't play hockey. Hockey.

I watched hockey. Okay. So they were, they were an expansion team in 1967, I believe, along with the flyers and penguins, et cetera.

And they were owned by Charlie Finley, Who Yes, they were, they had the same a colors gold and green. You just stole my thunder. Exactly.

They were terrible. They were the opposite of the As. But, uh, they were an interesting team.

I got to see 'em play when I was a kid. Didn't, didn't it. They moved to Vancouver and they became the Vancouver.

They grew Cleveland, they moved to, became the Cleveland Barons, I believe, and then, ah, Yeah, the Cleveland Barons, the nor that that was merged with the Minnesota North Stars, if you remember them. Anyway, it's a painted history. And, um, you know, it, it, it was, it was, they played in the Oakland Coliseum when the a and the Raiders and the Warriors were off.

I remember, I remember though, we're all old enough to remember, you know, I played, I did play hockey, I played roller hockey. I was a goalie. And what I did is I, you know, we used to have those ball bearing kinda wheels, and I smashed them square so they didn't roll.

And I could just walk. And as a goalie, I didn't have to walk too far. So I very rarely fell.

And I, I, I was a good goalie like that. Nice. Anyway, moving on.

Moving on to Colorado. We've got our, uh, future VP research, DevOps, Mitch Ashley. Hey, Mitchell.

We've got full on guitars today. You changed the angle there. Yeah, we're getting, we're getting a little up the upshot on the guitars, by the way.

The only seals we have in Colorado are the seals on mason jars. Were used for canning vegetables and fruits. Yeah.

So this, as close as speaking, I would imagine that's what a seal means to you. Okay. I guess that's why it's so regional.

Speaking of regional, let's go to a different region north representing the northeast bating left-handed throwing, right. Getting ready for baseball season. Chief Content Officer Mike Ard.

Hey, Mike, how are you? I'm good. One week opening day three o'clock Thursday next.

Yes. Yes, it is actually. So the game's going on in Japan now.

They're still preseason. Yeah, no, tho No, those are regular season. The the dogs are two and Oh yeah.

We might take a week off or, or so to recover from Japan, but yeah, everybody else starts on the 27th, right? Seventh. Oh, okay.

Very cool. Very cool, huh? Well, I could talk baseball more, but we've already gotta get going here, Mike.

We've got some new, uh, research coming out of our, uh, friends from fu. What's going on? Yeah, the research is on what's happening with DevOps in general.

And, um, there's actually two reports. One is kind of a survey, the other one is a market analysis where we're seeing, I think the number was a 9% compound annual growth rate for the next few years on DevOps tools and platforms. Mitch, I'm gonna let you dive into it, but, um, you know, we've heard all this noise over the years about DevOps, especially in the last two or so.

And yet, looking at the data things look pretty vibrant. It, it's interesting, you know, it is kind of, once things have been around for a while, you say, well, is that sort of passe? Or, you know, what's really happening with it?

And, uh, as you mentioned, we did both. We have our own market analysis, the growth of the market, you know, nine plus percent cagr, uh, over the next several years. Uh, but we also correlate that to buyer decision maker data.

So we have a very comprehensive, not just looking at DevOps, but really across the entire software development life cycle, considering DevOps and Agile, but also software development, uh, platform engineering, uh, testing, um, application security, uh, ai, AI ops, things like that, IT ops. So let's kind of think about the whole life cycle. And, uh, we had 855 responses to this.

com and I'll be having some more stuff come out. But the themes of it are, when it comes to DevOps is, is we have very high levels of people who see themselves in the kind of three quarters of the game. If you wanna think of a football game or in the fourth quarter of kind of very mastering DevOps or in the, you know, standardizing it across the organization, over half of, of the respondents and, and very few, it was like 14% said they were in the beginning stages.

So we're in a pretty far down the maturity stages. The interesting thing is, we, we kind of divided the, the analysis up into people who were doing dev DevOps, who are doing development, people who are doing platform engineering. When we asked the platform engineering folks, they weren't quite that far along, but not too far behind.

They, they saw themselves as pretty mature in their platform engineering efforts probably 'cause they were doing some of that stuff before. Maybe they're getting more attention and, and funding to that. Uh, a couple of other interesting things is, uh, we had both 41, 40 3% range of people both in platform engineering and in DevOps and in development saying that they're using AI as part of their, an aid to their tools.

Now, that can mean a lot of different things. Could mean we're using cursor. It could mean they're just using chacha to, to do, you know, code, code lookup or whatever, or get ideas for code.

There's a wide range of things, but the fact that, you know, almost half, close to half are saying that they are using AI today. And the two, the last thing I'll kind of add to that is the two biggest, well, I have my budget for 2025, but I'm planning to spend even more this year and even more in 2026, software security and ai. So those are the, those are the key themes coming out of this.

And nowhere really did we see, well, I'm cutting back in these areas. Almost, almost all of it was kind of full steam ahead and this was late 2024, early 20, 25 data. So we're not, you know, we're talking, not talking sometime last year.

This is pretty recent stuff. Hmm. Interesting stuff.

So I, I'm not surprised at the maturity findings, Mitch. com now for a couple of years, is that, you know, DevOps certainly crossed the chasm, certainly penetrated that, you know, 35% of the main of the, or the early 35% of the mainstream, right? And is clearly going after the, the other 35%, you know, the, the second half of the mainstream, if you will.

Um, what I, what I am pleasantly surprised 41% plan to use AI with it, right? That, that shows you, I think, you know, almost half half of folks are trying, are gonna be, you know, trying to use AI in, in their software development pipelines. Um, I think the other thing is though, that as part of this DevOps maturation, we've seen DevOps, you know, you know, general Douglas MacArthur said, old software never dies.

It just fades into the woodwork. And I remember that's, oh no, he didn't really say that, did he? But he said something like that.

But um, he was up to his ankles and water on a beach, right? Yeah, yeah. Trying to figure out those are the, those Right or something.

And I don't know what was in that pipe. But anyway, um, DevOps has kind of gone into the woodwork itself, so to speak, along with things like ITSM along with things like Agile, which is kind of the precursor, right? Agile is 25 years old.

And so, and then you have new things like platform engineering, which is really, you know, still very closely aligned. It doesn't replace DevOps, it works alongside it. And so, and you things and other new things like s re maybe and, and stuff like this.

So we cloud native I should mention as well. So you have this whole ecosystem of which of frameworks and, and ways of doing things and so forth and, and DevOps has, has taken its place. Kind of like when you look up at the stars, right?

And you see all the, the past rulers of Pride Rock and, um, DevOps is up there. So It is, you know, and interesting too, Alan, um, couple other thoughts. One is when we asked, so what do you see is, is the most important technology or investment areas to invest in to, um, getting software into production, uh, faster, more consistently?

Top of the list. The, the top things were gen ai, uh, A IML for dev, DevOps and test. Um, and also software security was up there at the very top.

So e even looking at just kind of, what are you using? What are you spending, what do you see as critical? You know, kind of, you oftentimes you look at different ways of analyzing those questions.

So you are, you kind of triangulate, are we saying the same thing? It it's very consistent. And these are decision makers, these are buyers, and these aren't, um, you know, just folks reading about it on, on, uh, you know, Udemy or something, taking a course on it.

Mitch, I'd love to get your opinion on this. 'cause when I talk to people, I get two divergent points of view. One is says that with the rise of AI coding tools, the pipelines we have are too brittle and we're gonna need to replace all our DevOps platforms to accommodate for that volume of code.

The other says that AI agents will just pull the data from all the existing platforms and the AI agents will manage in those workflows without having to replace any of the DevOps platforms. So I don't know what your sense of how that's gonna play out, but right now I can line up 20 people and they'll split evenly on that conversation. Well, I think there's multiple trajectories.

One is moving to platform solutions, that kind of, a lot of the pre-integration done for you, instead of development teams being, being in the tools integration business. That's one path of helping to reduce that problem. Uh, another, and, and it is an issue especially around CICD.

'cause CICD sounds like one thing, but if you really understand what's going inside of it, it could be 50 or a hundred different types of CID for CSED pipelines going on for different apps, different versions of apps, all kinds of things. So the complexity in that is very high. And oftentimes there's a few folks that will touch it to go resolve it.

'cause it is, it does take some real skill to do that. There, there's a belief that we can put AI onto that task, at least to analyze it and give us more people accessible to be able to resolve issues with CICD with Ag Agentic than maybe starting to address it. The, the kind of wild card factor is now we have a whole different path of doing development, you know, whether it's through cursor or, you know, Gemini code or whatever your latest, uh, flavor of the day of generating code through code, uh, natural language as opposed to writing it.

And how does that flow through into, you know, a DevOps. So in a way, we're making it more complex as we always do, kind of things that get more complex over time, but AI is one of the, one of the potential solutions for it. But I think there's others platforms are definitely a part of that.

com. We, we have an article on there with links, and if you go to futurum group, uh, dot com under research, it's there and there's, and there's also been a huge refresh in the, uh, FUTURUM intelligence portal that incorporates a lot of this and some other DevOps, uh, research Mitchell that you have spearheaded. And, and, uh, if you're not familiar with the futurum intelligence portal, go check it out.

It's, it's actually a really, really nifty tool. If you wanna stay on top, depending what you wanna stay on top of, I like data. That's the place to go.

We do all kinds of analysis. Good stuff. All right, let's take a break.

We're gonna come back here. We're gonna talk about Java. What could you, nothing new in Java is there.

Stay tuned. You're watching Text again, Discover Techron Group, the epicenter of tech innovation. We are your go-to for reaching IT, leaders and practitioners worldwide.

Our secret impactful content that sparks awareness, engagement, and top quality leads with us. You'll access editorial websites, streaming videos, virtual events, custom content analyst research, and more. Join our satisfied clients.

Let's revolutionize your tech journey. Contact us today and tell your story to the world in the most powerful way with Techron Group. Hey folks, we're back and we're talking about Java that got a new addition.

I think it's number 24. And this one is being driven largely by Oracle, but it has everything in it from, I don't know, post quantum cryptography, free support to AI capabilities. And it looks like, you know, Java, the venerable language we're using that word again, is, uh, getting a significant update.

And Oracle seems to be driving this despite the fact that Java was supposed to be this whole open source community thing. So Lisa, I know you're out on the west coast, but is Java cool again? I think it is.

It's hard to believe it's almost 30. When I was doing research on this, I thought really? 30 and, and the scary, I think it's what's scarier is I can remember 30 years ago and it was was, it doesn't seem like it was that long ago, but yeah, the event Java 1 20 25 up up the, the shore here in Redwood Shores, they announced the availability of Java 24.

The latest version reportedly some of the things they talked about in the press release, thousands of improvements they said to help developers really maximize their productivity drive innovation. We just talked about the DevOps, um, momentum going on that future machine, that's what organizations of every industry want is to accelerate that business growth. The pedal is to the metal and it really, I think what we're seeing from Java is it's continuing to really expand its tool set to meet developers where they are their evolving needs.

And I think considering we just talked about the DevOps momentum when the pedal is to the metal, I think this is a good thing. Absolutely. You know, I I re who remembers the little Java logo caricature?

The little black and white guy looked like a Star Trek kind of a kind of thing, you know, uh, energy wave or whatever that really is in Star Trek world. Um, and of course, look, if you're gonna call out Java being 30, you gotta pay homage to sun, right? I mean, for those of us of a certain age, what a golden era of, of computing Sun ushered in with Solaris and Java and Spark servers and all of the great innovations that that came out of there.

Um, it's interesting. It, you know, Oracle or Java is the language Oracle loves to hate or hates to love. I, I don't know.

But, you know, they keep improving it. And, and excuse me, this one really does seem to be a major upgrade, right? You've got AI integration in here, you've got post quantum cryp cryptography a little early.

Certainly though look, we're here at so much quantum stuff. I'm, I'm looking for Quantum in 2026. Um, and, and of course developer experience tools, which has always been at the heart of Java.

The, the other interesting thing is, you know, we are, we go on here and we, we, we argue whether, you know, is his line is correct in letting us in, in, in pushing rust over C sharp for colonel and, and what's the latest, greatest languages we're using and do we really care about languages? But you know what, 30 years later, Java still rocks and rules the roost, right? I mean, is there any language that is used more today?

I mean, it, it's a lot more of a fragmented world in terms of languages than it was, let's say 30 years ago. But it's still a dominant, a dominant force. You can't kill this beast.

That's, yeah, that's what, that's just what's so remarkable about it 30 years later is still relevant. And then they did really did do a push. I mean, I talked to an executive at Oracle about this and the la the only unfortunate thing is that they made the announcement the same time as Nvidia in the, the Monster conference that they had.

But, um, you know, kudos to them for, for keeping this alive and making it relevant and adapting, which is something that Oracle has to do as well as companies like Salesforce and C3. They, they've just gotta continue to foster and, and move along. Mitch, it seems like the appetite for learning new programming languages is not all that high, despite the fact that there's more of 'em than ever.

But if you go into your average enterprise, it's Java, Java, Java. Well, a really good point. There's such an embedded base of Java, right?

That's part of one of the, kinda like DevOps, right? It's part, it's embedded within the organizations, right? Once you start developing applications in Java, you're gonna be using Java first for a long time.

And, you know, after, remember, remember when introduced it was very revolutionary because that was, the days of the languages were things like c and c and c plus plus, and really, you know, more complicated languages to learn. And Java was seen as much easier, though it has its own complexities too. But I think the support from Oracle, you, you called out a couple things, uh, Alan and Elisa about what they announced.

I think one of the big things too is the backward compatibility, two versions of Java itself that are included in this new version, because that's always the hassle. As things mature and mature and mature, you get bigger and bigger embedded base of code of different versions of things. Some things get sunset or grandfathered, whatever, and it's hard to upgrade.

It's, it's a, that's that technical debt. And so I think them, by investing and trying to give as much backward compatibility as they could, you know, something's embedded in our, in our software stack, when the people we're talking about app modernization are talking about how do we migrate from Java to something else? And that's, that's part of that conversation too.

So it's not going anywhere. It's, it's gonna be with us for a long time. I think from a marketing perspective, John, you nailed it.

It's relevant. It's 30 years later, it's still relevant. And one of the things that they did here, I, I think a, again, from that marketing lens is they really nailed what is important to their target audience, which is developers.

They're really working on improving the onboarding experience, making this mm-hmm. Kind of p this OnRamp, as they said. And so I think they're really getting to maintaining a community that's healthier and healthier.

The ecosystem is there, but getting these, uh, developers onboarded much more easily is a, is an a plus. Remember, Allen, we all thought job was gonna be dead when Oracle took it. We thought, uh, oh.

That's the end job, everybody. Yeah, exactly. I would just like to point out that everybody on this call has been doing this for longer than 30 years and is hopefully still relevant.

So. Well, that's be in my case, but, uh, I'm not so sure well are, Yeah, I'm not so sure. I try to stay relevant, but, you know, I'm out here quoting Douglas MacArthur, who the heck knows who he's out, who's that?

Um, so anyway, all good. Happy birthday to Java and, uh, good to see it out there and thriving and staying current. Uh, you know, and I'm glad to see post quantum cry cryptography being used, right?

We're gonna need it. All right. We're gonna come back and do our C block in and right after this break, and I'm not sure if those are the drs we're looking for.

com is the leading resource for news analysis and education on challenges facing the cybersecurity industry. com covers all aspects of cybersecurity, including data security, DevSecOps, cloud security, application security, network security, security threats, and more. com has the largest selection of security content featuring breaking news, blog posts, podcasts, and more.

com to learn more. com. Home of security bloggers network.

Hey, folks, it's, John alluded to earlier, yes, there's been this massive conference involving Nvidia all week long, and one of the things that came out was Disney and Google DeepMind and and video are gonna go build some actual droids, you know, the ones from Star Wars, and you go to the, uh, amusement park there, and you'll be able to interact with these actual droids, whether it's R 2D two or not. I don't know, probably. We'll see.

But John, I'm telling you, this is a conspiracy right now. And here's how I'm viewing this thing, right? I could drag you to the amusement park.

The kids drag me into the gift shop, and the next thing you know, I'm taking home joy's. And that's how they get into my house. Yes, go for, yes.

It's like, it's you, you are channeling George Lucas. You're channeling Steven Spielberg. It was always about the merchandising and the marketing in addition to great movies and great created creative contents.

It was also about, that's where the real money comes. And I think, um, I think beginning next year we're gonna see these Star Wars inspired BDX droids at, uh, theme parks for Disney. That's the planet least.

There's a, uh, guy named Kyle Laughlin, who's the senior VP of, it's called Walt Disney Engineering Research and Development. And he basically said the BD steroids are just the beginning. They're committed to bringing more characters to life in ways the world hasn't seen before.

And that's the plan. And, and in fact, I think it's South by Southwest, there was a demo of one of these prototypes that was shown. I saw a video of it.

It was actually pretty interesting. Um, but again, these are entertainment robots, and I think we're gonna see various iterations of different types of, not just droids, but animals in the same story. I mentioned, um, this new dog that's being developed in Europe called Luna, that, uh, can be trained.

It is very strange. There's also, at uc, Berkeley, there's this, a robotic squirrel that's being developed that can leap and, and land on ledges. So this is the world we're In.

He's not rocky, is he? He's, no, no. There might be a Bullwinkle in the future, but, um, Well, he has a moose friend.

Yes, he does. I wonder if the dog will chase the squirrel. That's what happens in aren't, you Know what they should have developed that they should have developed the, the Rocky robot at what's the matter u right.

Not Berkeley. Yeah, that would've worked. But in any event, it's a, it's a very strange World.

Oh, John, that was, That was, that was, I got that from My brother. I'll give you, I'll give you a, I'll give you a few bonus points. All right.

Okay. Thank you. Thank you.

It was like an SPN show, right? Pardon the interruption. But, um, but anyway, that's where the, that's where, uh, Disney's going.

And Jensen, it's really weird. He, he made this presentation in the midst of a 90 minute fire hose of news. So it didn't really get, a lot of it got coverage.

I mean, obviously rewrote about it and others wrote about it, but he kind of like tucked it into this larger presentation. And I wish he kind spend more, a little bit more time with it. There was also, maybe the reason why he didn't spend more time was, there's a bit of a glitch during the demo, so that could have explained it, but Brave New World.

So Alan, will Paramount respond with the Commander data as a droid? Is that where it is Going? Well, come on.

They did. We're scratching the surface. First of all, let me say this, and I'm speaking on behalf of Mitchell and myself, I can't wait to go buy one.

Alright? I guarantee you I am buying it as soon as they're out. I'd like a C3, uh, CP three more than R two at first.

But I'll take anything they got. And then, you know, you know, it's Disney. Who wants, who doesn't wanna buy a princess, right?

For your little girl, her own, her own Snow White or Cinderella, or, or any of the princesses. But let's go. And why stop at Disney?

Why can't we get data? And why do we have to get tribes, you know, make 'em, make 'em animals, make 'em anything. This is, It's a little secret.

I I, I've got my agentic AI agents already on the task, and they are already cornering the market on all the supply coming out of China. Yeah. Or more.

These are being, Well, no, there's gonna be a har a huge tariff on this huge tariff. Oh, Geez. They're Tariff.

Oh, no. Do you think that Bob, I, But seriously, I mean, Bob, Bob Iger must, his eyes must be lighting up at the prospect of this, or whoever, whoever becomes a CEO of Disney eventually. I mean, because they've been struggling with the theme parks.

They're overpriced, they've had issues with weather, et cetera. But this is an opportunity to kind of build a new product line, a new Monet monetize something. And maybe they do it ironically, through robotics.

I don't know. One of the things that stuck out to me is, I was just on iHeartRadio an hour or so ago talking about giving them kind of an update of what, you know, this big AI conference in Silicon Valley is all about with the, with GTC and I talked about the humanoid robots. And there in the consumer space, there's a lot of fear of, of what a humanoid robot actually is.

So I wonder, when I saw this partnership with Walt Disney and Google and Nvidia, is this gonna help start to get the general population more comfortable with robots and show mm-hmm. How they're able to be used from an entertainment perspective? I think some of the fears out there might be dialed down by something like this.

Yes. Like a kind of cute and cuddly approach versus they're not gonna steal your job. They're, they're gonna entertain you.

They're gonna be your friend. Like I went to, when I went to Carnegie Mellon, we, we had the, the humanoid ro robot. There was a crude implementation, but nonetheless, it had a personality and almost felt as if it was a, another person in the room.

And it, it had a bit of a, a little bit of weird, I hate to say this, but charisma and it reacted to you. And I think that is Lisa, you're right. That is part of probably the mindset.

I got One You going do, we're all getting at, Okay. Mitch Poison. Pre tariff.

Pre tariff right here. Um, but come on, this is a no-brainer. This will this be the killer app for ai.

It could be, Or recreational robots. And, and, and you know it, and it'll grow from there, right? Because today the robot will do stupid checks, but tomorrow the robot will, will, will continue to get smarter and start doing your homework with you and everything We see your laundry for you do the dishes, they'll set up the table.

Yeah, there you go. Might be a little backroom betting on two robots having a battle. You never know.

Ooh. Spoken like a real Bronx guy right there, man. I, that never crossed my mind.

What, what was that? What was that movie? Not Rock And Suck.

A robots will be coming. No, no. Yeah.

Well, that would, that would be pretty cool. Crazy. Anyway, Hey, what a great time to be around.

We'll, we'll put, what's his name again? That's not R 2D. D-B-A-D-B-A, right?

We'll, we'll put it to the side for now, wherever it was. I've had him sitting here all this time. He was just, he wasn't smart enough.

Now I just, I could put a chip in there. Um, anyway, what a great, what a great story, what a great way to end our Friday on Textron Gang. We wish you guys having a great weekend.

There's a lot going on in, in, in the world this weekend. You know, a lot of us is starting to get a little better weather right now, you know, April is coming. Um, so good stuff all around.

We have a full text, drunk TV lineup, of course, following our gang show today. So do check that out, Mitch. Congratulations on this DevOps research, by the way.

That was a nice piece of work there. Thank you very much. A lot of folks contributed and made, helped make that happen.

So thanks to the team, everybody. Yep. Excellent stuff.

But for now, on behalf of our gang and all of us here at Techstrong, have a great weekend everyone. We'll see you Monday. We're out.

This is Textron tv. Hi everyone, it's Alan Shimmel back here at Techstrong tv. My next guest is Lynn Sun.

Lynn is the director of open source for solo solo io and is also serving as A-C-N-C-F-T-O-C member and ambassador and with cla, uh, cube Con, just less than two weeks away. What a great time to have her on here. Hi, Lynn, welcome to Techstrong tv.

It's great to have you. Hey, Alan, thanks so much for having me. Not a problem.

So, Lynn, as I told the, uh, audience, your director of open source at Solo solo io, as well as a TOC member and ambassador for CNCF, but you know, there's a lot that covers up a lot of history. Give us a little of the history, a little bit of your journey. Yeah, so I'm a immigrant to the us.

I'm the person that carries $100, come to the us gosh, 25 years ago. And I started my job at IBM. Um, I've actually worked at IBM for 19 years, uh, before I joined solo, right in the middle of C Um, I actually was thinking about retiring at, uh, my job at IBM.

'cause, uh, I was working on, is still open source, you know, something I'm really passionate about. Um, but when the founder of Solo, I lavin reach out to me and said, I want you to lead up the Open Source team at Solo, I started looking at what is solo? So SOLO is in right in the business of cloud connectivity down, right?

Um, connect microservices, how people expose their services outside of their Kubernetes cluster. So SOLO is right in the domain of service mesh, uh, which is where my expertise was. So I decided to, you know, jump onto the, the hype of the startup hype.

I, I feel like I would regret for not join solo, you know, take the chance, uh, when one day I retire. So that's how I end up, you know, being the number one employee doing open source at solo and, and, uh, I'm having a blast at Solo. I love it.

So it is a friend of mine, and I do tell her, send my regards, maybe I'll see her in London. Um, you know, it's a great story, right? 'cause you mentioned this DO and IBM and Service Smash.

And of course, you know, Istio though now is part of CNCF was not always right. There was a little history there with Google and how to that was gonna be dealt with and everything else. Um, but Solo is, has, has always had, I mean, for as long as we're doing, covering the Kubernetes space, which is probably going on seven or eight years now, right?

The cloud native space solo has always been a, uh, a player when it comes to Service Smash and all of the things that Service Mess brings to it. And, you know, our audience is a very technical audience and they're cloud native savvy. But for people maybe who aren't familiar with, like, where service mesh fits into the Cloud Native Stack, Lynn, how, how would you describe it?

That's a great, really great question. So, service Mesh is a term, I guess we started about eight years ago when we started, is still, uh, there's other projects out there in the market. Linker d is another player.

Service mesh essentially is trying to solve the connectivity problem for microservices, right? Um, instead of having developers solving connectivity, uh, problems of microservices as libraries, um, in their application service message, solving the connectivity problem, uh, for microservices as part of the framework. So as a developer, when you develop microservices, you don't have to worry about how your microservices are connecting to each other, how to have the connection, uh, secure through mutual TLS.

You don't have to worry about, uh, rotating your keys and your secrets. You don't have to worry about how do you observe your microservices consistently. So that's what Service Mesh is trying to solve.

Istio is a really interesting project in the domain of service mesh. Uh, not only we are the most, uh, popular and most, uh, uh, deployed in production service mesh out there in the market, but I always view Istio as an innovator in the service mesh market, right? So two, almost three years ago, we launched, uh, Istio service mesh in ambient mode.

What ambient is really driving Istio mesh is towards being the mesh being totally transparent to the user, right? That's the word ambient. So when we started is DO seven, eight years ago, we always view service mesh as part of the infrastructure that user can run and forget about it.

But we couldn't accomplish that vision of service mesh with sidecars, because with sidecar, with every single newer version of Istio, it could be a minor version or a fixed bag. You always have to restart their site car along with their application. They always have to worry about the downtime, the operation complexity.

So, fast forward to ambient. Uh, by the way, we just announced ambient outreach GA in Salt Lake City, uh, at North America last year. So with Ambient, we really have the opportunity to provide a service measure without sidecar that's, uh, totally transparent to the user.

Um, the layer for layer, which provides mutual TRS and, um, and simple policy authorization policy on the layer seven layer with, uh, service measure. We're talking about retry timeouts, we're talking about traffic shifting on the edge. TT P layer, uh, we're talking about reach authorization policy that you can configure authorization policy based, um, method based on whether it's GA or post based on certain particular paths, right?

We're getting really rich on the edge GDP layer. That's when, um, Waypoint coming. And what really interesting to me of is still ambient is we're bringing the vision of, uh, Waypoint as a gateway, um, but serving, uh, interservices traffic inside of the mesh, right?

Essentially, we're bringing the ingress and egress gateway into ambient also as the gateway, uh, for interservice communication inside of mesh as Waypoint. I believe this is also following the Kubernete gateway, API lead, right? Uh, for the audience who are not familiar with the Kubernetes gateway, API, it's the new networking, API for Kubernetes.

Uh, people view it as Kubernetes ingress V two. Well, it not only allow users to control traffic for ingress, but also expand to mesh, uh, with east or west. So I'm really excited about is geo ambient and the, particularly the architecture and the innovation with ambient.

Love it. I want to talk about K agent, though, so I'm gonna shift gears here a little bit. Um, give us, give us the lowdown on that, Lynn.

Yeah, totally. Um, so as I mentioned, SOLO is in the business of gateway and service mesh, right? So we support hundreds of our customers running, uh, service mesh, uh, using a CO and also Gateway.

Uh, our gateway is glue, and we recently donate the glue open source gateway to, uh, CNCF as a cn, uh, as A-C-N-C-F Sandbox project called K Gateway. Um, so we have, uh, hundreds of customers running these, uh, projects and our enterprise offering, um, in, in their, uh, data center or public cloud. And what we find out is our customer facing engineers often, uh, when they working with customers, um, they sometimes couldn't, most of the time, they were able to solve, uh, the issues with the customer, whether it's configuration management or figure out how to configure policy across, uh, different cloud, uh, in service mesh, or whether it's troubleshooting, uh, pinpoint, uh, when there's multiple connections in the hub, which of the connections may be causing the problems.

Um, we find out sometimes we had to bring in, uh, the top expert at solos. Certain people like, uh, John Howard, uh, we have to bring them into help troubleshooting problems. So as solo company was scaling to a larger scale, we started thinking about how can we free up our top developers from jumping to customer cause troubleshooting with customers to let them focus on writing new features for, for open source or for our enterprise offerings so we can innovate faster.

So, uh, we started to develop, we leveraging Agent ai, we started to develop a couple of, uh, agents based on our domain knowledge, which is, is still, uh, observability 'cause we always need to figure out observability for Gateway and me, uh, which is Kubernete, uh, which is, well, our control plane and data plane mostly runs on, uh, helm. We use Helm a lot and our customer team. So we started to develop needs sample agents and, uh, use it internally to, uh, help our customer facing engineers when they gon or help our customers.

And when they, we started thinking about why not just open source, uh, the agents we develop, uh, 'cause not only we develop the agents, we also develop the framework, um, by leveraging the Microsoft Auto Gen, uh, agen AI framework. We bring in UI and CI I for Kubernete and have the framework more integrated nicely with Kubernetes. So we have the whole framework stack, uh, kind of developed alongside with the sample agents, along with, uh, a, a couple of dozens of tools where these agents consume.

So this is where K agent come from, right? Uh, we decided to having something internally useful for us and, uh, open source, the whole thing. And, uh, we want to be able to benefit the broader ecosystem.

Certainly we couldn't make the agent successful by all itself because we only sampled, um, seeded K agent with a couple of sample agents. We develop internally. What we are really hoping for is, uh, in the next, uh, few months, um, we can bring the vision of K Agent Live.

Uh, what we really wanted to have is having every single CNCF projects out there in the CNCF landscape. I'm sure you look at the landscape before, right? At 200, 300 Projects.

It's a picture. Yeah. It's quite a picture.

Yeah, it's Quite a picture and very, very hard to figure out how to navigate. And once you decided a few projects you want to use, it's also very hard to get started and troubleshooting when anything goes wrong. So what we had, uh, a vision is for K Agent is we are hoping it can serve as an inspiration for the CNCF community, um, that we provide the simple framework, the simple, simple agents and tools, and having the ecosystem, uh, help us to build the rest of the, uh, agents that we don't necessarily have the expertise.

So we're hoping to have Project Maintainers willing to join us on the journey of key agents. We're hoping to have, um, develop engineers, uh, platform engineers who have a lot of cloud native operation expertise. Uh, many of these, uh, cloud native projects join us and help us make key agents better, help us making key agents, uh, produce agents in the catalog with every single CNC of projects.

So people can navigate the landscape a lot easier by having agents sitting next to them when they explore any of the projects in the CNCF landscape. Got it. Lynn, we don't have a lot of time left, but for people who are listening and saying, wow, K Agent is something I'm really excited about, it's what we need.

Excuse me, in the cloud native community, what would you recommend for people who want to get involved in the K Agent project? Yeah, so we would definitely recommend the checkout K Agent Dev. So that site is already up live since yesterday.

Uh, we also have, uh, GitHub. Uh, so you can go to the GitHub icon on the website. It's K agent Dash, uh, dev slash k agent.

Uh, we would love to you to check out the project. They all get started guide on our website. So you can play on the agent, like what I've been doing for the past few weeks myself.

And, uh, you can interact with or sample agents, um, using natural language so you don't have to remember some of the commands or look up the project manuals. Uh, so we would love you, give us a star on the GitHub. Uh, 'cause once the project reach, uh, 500 stars, we are really serious taking it to the next level, which is, uh, donated to CNCF as another sandbox project.

That would be great. Lynn, congratulations on K and congratulations to all the folks at Solo. I know, you know, idiot and the rest of the team has worked so hard, uh, at Solo and it, and it shows.

Um, we will see you in CubeCon at London. Yeah, thank you so much, Alan. I really appreciate the chat.

We will have a big boost at, uh, London, uh, at CubeCon. io boost if you're interested in you to chat. Uh, more about K Agent.

Thank you so much. Thank you. Lynn Sun, director of Open Source solo io, as well as C-N-C-F-T-O-C member and Ambassador here on Tech Drunk tv.

We're gonna take a break. We'll be back. Remember, we will be live all week streaming from CubeCon London.

Should be a great time. We'll be back in a moment. This is Textron tv.

Hey, everyone. We're back here with our continuing coverage of S Secon 25 in, uh, sunny Orlando, Florida. We've had some great weather this week.

Um, our next guest is, uh, Brett Schroeder. Yep. Brett is chief of the office of CTO.

I head the office of CTO, head, head, the office of CTO at SUSE Worldwide. And, uh, joins us here today after, I guess you've had a busy three days of speaking to customers. It's been very busy, which, which is exciting.

It's, I think this is the most exciting, uh, scon that really we've had since I've joined seven years ago. So, yeah. Good for You.

Ah, you know, I'm trying to think. I've been to a previous Scon over a Europe, was it, I don't know if it was Berlin. Berlin might have been Berlin.

Yeah. Um, you know what, what I loved about this event this year was, look, it wasn't one of these mega events with thousands of people where you feel like you're just, you know, on the subway or something. Um, it was a place where you really had a lot a chance to really have great discussions like that hallway session.

Yeah. You know, the water cooler sessions were really val for me anyway, I had a chance to meet and talk to a lot of people. Brett, a big part of your job is meeting and talking to people.

Yep. Right? Yep.

Why don't, well, I don't want to describe your job. Okay. Why don't you describe your job?

Uh, Yeah. So as office, as head of the office as CTO, probably 75% of my time is spent talking to customers in, in one manner or another. Um, so that's why I'm on the road.

I pick up mail in Austin and, and, uh, the rest of the time is on American Airlines. Yeah. But, um, so it is, is about that, right?

And, and, and how I start off almost every conversation is tell me about you. Mm-hmm. Right?

What are you experiencing? What are you trying to do? What's holding you back?

Um, because I need to learn, right? Um, what are their problems so that then we can apply technology and, and, you know, hopefully bring them the biggest value, uh, the customers, the biggest value from our portfolio that we can possibly deliver. So that's my role is, is really gonna, I love It.

Um, you know, one of the things that I've been, I, I actually wrote an article on Cloud Native now about it, and it, I've been talking to the people. I was very impressed with this DevX design Yeah. That they, they showed us over in the solution showcase the other evening.

I was, I got a hands on tour with it. Um, it's very exciting because I think as, as we were talking kind of off camera, I think one of the issues around cloud native adoption, especially it scale. Yeah.

Right? It's that could do science experiments all you want, but at scale is it, it it's almost like drowning in a sea of opportunities. Mm-hmm.

There's so many different solutions for every single facet of a cloud native deployment. Yes. That I think people are almost, you know, paralysis by analysis that Yeah.

No one wants to make the wrong choice. Everyone wants to pick what they perceive as What's their tool set of, right. Favorite tool set, tool set of choice, and why it's better than the next one.

Yeah. Yeah. But you know, this, this Dev X, uh, a framework to me was so comprehensive uhhuh, and, you know, and it really showcased all of the different pieces that Zus has assembled here.

Yeah. And to pull it all together into a platform. Yeah.

Truly a platform like that. I can't wait to, you know, I kinda imagine the market's gonna just love it. Yeah.

I'm wondering what you are hearing, see. Yeah. The, um, you know, this really comes back from our to, to our discussions with customers, right?

Mm-hmm. As I go out and talk to customers, there is no one model. There's no one IDE, there's no one language.

Uh, and so as we sit back and think about that, it's, you know, us coming out with another, you know, hard opinionated, this is the way you must do things, would not resonate with the vast majority of of customers. And so, and, and going back to your point on scale, you know, I think many customers are now wanting to pass that point of the science experiment, the departmental, um, you know, initial trial and scale. And so customers are in running into not technical issues so much, but organizational issues and productivity issues in scaling.

Mm-hmm. Uh, you know, how do they grow from 100 developers to 2000 developers? And if you ask every developer, you know, Hey, do you want to go program some, uh, some infrastructure?

It's not too many of 'em that are infrastructure's. Well, because they're, they're not busy enough. Yeah.

They, yeah. They're, you know, waiting for somebody to send 'em some more requirements, right? Yeah.

Yeah. They wanna focus on the business. Absolutely.

And they wanna focus on code. You know, one of the things I, I remember a couple of conferences last year, the average developer spends about 25%, 27% of their time actually coded. Exactly.

Yeah. So it's telling them they've gotta be the security person, they've gotta be the platform person, the ops guy, the tester. Yeah.

That's not what they wanted. No, it's not what they're paid to do either. Right.

A lot of them, that's all fine and dandy, but their manager says, how many lines of code have you Yeah, Exactly. Yeah, yeah, yeah. I see a very stark, uh, contrast between companies that have adopted some form of platform engineering Yes.

Versus those that there's an operations team, but the, the infrastructure's code falls on the developer. Yeah. Um, they run into the challenges of how do I educate them?

I get inconsistent implementations. Yep. Which lead to inconsistent security, uh, practices among the developers.

And so the platform engineering really helps, uh, unify the approach as it transitions from what the developer needs to do and is trying to do from a business standpoint. And how do you put that into operations, uh, and therefore helps scalability from the organizational standpoint. I get it.

You know, so just a quick plug, we Yeah. com. It's our newest site.

It's been up there now for about four or five months. org community, and Luca and Ente and those folks. We, we were, we are a media sponsor.

We'll be a platform con, but that you, you hit the nail on the head there. Right? com too.

So we're obviously we're bullish DevOps, but we saw the same things happening in DevOps. I used to call it the bubbles of DevOps. Uhhuh.

You would have a little team here, a little team there, like bubbles. Yeah. Within a bigger organization.

And this one was on Ansible. That one used chef, this one used Puppet, this one used Jenkins. That one used harness, that one used Git or GitLab or what have you.

And then someone at the enterprise level would say, Hey, we gotta consolidate. Yeah. See the mess.

Right. And it was kinda like, you know, when your kids play with bubbles, when they're little and you put two bubbles together, you got a bigger bubble. And until eventually the bubble bursts, but DevOps had a problem putting all those bubbles together.

Yeah. Because They don't fit. Right.

Well, just for what you said, everyone wants to use their favorite tool. Everyone has, you know, their way of doing it can't just keep shifting left and throwing it on the developer. Right.

I think platform engineering is a great Yeah. Answer to that. Exactly.

It's not that it replaces DevOps, you still have the whole DevOps thing. Still do the, the, but you need a platform that's gonna bring together the developer, the tester, the DevOps guy, the SRE mm-hmm. All of these people that work in this, you know, software factory mm-hmm.

That we enterprises run to. Right. Um, so I, I, I agree with you a hundred percent.

What's the feedback then? Um, I think it's going to, it's, you know, we're just releasing DevX now, right? Yep.

I think it's gonna be fantastic for the customers that I've talked to, and particularly the ones, uh, the ones that are like a couple years down the road on platform engineering. Yes. They're gonna love it because it's gonna give them, you know, the prescriptive, how do I just do the next thing faster?

Um, how do I get more consistency between, um, you know, differentiated teams, uh, et cetera. Those that haven't, it's now gonna give them part of the recipe for how to get started on platform engineering. And that's really, you know, what we're doing with DevX benefits both communities, the platform engineering teams and the development teams.

I agree. Uh, and platform engineering then can say, okay, here's some best practices that I want you to follow. Here's the tool sets that are pre-integrated and, and, and blueprinted on, on how to follow them and how to use them.

So it it, you know, trying to kinda bridge that gap of I need my tool set that fits the problems I'm trying to solve. You know, I might wanna use a different language if I'm doing video, um, applications and gaming Yes. Versus if I'm doing ERP programming.

Right. It's, those are different tool sets. Sure.

And so how do we give them the choice to do that? Um, you know, by giving them best practices and pre integrations with some of those tool sets, but not dictating which one they use. Choice happens.

Yeah. Choice Happens, right. And that, and I think that is the key.

Yes. There are a lot of choices and no, we're not here to dictate mm-hmm. This is a complete set.

I think one of the nice things I like about the whole DevX thing is here's the complete A to Z, you wanna substitute a different lettuce seed mm-hmm. And, you know, substitute at wh you want to use that over there? Go ahead.

Yeah. You do have choice. You're not locked in.

Because that's another thing we hear Yeah. From enterprises a lot, is they wanna stay away from lock in Yeah. As best they can.

Yeah. Right? Because things are changing and happening so fast.

Yeah. It helps you evolve faster, right. Is is if something new comes along, Gotta have your Options that has a productivity boost, you wanna be able to take advantage of that and not be in a five year transition.

Exactly. Plan Or, you know, like what we see going on in the, uh, in the hypervisor VMware world now where we're at sort of a generational juncture where people are actually saying, Hey, maybe this is a good time to modernize. Maybe it is a good time to go to, uh, not multi-feed microservice architecture.

You know, I'm, I'm looking at maybe going from on-prem to cloud, private, public, whatever. I'm changing hypervisors. It's a, it's, no one wants to be locked in at that moment in time.

Right. You gotta have our options. Yeah.

Speaking of innovation though, and changes ai Yeah. Whether we're talking generative ai, agentic ai, I'm sure you, your, your customers that you're speaking to are grappling with, is it real? How much is it real?

When is it gonna be real? How should I make it real? Yes.

What are you hearing? Yes. Um, I'm hearing that, and I'm gonna break it down into two, two aspects because it, gen AI and agentic ai, I think are in this next wave that's gonna open it up to so many more people.

Uh, the interesting thing that people have forgot about is that, you know, machine learning has been around for a while. Yeah. And we already have, um, hundreds of customers that have employed, um, AI in, in just astounding ways in medical, in, in retail and manufacturing, et cetera.

Well, I think this now opens up is probably the, um, a new wave of how to apply it. Um, but I think, and, and everybody's looking for it, right? And, and the the headlines you hear every day are, where's the ROI?

Right. And I think the key thing to remember in, in the gen AI space is it solves a specific set of problems. Just like the last AI or the still there, ml ml, um, solves a specific set of problems.

Don't try to apply it to every problem that your business has. So my guidance is, you know, really study the business processes, um, the workflows that you have, um, and does it fit and optimize it? Right?

I use Gen AI every day. Mm-hmm. Um, and it is absolutely a productivity boost to my day.

Uh, and I love using it, but there's other tasks that it may not benefit. Right. So, you know, knowing where to apply it is key.

And then as we move to Gen AI or ag AI Gen Now, I think that opens up another whole can Worms opportunity. Opportunity, but it can worms too, And Yeah. Issues that you need to grapple with from a governance and, and yeah.

There, and this is one of the things that, that, um, becomes so important in ag agentic ai, uh, your gray areas of how the quality of your data, um, is no longer an option. If you're doing age agentic ai, your data must be clean. Uh, hallucinations are not a good idea in an age agent AI workflow, did you That?

Right. Probably not safe to say. Safe To say, yeah.

Should we launch this direction or that direction? Right. You think To know, huh.

Uh, so I think that's the exciting part of Ag Agent AI is, is what it opens up. But again, okay. Do I have the problem understood and do I have good clean data to, I think that's gonna be, that, that is a key piece of it.

But I, I think the other thing, you know, we've discussed this on text on gang in a lot of our videos and interviews, is we, we can't go hog wild and have a hundred agents running, you know, doing, you know, how many agents are enough agents? Do we need an agent orchestrator at some point? Yeah.

Do you have a master agent? Do you, you know, what's the right mix? Yeah.

Because everybody's rushing out. I mean, SAP's coming out with a lot of AI agents, sports, obviously. Yeah.

Everyone is. Yep. And so, And kill mes coordinate with each other.

And how do you get, they, They're gonna have to, otherwise they're gonna start colliding, like, you know, bits on the internet. Right. Um, there's going to, you know, just the way you have this Dev x uh, uh, platform or framework, we're going to need sort of a framework to deploying and managing agents Yeah.

At scale cloud native infrastructure or whatever your infrastructure is. Yeah. You know, that because these agents are gonna be constantly, I think fine tuning, Fine tuning and tweaking.

And, and, you know, you bring up a good point, and I, and I think this is where agents have an opportunity to be disruptive. 'cause we've in it, you know, if we apply automation to it, right? Yep.

It's been the holy grail forever. Right. Automation is always a good thing.

You never hear them say, oh, no, automation's not good. Uh, And the challenge with automation is, uh, you know, what's the quality of your information? And I given an example, um, you know, and not picking on it, but just an example, like, uh, VMware, DRS Right.

Automatic, uh, load balancing and re uh, positioning workloads, et cetera. Yeah. And it operated on an incomplete information, uh, information set.

Yeah. And so in the early days, it was as dangerous as it was value at your book. Right?

Yeah. Uh, I remember those days. And that's the thing that we're gonna have to watch as we progress for agent, because Rolly as good as your information.

Right. So it's very easy. Like, you know, you can think you're optimizing something and yet incomplete information.

Um, and it was the wrong way to drive the workflow. Uh, yeah. So that's, we're gonna need some guardrails around look At the world through a, you know, a door hole, a pinhole.

Yeah. And you don't realize what else is out there, you wouldn't know. Right.

Exactly. Excellent. So, well, Brett, thank you for stopping by.

Absolutely. Talking with us today. Yes.

Continue success with, we're gonna watch all this. We're Excited. It's the most exciting time.

That's why I said it is, it's the best sushan I bet to, because the, the bringing the portfolio together in a way that we've never done before. Absolutely. And, you know, that are on the horizon.

Or, you Know, as, as a media press person, I've, I've seen the acquisitions. I mean, I was good friends with Chang from Oh yeah. From Rancher.

From Rancher. Mm-hmm. I, uh, Andreas, that's another good friend of mine.

I knew the new Vector people pretty well too. And you know, they're assembling a nice, stable, I don't know how this all fits together, but now you see how it all fits Together. It's coming together.

So. Excellent, man. Excellent.

Appreciate it. Appreciate it. Yes.

Brett Schroeder, head of the office of CTO at SUSE here at SUSE Con. We've got more suse uh, coverage coming up. Stay tuned.

Hello and welcome to the latest edition of the Techstrong AI video series. I'm your host, Mike Fazar. Today we're with Baik Hojat, who's CTO for AI at Cognizant.

And we're talking about this whole shift to Agentic AI and how we got here. 'cause it started all the way back with things like Siri, and it's a continuing journey. Baik, welcome to the show.

Thank you. Thank you for having me Put some perspective around this. I think everybody kinda understands Siri or whatever, uh, the folks in Google and Android provide, I think it's Bixby, but these things were the precursors to AI agents that we see today.

And it seems like there's a straight line here, but I don't think everybody appreciates how exactly these things are all connected. Yeah, well, uh, AI agents have been around, actually even before Siri. Um, uh, they are conceptually the same thing.

When you ask Siri to call your wife and it actually dials a number and gets the call done, that's an agent working on your behalf that understands natural language. Um, the difference today is that we actually have these Gen AI models, uh, to help with the understanding of the natural language and to help with the reasoning of the agents. So they're much more powerful than what we used to have in the past.

But even before that, you know, AI is, is really, really hard. So having a single AI system that does everything and is generally intelligent, has always been very difficult. So in the late eighties and in the nineties, people started, uh, thinking, okay, what if we simplify the environment within which the AI is operating?

And let's call that an agent. And back then we did have a pretty simple environment. It was the web, it was much simpler than it is today.

Uh, just some texts and hyper texts and, and links. Um, and so that's kind of where it all started. Uh, but you know, the, the aspect of, uh, agents that's really in interesting to me, which also started in the nineties, was multi-agency.

So you have one agent, and it might be collaborating with another agent or communicating with another agent to get something done for you As we go forward. As I look at it right now anyway, it seems like there's gonna be, I don't know, hundreds, thousands of these agents. How will we kind of connect them all together to kind of drive something and will the agents know of each other?

Not to mention who, not only am I, but who am I working with, or who's part of my extended family? Exactly. That is, um, a very important question.

And I think it's something that, in my opinion too, is inevitable, uh, with people, marketing agents right now for various different tasks. Um, you would want these agents to know of each other and actually collaborate and talk to each other. Uh, and so that we do need, uh, some way to make these agents interoperable.

Uh, we do need to make sure that, uh, when they're aligned, we're, we have less of a problem when they're not aligned with one another. How do you deal with that? How do they negotiate, uh, you know, to get something done for you?

These are all problems we will be running into the future, it running into in the future. And, uh, I, I think we are already seeing that. Uh, so companies have been starting off by creating these knowledge extraction chatbots, uh, using gen ai.

And, uh, they've created them, you know, large companies like ours have been creating them for various different use cases. And very naturally, uh, it just doesn't make sense for you to talk to one agent and the agent saying, well, I can't really help you here, and you gotta go talk to this other agent. And then for you to actually repeat yourself to the other agent that's responsible for it, because you started off talking to the HR agent.

Um, and so that interconnectivity, that interoperability is really important. And many companies are actually bringing in agents from third parties. You know, we have agent force, we have, um, uh, you know, SAP has its own agent.

You know, the various different companies are coming up with their own agents. There's agent space by, uh, by Google that, um, in fact has adapters into many different backends. And, uh, so yeah, I think the, the future, the way we see it is this, um, uh, coming together of agents representing various different functions in an enterprise.

Uh, you could think of it initially as really looking very similar to the microservices that we've created and even the organizational structure of, of a business. Um, and you should be able to, uh, get stuff done, uh, as long as you have authorization for a task, uh, across multiple agents. And in fact, have agents talk to each other and work out collaboratively, um, and consolidate their responses.

So you're only dealing with one, uh, interface, but in the background, you have a team of agents working on your, on your behalf. Um, I think we need to make that this can't be created in a centralized manner. So we have to come up with a way to actually nurture this organic, uh, emergence of these multi-agent systems.

So, for example, I want to see business units be able to create their own agent sub networks and have a process for, you know, sandboxing them, validating them, and then being able to plug them in into a larger organizational network. And by virtue of doing that, expanding the domain of discourse, uh, and and capabilities for, for that particular organization, Will these agents negotiate with each other? And, and how might that be accomplished?

'cause sometimes I wonder if I have an agent that is optimized to go buy something at the lowest cost, and you have an agent that's gonna have something that is optimized to sell something at the highest margin, won't they kind of just meet in the internet somewhere and beat each other up to a standstill and then call us for help? Yeah. In fact, that is something, uh, I I think that will happen in the future.

It's not the case right now. So we're really building from the ground up, and we're only at the stage where the assumption that the agents are all working for the same organization, uh, is, is, is probably gonna work for us for a while now, but we will very quickly get to that world, Mike, that you're, uh, you're describing where, for example, I have agents that on my behalf might want to broker some, uh, uh, you know, uh, service from a third party. And that third party, um, has created an agent, uh, to receive orders, for example.

Um, and, uh, and, uh, you know, there might be a negotiation going on. In fact, um, we did a research, um, uh, with Oxford economics just recently that showed that while consumers like you and I, um, are not comfortable with having AI agents actually, you know, do the transaction itself, we are comfortable with them giving and do the, doing the research and giving us the options. And so that inspired me to create an agent network that helped a consumer like myself make decisions.

And it was a number of different agents that came together to help me with various different decisions from, you know, what hobby to choose, to financial decisions, to, you know, buying stuff. And then I actually had a few agent networks that represented different, uh, third party, uh, B2C kind of businesses, uh, for example, for, um, uh, you know, hotels and, and accommodation and so forth. And I had more than one.

So I actually had a lot of fun, uh, having the agent that is responsible for, uh, you know, uh, coming up with my vacation, uh, agenda, negotiate and talk, and, and I would tell it like, you know, yeah, I want a vacation, uh, and I have a budget of whatever X dollars and see it go back and forth, uh, with these third party agents and in fact do a negotiation. And as part of their prompt was, don't trust the other side, the other stride is not fully aligned with you. So it would actually get some results and go to the other hotel provider, for example, or accom accommodation provider and say, Hey, I have a better deal than you, and can you beat this?

And, um, it was amazing just to read the transcript of how these agents were kind of trying to, uh, uh, you know, meet their own KPI, uh, while trying to, you know, close the deal on something. And ultimately the, the agent representing me came back with some a list of options like, here are the options that you have with these different providers. So the final decision is up to me, uh, the user, but a lot of that negotiation, the headache of trying to, uh, check and find these things out, uh, took place, um, without me involved, uh, it takes a while.

These, these systems might, uh, run for a while. One of the things that might be an issue, again, this is a future state we're talking about, is that these, uh, large language models are fine tuned to be very kind, uh, you know, very positive, very, uh, ethical, moral, uh, systems. So when you actually follow the dialogue between two agents, they tend to agree with each other very, very quickly, much quicker than you would like actually in these types of situations.

So that might call for a different kind of fine tuning when it comes to non-aligned agents talking to each other, for example. So there's, there's a whole world of research that has to go into, um, uh, kind of, uh, uh, coming up with that kind of world, uh, that, that kind of setup. Um, I must say that, um, again, currently the, the, the overarching assumption for everyone is that we're building agents or multi-agent systems that are all aligned and in the service of either our company or our consumer.

So that's an easier problem than, you know, we have a bunch of agents that might be talking and negotiating with some other agents that are probably not aligned with us. I've been trying to figure this out and, and I imagine, you know, the answer and maybe it's not, uh, obvious to everybody, or maybe the techie folks understand it, but so Siri more or less ran on my phone, tablet, whatever, is there enough horsepower to run these AI inference engines out at the edge because we're trying to create an interactive experience. So the round trip to the cloud, the latency might be too long.

So yeah, how much of the AI runs locally and how much of the AI runs somewhere in the network and how much of it runs in the cloud? Well, uh, let me correct you, uh, on, on the premise here. The initial Siri was a hosted system.

In fact, it was one of the first, uh, when, when Siri got acquired by Apple, they actually built the data center for Apple. Apple didn't have a data center before that. I mean, uh, so, so that was actually hosted, but for the processing capacity back then that was required, um, uh, not anymore for that, uh, type of, uh, Siri, um, system.

So you're very right that, that, uh, kind of, uh, processing didn't require what we require today, like our most powerful large language models have to be hosted. They actually run in very large data centers and take a lot of processing capacity. Today, we cannot even, uh, start to imagine what it would look like to run a GPT-4 oh on your phone.

That just doesn't, it, it won't work. However, having said this, you could today think of systems that are running in a hybrid mode, where some, um, you, you even see that actually today in Apple Intelligence. Uh, when it came out, I was thinking, okay, they have the right idea here because, um, much of Apple intelligence is actually running on your phone, and that is for data security purposes and so forth.

It's actually really, really good. Um, but it's, it's not that powerful, like what it does, what Apple Intelligence does on your phone. It's a small, uh, large language model.

So it's not that powerful and there's not a lot of functionality. You can, you can run just on your phone alone, uh, for agents that can understand natural language, do reasoning, and, um, be kind of a higher order type of agent. You will still today need to, uh, run them on the cloud and data centers.

But you could imagine a hybrid model where some agents are hosted and some agents that are much more specialized and therefore don't need a large, that large, uh, uh, a large language model to be running, uh, locally. And what that does for you is it, it, it does, uh, save money, uh, um, um, uh, because it kind of, depending on the use case and depending on the agent, you're using a different, um, model that, that might not have the same, um, processing capacity requirement. It also gives you some data security aspects for those particular, uh, parts of your multi-agent system where it's closer to the data.

Just imagine if you have an agent sitting in the cloud that generically knows what you're talking about, and then defers it to the agent that's sitting on your phone that is actually responsible for the data on your phone. That way your data isn't really moving off of your phone. Uh, and that functionality, um, is, is resolved through that, um, interaction between the agents without the cloud agent even getting that data.

So, um, that we can do, even today, the general trajectory of the technology today is, uh, these large language models are getting smaller, uh, at the same time, more powerful. Um, deep seek an obvious, uh, example of that where a much smaller, large language model could do things at the scale, uh, that wasn't possible in the past. You can run a 14 billion parameter, um, deep seq model on your, um, M three laptop and, and, and it will work.

And it's at, you know, it's, it's on par with a GPT-4 oh mini, for example. So it's actually pretty powerful, and it, in my mind, for many age agentic use cases, it pa it passes the bar. Um, and so, you know, we're, we're still in the early days, but I think in general, we will move to a point where these, um, uh, running more and more of these agents, uh, locally is gonna be viable.

The other thing people seem to be struggling a little bit with is, is an agent, should we just treat them like digital labor or are they essentially a new type of employee, or is it just software that we're using and we just need to invoke it through an API? But we don't need to think about it any differently than we do any other application. There is a distinction in that the moment we talk about an agent, we are assuming some level of autonomy, because if there were no autonomy needed, then, you know, it doesn't need to be an agent.

It's just pure software. You just write, write some code and some rules, and you have it do whatever, um, it needs to do. But the reason why you're using an agent beyond the fact that it understands natural language, is to defer to it, to make a decision as to what, uh, which one of its tools it needs to use and in what order, and synchronously or asynchronously, and perhaps in some cases, just go off and use its tools and review and go back and, you know, so to maybe make multiple calls and then come back to you.

So I don't know if we can treat them exactly like software for, for starters, we have to accept a world in which systems do exhibit some level of autonomy. So we have to design for that and make sure it's responsible, uh, in its operations. The second is we need to get used to a world in which things are not deterministic.

Uh, you know, the same inquiry is not gonna get you the exact same response every single time. Um, and it takes some getting used to. Uh, but, uh, yeah, I, I, I don't know if I answered the question, but generally I'm just, just kind of highlighting the distinctions here.

As you look forward and now that you're working over at Cognizant, you're touching more customers, um, at least among the early adopters, what do you see them doing right, that you kinda wish other people would kind of cribble a little bit? Yes. Um, I think, uh, uh, those who do recognize the fact that, you know, gentrification, AI enablement is not a one-stop shop.

You're not looking at a single be all end all model that will do everything for you. I think that that is the right kind of thinking, uh, those who are actually making interoperability a requirement for the agents that they, um, utilize, uh, I, I think are taking the right steps. And also recognizing the fact that this identification is an incremental process.

It's not a lift and shift. You don't have to go off and, uh, you know, say, okay, I'm not even gonna embark on this 'cause my data shop isn't an order, or, oh, it's a huge undertaking, like identifying my entire, um, business is gonna take forever or culturally, I'm not ready for that. Actually.

I think because of the nature, the modular nature of multi-agent system, you can start small and grow. And as long as you set the framework in a manner that allows for that kind of incremental, uh, adoption, um, you're in a good place. So being an early adopter, uh, in this case doesn't mean being completely disruptive to your, to your business.

It's, it's actually a smoother, um, a less painful process than, for example, I don't know, back when we were migrating to the cloud, uh, for instance. And, um, so those of our clients that recognize this, those early adopters that are doing that, I think, I think those, uh, that, uh, I'm just highlighting what, what, um, I think keeps them ahead of everybody else. And I've been surprised that, uh, some of our clients who are from domains that are traditionally quite conservative, um, are recognizing that and are actually taking, taking steps there.

So it's unlike what we've seen in the past where, you know, a conservative bank or an insurance company that would say, yeah, we'll wait until that, that this new technology is, has been out there and the risks have been, um, uh, mitigated. Um, no, many of them have embarked because they recognize the incrementality and the, the importance of, um, endorsing and managing this in a safe, uh, manner versus just letting it happen organically because it's happening organically and you just don't want that. It just, uh, it's not the responsible way to go.

We haven't talked about security, and we are struggling with just securing the humans who are a part of our environment. And if we have all these agents and they're essentially entities or endpoints, much like people, how will we secure thousands and thousands of agents that the bad guys are gonna go try to steal the credentials and manipulate? Yeah, that's a, that's a really important question.

I think, um, uh, I think it's important for us to, uh, recognize that if an agent is hosted by a commercial entity and it's a complete black box, especially if it's hosted by maybe a third party country, um, you know, that, that, that there's a trust element there that has to be, um, you know, taken into consideration. Um, I always say if, if, if the functionality, um, that you're, um, so delegating to this agent is sensitive or it's dealing with sensitive data, I think it makes sense for you to, um, host it, uh, and run it internally and secure it. Um, but there are ways, there are mitigations, um, uh, around authentication authorization.

Uh, an agent by definition is not just a la large language model, it's a large language model plus code. And the code is actually superseding the large language model. The code is what is making the calls.

The large language model only takes input and, and, and, uh, output, uh, produces output. It's the code outside of that, which is, uh, a deterministic human design code that decides what to do, like, which tool to call what API to call. So if you want to secure your agent, that's where you have to be writing your code.

And, um, the other thing is this acknowledgement that the agent is going to have some level of autonomy means that we have to always think very explicitly about what is the line that we draw. We're like, okay, up until this point, with this sort of level of certainty, with this kind of functionality, we allow the agent the autonomy, uh, because it gives, makes everything more efficient and productive and everything. Um, but here's the line below which I'm gonna take over.

I'm gonna write the rules, I'm gonna make sure there's a deterministic methodology for what happens. And we always talk about a fallback, like if all hell breaks loose, I want to be able to, you know, disconnect all LLMs in my enterprise and fall back into a rule-based model or a human-driven model. So having that in mind, I think is, is very important, especially with critical processes.

Um, yeah, I, I think, uh, you're, you're touching on a very, very important point here, Brian. Folks, you heard in here, as you listen to this conversation, it becomes pretty apparent that despite what AI agents may automate, the missing ingredient is still gonna be human intelligence. Hey, Baik, thanks for being on the show.

Thank you very much, Mike. ai video series. You can watch this episode and others on our website.

We invite you to check them all out and until land we'll see you next time. Hey everyone, it's Alan Shimel, and this is another episode of Shimmy Says, you know, I'm really excited to do, shimmy says this week, because we actually have a story that's not necessarily AI related. AI takes up so much of our Headspace these days, whether it's generative ai, agentic ai, or what have you.

But today I want to talk about just good old fashioned, hard earned green cash, like in $32 billion worth of cash. You know, the big story this week was that Google coughed up 32 billion. That's with a b billion dollars to buy the Israeli, uh, security startup, the Wiz.

Now, couple of things, if you're not in the security space, you may not know The Wiz, the Wiz, uh, originally founded, I believe in 2020, so just five years old, grew really quickly. You know, they came out during COVID, which they'll even admit, probably helped them to get some traction early on. And they got to a hundred million dollars in annual reoccurring revenue really quickly.

I think they're up close to six or 700 million in reoccurring rev annual reoccurring revenue right now. Um, what do they do in security? Well, they've made a few acquisitions, which has expanded their portfolio, but basically their cloud security, cloud security, uh, CAP, cloud Native Security, uh, they do do some SOM software, bill of materials, supply chain kind of stuff in the DevSecOps space a little bit via a, an acquisition they made.

Um, but it, it's more generalist cloud security. But they did a really good job. I think also what they did really well was they, they really made inroads working with the public cloud providers, all three of the major ones here in the west, uh, AWS Google and Microsoft Azure, their AWS marketplace product is probably one of the biggest drivers of revenue for them.

So, you know, a real poster child for that kind of success now, and that very success with the cloud providers is sort of what helped with, uh, making them as attractive to Google. Uh, and, and make no mistake, this is Google Cloud is, you know, as much as Google, uh, they wanted that strong cloud security product in their, in their portfolio. Now, were they better off buying it for $32 billion or just partnering?

Well, that's a question one might ask, but clearly they wanted it. For those who may not have been following this story, Google offered them $23 billion, oh, maybe six or eight months ago. And there were rumors that that deal was getting done, and then the Wiz turned it down, they walked away from the altar, they walked away from $23 billion only to come back here at 32 billion just six or eight months later.

Why did they take 32 now and they didn't take 23 before? It's a good question. Well, first of all, you don't have to be a mathematician and know that it's an extra $9 billion and, you know, a billion here, a billionaire, before you know it, you're talking about real money.

So $9 billion is maybe reason enough. But on top of that, I think the world was different six or eight months ago, I think the stock market was up, interest rates were coming down, inflation's coming down the market for IPOs look like it might pop. And I think what we've had over the last, you know, month or two months, certainly here in the us there's been a lot of uncertainty and businesses do not like uncertainty.

So with this uncertainty, the market has reacted. We're seeing inflation in up, we're seeing unemployment, interest rate pressures, all of the above. And so that money started looking better and better.

Also, from what I've read, Google has been pretty much in constant communication. The corp dev team has been in constant communication with the folks at the Wiz talking, continuing the dialogue, not giving up on this deal, and they sweetened it to 32 billion. And, and that, I guess, you know, they say every man has its price.

So does every company, I mentioned early on the Wizards and Israeli based startup, it's actually three co-founders, and this isn't their first startup. They sold a, a security, I think, cloud security startup to Microsoft prior to starting the Wiz, maybe in 2017 or 2018 for about $320 million. So they've made great liquid liquidity events in the past.

Of course, this one pales in comparison to Comp Compare. And speaking of comparison, $32 billion based on their present run rate and revenue is about 45 times revenue. 45 times revenues a lot.

That's a huge, huge multiple. To give you a little context, last year, or maybe it was the year before Cisco bought Splunk, and Splunk was a great company, public company. Cisco bought Splunk for I think $27 billion, and that represented about seven, seven and a half times revenue or value.

So you could, I mean, the difference between seven and seven and a half times to 42 times revenue, that's, it's not even in the same universe. And, you know, people thought Splunk wasn't bought cheap, so certainly the Wiz wasn't bought cheap. Now, I mentioned before Google bought 'em to be in cloud security.

Did Google buy them to, to deprive their biggest competitors, AWS and Microsoft Azure of using the Wiz? Or do they expect AWS and Microsoft to continue using the Wiz and contribute to Google's bottom line? I, I don't, I'm not quite sure what the answer there is.

You know, as a security partner, Wiz had NDA and access to roadmap and feature sets with, with AWS and Microsoft, and I'm not sure those companies are gonna be comfortable with knowing that Google is their parent company going forward. It's gonna be interesting to see if Google and the Wiz is able to still maintain their relationships with AWS and the Azure folks, uh, Azure folks at Microsoft, or do AWS and Microsoft sort of shun them, push 'em away and, and start looking at other, other products. You know, if, if that happens and the Wiz loses a lot of their revenue base based upon that, is that still, you know, how's that look for Google at $32 billion out the door?

I think that's gonna be the biggest question we need to watch going forward. Do do the other cloud providers still have whiz as sort of a favorite partner, if you will? Another thing to think about is, hey, Google had $32 billion laying around to just spend on this, and they've got a lot more, you know, all of the tech hyperscalers, all the giant tech giants are sitting on literally barrels full of cash and they're just waiting for the right things to buy.

Whether it's an AI related thing, maybe it'll be Quantum, or in this case, security. Um, but that's an awful lot of money to have laying around $32 billion. Who else does this affect?

I mentioned the cloud providers, but we also have companies like Palo Alto. Look, Palo Alto is probably the W's biggest competitor, and this could go one of two ways for them, right? Does the Wiz with Google behind them kind of really dominate Palo Alto because they have deeper pockets and broader distribution, or do does AWS and Microsoft is yours?

Say, Hey, maybe we should shift to Palo Alto more. Maybe there's a tremendous opportunity for Palo Alto to pick up business from companies who don't want to deal with a Google owned wiz. Another interesting thing that I think we'll have to see how that plays out.

I should mention that though, this is an all cash deal. It is not consummated yet, right? It'll have to be approved.

I imagine the EU maybe even more than the US will have some, uh, antitrust, uh, review process in place. Interestingly, if for some reason this deal doesn't happen because of regulatory or another reason, there is a 3 billion, that's 3 billion with a BA $3 billion, uh, breakup fee involved in the deal. So if this deal doesn't happen and Wiz doesn't, you know, join Google, they still wind up with $3 billion of Google's money.

Um, as someone who's been in the security industry for going on 30 years. Now, I gotta tell you, at, at some level, I am thrilled to see that security is valued this much, that someone would pay 45 times revenue, $32 billion in cash for a security company. That's a long way, long, long way away.

I remember the first big security, uh, m and a deal I saw was ISS being bought by IBM, and I wanna say that was for a couple of hundred million dollars. And everyone thought, I think ISS had 60 or $70 million in reoccurring revenue. And, you know, it was a little under 10 times revenue.

I think they paid for it, and we thought that was just crazy. And who would pay that much for a security company? Congratulations to the Wiz and their founders and their, all their employees there.

This is really a, a high watermark, I think, to this point for security companies, and it bodes well for the rest of the security companies out there. You know, we're coming in RSA season, we'll be seeing more and more security. Uh, we'll see if this sets off a whole frenzy of m and a and security and tech in general.

But until next time though, hey, man, $32 billion in, in cash. That's a big, that's a big number. Congratulations.

This is Shimmy. We'll see you next week on Shimmy Says, Shimmy says, Hey everyone, I'm Alan Shiel, and this is Jonathan Singer, and you are watching The DevSecOps Show Cracking the Code. You've never heard of that show.

Well, for good reason, this is the very first episode of it. We're just starting it. And thanks for joining in.

Um, we're going to take today's show to just kinda give you a what to expect and what's coming here and introduce the whole concept to you. Uh, DevSecOps show Cracking the code is a joint production between us here at Techron Group, techron tv, as well as check marks, our partners check marks. We partnered with check marks for many, many years.

They've been a leader in the AppSec space. DevSecOps coming now into platform engineering as well. So I'm thrilled to have check marks co-producing this with us.

And my co-host I mentioned, his name is Jonathan c Jonathan's with check marks. Hey, Jonathan, nice to have you co-hosting with us. Welcome.

Um, thank you. You know, you are the new guy on the block. Tell people a little bit about you.

Sure. So, uh, it's nice to virtually get my face out in front of everyone, and thanks again for the warm welcome. I am very much looking forward to doing this series with you.

Uh, my background, I've been with check marks for a couple years now, and, uh, I've spent a lot of the last 20 plus years, sadly. But yeah, it's been, it's been a long time. You look, uh, well, uh, you know, I'll, I'll take it, I'll take it, but yeah, Good living.

Yeah. Where can I say good skincare? It's, it's great.

Mm-hmm. Uh, but I've been in cybersecurity and, and some adjacent work in telecom for the last 20 plus years. Uh, and I, uh, I'm current in my current role at Check marks.

I'm doing a lot to help the organization shift our focus into the realm of developers. And we've done a lot of work, uh, as a company over the last four years, like really making our platform developer friendly, good for developer teams, good for huge like development organizations. And so we wanna take an opportunity to sort of get the word out, uh, as a company.

Um, and I am, I'm sort of leading that effort, so that's why I'm here. We've got a lot of fun topics to talk about. I've been talking a lot recently about DevSecOps maturity and, uh, about what that really looks like and, and how you advance as an organization.

So lots, lots to dig into. Absolutely. I want to dig into some of those topics, kind of pre-announce them here today.

I'd like to go into a little bit more about check marks in their history, though. You know, like you, I've been in security, well, probably longer than you, to tell you the truth. I've been in security now about 30 years, and, um, you, I've seen a lot of water under that bridge, right?

I've seen us move from a predominantly network security type of world where we put big boxes, you know, at the, at the drawbridge with the moat surrounding the castle to the advent of the cloud, to the advent of DevOps, ai, now platform engineering, SRE, so many, you know, subsequent waves. And each wave has brought new innovation, new techniques, new best practices. So over that time, I would say one of the biggest Innova, not innovations, but shifts in security, was the shift to AppSec, right?

Even before DevSecOps, the shift to AppSec, the idea of we are going to secure the applications, whether they're in the cloud or in a data center, or on your phone. We need to make sure our application code is secure. It's free of buffer overflows and cross site scripting and SQL errors, and, you know, all of those kind, kind of common things.

You know, obviously, uh, OAS top 20 kind of, you know, uh, of, of, of vulnerabilities. And that's when I first became aware of check marks, right? Check marks was a pioneer in AppSec, right?

And we, you know, the idea of, of static code analysis, dynamic code analysis. Then of course, later on came, um, uh, open source scanning, and I always forget what we call it now. Secure code analysis, SCA, right?

Basically scanning our open source code. Um, all of these things really, I think they made a huge difference in the quality of the code that gets released. And, you know, that's in our applications.

At the same time, things like DevOps and agile man change the way we develop software. The biggest change is what, you know, I call the shift to a software factory, right? Where it, it's not, I used to think of software as like, you know, like mid 18 or mid 18 hundreds Germans, craftsmen, fine craftsmen making furniture or iron metal workers, or, you know, the guild where you had apprentices and, and lifelong, you know, that real craftsmen kind of role.

But I think we sort of shift to the factory, right? Much like we did in automobile production, right? From bespoke automobiles to assembly line.

And we saw the same shift in software. Uh, we also saw the advent of repos and open source software where people, I, I, you know, it's like Frankenstein software. People stitch together a whole bunch of different components right?

From different places, and that's 85% of the code in today's applications. Um, these are all big changes. And then of course, the biggest one for us here on this show is the whole start of dev SecOps, right?

All of a sudden it became cool to say, Hey, did you know, hey, developer, we know you want to develop quality code, even though we're not those old, you know, mid 1800 craftsmen anymore. We still have pride in our work. We still have pride in the code.

We're publishing. We want, no one raises their hand and says, Hey, I feel like putting out some crappy code today. No, everybody likes good code.

And, and so that was a revelation for security people, Jonathan, right? We, we, we spent 20 years, we always said, nah, no one cares about security but us, we're the only people. But no, they care about security.

Let's give them the tools to do it. And, and again, check Marks led the way there, I think, right? With, uh, well, the most recent is the advent of check marks one, that whole platform.

So that was a long-winded intro for you to discuss check marks one and what that is. Well, uh, there were a lot of things in there that I'd love to address, but since you asked me directly about what check marks one is, I mean, uh, you know, I I think check marks one is our response to everything that you said. And yeah, like, I mean, we can go back to the Toyota production system and, uh, and, and, and, you know, Caugh and, and how that's, you know, grown up and influenced agile development and, and the kind of march from DevOps to somewhat argue back to DevSecOps.

Um, and, and I'll say that I was, I was talking to someone recently and he said, you know, I spent years as a DevOps leader, and I always thought DevSecOps was just a marketing term by security vendors, because we always knew that DevOps had to, it was, it was supposed to be everything, and security was a part of it. Yeah. So, you know, as, as a guy who's out there now talking about DevSecOps, I think I'll, I'll at least, uh, say, yeah, like we're, we're, we know.

But, uh, check marks one is still the response to this, right? It's the response to that need that, uh, maybe security folks felt like, uh, well, that's nice that you included it, but we're not talking about it enough. Um, and you know, your reference to, you know, coders a and developers as originally kind of craftspeople, I, I think they still are.

And I think that what all the open source stuff and the kind of Franken code that people put together is because we're trying to refactor people's time on doing the craftsman stuff, where it's really, really important. Uh, and we want security to still be a part of that, right? So we want security to be a part of your software supply chain.

So everything that you pull down from the internet, we wanna make sure that, you know, that code is secured when you build new code and you get time to do that. Craftsman, like work, we wanna be there. Uh, you know, doing the analysis of that code before it gets into production and, and check marks.

One is the response to those needs of taking all of these different types of analysis, right? Fast, SCA das, API security, uh, container security, and, and building those engines, not separately, but so that they work together and that they can fit into your production pipelines, right? Because if you're gonna do this effectively at scale, which is, which is really what large businesses need, they're trying to get all these developers, all these craftsmen who, you know, work on these little individual things to really, to make a big outsized impact.

Um, we wanna fit into all of those production lines, integrate with everything that you need, and make sure that we're securing as much early as possible so that when things get to production there, you know, there are as few critical vulnerabilities as, as there need to be. So that's check marks one, is the response to that need for that to happen in the cloud for that, to make it easy for everyone. Love it.

So you open this can of worms. Let's go back to the birth of Jeff SecOps. com in, uh, when we first published it in March of 2014.

We started in 2013, you know, planning and getting everything done like September, October, 2013. And, um, let's be clear back then. So I came from the security world.

I thought, what a tremendous opportunity DevOps represents for security. There wasn't a thing called DevSecOps. There was, there were proto like proto humans, you know, not Neanderthal, but Africans and some of the proto humans.

There were things like rugged DevOps. My friend James Wickett, who is now a runtime or drive run Secur is his new company. Uh, he started something called the Rugged DevOps Movement, right?

And it was, you know, ruggedized DevOps, making it resilient. org. Maybe we'll have Shannon on a show going forward.

I, a good friend of mine, um, and she actually wrote the Manifesto for DevSecOps, right? 10 years ago, this May was the very first DevOps DevSecOps Connect that I did at the RSA conference in partnership with my friends at RSA. Um, and the idea then was when we first did this 10 years ago, again, DevSecOps, it was funny, the security people thought it was full of crap.

John Jonathan, right? Because they said, oh, nonsense, no one cares about security. And the, and the developers thought it was full of crap too, which is a marketing term, the true DevOps people like my friend John Willis and, and Patrick dubois, who coined the term DevOps and, you know, the, uh, Andrew Clay Schaefer and, you know, the Damien Edwards, the, the, the founders of DevOps.

They felt, of course, security was part of DevOps. DevOps encompassed all of that. But what kind of needy, whiny individuals or security people that they feel it necessary to stick check right in the middle of the dev and the ops, and they resisted it, right?

And when we first started doing these events at RSAI, that was my mission, to bring the security community to the, and the DevOps tribe together. It's kind of mixing peanut butter and chocolate, and there was a lot of resistance. Go ahead.

Yeah. And I mean, let's, let's be honest. 'cause we're, we're gonna talk, we're gonna have a whole conversation on culture later, but like, yep.

From my perspective, that what you just said, oh, well, everyone thought it was, everyone thought it was bs. Like both sides kind of. That's, that's kind of part of the problem, right?

And that's why we needed to have it in there in the first place is because you can say DevOps always included security, okay? But DevOps started in 2009. It is 2025, and there is still a massive culture clash between security organizations and development organizations.

I was talking to my friend who, uh, you know, she was recently a senior staff engineer at an Amazon based company. And, and, and now she's often a, um, uh, in a, in a startup again, uh, you know, but, but they were saying like, you know, the security people want, it's so secure that like, well, we're just gonna unplug everything, right? Right.

And developers like, well, I still need to do my work. And that requires things to be turned off, right? And, and if we're still there where we have this, this big culture clash, which is fine.

And again, and I say this all the time, like, developers move fast and break things. Security people don't ever let anything break. And if we can't start coming together as, as distinct disciplines and working towards the goals of the business, not just our own individual metrics of like, I've tracked this many vulnerabilities so that I can buy more of this software and secure this, right?

And developers saying, well, I'm not meeting my development milestones, so I'm gonna skip this step and I'm gonna meet my development milestones. If, if we can't work together and have the business align us on goals of what producing secure software at a rapid pace looks like, then we still need to be talking about DevSecOps and talking about DevSecOps maturity and where you are. 'cause like that the, the cultures have to find a way to come together.

We can't just have security being the department of No. And we can't have developers being like, oh, they're all 20-year-old yahoos. And it's like, they're not like, these people have been doing this 30 years.

Like, come on. So, Absolutely. So let me, let me give, let me spread the good news today.

Like it's Sunday and I'm selling Watchtower or something. Um, the good news is we've made a t tremendous amount of progress Agreed Over the 10 years I'm doing this thing in RSA, which we're doing again this year in RSA in May, check Marks is a sponsor of it. They'll be there, I think they're on one of the panels even, uh, uh, uh, Toby, the chief product officer at Check Marks is, is on one of the panels, um, co.

But anyway, people recognize that DevSecOps is a real thing that you need. The second DevSecOps even more than that, when you look at the leading DevOps platforms in the world today, companies like GitLab and Jfr and Harness and CloudBees to name a few, they don't even call themselves DevOps platforms. They call themselves Dev DevSecOps platforms because they recognize how important security is.

So we have made progress. I have a more nuanced view of it today than maybe you, Jonathan, or what you said so far in that I think what we're seeing is under the maturation of DevSecOps, we've learned some lessons. Developers are not against developing quality code, but they're never gonna be security professionals.

A percent agree. Yep. And I think one of the mistakes that our DevSecOps industry has made is giving security tools to developers.

We need to give developer tools to developers that help them do better security, right? Because they're never going to truly understand the, the nuances of the CVSS rating system or something like, you know what I mean? One of these kinds of things.

Yeah. And that, so again, we talk about Check Mark Swan, bringing it back to that. That's one of the beautiful things about that is, right, creating a, a platform that developers can use and feel comfortable in without having to be a security pro, but also having an aspect of it that the Security pro can use to get their job done as well.

And again, these are things we're gonna explore. I wanna explore shift left, have we over shifted? I want to explore how platform engineering has kind of come in on top here and said, Hey, let us work with security to set up the guardrails so that those developers can just go faster.

And we, we do do the platform engineering show, right? Of which you, you've been on there and check Mark's sponsor. We'll be discussing more of that on there.

But we, you know, we'd be wrong if we didn't include it in, in here too. Um, and I think, here's the other thing. This whole, uh, software pipeline security, right?

Software and supply chain security, that's part of DevSecOps too, right? It's a huge part. The SBOs, everything else.

And here's another thing I'm seeing, John, and I'm wondering if you see this too. We're starting to see people say, Hey, we gotta extend, extend DevSecOps past the deployment horizon, right up till now. DevSecOps, it was like, it hit a black hole when we deploy, right?

No light escape to the other side. Well, no, there's life after deployment, right? For apps, and there's security after deployment, and that has to be tied into your DevSecOps too.

So I, another thing that I'd like to see us discuss, what else would you like, think we're gonna cover, Sean? Well, um, let's see. We're gonna talk about culture.

We're gonna talk a lot about security education, because, you know, while you said that, so look, everything you said about making security tools into developer tools, I completely agree with you. I think I even said it at Techstrong Predict, uh, that mm-hmm. You know, that's, that's the goal.

Um, but I wanna talk about security education. I wanna talk about how it's working, uh, because it is, we just did a survey of 1500 developers Yeah, sure. Working or not, but at least the developers who are out there seem to feel like it's working, and maybe security needs to change the way that it speaks to the market.

And stop complaining that they don't teach security and secure coding in as part of, you know, a university degree and say, okay, well we're, we're, we're doing it. So let's start speaking differently to developers about security. Right?

I Agree a hundred percent Again, that, that ties back to culture. So like, I think that the overarching conversation that we're gonna have across every single one of these meetings is the culture. And it's gonna be like the culture around integrating properly, around metrics, around security education, around matching the velocity of security to the velocity of development.

Um, you know, about security champions programs, all of these things that we're gonna wanna talk about throughout the course of this show. Uh, I, I think it's, it's all gonna tie back into culture and how we learn to continue working together and, and agreed, you know, security goes beyond deployment. That's why check Marks one partners with, uh, with folks like Wiz and, and, and with Cystic right Runtime partners.

So agree. Like we need to be looking at the whole software life lifecycle as developers look at the software lifecycle. Agreed.

Agreed. Hey, you know, what else though, for people watching this, are you a DevSecOps person? Are you a DevOps person?

Are you a developer? Are you a security? Would you like to be involved?

Perhaps be a guest? You have a point of view. It's not just gonna be you and I talking every week, Jonathan.

We're gonna have, that's true. Hopefully a panel every week of at least 3, 4, 5 people. Not every week, every other week.

I think we do this. Um, but every show, and we're looking for people. So if you have some thoughts and opinions and everybody has an opinion on, uh, DevSecOps and DevOps, write to us.

com, or reach out on LinkedIn or wherever you can reach me. I'm pretty accessible. So you can reach out to us there and we'll, we'll entertain any and everyone who'd like to come on here and, you know, have a thought on, on what we're gonna say.

You know, what else, John? I'm really proud of us. We're on now.

Oh, a good 15 0, 25 minutes. We haven't mentioned ai. What about AI at DevSecOps?

We'll, we'll talk about ai. And you met, you mentioned, uh, Patrick Debar earlier, but he and I had a, had a long conversation about AI that you can find somewhere online, probably on our website, uh, as well. Um, but yeah, you know, ai, uh, we're gonna talk about AI in a bunch of different ways, right?

'cause there are, there are lots of different ways of looking at, which is like, how does it help developers code faster? How does it help them do security faster? How does it help se security engineers to, you know, tune their products faster?

Um, and then what does it mean for the software supply chain? You, earlier you were talking about, uh, code and, um, and, and downloading other people's code and how that needs to be scanned. Well, but now there's hugging face and there are all these LLM models.

And you know, we've got a guy on at our company, ez, who's one of our lead researchers, and he's done a demo of like, here's how you poison an AI model, and here's what it looks like, right? Gimme a recipe for, you know, pasta Alfredo. And one of the ingredients that gives you is rat poison, right?

When he, when he does that right, poison this model. So there's, you know, if, if, if companies are building their own LLM or they're looking to build off of an open source, LLM, what's the security of that? Who's gonna scan that?

Who's gonna know whether or not your model is poised? So like, there's, and, and I don't mean to ramp up the fear factor 'cause that's obviously what security folks typically are, are known for doing, or at least accused of doing. But it's, it's a concern.

AI is now a supply chain concern in addition to all of the ways that it can be helpful. So let's totally talk And like everything else, it's the duality, right? Light and darkness.

Uh, it's always there, man. Every technology, it, you, you get it, it's new. It does something cool, and there are risks, and that's just life.

I always say this is why we can't have nice things on the internet. Um, but we do have nice things on the internet in spite of all. And, and, and, you know, again, I I I want to take a positive view of this as a result of DevSecOps, our code today is much more secure, like the apps you're using today.

And even though you may be updating them daily, weekly, monthly, whatever, they're much more secure today than they were before DevSecOps. I, I think we have made tremendous strides in, in releasing much more secure code. Yeah.

So, agreed. That agreed? Mm-hmm.

All right. Hey, that's gonna wrap up our very first version here of the DevSecOps Show. Cracking the code.

We're gonna be back in two weeks with a full on panel. Jonathan, let's tackle culture right out of the bat and talk about the DevSecOps culture on that show. Um, you can catch this show on Tech Drunk TV and the Tech Strunk TV network.

So it'll play on Tech drunk tv. It'll be streamed to LinkedIn and Facebook and x and YouTube to our tech Drunk tv, YouTube channel. tv website.

com, security Boulevard, cloud native, now, tech Strong, AI tech, strong it, and digital CXL. Um, additionally, audio versions of this will be available on Apple Podcast, uh, uh, Spotify podcast, Stitcher, and all of your favorite podcast platforms. So if you prefer listening to audio while you're running, exercising, whatever, driving, they'll be there for you too.

Um, Jonathan, I'm, I'm pumped. I can't wait to get cooking with this. Yeah, I'm, I'm excited too.

I think it's gonna be a great series, and I appreciate you and the organization for hosting it. Looking forward To it. Absolutely.

Absolutely. All right, until next time, then that's a wrap on episode one of the DevSecOps. So DevSecOps show, little tongue twisted there.

DevSecOps Show cracking the code. We're out everyone. Thanks very much.

Thank you. Hey everyone, it's a Shimmel here from Techron Group, and you're watching another episode of the CD Pipeline. The CD Pipeline is a, uh, partnership between the CD Foundation of the Lennox Foundation.

And here us here at techron, we're about, about once a month we try to bring you some of the latest topics regarding or germane to the CDF audience, to the CD Foundation. For those of you who're not familiar with the CD Foundation, we usually have someone here from the CD Foundation. Um, but for those not familiar, the CD Foundation, as I mentioned, is a daughter foundation of the Linux Foundation, but it's responsible actually for the management upkeep running of several of the largest tools in the CD universe, CICD universe, including Jenkins, uh, Spinnaker, um, Tracy, one of yours, Orus Orus.

Um, I think there's eight or nine different pro programs that fall under the auspices of the CDF, but it's more than just managing those, it's, it's working groups around the security of them, of operating them best practices. It is the community for CICD. And so this show, CD Pipeline tries to capture that.

Um, this week's show is challenges and wins in integrating security tooling into CICD workflows. Let me introduce you to our panel for today, and then we can jump right into the topic. First of all, I think it's her first time on, and if I am mistaken, right, Kate, it is your first time?

Yes, my First time. Very cool. And I'm gonna try not to mess up her name, but I forget things from one second to the next.

Uh, Kate Illa, Well, almost Scarcella Scarcella. If my eyes were better, I'd be able to read it up there, because my, they didn't put it on my prompt here for me like they're supposed to, but they try. All right, Kate, beyond Scarcella, what else can we learn, learn about you here today?

So I am a cybersecurity architect. Uh, I got my Master's of Science and Information Security and did my thesis on securing the electrical grid in North America. And I graduated way back in 2006.

And I tell people this because there was only four people in my graduating class, so nobody was really talking about cybersecurity, even though it was coming up in, um, in some products. You know, you had av, you had networking, security, and dare I mention the start of identity and Nexus management, which was like, ah, but anyway, so that's my background, and I did it for Very cool. Yeah, so very, For a long, that was the electrical grid without Texas.

Very good. Mm-hmm. So, um, I'm not gonna touch that one again, but I, I've been in security about 25 years, myself more now.

And, and you're right. Back then it was, it was network security or endpoint secure host security as we called it. And, uh, it certainly has changed over the years, though.

It's become more important than ever. Obviously, I, you still working in the security field today? I am.

I took a short sabbatical for about a year, and I'm just, uh, coming back out of that sabbatical, um, connected with Tracy, who has, um, who has, you know, full speed here this year. So, yes. Um, Well, it's great to have you on here.

Thank you. Thank you. I'm, I'm very happy.

Appreciate it. Looking forward to, to hearing more. Um, next up we've got Ryan Ware, as in software.

Ryan, welcome to CD Pipeline. Tell us about yourself. Hey, thanks, Alan.

Uh, I'm really happy to be here my first time as well. Um, uh, uh, I, I appreciate Tracy dragging me, uh, uh, to come on here. Um, so, uh, I've been doing security in one way or another for 27 years, uh, or so, uh, I'm a software developer by, by nature.

But, uh, uh, you know, early in my career, uh, I first started at Intel doing, uh, implementing security features into digital rights management stacks. Uh, later I did offensive security research into, uh, Intel's products. Uh, later I was more of a security architect and then, uh, worked in, uh, the realm of open source for quite some time, uh, on one.

Uh, how do, uh, uh, product teams incorporate open source in a secure way, as well as how do you securely, uh, uh, make and contribute to open source externally? Uh, Intel has a, a, a a, a large presence in the open source community, uh, these days. Uh, I work for Carrier, where I am Deputy Chief Product Security Officer, uh, focusing on security tooling, uh, CICD training, uh, secure Development practices, uh, and, uh, I'm also in the, the Open Source Security Foundation where I am the chair for the security tooling working group in that organization.

Very cool. You mentioned Intel's commitment to open source. I think it's very fashionable today to, to crap on Intel, right?

They're not, they're not Nvidia and, you know, have the mightier phone, but I, I think people have never given Intel enough credit for their commitment to open source, open source communities, open standards, and, you know, kudos to them for the work they do. I know they work very closely with the Linux Foundation, C-N-C-F-O-S-S-F, you know, a lot of the, the foundation. So Absolutely shout out to them.

They do, they do an amazing job with that and still do even, uh, with all the troubles they're having right now. com/intel. So, Absolutely.

So shout out to them. All right. Our last panel member today is our friend, Tracy Reagan.

Tracy, of course, CEO of Deploy hub, uh, Aurelius, one of the products under the CD Foundation came out of Deploy Hub and, and their, their efforts. Tracy's also, I mentioned she's a host on our Textron gang, and, you know, she works, she has a hand in a lot of different Linux Foundation, open source, uh, projects and, and boards, including OSSF, open Source Security, OSSF, and the, uh, the D Foundation among others. Tracy, great to have you on today.

Well, thank you. Yes, I am, um, a busy girl. I kind of have one foot in the security world and one foot in the DevOps world.

I am on the board of the Technology Oversight Committee at the CD Foundation. I've, uh, served in that role now for, uh, several years. And I'm also on the board of the open SSF, um, so I'm keeping kind of my thumb, um, on the heartbeat of both sides.

And we re at the CDF, we recently started a, um, special interest group called CICD Cybersecurity, which, which Kate is the chairperson of. Uh, and it, the reason we, I felt we needed to start it was because there isn't a strong enough handshake between what the security side of the business is doing and what the dev, what the DevOps side of the business is doing. So it's time that we have that, uh, conversation.

It's a really critical one. Um, most DevOps engineers, you know, even just putting in, uh, the scanning of a SBO m is a major undertaking, and there's so much more to do. So it makes me a little nervous that we are so far behind the eight ball.

Uh, I wanna remind everybody that it takes us about a hundred days to respond to a vulnerability. It takes a attacker less 10 days to exploit it. So we are, um, at a major disadvantage here, and there has to be a discussion on how to improve that time.

And so we're hoping that we can do that with this, uh, the, the new SIG at this, uh, CD foundation. So I'll use CDs out there, which I call you, please, C DERs. I want you to join the, uh, the CICD cybersecurity SIG and start helping us with really defining what that looks like in the pipeline.

And I hope we can have a deeper conversation around that, considering we have two security experts on the call today. Absolutely. So, as I mentioned, I've been in security 25 plus years, right?

com was I felt that DevOps and the whole CICD pipeline model was a way to get like a second bite at the Apple for security. We could correct a lot of past wrongs by moving further left, shifting left into the development pipeline to fix security problems that by the, by the time we saw them pop up in production, they were a lot harder to fix. It would be much easier to fix them further left.

It sounded great, right? com devs, the whole rise of DevSecOps, as we call it, right? Uh, we made a lot of progress over those 10, 11, 12 years, but most recently there's been a pushback where have we shifted left too far?

And by that, have we put too much of the onus on security on the developer who's not a security person, right? And, but nevertheless, you know, we, we've made them the, the focal point for our security efforts and, you know, pre-deployment security where instead of, let's say, maybe building it holistically into the whole pipeline process right from left to right. And, and so, you know, there's been pushback.

Hey, instead of shift left, we should shift everywhere. We, we, we need to build security into testing. We need it built into the pipe, not onto the developer's shoulders.

Now, Kate, you've got your master's degree in, in all of these things, and, and you're, you're the head of the sig. What can we do to, it can't just be, let's make the developer our security or make the dev our security person. He's, he or she is not.

What, what can we do? What are we doing? What should we do, you think, in, in terms of integrating security into this workflow?

Well, I think, and when you, um, go out, uh, to the specific page that, that we have, one of the areas, security is very complex, as you know. Um, cybersecurity is very complex, and it has become, the complexity in itself has, is also a vulnerability. So we need to make things simple.

So yes, are we putting too much on the developer and should we have it throughout the pipeline? Absolutely. But we also need to have, um, bite size, you know, these, these, you know, Lunchable type of, of packages that we can say we're gonna do, you know, we're gonna secure in the, in the, you know, free deployment phase and how, what does this look like?

And I think this, the more simple that we have the tools, because as, you know, to introduce a new tool, um, is, is just a headache for our developers, and yet another tool and another tool and another tool. And so I think we need to have, um, tools that are, and they're very expensive. So tools that are, you know, open source that can be used, that can be used easily, and so that it doesn't take a master's degree to go out to try to figure out, well, how am I gonna secure this?

I think that's, you know, something that we have talked about, um, with the sig. Um, and just, it's so important to keep it simple. I mean, it, it sounds, you know, ridiculous, but we have made it so hard.

We have made cybersecurity so difficult to consume and so expensive. I mean, think about the tools that we have developed. I worked with IBM for over 20 years, and it's not just, you know, it wasn't just one tool.

It wasn't just, you know, um, static, you know, analysis, coding, it became, I mean, you just, everything just grew and grew and grew, and we just would keep adding and adding. So I think we need to do more with less. So, you know, the one tool can take on this pipeline from left and throughout.

I don't know, Tracy and Ryan, what, what do you guys think? Well, I, you know, I, I preach simplicity all the time. Um, part of the problem with the CD pipeline, if I just put my DevOps hat on and not my security side, um, the problem with the, the CD pipeline is it's so brittle.

Um, everything's based on, uh, a script. So we have to go update all those scripts. And that is not an easy task, folks.

It is really not easy to manually update so many thousands of scripts, thousands and thousands of workflows. Um, so it becomes a challenge because we don't wanna touch those workflows. They break easily.

So then maybe we have to have a security workflow that the, that our workflow calls. So, Kate, as you pointed out, we've made everything so complex. Everything, not only just not security's complex, but so is our workflows.

They're complex too. So we've dug ourselves in a bit of a hole, and we're behind the eight ball. So how do we get out of it?

Now, many people know from my discussions that I have been a big fan of CD events. Let's rebuild and redefine how this, the, the pipeline works. But that e, even though IBM has done a great job, and that some of the team on that project has done a great job of defining what those events look like.

And even, uh, Jenkins has an event, has a CD events plugin. We, I don't see, uh, the, what I like to call the Giants, the Microsofts, and the, um, the, the intel, even though they've been doing a great job in some areas, I don't see them understanding why events are important, why it's important to re uh, to disrupt how we do pipelines. So as long as we have this, uh, this difficulty updating pipelines, I think we'll have difficulty implementing tools.

So what we have to be able to do is define the low hanging fruit. Let's at least get started with getting a, a, a software bill of material generated and make that a a, a common mantra that we can really expose to the DevOps pipeline and the DevOps engineers is say, this is one way we can get started. At least let's start there.

So simplicity, I think will be critical. Yeah, I, I agree with that, Tracy. Um, I, I would like to go back, uh, uh, uh, to what Alan was saying for a minute though, and, and just push back slightly on the idea that developers need to be security experts.

I, I don't, I don't think developers need to be security experts, but developers and do need to be capable of writing quality code. If, if, if we don't think that there's an expectation on them to, to write quality code, uh, um, then I, I, I think there's something fundamentally broken in, in the system. 'cause, uh, they're the ones that are writing the code.

Uh, and security in a lot of ways is, uh, you know, the many, many security vulnerabilities are just engineering 1 0 1 quality issues, uh, buffer, overflows, uh, uh, uh, null point or de references, things like that. Um, that said, I, I, I do, uh, uh, like what you're just saying, Tracy, uh, about events, I, I, I think one of the, the problems with how we have incorporated tooling into, uh, pipelines is, you know, it's all about, okay, how do we get this tool in here and get results out of it? And, and that's not the focus it should be on, it should be on what's the activity that the developer is doing right now, and what's the information that we can get from our tools that would be helpful for the developer to have during this activity?

A great example is pull requests with, uh, on, uh, for example, uh, uh, you know, a lot of, a lot of organizations use a, a static application security testing tools, uh, traditionally called static code analysis. Um, which by the way, uh, there's open source tools that have been making great strides in this area. GC fourteens, uh, static analyzer, uh, functionality is, is way improved over previous versions.

Um, that said, you know, the right time to be able to show a developer about flaws in their coal code using a SaaS tool is during poll request time. And, and ensuring that, that, you know, when a developer needs the information about the quality and security of their code, it's important for 'em to have it at the right time. Uh, traditionally we've told developers, Hey, yeah, you have to go over to this of the place over here where, where, uh, the results for, for all the scans are stored.

Developers hate doing that. They won't do it, and we're never gonna win by share doing it that way. So let me weigh in here.

I bet you if we did a survey of developers and said, how many of you want to develop low quality code? Not a lot of them are raising their heads. Every software developer I've ever met just about has a tremendous amount of pride in, in what they do and the code they develop.

You know, it used to be before we got into the age of DevOps and pipelines in the software factory that we have today, software development was very much sort of like a, a guild, right? Ancient, uh, not ancient, but you know, like old German guilds where there was a lot of pride in craftsmanship and stuff like that. When I was a security guy, I used to think, boy, those people don't give a hoot about security.

And if they did, we'd be better off. But then when I, the more I got into DevOps, the more I learned that they do give a hoot about security and quality, right? Because security is synonymous with quality and they do give a hoot.

And then early on in DevSecOps, a lot of security companies said, you give a who to bet security, Mr. And Mrs. Developer, here's a tool to use.

Use our tool. Use our tool, use our tool. And you know what?

And that's where it went off the rails. They don't, they're not good. Use a security tool.

When you start telling a developer, Hey, wait a second, we wanna do a static analysis scan of your code. And that's not enough. Hold on.

I wanna do a dynamic scan analysis of your code. Wait, there's more. I see you've been using a lot of that open source stuff.

We're gonna do an SCA software composition analysis scan of your code and whatever the, and I just bought this latest company's greatest new, you know, ICAS or whatever the heck they're calling the next one. And the developer, they just, Hey, can you just tell me if there's bugs in my code so I could fix it? That's all they wanna know a hundred percent.

Right? And, and we've, I think we lose sight of that. And, and in a perfect world, that's where, and along this pipeline, these things get done and it makes its way back there, right?

And the code gets fixed. And look, here's the good news. We live in a wild time right now with AI and automation and everything.

A lot of these things could be fixed on the fly like that, right? I mean, you know, stuff we dreamed about Yeah. In 2006, right?

The, the ability to do automated remediation. I, I was selling vulnerability management in 2006, you know, no one wanted it, it, it took 90 to 120 days to remediate code that was code in production, not code in, in, in development. So I haven't Gotten any better at that.

And still that, No, we, we have, because I'm gonna tell you, the problem I had back then is we were able to identify vulnerabilities and we built workflow into our product that pointed to the patch, and we had the ability, 'cause we also developed a NAC product network access control. We had the ability to remediate on the fly. No one would let us, yeah, no one would let us because they were afraid to patch without first testing to make sure that it didn't break something else.

It might break your stuff, Right? But we can't, or rather be insecure than have broken stuff. I don't necessarily agree with that logic, but nevertheless, that was the prevailing logic.

Have, have we changed? Ryan? You've been around.

We're trying. Yeah, We're trying. But that means we haven't changed.

Is that what you're saying? Yes. I, I would, I would say there, there are areas in the industry where, where it hasn't changed and change is hard.

Uh, um, and, and to be honest, I I work in one of those industries right now. Uh, um, one of the things that blew me away when I came to work for Carrier is the support life for some of our products. I, I mean, I, I used to work on automotive stuff where they're talking about support life of eight to 10 years.

Uh, we have to support software stack in our products for 25 to 30 years. And, and because of that, the interesting legacy implications of some of the software we have, uh, uh, just are, are an interesting challenge for us in, in the new ecosystems. And, and a lot of people are resistant to change because of that.

Agreed. You're talking about critical infrastructure. I mean, right, Brian?

I mean, you know, You, you know about it. Kate, Windows XP baby, you know, good luck. Um, you know, the one thing that I think would help us, and it's the antithesis of when we think about cybersecurity, but you know, the, the bad actors are doing this.

And that is, you know, when we talk about open source, you know, they actually, the, the bad actors actually do it, right? They collaborate, right? The reason they're able to get their stuff done so quickly is they have such huge collaboration tools.

And I actually think they're doing it right. I mean, it's a, you know, crazy idea. But I think we need the, you know, the, the, the, those who are trying to make things better that we really need to, to be, you know, have open source, you know, from, so from, you know, coming from all these, you know, companies that we're, you know, doing proprietary stuff, you know, I've been like this new open source, you know, let's collaborate.

Let's, I think it's gonna be one of the most important things because when we have this discussion about, you know, the pipeline and can it just be on, on, you know, the, the, the shoulders of, of the very beginning person, you know, when we talk about cybersecurity, one of the things that we would talk about is, is everybody's, you know, everybody has to know about cybersecurity. Everybody has to understand it from the user with their, you know, digital user interface with their, um, mobile phone, uh, which has become a human machine interface to so much to, um, you know, to, to the worker, because we are one in the same, right? You know, the, the, the home user is also the one who's going into the office, who's also working with the, you know, we all need to think about cybersecurity differently, um, in order to help things to become, I mean, it, it sounds, you know, somewhat esoteric, but we really, we need to, to do it.

So it's not so scary, right? Because we sell based on people being scared. And we need to, we need to really back up from that and think, what are we gonna do to make it better?

I think, and, you know, to, to Tracy's point about, you know, low hanging fruit, boy, how much can we, I I, how much can we do with just getting the low hanging fruit? You know? I mean that, I, I think I, I think it could be like a 70% type of thing.

And, you know, maybe there's a crazy percentile, but, you know, long hanging fruit, I mean, that's a, it's a great idea. There's definitive Wins there. Absolutely.

There's a whole bunch. If you could just, you know, just take those, you know, we've got a few minutes left. Let me bring up another kind of push pull that I think really affects us.

And that is, and this has been going on, bro, as long as I'm in security, which is what's my tolerance for security slowing things down? Yeah. Well, that's a good question.

That's, that's not a little question, You know, because that same survey where I asked the developers, do you like making low qual or, you know, crafting low quality clo uh, code, the next question is, you know, why don't you do security better? And it's always because the pressure is on, and I get paid based upon how many lines of code I publish, and I don't have enough time to write and test. We don't have enough time to write and test the code thoroughly because we have deadlines to meet.

And so when security becomes the people who say no, and puts the break on going faster, we very quickly get kind of shoved out to the side, pushed to the back, you know, stay outta the way of this. You're, you're standing in the way of progress. Um, how do we, and, and again, this was one of the things about Def SecOps that I thought we would do better.

How do we overcome that perception and move at the speed of business? I like to say moving at the speed of DevOps, Right? Okay.

Moving at the speed of DevOps. So we have a weird, there's a, you know, there's a, the cultures between the DevOps people and the culture between the security people could not be more different. Um, if we think about v uh, a new vulnerability that's been found in production, the mindset of security is don't tell anybody.

Go through a, uh, event management process. Notify the people, only the people that should know. Because if we, uh, tell everybody and let the development team who's being impacted know that they may have, we may have some kind of internal attack to it.

So there is a hold this, you know, hold the cards close to the chest mentality inside the inside on the security side. It just is there. They don't, they lack the trust.

They want the control of managing it. This slows everything down. The, the, our, our culture there has, is, is just wrong.

Now remember, it may have started back in the, in 2000, Alan, when you were trying to solve the problem. And what they were doing is they were, you know, if a, a, a bug was found, uh, uh, if a hacker found a vulnerability that impacted Microsoft or IBM or the government, or Hewlett Packard or anybody else, they got, they were purchased. So we had a zero day market and nobody told anybody about them.

So that's where we begin our story in security. Now, on the other side, we have DevOps engineers who have been preaching agile development and releasing fast for the last 10 years. And we have gotten really good at it.

And on top of that, we have Kubernetes, which means everything's decoupled. Everybody use, it builds their own container. So that one production vulnerability could be living in hundreds of containers across our endpoints.

So now we find ourselves having to fix some really big problems with a culture that doesn't want anybody to know about it. And another culture who says, you guys are way too slow. We need to continue pushing new innovation across the pipeline because that's what we're being told to do, and we're trying to build the best quality code we can.

And we're trying to manage DevOps pipeline so that they're getting code out as quickly as possible. Because that's what the business demands and security sitting there and saying, well, we don't want anybody to really know about this. Let us try to mitigate it and go through the process and only tell the teams that need to know that this problem happens.

It doesn't work. Those two cultures are, are conflicting. So somehow we have to create that handshake, is kind of what I began this conversation to.

Security has to be more willing to open up the door and let more people know about it. Security has to be willing to have those fixes pushed across. And Alan, you were just way before your time.

In our world, what we're trying to do, you know, for Intelius and to play up, we or we, Orus has the information right now to be able to push out a remediation. So we have discussions about discovery and how to remediate. We wanna shift the focus to how does DevOps fix it?

How can we use DevOps information to at least create, update a, a helm chart or a, a Docker file, and at least create a pull request for a high security vulnerability that's impacting certain teams and get it to them as quick as possible so they can make a decision if they want to move it forward, they can do the analysis and they can accept or reject that pull request. But to do that, we have to get the security teams to say, yeah, that would work. That would be okay.

But at the moment, they may not be saying that 'cause they're saying, no, we wanna manage that response ourselves, and it slows everything down and the world just keeps turning while security figures out what they need to do. I, I think that's beautiful. You're right on.

Yeah. I, I mean, we, we in the cybersecurity, um, Alan and Ryan, I mean, right? I mean, we, it we need to change this mindset that we have, and I really do believe that we need to be more open about the vulnerabilities that we have, or we're not, we're not making it the way we were doing it.

We know that. So it's about time that we switch things up and say, okay, let's try something different. Yeah, I, I, I agree with, with what both Tracy and Kate were saying.

Uh, I, I'd also just add to, uh, uh, taking a, a, a little bit of a, uh, uh, a perspective change. I, I think security folks a lot of times lose sight of what developers really need, uh, to, to do their jobs right, and, and do their jobs the way security folks think they should do their jobs. Uh, uh, uh, and, and a lot of the things that, that security professionals ask teams to do without thinking about it, uh, uh, dramatically slow development down.

And, and, uh, like I was talking about static code analysis results and pull requests earlier, well, that works great if you're doing, uh, uh, for example, writing code in Python, uh, or JavaScript, uh, uh, you can get results pretty quick out of there, but that doesn't work very well if, uh, uh, you're talking about a code base like the Linux kernel that has 40 million lines of C code in it. 5 times the build time. And building the Linux kernel is not a, a small event anyway.

So you can't ask dev teams to, to wait for, for 2, 3, 4, 5 hours for results on tools into a pull request before they can go accepted. Uh, uh, you, you know, you, you have to figure out what's the right balance, uh, uh, to be able to, uh, uh, bring the bar up from where teams are doing it right now, to, to, uh, doing it in a way that, that they feel is acceptable use of, of their bandwidth and their time. Agreed.

Agreed. Hey guys, we're, we're about outta time here, unfortunately, you know, we didn't mention the CDF. You mentioned the, uh, STIG that you guys started.

org, isn't it? Chasey, the website for the CDF, Uh, CD Foundation, Excuse me. CD Foundation.

CD Foundation, yes. And the SIG is new. It just started in January.

And our first exercise is we're going through the, um, secure software development framework. We're looking at every single task that relates to the pipeline, and we're associating open source tools that can be used to, to accomplish the task. I love it.

Can you get to the sig off of CD Foundation page? Yes, we should be able to go to the, um, uh, community page and find it. All right, Kate, congratulations on leading this fig there and getting your hand into this open source security world.

It's going to, we, we can all use the help. So thank you for your, for your efforts there, Ryan, same to you, right? It sounds like you've been involved in this for a while now, whether it through Carrier or Intel, what have you.

And thank you for all you are doing. Thank you. I appreciate it all.

I just have one more. I just have one more thing before we sign off. I wanna shout out.

Shout out to Sasha, uh, Wharton, who is one of our, uh, top or like Ortel contributors, and he was recently nominated to the, uh, the CDF uh, governing board as a open source representative. So we're super proud of him. Congratulations to Sasha as well.

All right. That's it for CD pipelines. foundation.

Until then, is Alan Shimmel for Techstrong. Thanks everyone. Bye-bye.