Techstrong TV November 3, 2025

Hey, everybody. Happy Monday. And are you ready for coupon?

Well, you will be in a minute. We'll be right back. Welcome back, everybody.

Today's edition of Textron Gang is gonna have our usual, some of our usual stars starting with Mitch Ashley. Mitch, how you doing? Good to see you.

Good, good morning. Good morning. Also joined by Kate Scarsella and Jack Poller, who gonna lend their insights into all kinds of fun stuff.

But first we're gonna start with, well, what's going on with Cloud native? Because not only did we host a cloud native, uh, now event last week, but cube con's coming up in a week or so, and we have some articles over on Cloud native now talking about how, uh, maybe AI is gonna drive more people to build cloud native applications. 'cause well, maybe it'll get easier, but Mitch, I know you were at the, uh, cloud Native NOW event and you gave a presentation there.

What's your overall assessment right now? Where are we on this March to cloud native? Well, we're all watching this.

It's like, like an F1 race, and we're sitting at one corner, right? You kinda see it zoom by for a minute and they're like, okay, what's happening in the next lap? It just goes so fast.

The, um, the, the market is starting to, to make the next shift, and this is the very leading edge of it where you see vendors that are, that are introducing, um, agent control planes and management of multiple agents doing development work, coding, coding agents. And there's a great article that, uh, we had on, on, uh, cloud Native now that also tied this in. I think it was na, Nathan, Eddie that wrote it.

Really good perspective on it. But I think what we're seeing, and it's not just there, but it's mostly on kind of the developer front end. And then we see it with code reviews.

We see some security guard rails starting to be implemented. Of course, uh, GitHub had their, uh, universe, uh, conference last week and, and made big, big announcements about Agent HQ and are trying to be sort of the neutral platform to bring your agents, bring your model, we'll, we'll run it on our control plane, et cetera. Um, cursor came out with their own kind of similar, we have our own coding model called, called Compose.

And, uh, we're also will help you run multiple agents in parallel. Uh, OpenAI came out with, um, a, uh, a vulnerability repair capability within, within their model. So you're starting to see them, see the vendors sort of try to take it up to the next level.

And I think it's a lot of, it's just a race for the, for the ground, right? Everybody's wants to plant the flag. And while the Oklahoma rush is going on, Kate, I don't think it's any secret that building these apps is hard and deploying them on Kubernetes isn't always a joy, but do you think, or do we have hopes that maybe AI agents will make this easier and more accessible and maybe we will build more of these applications faster?

What do you say? I I personally think, yes, we need to embrace this technology. We need to, of course put some sort of guardrails, which presently we, I, we don't have a lot of guardrails around that, but absolutely, I, I think that we need to embrace this technology and we need to understand it so that we're able to start to do a better job at securing it.

But yes. All right. Jack, any thoughts here?

Do you hope that this comes about or do you think that this is just going to be more trouble than it's worth? Uh, I don't think it's more trouble than it's worth. What I'm trying to understand is how much of the effort is being driven by AI improving the developer's, uh, life and or ai or the end user application that the developer is building, right?

And I think right now we're sort of seeing a lot of focus on developer activities and how do we improve the developer activ and hopefully as a result, the quality of the code they output. And more importantly, from my perspective, the security of the code they output, I think it's still gonna be a while before we get to the point where they're able to really embed AI and particularly agent AI into the final applications. Um, let's see.

I think there's two things to unwrap there, and I'll go to Mitch for the first one. Um, I think most of the AI applications that people are building these days is run on Kubernetes, and I think most of them are cloud native by definition, because well, they're so large that there's no other way to kind of get after this thing other than to break it up into a bunch of microservices. So do you think that as that occurs, that that just naturally pulls more people into building cloud native applications per Jack's point?

Well, first of all, um, we, we have some data in my research from buyers that indicates, it says AI is the number one workload that they're working to put onto Kubernetes. Um, but the point of it is actually that everything's going on Kubernetes cloud native applications, but everything else too, database, as you name it, it's, it's the, it's the workload platform now, kind of just above the operating system, uh, by default. Uh, to your, to your point about cloud native applications, there's a sort of a natural affinity between microservices and agents that kind of had look a little similar, um, but they don't function the same way.

But if you can imagine, you know, a group of agents doing different, uh, tasks, a part of completing some process, just like a group of microservices do now, are those agents running under Kubernetes themselves? Are they running in a, in a different control plane? Um, like in an Agent HQ or something like that?

Is is a different story that we'll see how that shakes out. But I gotta believe under underlying all of it, there will be Kubernetes there. And I think we'll see this real mix of, uh, cloud native microservices and sitting right beside them, you know, agents that are doing some, some workloads.

Increasingly to Jack's point, it's like, it's not like turn the page and it's all agents now. It's gonna slowly, uh, be put into production over time. Mm-hmm.

Okay. I'm trying to figure this one out. Are people just gonna take their legacy stuff and just toss it out the window and deploy something new that feels like a cloud native microservices application?

Or will they try to maybe use AI to take those applications apart and peel 'em off into a set of microservices that, you know, might take 'em a few years to do, but they're gonna keep the core app in place? Or is it just time to get rid of the stuff? Well, from previous podcasts, you probably have heard me say like, yes, we need just to get rid of it.

That's my own personal opinion. Um, because sometimes it takes a heck of, you know, it's like if you think about doing a, a project in your home, it can sometimes take on, if you're trying to save all these, you know, items, it, it can, it, it's painful. Sometimes it's just better just to take the wrecking ball, um, not to the White House, but in other situations.

Um, in this case, it's really, I believe that it's built on blocks, um, that perhaps have been, that is not secure. We're getting some new areas that we can really do this right? And I think to do this right, we need to think differently and we need to put it in place and, and build the right trust frameworks around it.

I, I think when we're building this, now, let's do the right foundation. We know what's wrong, we've seen it, let's do this. Right.

So yeah. Mitch, do you agree with that? Because a lot of the legacy applications were written by people who I hope are now sitting on a beach somewhere probably laughing their asses off and running.

This stuff was documented, and I don't think AI is gonna actually go in and maybe fully document all those things. So why not just start over? Well, my, uh, one axiom I've, I've come to agree with or put together part of my career is no technology ever actually dies.

It's all still out there in somewhere, some form someday. And, uh, you know, we say, Hey, that's the, you know, the, the old, uh, IAM and the old, uh, IIBM databases, those things will go away. It's all gonna be relational.

No, no, they're, they're out there too. Um, but I think to what you're talking about that you were asking, Kate, is there are efforts to specialize AI to help you modernize the applications, not just virtualization of it, but actually the app itself, and in my experience in my career is you rarely wholesale replace a whole application. That's usually a career ending move.

Um, you, you decide a different strategy. And so for example, IBM has something they call Project Bob. I call it Bob's your uncle.

Now it's Bob's your coding agent, but it, and it its specialty is understanding and help you modernize code base. The big issue for modernizing today is there's so much job out there and trying to maintain, uh, consistency with new versions of Java is a lot of code to update. So I, my, one of the things I did earlier in my career as about 10 years ago is the had a monolith application that we really wanted to, to do something with.

Um, but the people who built it were on the beach, right? And they were not coming back. We could not bring 'em back.

So we actually carved out a part of it, a small part of it, 'cause we didn't understand most of the app, and then re rebuilt that in a way that then we could actually with microservices and Kubernetes, and then we could enhance it and do that kind of thing. I think AI will help us speed those kinds of things up. So you may peel off part of an app and say, great, let's, first of all, let's understand it.

'cause nobody can understand that code anymore. Nobody knows it. AI will help us with that too.

The only thing I'll add is, you know, working for IBM, um, from 1999 into 2000, remember the whole Y 2K thing? Oh yes. You know, Do you know that we actually would shut down, um, mainframes and if we didn't get a call, we'd be like, okay, we're good.

And that's how, that's how we, um, basically, uh, went through getting rid of things that were no longer needed. I mean, it's, it sounds crazy that we did it like that, but, you know, sounds Like streaming services at my house. No, no, it haven't called yet.

So I guess nobody uses that anymore. True too. I think microservices are similar.

If you turn those off, people go, oh, I guess we're not using that one anymore either. Right? So, applause jar.

If the security people had a vote in this, where would they vote? Would they vote for trashing the legacy code and just starting over again and maybe, maybe this time building security in from the beginning? What do you say?

Well, I think most security people would actually be for trashing the, uh, the existing code and not starting over again because we wanna reduce the attack surface. But since not starting over, Thank you. Thank you.

It's not an option. We have to do something. I think security people would really like to start with security by design, right?

Is if you're going to do something, don't bolt on security after the fact. Think about security as you're architecting and designing the thing. And you know, that's true.

Whether you're re-architecting it or redesigning it from scratch, or, Hey, we need to make this modification. If we're gonna make this modification, how are we gonna secure it? Right.

And, you know, I am, I, I don't know, I can't beat that drum loud enough, right? Think about security mean, Jack. Think about the market.

If some model maker, some product maker came out with, I call it security OG at the point of origin, right? Right. Where we create the code, we combine it with other things, we configure it, we set up the environment, uh, using ai.

If, if a company came out with that and really made some big progress, man, talk about that would be, that would be the kind of the golden egg that the goose laid it, it would be. And I think, you know, as, as we think about AI and AI in the Kubernetes environment, there is an, it is very easy for us to conflate security and safety, right? And I wanna make that distinction.

Mm-hmm. When we think about AI in the world, safety to me is all about things like, does the AI follow your guardrails and prevent you from, you know, if, can you, can you force the AI to tell you how to build a bomb when the AI is there as a coding agent? That safety and security is really about how does it interact with the rest of the world?

Can somebody exploit it to attack your environment? Which is sort of two separate things, or use, you know, is it, you know, expanding your attack surface in the Kubernetes environment when we're using AI in terms of coding assistance, and how do we accelerate our development process? There's a tremendous amount of advantage we get, but we also should think about how do we use that AI to improve our security, to reduce the attack surface at the same time.

And that's really, I think, where we can, you know, companies that think about it that way and look at it and say, this AI that's gonna be a coding assistance is always, it's prime directive is always gonna be to generate secure code or to, uh, analyze your code that you'll look, that you've created for security as well as just for traditional, what we call bugs, right? And I think if you are, you're developing, uh, tools for the developers that help them security, which is a very complex and hard to understand topic, then you're gonna be, you know, you'll have a winner on your hands. What's interesting, Jack, is you brought up, when you started to, um, speak about safety and security, which is definitely an OT pros, uh, position, operational technology, posi position.

And traditionally from an IT perspective, we were always on the, you know, CIA, you know, confidentiality, integrity, and availability. Yeah. So I find it interesting that going forward we are thinking more, more from a critical infrastructure point of view from safety and security.

Um, and I think that that's important as we move forward. If we were to put that type of thought process in our heads as yeah, as we, as we, you know, define this path Well, and, and I, I, I like your, your concept of the OT versus the it right? In a different perspective.

And I actually think we need to take it one step further and we need to think about everything in terms of the benefits and risks to the business overall. So from a, you know, from a risk to the business, security is very, very important. But if you're developing an application that includes an LLM or an agent of some form or another, then the other, the safety aspects is also critical.

The classic case we all sort of hear about in the press is the AI agent that, uh, promised free flights to somebody when it should not have, right? And, and that's the safety aspect of it, is there's no, it wasn't a security issue. The user of the LLM didn't exploit it incorrectly, just the LLM gave the wrong answers.

But that's still a risk to the company, both a financial risk, a reputational risk, possibly compliance risk, all of those types of things. So as we make it easier, uh, for developers to include AI capabilities, particularly AI agents which have free reign to wander around through the, all the data of a company, safety and security become more and more of a concern as opposed to bare basic functionality and bugs, at least in my opinion. Here's my whole problem with the modernization storyline, and Mitch, correct me if I'm wrong here, but basically before ai, it was, uh, yeah, we're gonna come in and modernize your app, and here's these five really bright people that are gonna do it.

And then, you know, when the day came, the bus showed up and about 50 graduate students moved in for about a year or more and basically crashed your house. And now we're saying progress. It's great.

Those same students are gonna show up and they're only gonna stay for six months because of ai. It just doesn't sound very appealing. Tell me, Believe it or not, I was one of those graduate students showed up at a bank, we're gonna rewrite all your banking systems.

So we did. But it's pretty amazing. It, it's, it, it is a familiar model.

Maybe it is, maybe it's not, you know, 50 graduate students, maybe it's 10 of 'em, and you know, a season Kate or Jack or you or somebody, you know, directing that, that knows the domain. And that's what we're looking at. I mean, that's, that's, I think that's what people expect to happen.

It's not necessarily a great thing for people starting their career, but also I think there's a path for them too. It isn't just this, the, uh, indentured servant approach that, that I took through the consulting companies. There you go.

All right, folks, I'm gonna leave this one here. We will be at Cube Con, we'll be on the show floor, so come on by and say hello at the very least. And also, there's an article by Alan Shimmel over on the cloud native now talking about all the great things that are happening at Cube Con.

So you should check that out because, well, there's just a lot to do down in Atlanta, and we look forward to being there. And also by all means, if you can't make Q con or if you're just a glutton for the content, check out our little virtual event from last week. It's unavailable online, and we expect you to guys get a huge amount of content.

Mitch has a whole presentation there that's worth checking out for sure. And we'll be pack in a minute. You've earned it.

The spotlight, the responsibility, the weight of teams, companies, and entire industries fall on your shoulders. Lives depend on your decisions, your home life included, that work your are protected physically and digitally. Nothing gets through your team without a fight.

But in a globally connected world, everyone sees you, including those who mean to cause you and your organization harm. And now home your sanctuary attackers see an opportunity. Your digital front door is wide open.

And what compromises your home can breach your boardroom. Because the devil's greatest trick isn't targeting your workplace firewall. It's convincing you that your personal life isn't at risk.

Black cloak, digital executive protection, defending the new attack surface your personal life. Hey folks, we're back. I'm gonna have a little chat about cloud outages again, because now it's Microsoft's turn.

First it was AWS and then Microsoft had an outage. And maybe these things are just gonna become regular routines and we gotta figure out how to learn to live with all this stuff. But Kate, what's your take on what's going on here?

Is this just gonna be something that we have to live with because, well, these things are not too big to fail and they have some sort of single point of failure in 'em, and we just gonna randomly discover this from time to time. Well, so first, um, just to review the, there was an eight hour Azure outage this week, um, knockout services worldwide, which we all know. And as you said about AWS same thing.

What I continue to think about is I come to hate the word, and even being the cyber security person that I am in resilient. And I, and I've thought about why do I hate this word? So it just takes me back to the beginning of, um, you know, we used to talk about five nines.

If we were to think about building our cloud in a five, nine more from a redundancy framework mindset, I wonder if it would change, um, us away from the idea of resilience. And I, it sounds crazy, like we're talking about redundancy resilience, but I do think that if I think about five nines I notice in my life, typically I have a backup to a backup to a backup. And it seems to be across the board, it, it, it happens to me personally as well.

I'm like, oh, I have a backup and I have a backup. You know, that's the problem. When we, when we look at cloud, when we look at cloud, we, we don't think of redundancy.

I think we think as we program, oh, it's redundant because it's in the cloud, but it isn't. And we see that with, with both, you know, big cloud. And I know I've sort of gone off script here, but it's just this, you know, morning type of, uh, um, idea of what are we doing?

And when we think about resilience, we can't just think cloud, like cloud is our resilience. It isn't, we have to think of it from a redundancy perspective. We have to think if this, if, if east part goes down, you know, why do we not have it globally, um, in such a way that if one part of this goes down is it's gonna be somewhere else, we should be doing five nines and not think of this from a resilient perspective.

So that's my take. You Know, Kate, it kinda reminds me of CrowdStrike where pushing out a change, which is apparently some configuration change, is what caused this in the content distribution. Uh, the whole staging of rolling it out, right?

You know, push it all at once. I don't know how this was rolled out, but usually those are the, those are the circuit breakers, right? They'd like trip like, well, wait a minute, this didn't come up, or, you know, it worked fine at three, but now we've put on 30 and it's not working anymore.

So something in that, you know, it's, it's good to say we want it to be resilient. And also, of course, you know, back up and redundancy, but also sort of like, don't change everything. Don't paint your whole house until you've looked at what color you're gonna use, right?

I think Jack, to Kate's point, those extra nines in that five nine equation are frigging expensive. And I think people know that. And they, one of the reasons that things are not as resilient as they should be, as people don't wanna pay for it.

It's just, you know, the level of redundancy, the backup, the ability to switch networks on a dime is just get out all pricey. And people look at that and they go, well, you know, that's nice, but I'll take the risk. And if it goes down, you know, somebody will yell at me later, but I don't have the budget for five nine.

So how do we make this whole thing affordable? Well, I think I, I think that's actually the root cause and the reason we went to the cloud, and we've forgotten what our life was like before the cloud, is that maintaining five nines on our own infrastructure is very expensive, right? It's much more expensive than relying on the cloud service providers who are able to distribute that cost across their thousands or hundreds of thousands or millions of customers.

In the days before we had the cloud, or the cloud was so prevalent, all the services used to be down all the time. And there's this wonderful site, uh, down detector, and if you look at it, you can see who's up and who's down. And we don't talk about that anymore because for the most part, people don't go down.

This is a very, very rare situation, right? I mean, once the last time we've had a major outage like this, it's been a couple of years. So I think people lose a little bit of perspective and think about it at, when it goes down, a lot of services go down.

But on the other hand, how many of those services did maintain five nines or, or four nines, or even three nines or two nines, yeah, before then, right? There were a lot of services around that we relied on that were 95% uptime, not 99% uptime, and that would have be down for multiple outages over the course of a year. Um, so distributing that cost, you know, by the, through the cloud service providers, I think is how we ameliorated the, the issue.

But you can program for it to be distributed, right? Not to just show up in, you know, I mean, yes, you're right. And cost absolutely was a factor.

And I think though that, and one of the things that we saw with, um, CrowdStrike is that the cost becomes a human cost and it matters. We have to understand, especially as, um, AI becomes, you know, augmenting humans, that the cost is no longer a financial cost. It's actually human cost and this matters.

And so when we think about, you know, we have to think, the developers have to think that, um, the way that we distribute, um, across cloud and even having multi-cloud, it becomes important. And it, it's, is it not? I mean, is it that expensive?

I mean, I I honestly, it, you know, from a multi-cloud perspective, you know, is it that five nines? Yes, that was extremely expensive, but is multi-cloud expensive? I don't know.

I'm asking, I think Go ahead, Jim. I was, I I was gonna say it's, well, again, that's sort of, there's the human cost involved in that is architecting your environment to span across two different cloud service providers is actually fairly challenging, right? If, you know, there are many organizations that are multi-cloud, but they have, every single app is single cloud, right?

They just, right. They might have something in AWS and in Google and in Azure and in Oracle, and, and, and, and they're spread across all of that. But most applications are, um, monolithic across a single cloud because there's enough differences between the clouds and there's not a universal API and not a universal interfaces for this stuff.

So it is becomes very challenging to build an app, to make a single app resilient because it spans clouds. And the only other question, I'm sorry, that I would have then is when we used to architect for five nines or whatever, um, you know, we used to have, uh, data centers in different sites, especially in Florida, you know, being hit by hurricanes and et cetera. Why don't they just have like a, a backup ready to go, like IBM even used to offer that as a service, you know, like a, A hot spear.

Yeah, it's, I dunno. Yeah, I, I, well, my understanding is, uh, on, on these particular issues, the network routing, the, the, the network information was the cause of the failure. Mm-hmm.

So if you had another location you could switch to, it was dependent on being able to get the network information correctly, and because that part of it wasn't working, then you can't switch to whatever your yeah. Alternate site is, right? That's, that's a, that's at, you know, there's, it becomes very, very difficult to engineer out every single, single point of failure in the system.

Yeah. That's always the network guys fault. At the end of the day, I think that it's not the software developer system.

I didn't say that. I'll tell 'em all at network field day next this week. So yeah, that Mike, So, so Mitch, which is the better situation for an IT person, right?

So to Jack's point, right? Uh, so we had things on premise and they probably crash more often than they do in the cloud, but not everybody, you know, the employees knew it, but the whole world didn't know it. And now I have a cloud scenario where it doesn't crash as often, but when it does, the whole world knows it.

So which one do I want 'em have? Well, it's kinda like when the air traffic control system goes down and now every plane is, you know, trying to figure out how to get where they need to go. It's that level of an outage when you have a big outage.

Um, I, I can remember the day of pick your application, the invoice processing system's down again, it's down again fourth time today. They're trying to get it back up and figure out what's going on with it. You know, those days don't, those don't happen much to, to Jack's point, like, like they used to.

And I think it's 'cause we're architecting systems better, building a more redundancy, not relying as, as monolithic of code. But from a, from a, from my standpoint, I was happy to move it outta my own data center and put it in the cloud. Um, and part of it is I just to deploy networks in, in co-locations and in central offices and and service providers.

So I was pretty comfortable with it. But you know, the thought of, okay, the air conditioners, the chiller's got a problem. I do, I really wanna mess with that.

Is that what this was that what life is about? Is that what I got a CS degree for? Is the fricking chiller to keep, keep the computer room cold?

No. So, you know, it, I, to me, I think it's a blessing not to have it on site when you can do that. Um, doesn't mean there aren't pains moving up to the cloud too, but you have a lot more flexibility.

Um, you have less control, but you have a lot more flexibility of which you can do, Kate, is there a certain amount of comfort to be taken in the fact that when it does happen, it happens to everybody all at once and there's lots of misery to go around, I guess, uh, the adage, right? Misery loves company, so, uh, we'll go with that. We'll see how it goes.

Um, Jack, just one question here about the cost of all this stuff. I mean, do you think that it's that the providers haven't figured out a way to deliver that capability of five nines in a way that's cost effective? Or is it just that the IT people and the apps folks don't really want to pay for it, even though they haven't figured out that maybe the cost of downtime far exceeds the cost of that extra capability, especially for certain applications that are driving ing?

It's a little bit of both. I mean, but I'll go back to what Kate said in I think the previous segment about the human cost, right? And, and part of the challenge here is that we can build as much redundancy into a system as we want, and we can spend as much money as we want, but at some point, a human's gonna trip over a cable and knock out the power to everything.

And there's, that's really hard to avoid that, right? And so, you know, I think we're approaching the, the point of diminishing returns. We can spend infinitely large amounts of money to approach six nines or seven nines.

And the ROI of that investment is very, very small, if anything. And that's where we are today. I mean, as I, as I said, you know, there was a point where, and we forget now, but there was a point when failures were so common that we had custom failure pages that became memes.

Does everybody remember the Twitter fail whale, right? I mean, their failures, failures were so often that you had a, uh, a graphic that you designed specifically for your failure case. Nobody does that anymore.

So I think we're at the point where we've gotten, you know, we've, we've spent what we believe is the appropriate amount of money for the appropriate reliability and resiliency, you know, from a customer of those services perspective, what gets concerning is this is the third failure by fill in the blank. My, this vendor in the last 30 days or last 60 90 days. Oh, then I'm starting to get concerned, right?

What's going on here? Are they, do they have their act together, but the fact that they are rare, um, and aren't service affecting to what you run? Uh, this says, says that they do a pretty darn good job at it.

The only thing that I'd like to add is that, um, the AWS outage happened. It was an East coast outage, right? Mm-hmm.

And that should be, um, rectifiable, meaning, you know, not everyone should, like, if I had to develop, um, whatever, I wouldn't go to AWS East because the last two times it was AWS East, um, or make it multi-cloud. And that, I mean, there's, I think there's a checkbox if I'm wrong, that you can just, you know, multi-cloud that. And so that I think we're not blaming the network people.

So Mitch, you're gonna be off the hook and we're gonna be blaming the developers on that one. So Take it to GCP in Iowa. There you go.

There you go. I like it. Alright, I think we have some agreement here.

I think, you know, we need resiliency. It would be nice if it was cheaper, but right now it's a little bit expensive. So you gotta figure out whether it's worth it for your application.

And if it's not, suck it up buttercup. We'll be back in room. 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 Textron Group.

Hey folks, we're back in this next segment. I think personally I found it fascinating, but the bad guys have figured out how to avoid the takedown. So if, I don't know if you've been watching some of these things, but law enforcement officials around the world have been kind of taking down servers and in Elliot ness kind of fashion, they're short of actually having the cameras on hand, but they basically break into these warehouses and, you know, taking ax to the beer battles, beer barrels, and then they grab all the servers and the away they go and it makes for great theater.

But Jack turns out the bad guys are getting smart and using something called blockchain and ether riding. Please explain. Well, this has got to be the most diabolically evil case of hide in plain sight I've ever seen or heard of.

And, uh, the bad guys are basically using a feature of blockchain called con, uh, contracts, software contracts, where a blockchain is basically an immutable ledger. Everything that gets stored on the blockchain is incorruptible. You can't be modified, uh, except in very specific use cases, which we'll get into in a moment.

And everything is publicly, it can be seen and accessed publicly. And most importantly, the blockchain is distributed. It exists on millions of computers across the world.

So the law enforcement guys can't go in, crash the doors, grab the server, because that thing on the blockchain, that piece of data is replicated everywhere across the world. And so they'd have to subpoena and grab millions or billions of computers, which is just never gonna happen. Now what the bad guys are doing is they're taking advantage of something called a smart contract, which includes, uh, in it a data field or a set of data fields in that smart contract, the data fields in the contract itself can be modified through an API and the bad guys basically corrupt a machine.

And then once they have the initial compromise, they're able to go and fetch their code that exists in the data fields of the blockchain so they can modify that code and update it and change it as they want, and therefore use the blockchain as a distributed repository for their malware, which is really evil and is very, very hard to get rid of. And it is very hard to detect because they're not usually using the usual methods of command and control servers to get to this. Mm-hmm.

So Kate, do you think this will become kind of the standard setup for these guys? I think it's both. Uh, it's two North Korean groups that kind of pioneered this thing.

And, uh, but everybody else is gonna look up and go, well, thanks for the notes and Cribit and away they go. Right? Absolutely.

And from a cybersecurity perspective, and it's not just because, you know, Jack is right in front of my face, but I will say that this article that he wrote is pro, I would say is one of the most important articles, and I'm, you know, very serious here when it comes to, um, cybersecurity, um, moving forward. Like this is something cybersecurity people, um, architects, engineers really need to think about because this methodology moving forward is highlights, uh, this distributed architecture, which is gonna be very important for us moving, um, as we, um, as we grow. But absolutely 100% everything that, that Jack wrote in this article is a blueprint, um, on, on what's happening and what we need to do, um, and how do we start to, um, fight this specifically.

So great job, Jack, and really it's phenomenal. Mitch, what's your take on this from a DevSecOps perspective? Because, you know, as Jack noted in his article, they were targeting WordPress sites initially because, well, you know how great the security is of those WordPress sites.

So it seems like, you know, a natural distribution vehicle, Lockdown gold standard, that's for sure. Um, you, you know, in a way it's a supply chain attack, right? Just like, um, with SolarWinds attacking the, the build process and in the, in the software creation DevOps processes here, you're doing it in a payload that's going everywhere to, to Jack's point, it it is everywhere and you can't get rid of it.

Um, I, it you're usually in DevSecOps are thinking about application security oftentimes, but I think that's why I said supply chain, because now we're talking about something that we're relying on for other uses, you know, in this case, um, the blockchain to be the mutable ledger, uh, for whatever uses that it is crypto or whatever, um, and then it, it's getting hijacked, um, no pun intended, Jack, um, by the nation state guys in this case. So I don't, you're not gonna, you're not gonna solve this by scanning your code more often. This is a different kind of problem.

Um, and, and I think most software developers would say, I don't even know what you're talking about. I know, which mean using an API to get to something when it's, you know, when it's down I get, but you know, they're not blockchain experts. So it's, it's a, it's really a tricky problem.

I I'm not sure how we solve this, Jack, what are we supposed to do about all this? Well, the, the, I think there's sort of one silver lining here is that while the code repository that the bad guys are using, they're treating, essentially treating the blockchain as a code repository. And that is a distributed environment, but there is some centralization involved in their accessing and changing that repository.

So we, from a global perspective, a law enforcement or a, you know, people searching for the bad guys and what they're doing perspective, there is some hints that we can have to look at it from a how do we protect our environment from prevent from getting infected, um, you know, we need to start developing new concepts of what our, our attacker tactics, techniques and procedures TTPs are. And we need to start developing new rule sets and new heuristics to see when people are going to the blockchain and trying to understand what is legitimate activity from our say of corporate environment. How often do people go and access the blockchain and should they be accessing blockchain stuff?

And, uh, you know, and trying to see about that to detect when we've been compromised and how to, you know, defend against that. Basically you think we'll see some security, uh, enhanced around the API to get to that smart contract. That seems to me the only way to, you know, get getting it in there, you're not gonna prevent because people can do it on the blockchain themselves, but whether some process on your server is now accessing that API should it be and what's it using it for?

And no, I don't know what that is. So, you know, lock it out. I, I think we'll see that.

And we will also maybe, uh, if the people developing, you know, the, the blockchain owners, the Ethereums and the Bitcoin, you know, whoever it is, if they have some global moral concepts, then maybe they will start trying to figure out how they can detect bad people from using their environment. But a lot of those, you know, those environments, their whole concept is anonymity and privacy, and we don't care what happens on the blockchain is because it has legitimate uses as well as illegitimate uses. So it's, you know, that's the real challenge.

And, you know, it's, we have seen similar attempts at hiding activity, say, through DNS, where people have used DNS to exfiltrate data in a DNS query. And again, it's the, from a, a defender point of view, it's trying to figure out what does legitimate uses of this technology look like versus illegitimate uses, and how can we differentiate between the two? And this may be a case where AI can help us, I don't know.

But, you know, it's, it's becomes, you know, it's essentially, like I said, it's hiding in plain sight. So how do you differentiate the, the legitimate from the illegitimate is the challenge. I, and I think, you know, as a person who, you know, developed, you know, worked with, um, sox, you know, security operation centers, I would say, um, we could look at the chain telemetry, um, and feeding it into threat intel feeds.

So that would be one way that I would look at it. Uh, you know, just stuff Like 10:00 PM where's your blockchain been? Yeah.

All right folks, I think we're gonna leave this here. Um, I would just say to everybody, you know, I was sobering, happy Monday and that, uh, knowing feeling in the pit of your stomach is definitely not indigestion, but hopefully we'll get smart about all this and fix this sooner than later. Hey, I wanna thank everybody for sharing their knowledge and their insights today.

As usual, great show. Folks, I wanna thank you all for spending some time with us once again, and please stay tuned for the rest of the tech strong TV lineup, which is gonna be equally awesome, and we'll see all the mark. Hey everyone, it's Alan Shamo.

Welcome back here to Text Trunk tv. I'm happy to have my friend Tson Ziv Tson, co-founder and CEO of Ox Security here on Text Drug TV with us. Meetin, welcome back.

How are you? Great. It's a pleasure being here again, Always a pleasure to have you on.

So meets, look, not everyone watches every interview we do on text Drunk tv, believe it or not. But, uh, they may not have seen me talk with you before, though you've been on a number of times. For people who aren't familiar, why don't you give them a little bit about your background and how you came to found or co-found OX security?

Uh, sure. Uh, so about 15 years ago I joined, uh, checkpoint. Uh, and for about 10 years I led the cybersecurity business unit over there.

And it was a pleasure to see how big company and the super impressive companies growing from the inside. But then we started seeing the world is starting to move to code. And we asked ourself, okay, where is it going?

What's, what's next? How is it going to evolve? And we understood that the code is the essence of everything.

And we said, if we can find better ways to secure code, that would be an amazing future. So we tried different products in the market, we tried implementing Shift left, and I think we kind of got to the consensus that shift left is dead, it doesn't work. And this is how we started our journey saying, um, you know, it's, there's so many different opportunities to help other people, uh, protect themselves from software supply chain, from EC risk, from cloud risk across the board that are just risks and it needs to be easy for the developers.

Excellent. Well, that, that really was the problem with the devs sec, uh, shift left is it wasn't easy enough. It wasn't easy, easy enough for security people, let alone easy enough for developers and, and developers.

It's not that they wanna make insecure code, but you can't expect them to be security professionals either, right? They're, they're developers, they develop code, they're not security pros, but this is what led, of course, to the founding of OX Security, that's OX security and give us kind of a lowdown on OX security and what it does tsen. So think about OX as the platform that connects to your current environment, from code to build to cloud, to understanding your APIs, your data sources, your threat modeling, your runtime environment.

And from this goes back to the developer's environment and inside development environment, especially Vibe coding World is able to inject this as a dynamic context into the Vibe coding agent. So new code is actually written with security guardrails built into the code. So instead of thinking about it in the old way that we had like Waterfall and then we had to do quarterly scanning, and then we moved to CICD and it was a gate, and then we started automating Jira tickets, it's why are we creating those problems?

Let's give the right context to the vibe coding agent saying, Hey, this is going to be an API that is externally facing. Why don't we take this and make sure that we build a code in first place with those five protections? 'cause we already have the context.

We already know how to explain to a developer, why aren't we explaining it to a vibe coding agent that can take this and actually do this for you? And I think this is kind of the, the latest announcement that you've done with aox, which is what we call vibe sec Vibe security. I love it.

Vibe sec. But well, look, I remember sitting here on the set of Textron Gang the first time I heard Vibe coding and kinda laughing and thinking, oh, this, what kind of joke is this? It's no joke, right?

It's real. Yeah. It's like Q2 2025 right now.

It's like, Mm-hmm. But yeah, imagine that. Right?

And here we are going into Q4, but so Vibe sec Now, vibe SEC is to prevent vibe, code vulnerabilities, right? To bring better vibe, better quality vibe code, let's call it that. Is that fair?

I Think it, it, it is fair. I'm saying that there are two, actually two different kind of problems. One is new code generated, and of course it has its own vari.

It's like, okay, I'm using VI coding, there's a lot of drift. How do I make sure that my security, um, I would say restriction right now are actually being kept in the code and nobody's removing them. Simple questions.

Other questions? Yes, I understand this is going to be super important. When do I need to implement, uh, rate limit?

When do I need to implement, uh, flags to make sure that I'm protecting from CSRF? When do I need to to make sure that I'm protecting myself against, uh, for example, parameter injection? All of those come into play by understanding the broader system and injecting them.

That's absolutely fair. The second thing is you already have a lot of backlog. Some of those things are getting very close to the SLA saying, Hey, there's a high issue here.

We already agree that needs to be fixed within 30 days. How do we interact with the developer and make it easy for them saying, Hey, you're getting to this SLA in, in 24 hours. Would you like me to fix it for you?

So you won't be on the exception list. And with a simple yes, since we already had the, uh, agenda remediation for a few quarters, we just integrated in saying, why don't you just bring everything to the developer in an easy way, just, do you want to fix it? Yes.

Done. And instead of making the developer upec practitioners we're saying, no, no, that's, we, we've tried it for 15 years. Shift left, failed us, right and left.

The only way to go is simply going back to the vibe coding and saying, Hey, do this for us. We're a new age in an AI age. We don't need to do the shift or lift and shift like we used to do.

We can do it smarter in modern ways. Vibe sec. That's what we we're calling it.

Vibe sec. Hey, I love it. I I love that you, you kind of went out there and branded it.

Um, so needs in the, i I guess the question becomes who's responsible for making sure this is indeed working right? That the code is in fact secure, that these vulnerabilities never get generated? Is, is this like something the developer now gets to do?

So it, what you're really telling me is maybe you took a second bite at the Apple or shift left and maybe we'll get it right this time. Or is it No, we still, we get it. The developer's not a security person, but with, with Vibe Sec and, and the security team, we can, we can, you know, in essence, head this off at the pass before the developer gets him, you know, has to do it himself.

Uh, I think that the answer is that even though it's not a very, I would say nobody likes to say it out loud, developers don't feel accountable for security. Yes, they do it because they're forced to. Yes, if you implement enough culture and incentives and guild and, and you, you build around, you will get corporation.

But it was always security's accountability to make it happen. Now, we invented a few models in the industry like shared responsibility. Now for me, whenever I'm hearing shared responsibility, I'm, I'm hearing it's like, okay, if something goes wrong, who's the person that I'm blaming?

And somehow it's security. So security is accountable, it's developers are responsible. And while collaboration is probably the ultimate goal to make it happen, and you need the developers security need to create the culture, the rhythm, the agreements, the alignment.

It's up to them to make it happen. And in this new world, we're saying, Hey, if we don't need the developer not in a bad sense, in the sense that we don't need to bother them with that, we can actually tell them, Hey, this is kind of what we need to do in order to pass security instead of bothering them. I think it's a way better way for everybody to, to enjoy this benefit.

And if we're getting it out of environments like Cursor and co-pilot and, and cloud cloud, we should definitely take advantage of this to make sure that we're, we are delivering the best and the be and the most secure products out there. I agree with you. I agree with you.

Um, so look, our audience is a little of this, a little of that. We've got a, a lot of cybersecurity people we've got, but we also have a lot of developers. We have a lot of cloud native engineers, DevOps engineers, uh, platform engineers.

Where does this, where do you, where do you put this, right? Who, you know, who, who's responsible for getting this rolled out and getting it out there? I think that, uh, 95% of the time it's the application security team or the product security team.

These are the guys that are accountable to make it happen. It's always the CSO organization, even though we've seen developer teams that are trying to implement this, it's one of those program that unless you've got ongoing support and tracking and monitoring, end, end, end, end, end, uh, you're, you're constantly be accommodating backlog. So somebody needs to be accountable.

It's not something that you can do just as you go and swing it. You, you kind of need to have an accountable person saying, I understand the products we're really seeing have access to our data. It has access to our customers.

We need to protect them. Usually at this point you have somebody saying, I'm accountable for product security. Fair enough, fair enough.

Um, a lot of people are, uh, what I'm trying to think of a, a, uh, a, a de a delicate way of saying this, but a lot of people are falling out of love with the whole AI, vape, vibe, coding thing, let's say, right? Where you know, it, it's, you know, in recent study we saw 90% of developers are using AI to generate code. 40% of them don't trust it.

Two thirds of them, almost 65% say it, it, it, it, uh, injects instability into the code, but yet 90% of them are using it, right? So 90% use it, and that means a good chunk of that 90% think that it injects instability in code. It it, they don't trust it, but they yet they're using it.

What does that mean? What does that mean for Vibe Sec? Is, is that a reason why we need Vibe Sec, or what, what do you, what's behind that?

I, I think it's, it's a very good question because the answer is basically changing on a daily basis. We are in a place that moves so fast with so many alternatives, and the models themselves change so fast. The the IDs change so fast, meaning cursor, every few days you, you'll see an update.

Yeah. And you're using, uh, right now Cox, CLI and you're using Claude, meaning, it, it, you are still experimenting. We are still in the bleeding edge right now of this revolution.

So if you're asking me, do I trust this? No, I do not trust this. Do I use it?

Of course I use it. What do you mean? Like, if, if I'm not using this right now, I will find it very hard to do my job without AI and, and saying, how come it, it doesn't make any sense.

Like you don't trust it and it, it's become, yes, you are right now in the traditional, um, trust, but verify in the sense that I will write something, I need to read it, I actually need to verify it and I need to do small changes. And everybody knows that if you've got this long dash, then it means it's written by eyes. So yeah, you kind of need to edit afterwards.

So there are a lot of things that you need to understand and you need to understand how to work with this new technology. It's not just, oh, I'm going to this technology and it'll be fine. You need to change yourself in order to be better with this technology.

It's like, uh, when we, we started having Google like back in a few good years ago, um, you need to learn how to search things. It's not that you're just saying, I just want to search for it. It's like, you need to search, I need to add this word and that word.

The same thing goes with ai. You need to understand context and what does it mean? And this is kind of the fine line between getting the ultimate answer and getting and hallucination not enough data.

You'll fall to this edge. You, you'll provide enough data, you're going to get amazing results. So it's an ongoing process that I think that is accelerating super fast.

Agreed. Agreed. You know what, we, we certainly live in a very interesting time right now where we're gonna see how these things all play out, unfortunately, need somewhere we're almost out of time for people who want to, uh, learn more about Vibes SEC and what OX is offering with it.

Where, what's the best place for them to go. So we are organizing an online conference, uh, called Vibes SEC Con on the 4th of November. Uh, I think we got, wow, a few good thousands of participants already.

Um, so I was go over there. We're going to have a lot of collaborators, a lot of people telling us from the CSO perspective, from the EC perspective, from the dev perspective, from the research perspective, it's like, where are we going now? When we are thinking about it, it's, we used to have like a yearly conference on something, but at the pace of the, of the current evolution of those products, every quarter you kind of look backwards and say, oh my God, we didn't understand anything last quarter.

We kind of need to rewrite the playbook. So we understand that this is just, uh, step number one, and we're going to continue and do this as a, as a public resource for everybody. Excellent.

That's November 4th. It's a virtual event or in person? Virtual.

Yes, it's a virtual event. We're gonna have a physical event in q1. Yeah.

Are you gonna do a physical event in Q1? We Are going to do it in Q1, uh, probably very adjacent to RSA. Oh, so maybe the end of March, Maybe.

Um, it's still not locked. Right? You'll let us know.

Of course. We'll be at RSA, you know, we put on our DevSecOps event the Monday of RSA week in, in Moscone with them. But then we're live all week on, uh, silicon, uh, not silicon alley, our broadcast alley, uh, video.

So we'd love to cover it if you do it there. Let me go back to November 4th. On November 4th, virtual event.

Vibe sec Con. Is there a website or uur l we could send People? Yeah, it's Vibe SEC io.

Well, on OX website is OX Security io OX security. Yes. Ox Security.

That was it. Exactly. And you could get, and they could get to it from there.

Exactly. Perfect. Neat Sun as always.

It's great seeing you. Thank you very much. Keep the great work.

We'll be watching the development of Vibes. Sec. Pleasure seeing you.

All righty. Bye-bye. Bye-bye.

Neat. Sun Ziv here, co-founder, CEO of OX Security. We're gonna take a break.

We'll be back in a minute. Hey, everyone, welcome back here to Techstrong tv. My next guest is Bji Raghavan.

Bji is Head of Engineering a Postman, and let's welcome him. Welcome Bji to Text Drug tv. Thank you, Alan.

It's great to be on Text Drunk. Thank you. It's nice to have you here.

So, BJI, head of Engineering, talk to me what, you know, how did, how did you wind up? I mean, I'm not sure, is that at C-level position at Postman? Is it how, give us your, your journey to how you became head of engineering here and what that means.

I can go a long way back when I was actually in, like, in know, aiming to be an academician and then ended up with, uh, Google coming for an interview on our campus, dropping out of PhD, joining Google in its early days. So I spent a good amount of time growing with Google. So like, you know, I started with, uh, when, back in 20 2004 on the Gmail team, when Gmail was newly launched and then helped grow it to billion active users along with it, like rebuilding a lot of the systems, recognizing the importance of like, you know, what microservices means, why it is actually important to design those APIs, right?

Et cetera. After that, uh, have also done a startup in, you know, search, which I sold eventually to Lyft and worked as the head of, uh, ride share engineering at Lyft for a little while. And then from there, uh, went to another startup in the conversational AI space named Unifor as their head of engineering as a C-level, CTO, uh, grew their AI charter, uh, charter in the last three and a half years.

And, uh, before I realized that like, you know, a lot of these SaaS companies were pivoting towards agent AI platforms, I realized that like, you know, the platforms really didn't exist at all. And to build those mature platforms, you had to start at the basic layer, which is the APIs, and then start building the layers above it. That's when I had a conversation with, uh, our CEO Abena at Postman and started discussing has, he looked at like, you know, MCP and he was very excited at the time about MCP, and I realized that like, you know, postman could have come up, come out with an even better protocol than MCP given its proximity to APIs.

So that conversation then, like, you know, went into me taking this role of head of engineering at Postman, and I've been here now for six months. Wow. What a great story.

Mm-hmm. That, that's interesting how, how, you know, it transitioned into a role of postman. And it's funny you mentioned MCP with API, because, you know, when the whole agent AI thing started hitting, I had questions about, so kinda what's the difference between API calls and, and Agen AI task?

You know, I get it. There's the autonomy or, you know, autonomous nature of it, the ability to string together multiples kind of task. And then of course the MCP, it's crazy.

The MCPI really, I think it was December it was first announced January, here we are nine, 10 months. And you would think it's been around, it is the, you know, it's the standard. Everyone's using MCP now, even though there might be security issues and other things, but in any event, it, it's, it's become the defacto standard.

In the meantime, a majority of the traffic on the internet are API to API communication. That's Right. Do you see a future where these things kind of merge?

I do see a future where like, you know, uh, systems will have the choice to either like, you know, go with like a higher predictable outcome versus like, you know, potentially ambiguous paths that need to be deciphered automatically. Like, you know, a quick changing landscape, especially like, you know, would benefit from, uh, AI agents. Like, you know, looking at a small percentage of like, you know, requests and recognizing that there's a change in pattern and like starting to operate with that.

And, uh, while there are like, you know, traditional systems that require pretty much like, you know, predictable outcomes over there, like, you know, AI has nothing, no, uh, no, no business. So those will continue to actually operate with like, you know, predictable journeys. One of my friends once told me like, you know, distributed systems, you know, you don't need to bring in a distributed system if you don't need to, but like, you know, if something has to scale better and you are not able to make it scale without a distributed system, that's when you actually like squeeze in and distribute system.

So AI has to have the same solution. You don't put AI everywhere where like in our traditional systems don't scale, they don't actually operate with the expectations of the business. That's where AI basically can be a leverage, It seems.

So, it sounds so commonsensical coming from you right outta your mouth. I just wish people would take that to heart. 'cause it seems like we're trying to stick AI everywhere and anywhere I, at Postman, like that's why when we do tooling, we are actually enabling tooling with both like, you know, understanding of the API, which is like the ground truth, and then AI to have like better visibility into the API, so that like, you know, you have better documentation, better details in the SDK to be able to use that a API better.

So making LLMs like not have the knowledge necessarily about the backend system, but like, you know, decipher it is a key component of like, you know, actually making agent workflows work better and not put like, you know, all that knowledge into the model itself. And a lot of businesses like, you know, have nuanced business logic that, uh, only their internal systems have visibility to. They can't actually embed it into the models.

So more and more of that logic has to move towards the API, not towards the model. Agreed. So I do think agreed, like, you know, as a result, like this, uh, relationship between the models and the APIs will continue to kind of grow.

A lot of people are looking at the low hanging fruit where the model has the knowledge, but like for mature systems, you need both maturity of like APIs and models to evolve. So that is where, like, you know, postman, ad postman, I'm pretty excited about continuing to operate with that, like, you know, uh, mindset and enabling developers to have both, like, you know, access to both tooling for predictable journeys as well as for AI journeys. Love it.

Ji if you, if it's okay, I'd like to turn to Postman itself. I had a lot, I think a lot of people, most people in our audience have heard of Postman. They've made a tremendous impact over the last, you know, five to seven years.

But if for people out there, maybe they've got someone out there said, geez, I don't know that I've never heard of them. How would you describe Postman to them? Uh, description of Postman, I would say it's like a, a end-to-end API platform, which enables like, you know, two things for the developer and like three things for an enterprise.

The two things that it enables for a developer are, um, collaboration and automation. So when you take your APIs, making sure like, you know, any braking changes is validated through monitoring, et cetera, et cetera, like, you know, all of those things can be embedded in and automated into your CICD pipelines before it hits production. So Postman provides a comprehensive tool for tooling for being able to enable that in addition to it for an enterprise.

The third vector it provides is governance. So that like, you know, any use of your APIs, any, uh, evolution of your APIs, any breaking changes in your APIs, you have governance on and are able to build, like, you know, visibility into it as well as reactionary, uh, solutions on top of it. I love it.

Now among around here at Techstrong, you know, we've been covering Postman as pretty much also seven years, maybe longer than nine years, but we always cover their state of API report, which has become something of a standard in, in, uh, in terms of a, a good, a good peek into a good kind of, uh, judge of, of where we are in this API economy, right? And API adoptions and so forth. Postman recently released its seventh annual state of the API report, 5,700 some odd developers, architects, and executives, you know, taking place.

And I think that was just this year's. Um, give us the headline first. I guess Balaji would, what do you think the big takeaway is there?

Uh, the big takeaway for, uh, me personally is that like, you know, a, people continue to struggle with APIs and while a lot of people are talking about agents and AI journeys, like, you know, the actual API evolution itself has not happened to enable many of those agent journeys. So when I look at like, you know, just, uh, statistically looking at number of people who are aware of like, you know, CPS and are designing towards like, you know, so AI solutions versus like the actual adoption of MCP, like, less than 10% of active developers have, uh, you know, actually used MCP in their, in, in their workflows, which is a astonishing number because like, you know, if you look at like, the number of posts about like, you know, technology at this point, I feel like, you know, I read 80% about agent and MCP when in fact only 10% is adopted. But yet when you look at it, Hey, it's only been around for nine, 10 months, 11 months, 10 percent's pretty good.

But I think, I think what's happened is, is the, the AI adoption hype cycle has gotten so overheated that we just think everybody's doing this. Everybody's using MPC, everybody's developing or managing agents. Everyone of course uses generative, you know, and, and it bears up, you know, we see, we see other, uh, metrics surveys.

90% of developers are using ai, 40% don't trust it. 65% thinks it, they thinks that it introduces instability into the software base, the code base, but yet 90% use it. So the whole thing is kind of cockeyed, if you will, right?

The whole thing's kind of upside down. Um, but that's interesting. 10, 10%, yep.

In 11 months, there's nothing, nothing to, to sneeze at. What else were some of the key findings, do you think? I mean, the other key finding, I actually, uh, I mean, being new to Postman, this is not new for Postman, but new for me, my personally, is the fact that like, you know, uh, I know that like, you know, a majority of their teams that are collaborating with like, you know, APIs and microservices tend to be under 10, 10, uh, engineers.

And so that like, you know, wasn't the astonishing number, which is like 84% of our, of, uh, overall teams are less than 10 people. What was astonishing to me is, uh, despite like, you know, so many, uh, teams being under 10, uh, several of these teams still have collaboration challenges with regards to their, like, you know, microservices and a PS. So, uh, when, when you look at like raw numbers and like, you know, we did the survey to understand what are the collaboration challenges they're running into about 55% of the developers were struggling with, uh, just documentation around those APIs.

And, uh, you know, about 34, 30 5% of them were struggling with discovering APIs that are already present within their organization. So, like, you know, despite having several tools available in the market to actually like, solve many of these problems, including our own API platform, which solves most of these prob problems, I continue to see like in our small teams, medium sized teams actually struggling to actually to utilize these tools very well. So I think that that is a key insight which enables me to write, like, think about like, how do I make this problem completely go away, and like if I can design better for that, like, you know, identify what, what is missing for people to be able to kind of like, you know, solve this with Postman, we will continue to invest in that direction and like, you know, bridge this gap.

It's a huge opportunity because like, you know, first of all, like, APIs have existed for a while, but like, you know, APIs have always been deci designed for human consumption, not for machine consumption. And so APIs by definition are going to change over the next year, two years, uh, to be more machine consumable and like, you know, during that period, we have to solve not only for human, uh, like, you know, discovery of APIs, but also for machine discovery of APIs. So it gives us an opportunity to bridge this gap in the right way to design the right product in that space.

And, uh, I'm pretty excited about that. Absolutely. I got a couple questions on that for you.

When you say teams, you, you could have multiple small teams within a larger organization. com here, right? com and others.

You know, there is that the Spotify squad sort of, you know, 10, 12 members, the, the Amazon two pizza team. So that, that seems like the, the right size for a team of engineers, right? Absolutely.

It seems like a manageable size. Um, what's interesting is even in teams of that small size communication, 'cause I would've guessed, well maybe because everyone is remote and we have, you know, remote issues. I'm on a different time zone.

I'm in India, I'm in Europe, I'm in California, I need asynchronous communication versus synchronous, you know, maybe that, but that doesn't seem to be what the issue is. Yep. Very interesting there.

Um, and both of those were kind of counterintuitive too. Like you wouldn't, you wouldn't necessarily think that. What else did you find interesting in the report?

I mean, the positive thing that I actually was pretty excited about is, um, the fact that like, you know, when you look at, um, uh, the percentage of, uh, developers who are actually, uh, utilizing an a p first development approach, like and I, that is continuing to increase, it's about 25% right now. And, uh, several others are like, you know, partially API first. So that number is continuing to increase over time.

So that's a very promising number. The second part that was exciting for me is also the fact that 70% of those, uh, API first developers said that Postman helps them collaborate, collaborate with other developers, and, uh, the same population, 55% of them said that like Postman also enables them to collaborate with non-developers. So from that perspective, like, you know, the ones that are using our tooling already, it it is clear that like, you know, we are building the right journeys for them.

The ones that are not using our tooling and like, you know, continue to struggle with API collaboration, those are the audience that like, you know, I'm, I'm looking forward to actually like getting more in front of and having discussions on like how postman can be actually helpful for them to continue on that path. Excellent. Um, on, on that front, look, I, I think we both agree that we're gonna see more and more code being developed, being written or gen written is the wrong word, generated by ai, right?

The Hip. Do you think the AI generated code is going to make the AP, like incorporate the APIs and API calls into that? Or do you think that will maybe, so is, so is AI generated code gonna result in us using more APIs, the same amount of APIs or less APIs?

I, I do believe AI generated code will require more because like, you know, there are already solutions being proposed because of like the explosion of number of tools and the tool selection process in like the MCP protocol itself, uh, that like, you know, companies are recommending rather than directly using the tools, uh, to actually generate code to in, to invoke the tools and the like, generation of code require, like, you know, will require execution through APIs, so calling APIs. So that's why, I mean, like, you know, I do believe that even like, you know, an optimized solution for an agent journey started with like, you know, this assumption that LLMs will be able to directly interface with these services to then recognizing that like, you know, there is, it's a distributed system problem where you will end up with like too many services to call and you have to pick the right ones, and you have limited context to do so. So better way to solve that problem is to actually generate the code that can execute and like, you know, call into those a subset of those particular APIs.

So that does gimme confidence that like, you know, I will see continued investment in every company, you know, building more mature APIs so that LLMs are, have less ambiguity in how to use those APIs. Okay. Excellent.

Bola, you're, we're probably a little over time already. These 15 minutes goes quickly for people who want to get a, uh, download and maybe dive into this report themselves, maybe even look at previous reports. Where could I, I, I imagine they could go to the Postman's site.

What's the URL and where can they find this report within the site? I, when you just search in Google as well for state of the A API report, postman, you will always find it. Okay.

com/state of API state dash of dash API slash 2 20 25. Perfect. Hey, Balaji, first of all, congratulations on the role of Postman and I think congratulations, you're in order to Postman for getting someone of your quality on board here, uh, heading up engineering, looking for great things going forward.

You welcome back anytime you'd like, man. Appreciate it a lot, Alan, it was great meeting you. Appreciate you Alrightyy.

Bji Raghavan, head of engineering a Postman here on Text drunk tv. Go check out their seventh annual state of API report. As Balaji said, Google it, ai it, go to the website, whatever.

Just go get it. We're gonna take a break on text Drunk tv, we'll be back in a little bit. Hey guys, thanks for the throw.

We're here with Rachel Nus, chief Enterprise Platform Officer for Trend Micro, and we're having a chat about AI and maybe how it will help the defenders a little bit more than just the adversaries, because we might be able to maybe see how these attack patterns are developing. Rachel, welcome to show, Welcome to have, thank you for having me here. No worries, no worries.

Um, so explain, I think we're all kind of obsessed these days with what the bad guys might be doing with ai, but is there a, a future where we might be able to say, level the playing field thanks to ai because we can see what they're up to and react to it faster than they can do it? Yeah, so, uh, I think, I think AI is really changing a lot of things and, uh, um, it's not just, uh, you know, changing our cyber defense strategies, it's also helping changing a little bit, you know, like, uh, the, uh, the attackers part. Uh, so, um, what we see is, um, what we see is, uh, so, um, like cybersecurity, LLM it is kind of evolving from, you know, the passive tools and into, uh, very active participants, um, in the threat defense.

And right now, for example, you know, a lot of, most of the l lms, uh, used for summarization, enrichment and automation. Uh, but the next frontier, what we see is the predictive modeling and the, for example, like trend micro. And we are training our, um, our models to recognize not just the, you know, non threat patterns, but the behavioral, uh, signals that indicate intent.

And, uh, recently we also have, uh, some of our innovations like digital twin initiatives. This is also major step forward, and it also allow us to simulate, you know, enterprise environment. And, but you know, with that said, and LLN is also helping attackers, which we see recently, we looking at our detections and, uh, you know, in the backend we see, um, a lot of threats coming from in a very productive way.

And the amount and quality is also totally different. And so, uh, we do see that, uh, uh, this is also helping redefining about a lot of attacker behaviors. So this is the interesting timing, Mike.

So if I understand what you just said is a combination of not just all these gen AI models, but it's also advances in the predictive models that enable us to kind of see the patterns that the bad guys are using, even though the volume of those attacks seems to be increasing exponentially. Is that a fair assessment? Yeah, this is fair because, uh, based on our email security detections and recently we see, you know, um, this is like, um, this is like amount of the email detections become so large and huge then, uh, much, much bigger than before.

And in the past we don't see this amount of threat. And of course, this is also related to different geolocations. They have different dynamic.

And the other thing that we see is not just, you know, the quantity, it's also about the quality. And, um, you know, um, there's one very efficient attack, which is like the social efficient, you know, social related email phishing. And in the past attackers they need to take time to analyze, um, all the, you know, social related, you know, uh, context related to the person or related to the organization and related to the asset.

And today with ai it's so easy to connect the dots and get all the context. For example, AI is just so easy to get, you know, even external intelligence as well, what you are talking about in linking and what you are, you know, posting Facebook and also internally and what, what is the ongoing, you know, information is flowing and so they can jump in it with the right context. And, um, the right context is kind of, you know, the fraud context to our customers.

Hmm. How quickly will all this be happening? Because right now when it seems to happen is folks will get a bunch of data and they'll get an analyst in the SOC who will go looking through that and kind of try to discern some patterns and maybe apply some policies, but it's usually well after the fact, are we moving more towards a scenario where policies will be instantly applied and then we'll analyze it later to see what it was really all about?

'cause the machines are gonna run faster than we humans can keep up with. Yeah. So, um, I think I would say this is moving very fast and, uh, let's say the, the pace of AI innovation is generally fast and, um, super, super fast that, you know, comparing to before.

And the defenders, um, need to be, just need to be very agile. And the key is to, you know, embed AI into the operational fabric of the cybersecurity. So not just as a void on a tool, but as a core capability.

So, um, like, uh, what we are doing, uh, to micro is, uh, we are doing it this, uh, across multiple layers. And for example, AI helps us tri the alerts signals across hybrid environments, surface, uh, very high confidence threats in real time. But it's not just about, you know, automation, it's also about intelligence.

AI can help defenders understand why behind and alert and, um, not just the what. It's, that's the game changer. And we are also like investing in some, um, you know, self explainable AI so teams can trust and also act on AI driven insights.

And so the, the whole goal for defenders like us is, you know, using AI as a trust, trusted partner and, uh, one that can enhance human adjustment and, uh, accelerate response and reduce fatigue. And, uh, defenders don't need more data. They need smarter data.

And that's where, you know, AI shines, and for the attackers part and ai, whatever I say in the defenders, attackers are also smart. They can also utilize AI to help them, you know, get better data, get better intelligence. So this is a really, uh, interesting time is, uh, we need to know how to utilize AI as our partner to work for Defend and, um, continue defending, you know, uh, with the attackers cyber attacks with ai.

Mm-hmm. And to your point about multiple layers, I'm assuming that we'll also see AI agents in that mix, and they will be consuming, uh, output from both predictive models and from generative AI models and causal models and all kinds of fun stuff that's out there. But how will all that get orchestrated?

Where will the intelligence be that kinda enables me to talk to the agents and have them go do something in a way that is, shall we say, cohesive and comprehensive? Yeah, so, uh, for the, I think this is about AI agent agents and also about the agent ai. And, um, there will be a lot of AI agents in the world and in different organizations, and because people say, Hey, you know, yesterday we only work with human, and tomorrow we work with AI agents and the human.

So it's, it's also the, you know, the industry evolvement. And so a lot of people, they are building their a agenda AI system, and that can act automatically and that can also incredibly, you know, powerful. Um, but they also introduce new risk.

And this, for example, these, you know, AI agents or you know, agent AI system, they can make decisions, they can take actions, they can even interact with other agents, which means their attack service is dynamic and also and often, you know, uh, unpredictable. Yeah. So to safeguard them and organizations need to rethink, uh, traditional security models.

Um, for example, we need to apply, uh, thrive modeling to AI agents just like we would for any other critical assets. And, um, we also can start to using some of the, you know, digital twin is not just the physical digital twin. It could be cybersecurity, digital twins, to simulate how these agents behave and their stress and their attack.

And also in very complex environments. And all of these agents, you need to have a orchestration, you know, layer to make sure every agent they are running, you know, built fully together and coming up with, you know, uh, one mission and to be completed. And sometimes by one agent, sometimes by multiple agents.

That's why a lot of PE people, they put, um, orchestrator agent on top of all of these AI agents. This is really based on your need. And so, um, I think, uh, AI agent is there and, uh, even actual micro, you know, uh, a lot of our organizations, not just the technical team, they started to build their AI agent.

They also build their orchestration layer on top of these AI agents to make sure, you know, all of these AI agents can, you know, be, behave, uh, can action, and, but of course always think about the risk. And this is also new risk coming from AI agent, even coming from the MCP servers as well. And those AI agents will need to talk to, not just each other in the sense that they belong to Trend Micro, but third parties as well, I'm assuming.

So can we get to a model that kind of looks like this, where there may be some predictive analytics that tells me that, uh, there's a wave of a attacks coming that are aimed at this particular vulnerability, and then I can pass that on to an agent from the app dev or IT ops people who will then go fix that before it hits. And that's kind of the closed loop that we're trying to get to. Yeah, that's a great question.

So, um, yeah, agent is not just the, you know, trend micro thing. This is entire ecosystem and I think that's also why there's MCP coming up and this is like building, you know, the new protocol to connect all of these world. Yeah, this is this, this is also something that I talked with the team, uh, who is doing, you know, the API, um, integration in the past.

I say, Hey, this is the new world in the past, the traditional way it's API integration. Now it's all about, you know, MCP as the new protocol and how to collaborate with all the AI agents. And so this is the whole ecosystem.

It's not just the TRA micro thing. And TRA Micro could have our AI agent to perform different things. For example, we have our AI agent to digest the logs and also, you know, analyze, analyze logs and which is part of our genetic SIM features.

And we use AI agent to do the auto coding and behind the scene so we can support so many third party logs and ecosystems, these data just getting in. And this also means that whenever we achieve anything, we need to think about ecosystem. That's also, you know, we know customers environment, a lot of time, customer environment, they have 50 tools, some customer has 100 tools, and all of these tools coming together that could help our customers.

So I do think, you know, uh, no matter what AI agent we build at Micro and uh, it's also we need to make sure everything is e ecosystem friendly and also ecosystem fit. Alright. What's your best advice then to folks about how to get ready for all of this?

I think everybody's kind of getting the general idea that there's gonna be AI agents, they need to be orchestrated and we're kind of have a new way of managing it and security. But what should they be doing today to get ready for that now? Yeah, so I can give, I will try micro example.

Yeah. For example, this is nothing related to security, but of course we'd want everything to be secure. Yeah.

So this is about, let's say, you know, what we are doing today, Atmic, we have half of our code is generated from AI and a lot of AI agents behind the scene. And we deliver, we build our product software and we deliver this software to our customers. And so we actually have a lot of different AI agents today and we have AI agents sitting in the developer side.

We have AI agents sitting in product manager side, we have AI agents sitting in the marketing side. We even have AI agents to provide intelligence for our sales seller. So this is the entire ecosystem.

I'll give you one example is for example, if I understand this is the customer problem, I use my AI agent, my product manager, AI agent, to generate the requirement. And also furthermore, is the, another AI agent will help me generate the mockup, the UX mockup, how we will solve the problem. And also furthermore, we can generate an MVP product for our customers to do.

The quick validation, which I feel we still need a lot of developers involved today, is if we want to build, you know, you know, thorough and, uh, comprehensive, you know, production environment, we, today we need developers in, I, I think I can imagine the future. It'll also be, you know, uh, quite improvement, uh, have a lot of improvement as well. But these are all how AI agents is changing us.

And even our HR can build their robot today and build some robot and looking at all the resumes. And in the past they have thousands of resumes coming in and now AI agent help them to filter out. So I feel for everyone, this is also my advice to my team members.

Every single, you know, person, employee, yeah, needs to start to build your AI agent to make sure you know, you know how to work with your AI agent because that productivity is like, you know, um, um, phenomenally, you know, like changed. And also, you know, one of amazing things I really like AI is in the past, if we want to be a domain expert, it takes time. You need so many years to learn this domain.

You need to learn so many years to learn this domain. And now AI kind of lowered this bar. For example, I see some financial report, AI help me understand what's the context.

I see this kind of you another domain. AI helps me understand that this domain so easily. And also the interesting thing is AI is also can correlating all the different domain knowledge and tell me what's going on.

So that also reduced a lot of time and effort. So for everyone, I will really encourage everyone start to have your AI agent start to think about, you know, how you can utilize AI to make a better you. So that's my advice.

All right, I like that idea. Make ourselves a better you. But coming back to security, I think the important thing to remember is an ounce of prevention is still worth a pound of cure.

And in ai, we need to do that now in real time. Hey Rachel, thanks for being on the show. Thank you.

All right, and back to you guys in the studio. Hey everyone. We're back here at Qualys Rock on continuing day two afternoon coverage.

Our next guest is also with Qualys, a product manager. Um, I'm sorry, one second. A new ca Kapil.

Kapil. Yes. A new, I remember interviewing a new last year at, uh, Qualis Rock Island.

Wasn't it? Was Qualys security Conference Yes. In San Diego last year.

Yes. But it's been a full year. It's been a full year.

What you've been doing over the year? Well, we have been building the industry's First Rock for all our customer base. It's the first in, uh, risk operation center.

And since I work in policy audit, I have been working on how you can operationalize rock from day one, leveraging policy audit. We also did a launch of policy audit. It used to be called Policy Compliance before, and this year we rebranded and relaunched with a new lot more new capabilities that helps customers to be audit ready and that's why policy audit.

Got it. Um, let's talk a little bit about compliance and rock, right? 'cause at first, at first blush, they don't really necessarily go together, right?

I'm, I'm looking at my risk compliance is almost a separate reporting thing, right? The GRC and, and all of that. But they're connected.

They're, they are connected. Let's talk about that connection and how ROCK is helping people with their compliance. Yeah, so compliance and executive reporting is the seventh pillar.

That is the seventh Chevron of Rock and compliance is no longer just a check box. You know, you assist your compliance and prove it to auditors one time. But now most of the evolving frameworks, they have a check that you need to be continuously assessing, and it should be risk-based assessment and compliance.

When it comes to compliance, it should always be proactive rather than reactive, that you are acting when there is a risk combined. So how policy Auditor compliance helps is it helps you assist with the unified asset inventory pillar of Rock, where it, uh, proactively finds out all the technologies that have been running in your default on default locations, helps you to prioritize and for response, provides the remediation capabilities to fix your failed controls. And with the executive compliance based reporting, you can provide those reports to auditors.

And like I said in my chart, misconfigurations are like the leading cause of security breaches. And at the same time, audit failures have a re root cause that is related to missing evidence. And both of them have the same root cause.

That is a policy that is on paper, but not in practice. And whether it's the risk of audit failure or risk of misconfiguration, both can be prevented if you implement your rock from day one with policy audit. That's how we, we connect policy, audit or compliance piece to the rock day.

Sure, sure. You know, when we look at compliance, there's talk and then there's compliance. Yes.

It, it looks like what we're seeing is a lot of compliance coming out of states, you know, California, Illinois, what have you, and then of course the European Union has compliance. Mm-hmm. And then there's sort of non-government complaints, PCI four.

Oh yes. Right. A good example from the, uh, payment card industry.

How does, for the people out here who do this for a living, right? How do you stay on top? Well, I spoke to a lot of customers yesterday and I was really surprised that there are still a lot of them doing manual processes.

They Do, I think most too. I mean, that's commendable. If they're putting so much hours efforts, there's always chance of failures.

And now with more and more evolving requirements mandates, it's not like a one time audit a year. If you're a big enterprise, you have five to seven audits. And if you're doing it manually, everything is critical.

That means you are on a constant fire drill, continuous audit mode, and you don't even have visibility on what you're fixing. What is the end result? You are just scanning for compliance producing these reports.

So, uh, how policy audit helps is it gives you a audit readiness score from day one. So you don't have to wait for your mandates to come or evolve. 0.

We do the mapping for, uh, for our customers. We automatically map the new requirements to compliance objectives to the reporting. So they can just rely on the tool to automatically update the reports.

They can go into the system generate audit readiness report and see where they stand today. They don't have to slog for months and months of spreadsheet and they don't even know the end result. That is scary.

And at the same time, they're not even managing the risk of misconfigurations that comes from compliance, which is as per the Verizon report, one of the leading cause of security breaches. And it can be prevented if you have your checks and policies in place. Love it.

Um, you haven't mentioned AI very much though, and AI has really been a big change this year. Yes. How does that play into Compliance Rock and everything else?

So Quality ETM platform is moving toward agent to AI yesterday. We showcase that we are now launching our own agent marketplace. There's a AI agent that is Agent Chang for audit readiness and reporting.

That's, you can assign autonomous task with it, just ask it to create your risk prioritization plan or ask to onboard assets or detect technologies. It can do all those task autonomously for you. So you don't have to do, you can just schedule those tasks.

You can directly talk to the agent, you can even create your own agents. That's how we are leveraging it across the platform to uplift it for customers so they don't have to do these reporting and they, the team can spend time on other tasks. Excellent.

Anu, thank you for coming on and getting us up to speed. What else can you share with the audience that you think they'd be interested in? Yeah.

Uh, so I'm very excited to talk about ETM audit. That's our vision. Okay.

Um, so Mitch showcased in his demo yesterday, a little bit of preview through agent and I showcased it in my demo today. ETM audit is on top of ETM, which we're going to build as the vision for ETM and how policy audit helps you with technical control, audit readiness to be audit ready, prevent the risk of your misconfiguration and audit failures. We are uplifting it on ETM, where we already have customers, connectors, third party data coming in, Quas data coming in, and we are going to provide audit readiness for customers for both of their technical as well as procedural controls automatically.

2 itself. You might have a control that ask, do you have patch in place? Do you have vulnerability scan results?

Do you have cloud scan results? Now whether you have third party tools or connectors, we will automatically map that using AI and generate the evidences and reporting for customers. Love it.

But love it. That's really exciting. Thank you.

You know what? I hope to see you next year. We'll continue this conversation, but in the meantime, keep doing what you're doing.

You're obviously doing a good job. Thank you. Thank you.

Nice seeing you. Hey, we're here live at Houston's, uh, Qualys Rock Con. We're gonna be back, we've got a few more interviews coming your way.

You're watching Textron tv. Hey everyone, it's Alan Shimel and we're back here at Qualys Rock on in Houston, of course, rock On is risk operations, uh, conference. And we're here to talk a little risk operations with y'all.

Let me introduce you to Shalesh. Yeah, You got it right. All right.

If you've watched our prior coverage of prior Qualys conferences, like the Quas Security Conference, QSC, you've seen Sheesh talk with us before. But sheesh, most people probably, if they did, they don't remember. Tell us about you, your position at Qualys, a little bit of your journey coming here.

Yeah, absolutely. Thanks so much for having me again. It's always a pleasure to talk with you and your audience so quickly.

Shelly Charle, I look at the products, go to market strategy and now solution architect team for Qualys. My job is essentially to make sure that what I'm hearing from customers is translated as product capabilities and then see to it that our teams are working with customers in making these capabilities map to their use cases and they're successful. Absolutely.

You know, Shilesh, we've done a lot of interviews today and a lot of it obviously around managing risk and risk operations. One of the areas I wanted to you to expand on was this is more than security, right? This is about more than security.

Part of this whole reason to do this is to map the risk and, and the, I I don't wanna just take it to dollars and cents Yeah. But to wrap, to to map the dollars and cents Yeah. Of this risk Yeah.

To business operations and how, not just security remediation, better vulnerability management, et cetera, how not just security, but all kind of business operations Yeah. Plays into this risk, right. And risk management.

Yes. So talk, if you don't mind, talk a little bit about, you know, mapping that. Yeah, absolutely.

I, I think one of the parts what, uh, risk Operation Center does is trying to move the conversation away. Like Sumit talked about it from how many vulnerabilities do I have or how many patches do I have or do have I implemented MFA, et cetera, to actually what is the impact of me having less number of vulnerability on business operations and the business value. Now, how we are looking at doing that is essentially seeing that, you know, one on one side of the spectrum, like you talked about it, that there are business operatives or executives, they wanna see everything from what's my dollar value, what's my business impact, how much I'm spending on cyber insurance and what is impacting them.

Now, what impacts them is a simple checklist, is my patch management policy effective or not? Is my ransomware prevention working or not? Is my permission management working well or not?

Now, what we are doing bottoms up with our security audience is to not get overwhelmed with this dollar value and all these policies, we are bubbling up the contributing factors of this true risk, such as if you have, let's say 10% of ransomware vulnerability, then look like Mr. Customer, you could be in your cohort of lower 50% of customer base. That would mean when we compare all of these cohort of insurance policies and the breaches related records look like there is a 10% chance of you getting a material breach.

And that means your patch management or vulnerability risk management process is of lower maturity. So that's why your truist needs to come in, in 200 to 300 range so that all of these upstream systems will provide the result to your executives how both of our improvements would result into me having lesser chance of a breach, lesser chance of me losing money. So that's how we are trying to tie the cyber risk and exposures to the higher level dollar value and its impact.

That was the best, uh, explanation we've had today. So you wouldn't apply straight that one. You know, that That's one chance of looking into products and actually owning that area.

Yeah. Good for you. Um, you know, Sumit and his keynote today mentioned the phrase that I left, actually, I spit my coffee outta my mouth, but I told him I'm gonna steal it and use her.

And that is this, uh, dashboard tourism. Yes. Right.

Or dashboard terrorism even too. Um, you know, and that is, everybody has their own unique view on a dashboard, right? Yeah.

And so whether you're on the security team, the executive team, the dev dev team, the ops team, the DevOps team, right? We're all, we're all looking at different views of the same underlying data. Yeah.

And, and I think it becomes like, uh, it's almost like a tower Babel where we all talk a different language. Yeah. And I don't understand what you talk about, but your people do it.

My people understand what I talk about, but not what you talk about. And you know, I think part of the, of the mission for for Rock Yeah. Is to make sure we're all talking a similar language.

Yes. An understandable language, right? Break down the silos that exist.

Yeah. Even in security, there's so many silos, let alone once you go outside of security. Yes.

Talk about that mission. Yeah. That, that's interesting Alan, you said that at the end of the day, I, I know there was, was really well put by Sume, you know, as, as an interesting witty command.

But at the end of the day, if, if you see the psyche behind the dashboard is also about why am I creating it? 'cause if I don't create it and track it, there's something I'm gonna lose. But that's something is very, very me-centric or my team centric or my org chart centric.

If you have to see even the dashboard, what we are trying to say is how can you actually see the dashboard which whole of your company cares about, whole of your organization cares about? And that's where I think what you are trying to say also, what is the common language, right? Which is set by your whole of your company and though the dollar value and the business impact is generally used as common language, that's still nuances, right?

Like the public sector might not care as much as for the dollar value. What do they care about? What's the risk to my mission statement?

And I was meeting with one of the, one of the really high profile customer in dc what they care about is my mission statement is I need to manage the risk to my agents who are in the field. 'cause that's, there's no dollar value which can be assigned to their safety. So now how we look at it, okay, if, if you wanna manage the risk and reduce that risk to your agents in the field, what are the contributing factors which make this as a risk?

So now how we help these bottoms up approaches of the security analyst, let's bubble up those dashboards. Let's see to it how your dashboard now maps their company's dashboard and can we actually create one unified way to track it down? And that could be, you know, from your dashboard, how well your company's mission statement, your business value is tracked.

So that's how we are looking at, you know, creating a bridge from me-centric dashboard to whole company centric dashboard. So all of us talk the same language essentially. Got it.

Excellent. Let me bring up another. Sure.

Okay. So with this whole rocking Qualys has sort of been, some people say eating your own dog food, some people say drinking your own champagne, whatever you wanna call it, but Qualys themselves has been, have been using it and it's helped in the, uh, Qualys enterprise tru risk kind of management. You know, they've been learning lessons internally as the bottom line here.

Can you talk a little bit about that? Yeah, great. Great question.

Actually it's, it's a two part answer if I may. Uh, so Rock is obviously a program and now program includes your people, technologies and tools and your processes around it. So Qualys is transforming its own platform to be the world's first risk operation, center driven capability or the product which would help customers tie all the chevrons in the risk operation center together.

So how can we get best asset inventory, which would become the base of your rock? How can you now get all these exposures together, which are typically used by the 70 plus What I'm hearing, Alan, like customers typically use 70 plus security products. That's what I hear too.

Yeah. They all generate their own exposure. So how do we actually bring them together?

How do they then correlate your threat feed business context so that we talk the same language so that we are able to actually prioritize the risk which matters to business and then try and reduce it and produce that report as an evidence, as an outcome to our compliance auditors. Now, as all of these chevrons, we are trying to actually cater using the ETM as a product where all these capabilities will come together, where our true risk algorithm will work on all of these data indicators. We created true risk, eliminate capability to help customers reduce the risk.

How now that would come together to help customers reduce the risks. And now at the end of the day, we are not saying that you just call this product. Well the ETM, you can just connect your other products as well.

If you like your, my, i, I don't know, maybe your SCCM product to reduce your risk, it's okay. Like just create a job from ETM in your product to reduce your risk. That's from the product side.

What we are creating now, like drinking the own champagne part, as you all know, call this is the biggest FedRAMP authorized platform. Um, probably number fifth in overall IT and security spectrum. So we have our big FedRAMP audit as well as our security teams.

They all need to do, guess what? They have to all cater to each of these Chevrons in own manner. We used to use our own inventory differently.

We used to use Qualys for assessment, we used to use another tool for reporting, et cetera. As we are combining all of these data points required for say, key elements of FedRAMP, what are the key elements of FedRAMP? We need access control related requirements, vulnerability management requirements.

Now all of these are getting unified signals to go into their audit reports. So this is what being the outcome of our ETM. So every time, you know, customer comes in, in our data center, if you actually go in sometime Alan Niche, we should take you to our data center sometime to show you that.

I'd Love it. Where is it? So it's in two places.

One is in us, the other one is in India where our teams actually have three types of monitoring. One is your noc, which is network operations, right? On the right hand side we have soc, which is security operations and the right in the center, which now sits a rock, which is a risk operations center.

Excellent. I, you know, I may take you up on that. Alright, well you we'll go from there.

Siresh, we're about outta time. These are only 15 minutes. I appreciate you as always coming on here.

You know, I always, I I tell you the truth, I always listen to you talk. This is maybe the third time we've died and I say he's the guy who gets it right. He, I, I am sure SIRS is leaning on him for a lot of these things and you have a great handle on this.

Thank you so much. Thanks for all having me. Really always.

Appreci good. You and your team. Thank you.

Absolutely. We're live, we're in Houston. We still got I think one or two more interviews.

Two more interviews today. So stay tuned. We'll be back on in just a moment.

You're watching Textron tv. Hey folks, we're at Atlassian Europe and we're talking with Tiffany Tow, who's executive vice president for platforms and enterprise and we're having a little chat about cloud and ai. Tiffany, welcome to show.

Thanks so much for having me Mike. My Pleasure. Um, you guys have announced that you're gonna end the life Atlassian data center, which probably doesn't come as much as a surprise to folks because you've been pushing folks towards the cloud for a while.

But, um, why now? What's the transition that you're trying to achieve and well, how far are people making that migration anyway? 'cause you've been at it for a few years.

Great question, Mike. And you're exactly right. It did not come as a surprise to any of our customers.

We've been investing so much in our cloud platform the last seven years. Um, and as folks hopefully saw in the keynote so many new things in terms of AI and all the collections and the system of work deliver all this new business value for customers. Um, but why now?

A big part of it is as we talk to our customers, many of them have been migrating to cloud. Uh, 99% of our customers have some bit of footprint already in cloud. But what we hear from some of them is that sometimes there can be inertia in their organizations, right?

Many of them have had data center for 10, 15 years. And so being able to make a clear timeline for them that says, this is when March, 2029, it's time to be off of data center and into the cloud platform, enables these teams to start planning right backward from that timeline within their companies and start to build a business case because quite frankly, they're not migrating from, uh, JIRA data center to Jira Cloud. They're moving from kind of traditional behind the firewall, siloed, uh, products that work very well and have scaled, but into a cloud platform.

And that's what it's all about when it comes to ai, right? Every customer that I talk to is so excited about bringing AI to all of their workflows, but to do that, it's gonna be leveraging cloud technologies. It's gonna be leveling how these systems are built out on the cloud.

And so for many of these customers having that balance of new value by real rebuilding their workflows with AI in the cloud, and then also having new deployment models in the cloud to support even the most regulated industry customers. Um, we've announced that we have support not just for, uh, high levels of security with Atlassian Guard on top of our commercial cloud, but we now have our gov cloud for our US government customers that has FedRAMP certifications soon to be IL five as well. Uh, but we announced isolated cloud earlier this year.

And so isolated cloud gives you, um, a dedicated tenant. You have isolated, um, uh, compute storage and networking. And so that's a great environment for some of our regulated industry customers, and we'll support that, not just in the US but all of our data residency regions.

So mm-hmm. So in effect, I get a private data center is just on somebody else's infrastructure. Correct.

Um, what's been the reception to that concept among folks who do have those requirements for compliance stuff? Are they willing to do that? Because a lot of them seem to, sometimes they wanna hug their servers and they're like, I own my infrastructure, but, you know, psychologically speaking, that may not as be as, uh, compelling as an issue if I have a private cloud, right?

Mm-hmm. No, you're right. And, and I think that's also another reason why it's been great to actually put this announcement for a send out, because we can start to have these conversations with these customers.

Um, what we're hearing has been really positive. I think initially we had, uh, a very small set of customers in the US that we thought were gonna be going on to isolated cloud, but once the announcement came out, we've been hearing a lot more demand for it, and not just here in the us, but, you know, obviously we're here in Barcelona at the Team AMEA conference. Um, we've had a lot of impromptu meetings these this week from customers here that are excited about looking at an isolated cloud environment for them.

So yes, there's gonna be a, you know, change management is, is always hard as, as you alluded to. Um, but I think the signal we're getting from customers is that the excitement to rebuild all this with AI in the cloud and a clear timeline enables them to start putting plans together. So that point, does AI not force the issue?

Because ultimately I have all these models, I need to expose them to data, and the more data I expose to them, the smarter the models get, that all lends itself to the cloud. Because if all my data's sitting in some isolated data center somewhere, I'm really not gonna be able to do that as efficiently. You're exactly right, Mike.

Um, for, uh, customers, a lot of what we discussed with them is, look, everyone is using, uh, AI on the consumer side, and that's all one uniform data set, right? It's everything on the web is the data set that feeds chat, GPT. But when you think about harnessing the power of AI for your company, how are you gonna expose all of that data?

And oftentimes that data doesn't come from one vendor. You know, they have products from Atlassian, they have products from Microsoft, maybe they have products from ServiceNow, Salesforce. And so being able to provide that rich context to customers is gonna require a lot of interoperability between these platforms, and that's gonna be done best in the cloud, right?

And you, you see that right now with, um, a lot of the conversations around MCP model, context protocol, how the agents are gonna access this data, how the agents are gonna work together. So you're spot on. Any customer that wants to bring AI agents into their workforce is going to have to be able to build some sort of platform strategy that connects this data together.

Um, and that's why we've built the teamwork graph. Um, hopefully you've heard a little bit about that. The teamwork graph, as I understand it, is the, the thing that maintains the context and discovery and the relationships between all the various components that are in the cloud or in the SaaS applications, but not just your applications, third party applications as well.

So, um, a lot of folks probably don't know what a graph is, but explain, yeah. Um, a graph is really important because it's about the relationships between the data, right? You can have all of the data sitting there in buckets, but if you don't have, uh, an understanding of how that data is related to each other, what kind of insights can you draw?

What kind of insights can an agent draw? What kind of context can you give it? And so the teamwork graph was born from, um, kind of pre all this AI stuff, but at Atlassian, customers were asking us to help them get more insights from the data that was coming into the system.

And like you said, not just from, you know, Atlassian's products, JIRA, confluence, JIRA service management, but they often are using a pretty rich set of developer tools, right? And other functions, Salesforce, et cetera, bringing in data. Mm-hmm.

And so as we started to look at the relationships between that data, we saw that we could be quite opinionated about it because the way teams work, uh, is usually modeled in a specific way. Development teams have certain objects that they're using, whether it's, you know, repos, right, code, et cetera. Uh, teams work around goals that they're setting for themselves.

They're managing projects in Jira. So all these data objects have relationships together and context. And so we started to invest in making that bigger and bigger.

And you, you saw in the keynote, we've got now billions of relationships now between all those objects. And so what that means is think of it as a very unique fingerprint of your company. And so what that means is when you log into our systems and you make a search query, or you initiate some task, it knows Mike, it knows what projects you've been working on, it knows what team you're on, it knows what your team is working on.

And so it doesn't just look at the structured data to answer these questions, it's actually using the teamwork graph to provide context for the query. Um, and now it has memory, as you probably saw in the keynote, right? And so it makes your agents smarter and smarter about the way you work, but also the way you work with others in the company.

And that's the really hard bit, right? It's like there's personal productivity and there's team productivity, and those are at very different levels. And I think the teamwork graph, um, is really exciting because we're starting to see not just, obviously our own teams build experiences on top of it, but we announced, um, today that we're opening it up.

And so that means people can extend and add their own custom objects into it. They can pull from the graph and build their own applications off of it. So we really see it being kind of an, an exciting piece of, uh, making AI really valuable, um, for customers.

And that Goes back to what you were talking about with context and my personal preferences, and everybody has a slightly different way of working. Does the AI agent in that context become, um, my primary engagement partner? Mm-hmm.

Or am I managing a hundred agents that all have different kinds of memory and different kinds of experience? How do I kind of marshal this small army of AI agents? What's that gonna look like?

That's a great question. And I feel like, uh, the whole agent strategy and what that workflow is gonna look like has been evolving so fast the last six months, right? I think initially it was, Ooh, everyone's gonna have an agent.

You know, Mike's gonna have his personal agent. And then it became, well, no, he's gonna have hundreds of agents and they're all gonna do lots of stuff. And then it became, okay, well, every company's gonna have thousands of agents.

How are we gonna manage this? Right? What we've been hearing from customers is they want simplification.

You don't, you want to not have to think about managing a whole set of agents. So we're trying to provide a good amount of flexibility right now because we recognize customers are gonna try lots of different things. And across the wide range of use cases we're seeing, there's probably not a one size fits all.

Um, but we believe what's really important is the skills that you're endowing those agents with. So part of what we announced today is, um, a really large library of several hundred skills that an agent can have. So you could choose to build one Uber agent for Mike that has all the skills.

It can do a bunch of admin tasks for you. It could do your core work, it could do personal work, it could do all sorts of things, or maybe you don't like that, and you'd prefer to have very separate siloed agents. So we wanna give you that flexibility to be able to do, um, the model that you'd like.

So I think there's gonna be a lot that shapes o up over the next, um, six months year. But what's exciting for us is we're seeing customers customize, uh, tens of thousands of agents and give those agents the ability to, uh, go and actually initiate workflows in our system. We're seeing millions of workflow automations being triggered by agents already.

So, uh, we believe that probably Atlassian right now is probably one of the largest AI workflow, um, generated platforms. Mm-hmm. To bring this full circle, a lot of folks who have their own data centers will be concerned that their data doesn't wind up training an AI model.

So how does Atlassian kind of protect everybody's data or isolate that data from all the other AI models and agents that customers might be using in the cloud? That's a really important question. I get a lot from our customers.

So the models that we use right now today, we work with OpenAI, we also work with Meta and have their models. We do not share any customer data with those model providers. So the teamwork craft data that we're using to provide that structured context, it's only used when you're querying.

And so it's providing that grounding so that you can get the right response back, but we're not sharing any of that data directly, um, with the model providers. And it's also isolated, uh, per customer, right? So each teamwork graph instance, right, that we're training is for that particular customer.

So, um, it's a really important question that I know customers, and if they wanna see the architecture diagram, we've got a lot on the website as well that kind of goes through exactly what, um, the life cycle of that data goes through. So, uh, All right. Hey, folks, you heard it here.

You're going to the cloud and there's gonna be a lot more functionality and a lot more features and things you never imagined you could do. So better do it sooner than later. Tiffany, thanks for being on the Show.

Thanks so much, Mike. All Right, we'll be back in a minute. Hey, everybody, we're back at Atlassian Europe, and we're talking to my good friend Andrew here, who's the customer, CTO for the Atlassian Williams F1 racing team.

Andrew, welcome to show. Hey, Mike, thanks for having me. How did this whole relationship between Atlassian and Williams come about?

And, and, and, and why Atlassian and how did you guys like decide that Williams was the team to be? Yeah, so, um, earlier this year we signed on as a title partner and technology partner for, uh, Williams Racing. Uh, and initially we, we were having a look at many teams and, um, it was clear that Williams had a great culture.

They were, um, on the, a similar journey to, uh, to the top. Uh, we felt like we could support them in getting there, uh, and they really felt like teamwork and technology was gonna be the key to help them get back to the top of the grid. And when you're looking for better teamwork, who do you come to, I suppose?

So what were they using before they found you guys, and what have you done as the technology partner to upgrade their environment? Yeah, so, uh, if you look at the history of Williams racing, they haven't really invested too much in technology, uh, in terms of knowledge worker technology, uh, over the past 10 years. Uh, and so they were using a variety of, of different tools.

Uh, however, if you look at the different software, the different collections from Atlassian, uh, we are leaders in, in every market that we play in. Uh, and so we came in and we had a look at, um, how are they working? What kind of products are they using?

How could we help? Uh, and so we've started rolling out our teamwork collection there, uh, and they're, uh, Williams are really seeing a massive uplift, uh, as a result of that. Yeah.

So are they wor, are the engineers working differently now together? I mean, you know, gimme an example of what they're doing that they probably weren't doing before, or should have been doing before. Yeah, I mean, uh, a good example is what happens at the track.

Um, so a lot of people dunno that when a Formula One team turns up to a track, uh, they have a garage. When you see it on tv, it looks great. It says Atlassian everywhere, lots of shiny cupboards, two beautiful cars inside.

Um, but the reality is when a team first turns up there, it's an empty concrete box. They, they start off by painting the floors. So that's the level of work that needs to go into it.

And a lot of people don't think about what does it take to get all those things there and set it up. Uh, and one of the, one of the things that they were doing we're tracking basically in a notes app, all the tasks that had to be done to set up a garage. Uh, and as a part of that, there are incidents and things that go wrong, uh, that they also need to keep track of.

So rather than using a a Notes app for that, which, uh, wasn't really giving them a lot of insights about repeat issues and, and ways they can improve, we transitioned them onto Jira. Uh, where now we have a repeat, uh, uh, repeatable cycle. Uh, the tasks are assigned to people when something goes wrong, they're able to, uh, log it as an incident, talk about what's happened, uh, and that way after the race, they're able to go back and see how they can improve and how do they avoid those things from happening again.

Uh, an extension of that actually is they can ask Rover at the end of the day, how was the setup today in Singapore? Uh, and Rover will give a report about what's been done, what's outstanding, uh, how many incidents happened, uh, which really helps, uh, in terms of continuous improvement, How big is the team and is it the same team that goes to every one of these cities where the race is At? Yeah, a lot of people don't really think about the size of Formula One team, and they're surprised when I say there's about 1,100 people who work at Atlasian Williams Racing.

Uh, I don't remember the exact number of people who traveled to a race, but I think it's like 80 people go to a race. Uh, and so it's not always the same 80 people who go every week to different races, but, uh, they have different teams. So for the, for example, the Garage team that I spoke about earlier, uh, they have, I believe, an A and a B team.

Uh, so they're setting up two different tracks at the same time. Yeah. So how is the team doing from your perspective?

Yeah, they're doing great. I mean, it's been six months since we, uh, started working and we're already seeing massive improvements, uh, in the way that they work. Uh, we've reduced how many meetings they're having.

Uh, we've been unlocking knowledge between the different teams, uh, at a, at the, at the race team, uh, predominantly using Confluence and Rvo. Uh, they're seeing great benefits from using Loom. Um, that was one way of cutting down meetings, but also recording meetings, uh, which gives you a nice summary with nice actions, uh, automated as a result of that, uh, is also paying some big dividends for them.

Um, are the engineers discovering anything or they, they didn't know before? Or are they finding duplicate efforts or anything like that? Yeah, I mean, if you look at any company, they, they're problems that happen, uh, in any company where you have people working on the same thing or the same thing in different ways.

Uh, I think it comes down to a few things. It comes to prioritization and to, um, visibility across what people are doing in different teams. If we, if we talk about prioritization for a second, um, their, their top level goal is to improve lap time.

Now, the thing about Formula One teams is they have a cost cap. And so nearly all the people they hire are trying to contribute to reducing lap time. Uh, and so then it becomes hard to prioritize because everything is contributing to the overall goal.

Uh, and so what they've been able to do using JPD is define what is value for them, uh, what does it mean to reduce lap time. They put all of their ideas in one place with all of their data that supports that idea. They can track how much effort something will take and the impact they think it's going to have.

And it becomes a really nice way for them to prioritize what's important for them to work on right now, versus something that we can work on a little bit later on. I would imagine that they're also trying to prioritize their own efforts, but a lot of the knowledge you seem to be capturing used to be, you know, what we call wear between somebody's ears. So have they kind of figured out that they can now maybe, um, you know, if somebody leaves the team, it's not as catastrophic an event because there's, um, the tribal knowledge is captured.

Yeah, absolutely. I mean, um, as a part of the design of the car and when they're, when they're doing their aerodynamics, uh, a lot of the information was captured in places where it was only accessible to one or two people or, or a very small group of people, uh, which is problematic when, um, that's the very beginning of a process. 'cause that that information, uh, results in the design, which ends up in the wind tunnel, which eventually ends up as a part of a car.

So there are many people who need to contribute to, um, that process. And so having the very beginning of that process locked away, uh, doesn't enable a nice collaboration flow, uh, throughout that value stream. So now that it's being captured in Confluence, it's indexed by ro, uh, and people are able, are able to surface the right information at the right time throughout the, uh, the end-to-end process.

And the thing that's different about all this with the AI is that, as least as I understand it, it used to be somebody would stand around with like a clipboard and then capture data and then type it in somewhere that nobody else could access it. Um, now it seems like the AI agent is actually capturing all that data and then sharing it with the team. So I'm not sitting there doing a lot of data entry.

Yeah, I mean, so we, with the Atlassian platform, the, the most powerful thing is actually the teamwork graph. So people don't really have to go too far out of their way to put information somewhere. We try and connect all the different elements into the teamwork graph so teams can put the information where it works for them, uh, and, and it'll still be accessible through the platform and through rvo.

Yeah, because I think half the battle we've seen with any application is nobody actually wants to spend time putting the data in there, which kind of defeats the purpose. So, um, are we gonna get the value out of the software investments that we've been making all these years in ways that we never could before? I think there's a different way to think about things now.

Uh, I've been speaking to a lot of customers at this conference, uh, about standardization and why they wanna standardize the way teams work. If you think about what a why people wanna standardize is so that information is stored in a consistent way in a, in a place that people can find it and digest it easily. But teams don't want that.

Teams wanna work in a way that works for them in a way that supports them to go faster and get to their outcomes faster. The beauty of teamwork graph and robo means teams are able to work in a way that goes faster for them, maybe with minimal standardization, uh, but other people in the company can still find that information without knowing exactly where to look and in an expected format. Uh, and so now we, we kind of solve that problem around standardization and, uh, limiting the way that teams work through the use of rvo and the team of graph.

Are they consolidating the number of tools they have? At least I know in my job, my issue isn't necessarily that I don't have a tool. It's more like I got too many of them and I can't quite figure out how to make them all work together.

Yeah, I mean, obviously, uh, they're huge advocates of the Atlassian platform. Uh, and so it's more around enterprise architecture and what products should we use for different things. Uh, and so they are centralizing on Atlassian.

Alright. Um, are they playing around with AI agents? Are they gonna build their own, or what are you guys thinking?

Yeah, they've built, uh, they've built many different Rover agents. Uh, we had a session this morning where, uh, Richard Slaughter from a WR spoke about, uh, a wind tunnel tapping agent that he built. So he had a lot of knowledge in his head, actually.

He used to be an aerodynamicist. And, uh, he's captured all that information in the platform and built his own rover agent so that he can reduce the number of questions he's being asked, uh, about this particular thing. And people are going to the agent now, he's actually been tracking how many people are hitting the agent, and he counts that as a benefit to him.

'cause all those people would've come to him in the past. Yeah, You hit on an interesting point, right? 'cause there are people who are specialists and they have a lot of knowledge, but I might argue they spend half their time just answering questions from the rest of the organization rather than doing what their real day job is.

So will that change the way we think about general purpose workers versus specialists? And, um, the way we might even organize our companies? I I think about it in, um, this concept of low value collaboration and high value collaboration.

So low value collaboration is something similar to what you described, where you have someone with deep expertise, people contact that person to extract information that's low value for the person who has the information, even if it's high value for the other person. So overall, that collaboration is low value. 'cause only one party gets, uh, gets benefit from it.

High value collaboration is, uh, what I think is being enabled through ai, which is, um, they can go to an agent, they can get the information they need, then if they need to work together on something, both parties will get information because, but get value, uh, because the person who was originally asking the the question has enough information to have an informed conversation rather than asking basic questions. Yeah. So at the end of the day, um, am I gonna get more work done or am I just gonna have less stress in my work life, per se?

Uh, I think about it in terms of value, right? Like if we think about the person who is answering questions, that's low value for them. If they're an expert in something, you want them spending as much time as they can working on whatever's, whatever's their area of expertise.

Uh, so I think by uh, introducing ai, we're able to free up that person's time to spend more time probably on the thing they like doing rather than answering questions. If that reduces stress or not, I don't know, depends on the individual. Is Williams trying to figure out, you know, how much of a productivity boost they're seeing?

Or are they just kind of accepting the fact that everybody seems to be working more cohesively and with less toil, and that's the benefit in its own right? Yeah, Productivity. Productivity is an interesting one.

Uh, academics have been trying to measure productivity for decades unsuccessfully. Um, but absolutely we're looking at how can we be more efficient? Uh, so where is there time wastage, uh, in the things that they're trying to do, and how do we reduce that?

And that shows up in different ways. Like it shows up in number of meetings or effective meetings, uh, you know, how many emails are being sent, things like that. Uh, where we often see efficiency traps, um, is showing up.

Yeah. So you've been working with them for a while. What's the one thing that you know, kind of surprised you to discover?

Actually, their culture is very similar to the Atlassian culture, where, uh, people are very supportive. Everybody who works there really loves their job. Uh, they're all happy to be there and, uh, they're teams who want to collaborate.

Uh, and so for me, it's an absolute pleasure to be able to enable them to do what they already want to do. All right, folks, you heard in here at Atlassian Williams is a winning team. And when they actually win the next trophy, we'll see.

Hey, thanks for coming by. Thanks a lot. All right.

Hello everybody, and thank you for attending my DevOps experience session. I'm gonna talk a little bit today about DevOps and the secure software development framework. I know I call 'em allies for security or opposing forces.

I'm not quite sure. I kind of think that the first one's true. So what we're gonna cover, um, we're gonna talk about a little bit about the secure software development framework.

However, this is not a, a session that really educates you on it. So if you have, if you haven't learned about it, take your time and go read about it. Um, because for many DevOps teams, the secure software development framework can feel a little bit more like, uh, you know, being chained or breaks on your speed and agility, but I don't think it has to be.

So we're gonna explore in this session whether DevOps and this, the secure software development framework or SSDF or allies or forces in Intentioned, and I think they are a little both. So the challenge here, you know, what is the problem I'm talking about today? And, you know, over the course of time, all of you have heard this more than once.

DevOps makes you go faster. It emphasizes speed, speed, automation, and agility. But if we think about what those things mean, it means delivering new innovation faster to our end users.

But at the same time of delivering this better product and doing it faster, we also have to be more secure. Um, and the secure software development framework is really a prescriptive, uh, a document that emphasizes prescriptive controls, very specific tasks, um, and documentation to keep the software we're delivering safe. So tensions can arise when security feels like, uh, it's really not helping, it's just a slow down.

Now, I have to, I have to tell you that, uh, at the Open Source summit back in, um, in, in Denver, in, I believe it was in June, I held a kind of an open discussion on this topic. And not everybody was that excited about doing security through the DevOps pipeline. And I wanna say, in my opinion, in my very humble opinion, and I've been been doing this for a very long time, we really do have to evolve to DevSecOps, and that at least is generating an SBO m folks.

And we're gonna take that a little farther here. We're gonna talk about doing more than just generating an SBO m but yes, maybe SBOs aren't completely accurate, but at least it's the beginning. So the challenge again is how do we continue to be fast?

How do we continue to innovate at the speed of DevOps and add security tooling into that? I, it, it seems like an impossible challenge, and it might be, but the dis the discussion is pretty critical at this point. And where does this, the friction really emerge, right?

It's, uh, many, many people at the conference talked about, um, the lack of compliance requirements after deployment. So why are they worried about it in the, the, the dev, the the CIC pipeline, other than doing some scanning? Um, they don't wanna have to do the documentation.

There's documentation overhead. So there's a, there really is a balancing act between speed and accuracy and security when we talk about adding the secure software development framework or the SSDF into the CICD pipeline. Uh, and that in essence though, to be quite honest, that's where it belongs.

We can try to do security outside of the, of the pipeline, but the software factory floor is where the game is. That is where we can stop it. That is where we can begin tracking it, we can gather evidence, we can start tracking post-deployment issues, so we understand how to respond to vulnerabilities.

There is so much that we, as DevOps engineers are not necessarily taking on that we can take on. And I hope that I can convince you that it's time to start looking at these compliance, um, uh, like the, like the SSDF and sort out, maybe you should start looking at it and start adding some tools to your pipeline that can help you achieve the compliance levels. That is pretty basic, pretty basic stuff.

So, who am I and why am I lecturing you about DevOps pipelines and SBOs and security? Um, my name is Tracy Reagan. I am the CEO of Deploy hub.

I have been around for a while. I've been doing software configuration management, um, for pretty much my entire career. Uh, I was a consultant on Wall Street, and I got a, uh, a job working for, um, UPS when they were building out one of their big fact, their big, um, I would call it logistics and, uh, supply chain work.

And I learned about builds at that point. I got assigned to doing builds and writing make files. And that has taken me on an amazing journey, uh, that is really specific to how software is constructed, how software components are brought into the supply chain, and what it really means to have a dependency and the impact that de that dependency can have on your code.

Uh, so I, I love this space. It's given me an amazing career. Um, I've also, pre previous to Deploy hub, Steve Taylor and I started a company called Open Make Software.

We created a product called Meister, and we really enforced which libraries you can consume in the, uh, c plus plus days when we're trying to do object oriented, uh, coating. And believe it or not, that tool is still in, um, is still being used by some major companies. Uh, I'm also a founding board member of the Eclipse Foundation.

I've been involved with the open SSF and the Continuous Delivery Foundation, uh, for quite some time, both since their inceptions. I'm on the governing board of the open SSF, and I still serve on the Technology Oversight Committee for the Continuous Delivery Foundation. I give you that background so you have some faith in what I'm telling you.

So why, why should we bother with this? Well, it's kind of important. Um, according to IBM's, uh, data breach report, uh, vulnerabilities can cost you some money, nine and a half trillion dollars globally, um, 250,000 CVEs today with over 50% of them targeting the US government.

Um, we're looking at meantime to remediations. Uh, you can exploit it in less than 10 days. Uh, but it takes us over a hundred to, to remediate.

You know, some companies are doing better, they're getting 70, 60, you know, two months. They can get it fixed, but it's still not good enough. We have all of these tools that we are working on, uh, but many of 'em are not in the software workflow factory.

They're not in the CICD pipeline. And oftentimes we don't even know when a new vulnerability shows up that we need to fix. It's critical or high risk.

And I do hear things like, Hey, we should fix every vulnerability, but I don't know if we have 250,000 CVEs. Is that a realistic goal? So we have some, we, we have, we have some, uh, you know, come to Jesus moments, so to speak, to really understand how we should address this problem, because it can be catastrophic.

Um, you know, we all talked about long for J, but one of the most interesting, um, use cases for why it's important to secure the software, uh, supply chain is, uh, the war in Ukraine, uh, in 2022, um, after ViaSat's, uh, satellite attack, and that was on, uh, modems. It was called acid rained. Those are on edges, right?

The edge, these edge devices, another 124 cyber operations targeting a space sector were recorded in the conflict. So, yeah, it's time that we really, um, address this and, uh, start thinking about it. Not that everybody is running as critical as a war, but it can be pretty essential if you are exposing your customer's data and, uh, your data has been breached.

So let's think about where DevOps and the SSDF might align. Um, first of all, automation, um, of, of these tasks within the CICD pipeline is a really, really core spot for us to have this discussion. Building out A-C-I-C-D pipeline, we have done a great job of pulling in some of these tools, but we've kind of gotten lazy, I hate to say that, but we have kind of gotten lazy.

Our pipelines are working. We have so many workflows that we would have to update even to add SOM generation. It's a lot of work.

I don't, I'm not saying that it's gonna be easy, but it's important because these are basic shift left security principles that we've all been talking about for some time, and just having just did a code analysis one time. Maybe it's just not enough. Maybe there's some other new tooling that we should be looking at, like signing, for example, attestation that is also critical.

That should be, also, should be also tracked and understood through the CICD pipeline. So both, I believe the SSDF and our DevOps community ha have a commitment to deliver secure and resilient software to their end users. Everybody wants to do that.

Nobody's out of that cycle. We all wanna do better, but it is work. It does take some understanding of the tooling, and we're gonna kind of jump into that.

So you, the DevOps teams, you guys are so key to this. It is you who can do the automation of the tooling that's coming out of these security teams. Um, you're key to implementing so many aspects of the SSDF and without you, the SSDF just becomes a document, um, because you do sit at the heart of the automation, and this has to be automated.

We can't do things one at a time, and it really is about automation. Now, not every single task within the SSDF is about workflow automation and do not include task that should be in your CICD pipeline. But there are many tasks that do require automation through the, through the CICD pipeline.

And you as the DevOps team are super critical to making sure that we're transforming these practices to address the SSDF, understand what it's trying to tell us, and add these security controls into this repeatable, scalable workflow. In other words, we need real time security at DevOps speed. And how do we get there?

There's a bunch of open source tools for DevSecOps. I, um, am amazed how many tools are out there. And there's new tools coming out every day that are open source tools that are addressing some of the SSDF tasks that you can implement fairly quickly.

Most of them have ACL I. Um, some of them, um, are, are as simple as a kind of a, a tracking mechanism, but they're out there to be consumed and to be used. Now, the SSDF is broken into four primary categories.

Prepare the organization, protect the software, produce well secured software, and respond to vulnerable vulnerabilities. There are many ways to see this information, um, and we, we need to understand that we have to break it down into some individual parts so we can apply those four principles to the DevOps pipeline. The problem becomes, there are so many tools out there, and where do the, to where, where are the tools fit?

Are they build tools? Are they deployed tools? Are they scanning tools?

You know, do they go on the build? Do they go post deployment? Are they responding to vulnerabilities?

There are so many tools out there, and it's time that we really understand which tools fit in what areas that support, uh, delivering the task of the, the software, the secure software development framework. So the good news, um, of course, if you know me, you know, I like to start things. And recently I started, um, with a group of, of folks, uh, one woman by the name of case Ella, who used to be an, a security architect at IBM.

We pitched to the Continuous Delivery Foundation, the idea of A-C-I-C-D cybersecurity sig. Um, we got some amazing people that immediately, uh, jumped on board and started looking, um, at how to solve this problem, CICD and cybersecurity. And what we decided was that we wanted this sig to play a real pivotal role in advancing security and supporting organizations in meeting modern cybersecurity demands with a focus on integration frameworks, best practices, and emerging tooling.

Emerging tooling was probably the most interesting area to us because we didn't wanna build another, um, another SSDF. There's plenty of, of, of standards and compliance that we can follow. What we wanted to do was to expand on it.

We wanted to expand on it by identifying tools that could be used to achieve the goals set out in the SSDF. We're also gonna work on cyst and do some mapping between some of the other, um, frameworks. But we started with the SSDF and we would created a guide.

So we started working first on just lists of tools that could fit into these, these se these categories within the SSDF. So we built a guide that helps DevOps engineers build the security compliances in the CICD pipeline by mapping open source automation tools for security into, um, the SSDF identified by the SSDF framework and where it needs to go. So our SSDF guide is ready for you today.

Um, it is going to be officially launched October 1st, so you're getting it, um, a little bit early. But the point is, it's out there. It's out there for you to, to take advantage of.

It's out there for you to contribute to, it's out for there for you to say, Hey, you forgot this tool, or you got this one wrong. This is a, a live document that we all can contribute to so that we all understand how to meet the demands of these new frameworks. So important thing to note here, we segmented the chapters within this guide into three categories, code and pre-build, build, and deploy, and post-deployment.

Those were the categories that we saw were best represented. The workflow of the CICD pipeline, build and deploy is what we normally think of, but post-deployment, responding to vulnerabilities is a critical piece, and we're already doing some of that. So to get there, um, it doesn't have its own URL yet.

It will grow up, but it's a netlify app. Uh, I look for ci cd dash cybersecurity, and right here on the top where this arrow is pointing, that's where you can find the guide. Now, I also have to point out that you can learn how to join the team as well.

And we would love to have, uh, DevOps engineers who may not be security expert experts join this group where that's kind of who we are, except for Kate, who's our, um, our lead here in security, we're DevOps engineers, um, and we're all learning and we're all discovering new tools. And this is the place if you discover a new tool to open an issue in the GitHub, uh, in the CICD cybersecurity, uh, GitHub repo. So we know we need to add it, or you can add it yourself.

So once you drive down into the security guide, you're gonna see some things, um, that I just talked about. On the left hand side, you'll see the code and pre-build, you'll see build and deploy, and you'll see post-deployment. So you can drive down into any one of these areas to find open source tools that will meet particular actions of the SSDF.

So in this case, I drill drilled down into code and pre-build. Now, notice we have, it's a chapter that e expands to secure software development framework because we wanna add additional frameworks in there, and it breaks down the frameworks that I discussed. Protect the organization, protect the software, produce well secured software, and respond to vulnerabilities.

Now, drill driving down into this even further takes us into the different tasks and actions that the SSDF has. In this case, I chose respond to vulnerabilities. And the first thing that comes up is RV dash one, identify and confirm v uh, vulnerabilities on an ongoing basis.

Yes, I checked that one because it's one of my favorite ones to talk about, because that's what I focus on so much in my own career, that how do we know when vulnerabilities are being, um, are, are, have been new vulnerabilities have been found post deployment, and how do we respond to vulnerabilities when we, uh, across the pipeline from dev, uh, from at the code and pre-build state. So if I, if I was to have a live, uh, vi uh, demo going on, I could select post, uh, or post deploy and respond to vulnerabilities would also show up there. So how do you respond to vulnerabilities in code and pre-build?

How do you respond to them in build and deploy, and how do you respond to them post-deployment? So the goal here is to create a, uh, a, a reference document, a reference guide for these, uh, for the SSDF and soon to come, the CIS framework that shows you what tools could potentially meet that compliance level, or at least serves it in a certain way, serves it to some level. Now, we're not saying we're gonna, we're completely accurate in this, so you should take this, you know, with your, under your own understanding and your own research.

But it sure starts the conversation. And the team has put a lot of effort into coming up with these tools. It's not, it has not been an easy process.

You know, when, when I first started it, I thought we would be like three months in and we'd have this particular, we'd have a list done. Well, we started in January and we're running into October for the, its first, uh, full launch. So the team has worked very hard to deliver this.

And, uh, I think you'll find it a useful guide. I know I did, and I learned so much about the tools. I ha some tools I'd never heard of and what they're doing.

It's pretty fascinating out there. So many people are, are concerned about security issues in their, in their code, and there's a lot of new innovation around it. But I can promise you the innovation, most of the tooling has to be generated and or has to be pushed through the CICD workflows.

It's not something that you're gonna run at a command line every time you need to see it. So the results is DevOps aligned with the secure software development framework, not adversaries, but friends. And I do believe that as we push through this process, we all learn about what the SSDF is talking about.

We can understand that there are things that can be done at the early stages of development that we can prepare the organization. You know, how many people I still talk to that don't have version control? It's a, it's silly.

There are, there are companies out there who haven't done that. So let's just get that, that off the, let's just get that off of everybody's plate or how to protect the software. Do software code scanning, generate a software bill of material report.

How do we make sure when we deploy it that it, what we produced was it was well secured, and then how to respond to vulnerabilities when they show up in our production environments? Because new vulnerabilities happen every day. This is not point in time.

Solutions are great for the protecting the software, but new, new stuff shows up. So how do you fix that once it's out there? So each one of these sections, po ps, PW, and RV have a section under code and pre-build, build and deploy and post-deployment, which means that you can begin adding these, the adding these tools or adding solutions to your DevOps pipeline to align with what the secure software development framework, um, is all about.

Thank you for listening and having me lecture you about doing better and, uh, security. I know we all can do much better. It's just understanding what tools we should use and where they go.

Uh, I encourage you to, uh, give me a call if you really want to. Honestly, those are my phone, my phone numbers call me. I would be happy to chat or just reach out to me on LinkedIn.

I'm at Tracy Reagan, oms. Um, but I would love to chat and have more conversations and probably recruit you for either the ORUS project, which is a, a, a project that I'm working on, or the CICD cybersecurity sig. Thanks.

Hey, everybody, happy Monday. And are you ready for coupon? Well, you will be in a minute.

We'll be right back. Welcome back, everybody. Today's edition of Textron Gang is gonna have our usual, some of our usual stars starting with Mitch Ashley.

Mitch, how you doing? Good to see you. Good, good morning.

Good morning. Also joined by Kate Scarsella and Jack Poller, who are gonna lend their insights into all kinds of fun stuff. But first we're gonna start with, well, what's going on with Cloud native?

Because not only did we host a cloud native, uh, now event last week, but cube con's coming up in a week or so, and we have some articles over on Cloud native now talking about how, uh, maybe AI is gonna drive more people to build cloud native applications. 'cause well, maybe it'll get easier, but Mitch, I know you were at the, uh, cloud Native NOW event and you gave a presentation there. What's your overall assessment right now?

Where are we on this march to cloud native? Well, we're all watching the, it's like, like an F1 race, and we're sitting at one corner, right? You kind of see it zoom by for a minute and they're like, okay, what's happening in the next lap?

It just goes so fast. The, um, the, the market is starting to, to make the next shift, and this is the very leading edge of it where you see vendors that are, that are introducing, um, agent control planes and management of multiple agents doing development work, coding, coding agents. And there's a great article that, uh, we had on, on, uh, cloud native now that also tied this in.

I think it was na, Nathan, Eddie that wrote it. Really good perspective on it. But I think what we're seeing, and it's not just there, but it's mostly on kind of the developer front end.

And then we see it with code reviews. We see some security guardrails starting to be implemented. Of course, uh, GitHub had their, uh, universe, uh, conference last week and, and made big, big announcements about Agent HQ and are trying to be sort of the neutral platform to bring your agents, bring your model, we'll, we'll run it on our control plane, et cetera.

Um, cursor came out with their own kind of similar, we have our own coding model called Compose. And, uh, we're also will help you run multiple agents in parallel. Uh, OpenAI came out with, um, a, uh, a vulnerability repair capability within, within their model.

So you're starting to see them, see the vendors sort of try to take it up to the next level. And I think it's a lot of, it's just a race for the, for the ground, right? Everybody's wants to plant the flag.

And while the Oklahoma rush is going on, Kate, I don't think it's any secret that building these apps is hard and deploying them on Kubernetes isn't always a joy. But do you think, or do we have hopes that maybe AI agents will make this easier and more accessible and maybe we will build more of these applications faster? What do you say?

I I personally think, yes, we need to embrace this technology. We need to of course put some sort of guardrails, which presently we, I, we don't have a lot of guardrails around that, but absolutely, I, I think that we need to embrace this technology and we need to understand it so that we're able to start to do a better job at securing it. But yes.

All right, Jack, any thoughts here? Do you hope that this comes about or do you think that this is just gonna be more trouble than it's worth? Uh, I don't think it's more trouble than it's worth.

What I'm trying to understand is how much of the effort is being driven by AI improving the developer's, uh, life and or ai or the end user application that the developer is building, right? And I think right now we're sort of seeing a lot of focus on developer activities and how do we improve the developer activity and hopefully as a result, the quality of the code they output. And more importantly, from my perspective, the security of the code they output, I think it's still gonna be a while before we get to the point where they're able to really embed AI and particularly agent AI into the final applications.

Um, we'll see, I think there's two things to un wrap there. And I'll go to Mitch for the first one. Um, I think most of the AI applications that people are building these days is run on Kubernetes, and I think most of them, or cloud native by definition, because well, they're so large that there's no other way to kind of get after this thing other than to break it up into a bunch of microservices.

So do you think that as that occurs, that that just naturally pulls more people into building cloud native applications per Jack's point? Well, first of all, um, we, we have some data in my research from buyers that indicates, it says AI is the number one workload that they're working to put onto Kubernetes. Um, but the point of it is actually that everything's going on Kubernetes cloud native applications, but everything else too, database as you name it, it's, it's the, it's the workload platform now, kind of just above the operating system, uh, by default.

Uh, to your, to your point about cloud native applications, there's a sort of a natural affinity between microservices and agents that kind of had look a little similar, um, but they don't function the same way. But if you can imagine, you know, a group of agents doing different, uh, tasks, a part of completing some process, just like a group of microservices do now, are those agents running under Kubernetes themselves? Are they running in a, in a different control plane?

Um, like in an Agent HQ or something like that? Is is a different story that we'll see how that shakes out, but I gotta believe under underlying all of it, there will be Kubernetes there. And I think we'll see this real mix of, uh, cloud native microservices and sitting right beside them, you know, agents that are doing some, some workloads.

Increasingly to Jack's point, it's like, it's not like turn the page and it's all agents now. It's gonna slowly, uh, be put into production over time. Mm-hmm.

Okay. I'm trying to figure this one out. Are people just gonna take their legacy stuff and just toss it out the window and deploy something new that feels like a cloud native microservices application?

Or will they try to maybe use AI to take those applications apart and peel 'em off into a set of microservices that, you know, might take 'em a few years to do, but they're gonna keep the core app in place? Or is it just time to get rid of this stuff? Well, from previous podcasts, you probably have heard me say like, yes, we need just to get rid of it.

That's my own personal opinion. Um, because sometimes it takes a heck of, you know, it's like if you think about doing a, a project in your home, it can sometimes take on, if you're trying to save all these, you know, items, it, it can, it, it's painful. Sometimes it's just better just to take the wrecking ball, um, not to the White House, but in other situations.

Um, in this case, it's really, I believe that it's built on blocks, um, that perhaps have been, that is not secure. We're getting some new areas that we can really do this right? And I think to do this right, we need to think differently and we need to put it in place and, and build the right trust frameworks around it.

I, I think when we're building this, now, let's do the right foundation. We know what's wrong, we've seen it, let's do this. Right.

So yeah. Mitch, do you agree with that? Because a lot of the legacy applications were written by people who I hope are now sitting on a beach somewhere probably laughing their asses off and none of this stuff was documented, and I don't think AI is gonna actually go in and maybe fully document all those things.

So why not just start over? Well, my, uh, one axiom I've, I've come to agree with or put together, part of my career is no technology ever actually dies. It's all still out there in somewhere, some form someday.

And, uh, you know, we say, Hey, that's the, you know, the, the old, uh, IAM and the old, uh, IIBM databases, those things will go away. It's all gonna be relational. No, no, they're, they're out there too.

Um, but I think to what you're talking about that you were asking, Kate, is there are efforts to specialize AI to help you modernize the applications? Not just virtualization of it, but actually the app itself, and in my experience in my career is you rarely wholesale replace a whole application. That's usually a career ending move.

Um, you, you decide a different strategy. And so for example, IBM has something they call Project Bob. I call it Bob's your uncle.

Now it's Bob's your coding agent. But it, and it it's specialty is understanding and help you modernize code base. The big issue for modernizing today is there's so much job out there and trying to maintain, uh, consistency with new versions of Java is a lot of code to update.

So I, my, one of the things I did earlier in my career as about 10 years ago is the head of monolith application that we really wanted to, to do something with. Um, but the people who built it were on the beach, right? And they were not coming back.

We could not bring 'em back. So we actually carved out a part of it, a small part of, of it 'cause we didn't understand most of the app. And then re rebuilt that in a way that then we could actually, with microservices and Kubernetes, and then we could enhance it and do that kind of thing.

I think AI will help us speed those kinds of things up. So you may peel off part of an app and say, great, let's, first of all, let's understand it. 'cause nobody can understand that code anymore.

Nobody knows it. AI will help us with that too. The only thing I'll add is, you know, working for IBM, um, from 1999 into 2000, remember the whole Y 2K thing?

Oh yes. You know, Do you know that we actually would shut down, um, mainframes and if we didn't get a call, we'd be like, okay, we're good. And that's how, that's how we, um, basically, uh, went through getting rid of things that were no longer needed.

I mean, it's, it sounds crazy that we did it like that, but, you know. Sounds Good. Sounds like streaming services at my house.

No, no. Haven't called yet. So I guess nobody uses that anymore.

True too. I think microservices are similar. If you turn those off, people go, oh, I guess we're not using that one anymore either.

Right. So, applause jar. If the security people had a vote in this, where would they vote?

Would they vote for trashing the legacy code and just starting over again and maybe, maybe this time building security in from the beginning? What do you say? Well, I think most security people would actually be for trashing the, uh, the existing code and not starting over again because we wanna reduce the attack surface.

But since not starting over, Thank you. Thank you. It's not an option.

We have to do something. I think security people would really like to start with security by design, right? Is if you're going to do something, don't bolt on security after the fact.

Think about security as you're architecting and designing the thing. And you know, that's true. Whether you're re-architecting it or redesigning it from scratch, or, Hey, we need to make this modification.

If we're gonna make this modification, how are we gonna secure it? Right. And, you know, I am, I, I don't know.

I can't beat that drum loud enough. Right? Think about security.

I mean, Jack, think about the market. If some model maker, some product maker came out with, I call it security OG at the point of origin, right? Right.

Where we create the code, we combine it with other things, we configure it, we set up the environment, uh, using ai. If, if a company came out with that and really made some big progress, man, talk about it, that would be, that would be the kind of the golden egg that the goose laid it, it would be. And I think, you know, as, as we think about AI and AI in the Kubernetes environment, there is an, it is very easy for us to conflate security and safety, right?

And I wanna make that distinction. Mm-hmm. When we think about AI in the world, safety to me is all about things like, does the AI follow your guardrails and prevent you from, you know, if, can you, can you force the AI tell you how to build a bomb when the AI is there as a coding agent?

That's safety and security is really about how does it interact with the rest of the world? Can somebody exploit it to attack your environment? Which is sort of two separate things, or use, you know, is it, you know, expanding your attack surface in the Kubernetes environment when we're using AI in terms of coding assistance and how do we accelerate our development process?

There's a tremendous amount of advantage we get, but we also should think about how do we use that AI to improve our security, to reduce the attack surface at the same time. And that's really, I think where we can, you know, companies that think about it that way and look at it and say, this AI that's gonna be a coding assistance is always, it's prime directive is always gonna be to generate secure code or to, uh, analyze your code that you'll look, that you've created for security as well as just for traditional, what we call bugs. Right?

And I think if you are, you're developing, uh, tools for the developers that help them security, which is a very complex and a hard to understand topic, then you're gonna be, you know, you'll have a winner on your hands. What's interesting, Jack, is you brought up, when you started to, um, speak about safety and security, which is definitely an OT pros, uh, position, operational technology, posi position. And traditionally from an IT perspective, we were always on the, you know, CIA, you know, confidentiality, integrity, and availability.

Yeah. So I find it interesting that going forward we are thinking more from a critical infrastructure point of view from safety and security. Um, and I think that that's important as we move forward.

If we were to put that type of thought process in our heads as yeah, as we, as we, you know, define this path Well, and, and I, I, I like your, your concept of the OT versus the it right? In a different perspective. And I actually think we need to take it one step further and we need to think about everything in terms of the benefits and risks to the business overall.

So from a, you know, from a risk to the business, security is very, very important. But if you're developing an application that includes an LLM or an agent of some form or another, then the other, the safety aspects is also critical. The classic case we all sort of hear about in the press is the AI agent that, uh, promised free flights to somebody when it should not have, right?

And, and that's the safety aspect of it, is there's no, it wasn't a security issue. The user of the LLM didn't exploit it incorrectly, just the LLM gave the wrong answers. But that's still a risk to the company, both a financial risk, a reputational risk, possibly compliance risk, all of those types of things.

So as we make it easier, uh, for developers to include AI capabilities, particularly AI agents which have free reign to wander around through the, all the data of a company, safety and security become more and more of a concern as opposed to bare basic functionality and bugs, at least in my opinion. Here's my whole problem with the modernization storyline, and Mitch, correct me if I'm wrong here, but basically before ai, it was, uh, yeah, we're gonna come in and modernize your app, and here's these five really bright people that are gonna do it. And then, you know, when the day came, the bus showed up and about 50 graduate students moved in for about a year or more and basically crashed your house.

And now we're saying progress. It's great. Those same students are gonna show up and they're only gonna stay for six months because of ai.

It just doesn't sound very appealing. Tell me, Believe it or not, I was one of those graduate students showed up at a bank, we're gonna rewrite all your banking systems. So we did.

But it's pretty amazing. It, it's, it's, it is a familiar model. Maybe it is, maybe it's not, you know, 50 graduate students, maybe it's 10 of 'em, and you know, a season Kate or Jack or you or somebody, you know, directing that, that knows the domain.

And that's what we're looking at. I mean, that's, that's, I think that's what people expect to happen. It's not necessarily a great thing for people starting their career, but also I think there's a path for them too.

It isn't just this, the, uh, indentured servant approach that, that I took through the consulting companies. There you go. All right, folks, I'm gonna leave this one here.

We will be at Cube Con, we'll be on the show floor. So come on by and say hello at the very least. And also, there's an article by Alan Shimmel over on the cloud native now talking about all the great things that are happening in CubeCon.

So you should check that out because, well, there's just a lot to do down in Atlanta, and we look forward to being there. And also by all means, if you can't make CubeCon or if you're just a glutton for the content, check out our little virtual event from last week. It's unavailable online.

We expect you to guys get a huge amount of content. Mitch has a whole presentation there that's worth checking out for sure. And we'll be pack in a minute.

You've Earned it. The spotlight, the responsibility, the weight of teams, companies, and entire industries fall on your shoulders. Lives depend on your decisions.

Your home life included that work. You are protected physically and digitally. Nothing gets through your team without a fight.

But in a globally connected world, everyone sees you, including those who mean to cause you and your organization harm. And now home your sanctuary attackers see an opportunity. Your digital front door is wide open.

And what compromises your home can breach your boardroom. Because the devil's greatest trick isn't targeting your workplace firewall. It's convincing you that your personal life isn't at risk.

Black clerk, digital executive protection, defending the new attack surface your personal life. Hey folks, we're back. I'm gonna have a little chat about cloud outages again, because now it's Microsoft's turn.

First it was AWS and then Microsoft had an outage. And maybe these things are just gonna become regular routines and we gotta figure out how to learn to live with all this stuff. But Kate, what's your take on what's going on here?

Is this just gonna be something that we have to live with because, well, these things are not too big to fail and they have some sort of single point of failure in 'em, and we just gonna randomly discover this from time to time. Well, so first, um, just to review the, there was an eight hour Azure outage this week. Um, knockout services worldwide, which we all know.

And as you said about AWS same thing. What I continue to think about is I come to hate the word and even being a cyber security person, that I am in resilient. And I, and I've thought about why do I hate this word?

So it just takes me back to the beginning of, um, you know, we used to talk about five nines. If we were to think about building our cloud in a five, nine more from a redundancy framework mindset, I wonder if it would change, um, us away from the idea of resilience. And I, it sounds crazy, like we're talking about redundancy resilience, but I do think that if I think about five nines I notice in my life, typically I have a backup to a backup to a backup.

And it seems to be across the board, it, it, it happens to me personally as well. I'm like, oh, I have a backup and I have a backup. You know, that's the problem.

When we, when we look at cloud, when we look at cloud, we, we don't think of redundancy. I think we think as we program, oh, it's redundant 'cause it's in the cloud, but it isn't. And we see that with, with both, you know, big cloud.

And I know I've sort of gone off script here, but it's just this, you know, morning type of, uh, um, idea of what are we doing? And when we think about resilience, we can't just think cloud, like cloud is our resilience. It isn't, we have to think of it from a redundancy perspective.

We have to think if this, if, if east part goes down, you know, why do we not have it globally, um, in such a way that if one part of this goes down is it's gonna be somewhere else, we should be doing five nines and not think of this from a resilient perspective. So that's my take. You know, Kate, it kinda reminds me of CrowdStrike where pushing out a change, which is apparently some configuration change, is what caused this in the content distribution.

Uh, the whole staging of rolling it out, right? You know, push it all at once. I don't know how this is rolled out, but usually those are the, those are the circuit breakers, right?

They'd like trip like, well, wait a minute, this didn't come up, or, you know, it worked fine at three, but now we've put on 30 and it's not working anymore. So something in that, you know, it's, it's good to say we want it to be resilient. And also of course, you know, backup and redundancy, but also sort of like, don't change everything.

Don't paint your whole house until you've looked at what color you're gonna use, right? I think Jack, to Kate's point, those extra nines in that five nine equation are frigging expensive. And I think people know that.

And they, one of the reasons that things are not as resilient as they should be is people don't wanna pay for it. It's just, you know, the level of redundancy, the backup, the ability to switch networks on a dime is just get out all pricey. And people look at that and they go, well, you know, that's nice, but I'll take the risk.

And if it goes down, you know, somebody will yell at me later, but I don't have the budget for five nine. So how do we make this whole thing affordable? Well, I think I, I think that's actually the root cause and the reason we went to the cloud, and we've forgotten what our life was like before the cloud, is that maintaining five nines on our own infrastructure is very expensive, right?

It's much more expensive than relying on the cloud service providers who are able to distribute that cost across their thousands or hundreds of thousands or millions of customers. In the days before we had the cloud, or the cloud was so prevalent, all the services used to be down all the time. And there's this wonderful site, uh, down detector, and if you look at it, you can see who's up and who's down.

And we don't talk about that anymore because for the most part, people don't go down. This is a very, very rare situation, right? I mean, once the last time we've had a major outage like this, it's been a couple of years.

So I think people lose a little bit of perspective and think about it at, when it goes down, a lot of services go down. But on the other hand, how many of those services did maintain five nines or four nines, or even three nines or two nines, yeah, before then, right? There were a lot of services around that we relied on that were 95% uptime, not 99% uptime.

And that would have be down for multiple outages over the course of a year. Um, so distributing that cost, you know, by the, through the cloud service providers, I think is how we ameliorated the, the issue. But you can program for it to be distributed, right?

Not to just show up in, you know, I mean, yes, you're right. And cost absolutely was a factor. And I think though that, and one of the things that we saw with, um, CrowdStrike is that the cost becomes a human cost and it matters.

We have to understand, especially as, um, AI becomes, you know, augmenting humans, that the cost is no longer a financial cost. It's actually human cost and this matters. And so when we think about, you know, we have to think, the developers have to think that, um, the way that we distribute, um, across cloud and even having multi-cloud, it becomes important.

And it, it's, is it not? I mean, is it that expensive? I mean, I I honestly, it, you know, from a multi-cloud perspective, you know, is it that five nines?

Yes, that was extremely expensive, but is multi-cloud expensive? I don't know. I'm asking, I think Go ahead, Jim.

I was, I I was gonna say it's, well, again, that's sort of, there's the human cost involved in that is architecting your environment to span across two different cloud service providers is actually fairly challenging, right? If, you know, there are many organizations that are multi-cloud, but they have, every single app is single cloud, right? They just, right.

They might have something in AWS and in Google and in Azure and in Oracle and, and, and, and they're spread across all of that. But most applications are, um, monolithic across a single cloud because there's enough differences between the clouds and there's not a universal API and another universal interfaces for this stuff. So it is becomes very challenging to build an app, to make a single app resilient because it spans clouds.

And the only other question, I'm sorry, that I would have then is when we used to architect for five nines or whatever, um, you know, we used to have, uh, data centers in different sites, especially in Florida, you know, being hit by hurricanes and et cetera. Why don't they just have like a, a backup ready to go, like IBM even used to offer that as a service, you know, like a, The hot spear. Yeah, it's, yeah.

I, I, well, my understanding is on, on these particular issues, the network routing, the, the, the network information was the cause of the failure. Mm-hmm. So if you had another location you could switch to, it was dependent on being able to get the network information correctly, and because that part of it wasn't working, then you can't switch to whatever your yeah.

Alternate site is, right? That's, that's a, that's at, you know, there's, it becomes very, very difficult to engineer out every single, single point of failure in the system. Yeah.

That's always the network guys. While at the end of the day, It's not the software developer system. I didn't say that.

I'll tell 'em all at network field day next this week. So yeah, that Mike, So, so Mitch, which is the better situation for an IT person, right? So to Jack's point, right?

Uh, so we had things on premise and they probably crash more often than they do in the cloud, but not everybody, you know, the employees knew it, but the whole world didn't know it. And now I have a cloud scenario where it doesn't crash as often, but when it does, the whole world knows it. So which one do I want 'em have?

Well, it's kinda like the, when the air traffic control system goes down and now every plane is, you know, trying to figure out how to get where they need to go, it's that level of an outage when you have a big outage. Um, I, I can remember the day of pick your application, the invoice processing system's down again, it's down again fourth time today. They're trying to get it back up and figure out what's going on with it.

You know, those days don't, those don't happen much to, to Jack's point, like, like they used to. And I think it's 'cause we're architecting systems better, building a more redundancy, not relying as, as monolithic of code. But from a, from a, from my standpoint, I was happy to move it outta my own data center and put it in the cloud.

Um, and part of it is I just to deploy networks in, in co-locations and in central offices and and service providers. So I was pretty comfortable with it. But you know, the thought of, okay, the air conditioners, the chillers got a problem.

I do, I really wanna mess with that. Is that what this was that what life is about? Is that what I got a CS degree for?

Is the fricking chiller to keep, keep the computer room cold? No. So, you know, it, I, to me, I think it's a blessing not to have it on site when you can do that.

Um, doesn't mean there aren't pains moving up to the cloud too, but you have a lot more flexibility. Um, you have less control, but you have a lot more flexibility of what you can do, Kate, is there a certain amount of comfort to be taken in the fact that when it does happen and happens to everybody all at once, and there's lots of misery to go around, I guess, uh, the adage, right? Misery loves company, so, but we'll go with that.

We'll see how it goes. Um, Jack, just one question here about the cost of all this stuff. I mean, do you think that it's that the providers haven't figured out a way to deliver that capability of five nines in a way that's cost effective?

Or is it just that the IT people and the apps folks don't really want to pay for it, even though they haven't figured out that maybe the cost of downtime far exceeds the cost of that extra capability, especially for certain applications that are driving Remy? It's a little bit of both. I mean, but I'll go back to what Kate said in I think the previous segment about the human cost, right?

And, and part of the challenge here is that we can build as much redundancy into a system as we want, and we can spend as much money as we want, but at some point, a human's gonna trip over a cable and knock out the power to everything. And there's, that's really hard to avoid that, right? And so, you know, I think we're approaching the, the point of diminishing returns.

We can spend infinitely large amounts of money to approach six nines or seven nines. And the ROI of that investment is very, very small, if anything. And that's where we are today.

I mean, as I, as I said, you know, there was a point where, and we forget now, but there was a point when failures were so common that we had custom failure pages that became memes as everybody remember the Twitter fail whale, right? I mean, their failures, failures were so often that you had a, uh, a graphic that you designed specifically for your failure case. Nobody does that anymore.

So I think we're at the point where we've gotten, you know, we've, we've spent what we believe is the appropriate amount of money for the appropriate reliability and resiliency, you know, from a customer of those services perspective, what gets concerning is this is the third failure by fill in the blank, my, this vendor in the last 30 days or last 60 90 days, oh, could then I'm starting to get concerned, right? What's going on here? Are they, do they have their act together, but the fact that they are rare, um, and aren't service affecting to what you run?

Uh, this says, says that they do a pretty darn good job at it. The only thing that I'd like to add is that, um, the AWS outage happened. It was an East coast outage, right?

Mm-hmm. And that should be, um, rectifiable, meaning, you know, not everyone should, like, if I had to develop, um, whatever, I wouldn't go to AWS East because the last two times it was AWS East, um, I or make it multi-cloud. And that, I mean, there's, I think there's a checkbox if I'm wrong, that you can just, you know, multi-cloud that.

And so that, I think we're not blaming the network people. So Mitch, you're gonna be off the hook and we're gonna be blaming the Developers on that one. So Take it to GCP in Iowa.

There you go. There you go. I like it.

Alright, I think we have some agreement here. I think, you know, we need resiliency. It would be nice if it was cheaper, but right now it's a little bit expensive.

So you gotta figure out whether it's worth it for your application. And if it's not, suck it up buttercup. We'll be back in night.

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 Textron Group. Hey folks, we're back in this next segment. I think personally I found it fascinating, but the bad guys have figured out how to avoid the take down.

So if, I don't know if you've been watching some of these things, but law enforcement officials around the world have been kind taking down servers and in Elliot Nest kind of fashion, they're short of actually having the cameras on hand, but they basically break into these warehouses and, you know, taking ax to the beer battles, beer barrels, and then they grab all the servers and away they go and it makes for great theater. But Jack turns out the bad guys are getting smart and using something called blockchain and ether riding. Please explain.

Well, this has got to be the most diabolically evil case of hide in plain sight I've ever seen or heard of. And, uh, the bad guys are basically using a feature of blockchain called con, uh, contracts, software contracts, where a blockchain is basically an immutable ledger. Everything that gets stored on the blockchain is uncorruptible.

You can't be modified, uh, except in very specific use cases, which we'll get into in a moment. And everything is publicly, it can be seen in access to publicly. And most importantly, the blockchain is distributed.

It exists on millions of computers across the world. So the law enforcement guys can't go in, crash the doors, grab the server, because that thing on the blockchain, that piece of data is replicated everywhere across the world. And so they'd have to subpoena and grab millions or billions of computers, which is just never gonna happen.

Now what the bad guys are doing is they're taking advantage of something called a smart contract, which includes, uh, in it a data field or a set of data fields. And that smart contract, the data fields in the contract itself can be modified through an API and the bad guys basically corrupt a machine. And then once they have the initial compromise, they're able to go and fetch their code that exists in the data fields of the blockchain so they can modify that code and update it and change it as they want, and therefore use the blockchain as a distributed repository for their malware, which is really evil and is very, very hard to get rid of.

And it is very hard to detect because they're not usually using the usual methods of command and control servers to get to this. Mm-hmm. So Kate, do you think this will become kind of the standard setup for these guys?

I think it's both. Uh, it's two North Korean groups that kind of pioneered this thing. And, uh, but everybody else is gonna look up and go, well, thanks for the notes and Cribit and away they go.

Right? Absolutely. And from a cybersecurity perspective, and it's not just because, you know, Jack is right in front of my face, but I will say that this article that he wrote is pro, I would say is one of the most important articles, and I'm, you know, very serious here when it comes to, um, cybersecurity, um, moving forward.

Like this is something cybersecurity people, um, architects, engineers really need to think about because this methodology moving forward is highlights, uh, this distributed architecture, which is gonna be very important for us moving, um, as we, um, as we grow. But absolutely 100% everything that, that Jack wrote in this article is a blueprint, um, on, on what's happening and what we need to do, um, and how do we start to, um, fight this specifically. So, great job, Jack, and really it's phenomenal.

Mitch, what's your take on this from a DevSecOps perspective? Because, you know, as Jack noted in his article, they were targeting WordPress sites initially because, well, you know how great the security is of those WordPress sites. So seems like, you know, a natural distribution vehicle, Lockdown gold standard, that's for sure.

Um, you know, in a way it's a supply chain attack, right? Just like, um, with SolarWinds attacking the, the build process and in the, in the software creation DevOps processes here, you're doing it in a payload that's going everywhere to, to Jack's point, it it is everywhere and you can't get rid of it. Um, I, it you're usually in DevSecOps are thinking about application security oftentimes, but I think that's why I said supply chain, because now we're talking about something that we're relying on for other uses, you know, in this case, um, the blockchain to be the mutable ledger, uh, for whatever uses that it is crypto or whatever, um, and then it, it's getting hijacked, um, no pun intended, Jack, um, by the nation state guys in this case.

So I don't, you're not gonna, you're not gonna solve this by scanning your code more often. This is a different kind of problem. Um, and, and I think most software developers would say, I don't even know what you're talking about.

I know which using an API to get to something when it's, you know, when it's down, I get, but, you know, they're not blockchain experts. So it's, it's a, it's really a tricky problem. I I'm not sure how we solve this, Jack, what are we supposed to do about all this?

Well, the, the, I think there's sort of one silver lining here is that while the code repository that the bad guys are using, they're treating, essentially treating the blockchain as a code repository. And that is a distributed environment, but there is some centralization involved in their accessing and changing that repository. So we, from a global perspective, a law enforcement or a, you know, people searching for the bad guys and what they're doing perspective, there is some hints that we can have to look at it from a how do we protect our environment from prevent from getting infected, um, you know, we need to start developing new concepts of what our, our attacker tactics, techniques and procedures TTPs are.

And we need to start developing new rule sets and new heuristics to see when people are going to the blockchain and trying to understand what is legitimate activity from our site, a corporate environment, how often do people go and access the blockchain and should they be accessing blockchain stuff? And, uh, you know, and trying to see about that to detect when we've been compromised and how to, you know, defend against that. Basically you think we'll see some security, uh, enhanced around the API to get to that smart contract.

That seems to me the only way to, you know, get getting it in there, you're not gonna prevent because people can do it on the blockchain themselves, but whether some process on your server is now accessing that API should it be and what's it using it for? And no, I don't know what that is. So, you know, lock it out.

I, I think we'll see that. And we will also maybe, uh, if the people developing, you know, the, the blockchain owners, the Ethereums and the Bitcoin, you know, whoever it is, if they have some global moral concepts, then maybe they will start trying to figure out how they can detect bad people from using their environment. But a lot of those, you know, those environments, their whole concept is anonymity and privacy, and we don't care what happens on the blockchain is because it has legitimate uses as well as illegitimate uses.

So it's, you know, that's the real challenge. And, you know, it's, we have seen similar attempts at hiding activity, say, through DNS, where people have used DNS to exfiltrate data in a DNS query. And again, it's the, from a, a defender point of view, it's trying to figure out what does legitimate uses of this technology look like versus illegitimate uses, and how can we differentiate between the two?

And this may be a case where AI can help us, I don't know. But, you know, it's, it's becomes, you know, it's essentially, like I said, it's hiding in plain sight. So how do you differentiate the, the legitimate from the illegitimate is the challenge.

I, and I think, you know, as a person who, you know, developed, you know, worked with, um, sox, you know, security operation centers, I would say, um, we could look at the chain telemetry, um, and feeding it into threat intel feeds. So that would be one way that I would look at it, you know, just stuff like 10:00 PM where's your blockchain been? Yeah.

All right folks, I think we're gonna leave this here. Um, I would just say to everybody, you know, that was sobering, happy Monday, and that, uh, knowing feeling in the pit of your stomach is definitely not indigestion, but hopefully we'll get smart about all this and fix this sooner than later. Hey, I wanna thank everybody for sharing their knowledge and their insights today.

As usual, great show. Folks, I wanna thank you all for spending some time with us once again, and please stay tuned for the rest of the tech strong TV lineup, which is gonna be equally awesome, and we'll see all the mark. Hey everyone, it's Alan Shimel.

Welcome back here to Text Trunk tv. I'm happy to have my friend Zen Ziv Tson co-founder and CEO of Ox security here on Text Drunk TV with us. Meson, welcome back.

How are you? Great. It's a pleasure being here again, Always a pleasure to have you on.

So, Meen, uh, look, not everyone watches every interview we do on text Drunk tv, believe it or not. But, uh, they may not have seen me talk with you before, though you've been on a number of times. For people who aren't familiar, why don't you give them a little bit about your background and how you came to found or co-found OX security?

Uh, sure. Uh, so about 15 years ago, I joined, uh, checkpoint. Uh, and for about 10 years I led the cybersecurity business unit over there.

And it was a pleasure to see how a big company and the super impressive company is growing from the inside. But then we started seeing the world is starting to move to code, and we asked ourself, okay, where is it going? What's, what's next?

How is it going to evolve? And we understood that the code is the essence of everything. And we said, if we can find better ways to secure code, that would be an amazing future.

So we tried different products in the market, we tried implementing Shift left, and I think we kind of got to the consensus that shift left is dead, it doesn't work. And this is how we started our journey saying, um, you know, it's, there's so many different opportunities to help other people, uh, protect themselves from software supply chain, from upec risk, from cloud risk across the board. There are just risks and it needs to be easy for the developers.

Excellent. Well, that, that really was the problem with the devs sec, uh, shift left is it wasn't easy enough. It wasn't easy, easy enough for security people, let alone easy enough for developers and, and developers.

It's not that they wanna make insecure code, but you can't expect them to be security professionals either, right? They're, they're developers, they develop code, they're not security pros, but this is what led, of course, to the founding of OX Security, that's OX security and give us kind of a lowdown on OX security and what it does Nissen. So think about OX as the platform that connects to your current environment, from code to build to cloud, to understanding your APIs, your data sources, your threat modeling, your runtime environment.

And from this goes back to the developer's environment and inside the development environment, especially in Vibe coding world is able to inject this as a dynamic context into the Vibe coding agent. So new code is actually written with security guardrails built into the code. So instead of thinking about it in the old way that we had like Waterfall, and then we had to do quarterly scanning, and then we move to CICD and it was a gate, and then we started automating Jira tickets, it's why are we creating those problems?

Let's give the right context to the Vibe coding agent saying, Hey, this is going to be an API that is externally facing. Why don't we take this and make sure that we build a code in first place with those five protections? 'cause we already have the context.

We already know how to explain to a developer, why aren't we explaining it to a vibe coding agent that can take this and actually do this for you? And I think this is kind of the, the latest amount it we've done with aux, which is what we call vibe sec Vibe Security. I love it.

Vibe sec. But well, look, I remember sitting here on the set of Textron Gang the first time I heard Vibe coding and kinda laughing and thinking, oh, this, what kind of joke is this? It's no joke, right?

It's a real, Yeah, it's Q2 2025 right now. It's like, mm-hmm. But yeah, imagine that.

Right? And here we are going into Q4, but so Vibe sec Now, vibe SEC is to prevent vibe, code vulnerabilities, right? To bring better vibe, better quality vibe code, let's call it that.

Is that fair? I think it, It, it is fair. I'm saying that there are two, actually two different kind of problems.

One is new code generated, and of course it has its own variant. It's like, okay, I'm using VI coding, there's a lot of drift. How do I make sure that my security, um, I would say restriction right now actually being kept in the code and nobody's removing them.

Simple questions. Other questions? Yes, I understand this is going to be super important.

When do I need to implement, uh, rate limit? When do I need to implement, uh, flags to make sure that I'm protecting from CSRF? When do I need to to make sure that I'm protecting myself against, uh, for example, parameter injection?

All of those come into play by understanding the broader system and injecting them. That's absolutely fair. The second thing is you already have a lot of backlog.

Some of those things are getting very close to the SLA saying, Hey, there's a high issue here. We already agree that needs to be fixed within 30 days. How do we interact with the developer and make it easy for them saying, Hey, you're getting to this SLA in 24 hours, would you like me to fix it for you?

So you won't be on the exception list. And with a simple yes, since we already had the, uh, agenda remediation for a few quarters, we just integrated in saying, why don't you just bring everything to the developer in an easy way, just, do you want to fix it? Yes.

Done. And instead of making the developer upec practitioners we're saying, no, no, that's, we, we've tried it for 15 years. Shift left, failed us, right and left.

The only way to go is simply going back to the vibe coding and saying, Hey, do this for us. We're a new age in an AI age. We don't need to do the shift or lift and shift like we used to do.

We can do it smarter in modern ways. Vibe sec. That's what we calling it.

Vibe sec. Hey, I love it. I I love that you, you kind of went out there and branded it.

Um, so it needs in the, I I guess the question becomes who's responsible for making sure this is indeed working right? That the code is in fact secure, that these vulnerabilities never get generated? Is, is this like something the developer now gets to do?

So it, what you're really telling me is maybe you took a second bite at the Apple, a shift left, and maybe we'll get it right this time. Or is it No, we still, we get it. The developer's not a security person, but with, with Vibe Sec and, and the security team, we can, we can, you know, in essence, head this off at the pass before the developer gets him, you know, has to do it himself.

Uh, I think that the answer is that even though it's not a very, I would say nobody likes to say it out loud, developers don't feel accountable for security. Yes, they do it because they're forced to. Yes, if you implement enough culture and incentives and guild and, and you, you build around, you will get corporation.

But it was always securities accountability to make it happen. Now, we invented a few models in the industry like shared responsibility. Now for me, whenever I'm hearing shared responsibility, I'm, I'm hearing it's like, okay, if something goes wrong, who's the person that I'm blaming?

And somehow it's security. So security is accountable, it's developers are responsible. And while collaboration is probably the ultimate goal to make it happen, and you need the developers security need to create the culture, the rhythm, the agreements, the alignment.

It's up to them to make it happen. And in this new world, we're saying, Hey, if we don't need the developer not in a bad sense, in the sense that we don't need to bother them with that, we can actually tell them, Hey, this is kind of what we need to do in order to pass security instead of bothering them. I think it's a way better way for everybody to, to enjoy this benefit.

And if we're getting it out of environments like Cursor and co-pilot and, and cloud cloud, we should definitely take advantage of this to make sure that we're, we are delivering the best and the be and the most secure products out there. I agree with you. I agree with you.

Um, so look, our audience is a little of this, a little of that. We've got a, a lot of cybersecurity people we've got, but we also have a lot of developers. We have a lot of cloud native engineers, DevOps engineers, uh, platform engineers.

Where does this, where do you, where do you put this, right? Who, you know, who, who's responsible for getting this rolled out and getting it out there? I think that, uh, 95% of the time it's the application security team or the product security team.

These are the guys that are accountable to make it happen. It's always the CSO organization, even though we've seen developer teams that are trying to implement this, it's one of those program that unless you've got ongoing support and tracking and monitoring, end, end, end, end, end, uh, you're, you're constantly be accommodating backlog. So somebody needs to be accountable.

It's not something that you can do just as you go and swing it. You, you kind of need to have an accountable person saying, I understand the products we're really seeing have access to our data. It has access to our customers.

We need to protect them. Usually at this point you have somebody saying, I'm accountable for product security. Fair enough, fair enough.

Um, a lot of people are, uh, what I'm trying to think of a, a, uh, a, a de a delicate way of saying this, but a lot of people are falling out of love with the whole AI, vape, vibe, coding thing, let's say, right? Where you know, it, it's, you know, a recent study we saw 90% of developers are using AI to generate code. 40% of them don't trust it.

Two thirds of them, almost 65% say it, it, it, it, uh, injects instabilities into the code, but yet 90% of them are using it, right? So 90% use it, and it, that means a good chunk of that 90% think that it injects instability in code. It it, they don't trust it, but they yet they're using it.

What does that mean? What does that mean for Vibe Sec? Is, is that a reason why we need Vibe Sec, or what, what do you, what's behind that?

I, I think it's, it's a very good question because the answer is basically changing on a daily basis. We are in a place that moves so fast with so many alternatives, and the models themselves change so fast. The, the IDs change so fast, meaning cursor, every few days you, you'll see an update.

Yeah. And you're using, uh, right now Cox, CLI and you're using Claude, meaning, it, it, you are still experimenting. We are still in the bleeding edge right now of this revolution.

So if you're asking me, do I trust this? No, I do not trust this. Do I use it?

Of course I use it. What do you mean? Like, if, if I'm not using this right now, I will find it very hard to do my job without AI and, and saying, how come it, it doesn't make any sense.

Like you don't trust it and it, it's become, yes, you are right now in the traditional, um, trust, but verify in the sense that I will write something, I need to read it, I actually need to verify it, and I need to do small changes. And everybody knows that if you've got this long dash, then it means it's written by eyes. So yeah, you kind of need to edit afterwards.

So there are a lot of things that you need to understand and you need to understand how to work with this new technology. It's not just, oh, I'm going to this technology and it'll be fine. You need to change yourself in order to be better with this technology.

It's like, uh, when we, we started having Google like back in a few good years ago, um, you need to learn how to search things. It's not that you're just saying, I just want to search for it. It's like, you need to search, I need to add this word and that word.

The same thing goes with ai. You need to understand context and what does it mean, and this is kind of the fine line between getting the ultimate answer and getting and hallucination not enough data. You'll fall to this edge.

You, you'll provide enough data, you're going to get amazing results. So it's an ongoing process that I think that is accelerating super fast. Agreed, agreed.

You know what, we, we certainly live in a very interesting time right now where we're gonna see how these things all play out, unfortunately, need somewhere we're almost out of time for people who want to, uh, learn more about Vibes SEC and what OX is offering with it. Where, what's the best place for them to go. So we are organizing an online conference, uh, called Vibe sec Con on the 4th of November.

Uh, I think we got wow, a few good thousands of participants already. Um, so how go over there? We're going to have a lot of collaborators, a lot of people telling us from the CSO perspective, from the OPSEC perspective, from the dev perspective, from the research perspective, it's like, where are we going now?

When we are thinking about it? It's, we used to have like a yearly conference on something, but at the pace of the, of the current evolution of those products, every quarter you kind of look backwards and say, oh my God, we didn't understand anything last quarter. We kind of need to rewrite the playbook.

So we understand that this is just, uh, step number one and we're going to continue and do this as a, as a public resource for everybody. Excellent. That's November 4th.

It's a virtual event or in person? Virtual. Yes, it's a virtual event.

We're have a physical Event in Q Q1. Yeah. Are you gonna do a physical event in Q1?

We Are going to do it in Q1, uh, probably very adjacent to RSA. Oh, so maybe the end of March, Maybe. Um, it's still not locked.

Alright, you'll let us know. Of course. We'll be at RSA, you know, we put on our DevSecOps event the Monday of RSA week in, in Moscone with them.

But then we're live all week on, uh, silicon, uh, not silicon alley, our broadcast alley, uh, video. So we'd love to cover it if you do it there. Let me go back to November 4th though.

November 4th virtual event. Vibe sec con ha. Is there a website or URL we can send People?

Yeah, it's vibes. SEC io. Well, on OX website is OX security.

I Ox security. Yes. security, that was it.

Exactly. Fine. You could get and they could get to it from there.

Exactly. Perfect. Neat Sun as always.

It's great seeing you. Thank you very much. Keep the great work.

We'll be watching the development of Vibes. Sec. Pleasure seeing you.

All righty. Bye-bye. Bye-bye.

Neat. Sun Ziv here, co-founder, CEO of OX Security. We're gonna take a break.

We'll be back in a minute. Hey everyone, welcome back here to Techstrong tv. My next guest is Balaji Raghavan.

Balaji is Head of Engineering a Postman, and let's welcome him. Welcome Bji to Techstrong tv. Thank you, Alan.

It's great to be on Techstrong. Thank you. It's nice to have you here.

So, Balaji, head of engineering, talk to me what, you know, how did, how did you wind up? I mean, I'm not sure, is that at C-level position at Postman? Is it how, give us your, your journey to how you became head of engineering here, what that means.

I can go a long way back when I was actually in like, you know, aiming to be an academician and then ended up with, uh, Google coming for an interview on our campus, dropping out of PhD, joining Google in its early days. So I spent a good amount of time growing with Google. So like, you know, I started with, uh, when, back in 2004 on the Gmail team, when Gmail was newly launched and then helped grow it to billion active users along with it, like rebuilding a lot of the systems, recognizing the importance of like, you know, what microservices means, why it is actually important to design those APIs, right?

Et cetera. After that, uh, have also done a startup in, you know, search, which I sold eventually to Lyft and worked as the head of, uh, right share engineering at Lyft for a little while. And then from there, uh, went to another startup in the conversational AI space named Unifor as their head of engineering as a C-level, CTO, uh, grew their AI charter, uh, charter in the last three and a half years.

And, uh, before I realized that like, you know, a lot of these SaaS companies were pivoting towards agent AI platforms, I realized that like, you know, the platforms really didn't exist at all. And to build those mature platforms, you had to start at the basic layer, which is the APIs, and then start building the layers about it. That's when I had a conversation with, uh, our CEO Abena at Postman and started discussing has, he looked at like, you know, MCP and he was very excited at the time about MCP and I realized that like, you know, postman could have come up, come out with a even better protocol than MCP given its proximity to APIs.

So that conversation then, like, you know, went into me taking this role of head of engineering at Postman, and I've been here now for six months. Wow. What a great story.

Mm-hmm. That, that's interesting how, how, you know, it transitioned into a role of postman. And it's funny you mentioned MCP with API, because you know, when the whole age Agentic AI thing started hitting, I had questions about, so kinda what's the difference between API calls and, and agentic AI task?

You know, I get it. There's the autonomy or, you know, autonomous nature of it, the ability to string together multiple kind of task. And then of course the MCP, it's crazy.

The MCPI really, I think it was December it was first announced January, here we are nine, 10 months. And you would think it's been around, it is the, you know, it's the standard. Everyone's using MCP no, even though there might be security issues and other things, but in any event, it, it's, it's become the defacto standard.

In the meantime, a majority of the traffic on the internet are API to API communication. That's Right. Do you see a future where these things kind of merge?

I do see a future where like, you know, uh, systems will have the choice to either like, you know, go with like a higher predictable outcome versus like, you know, potentially ambiguous paths that need to be deciphered automatically. Like, you know, a quick changing landscape, especially like, you know, would benefit from, uh, AI agents. Like, you know, looking at a small percentage of like, you know, requests and recognizing that there's a change in pattern and like starting to operate with that.

And, uh, while there are like, you know, traditional systems that require pretty much like, you know, predictable outcomes over there, like, you know, AI has nothing, no, uh, no, no business. So those will continue to actually operate with like, you know, predictable journeys. One of my friends once told me like, you know, distributed systems a you know, you don't need to bring in a distributed system if you don't need to, but like, you know, if something has to scale better and you are not able to make it scale without a distributed system, that's when you actually like squeeze in a distributed system.

So AI has to have the same solution. You don't put AI everywhere where like in our traditional systems don't scale, they don't actually operate with the expectations of the business. That's where AI basically can be a leverage, It seems.

So, it sounds so common sensical coming from you right outta your mouth. I just wish people would take that to heart. 'cause it seems like we're trying to stick AI everywhere and anywhere I, at Postman, like that's why when we do tooling, we are actually enabling tooling with both like, you know, understanding of the API, which is like the ground truth, and then AI to have like better visibility into the API, so that like, you know, you have better documentation, better details in the SDK to be able to use that API better.

So making LLMs like not have the knowledge necessarily about the backend system, but like, you know, decipher it is a key component of like, you know, actually making agent workflows work better and not put like, you know, all that knowledge into the model itself. And a lot of businesses like, you know, have nuanced business logic that, uh, only their internal systems have visibility to. They can't actually embed it into the models.

So more and more of that logic has to move towards the API, not towards the model. Agreed. So I do think like, you know, as a result, like this, uh, relationship between the models and the APIs will continue to kind of grow.

A lot of people are looking at the low hanging fruit where the model has the knowledge, but like for mature systems, you need both maturity of like APIs and models to evolve. So that is where like, you know, postman at Postman, I'm pretty excited about continuing to operate with that, like, you know, uh, mindset and enabling developers to have both, like, you know, access to both tooling for predictable journeys as well as for AI journeys. Love it.

Bella, if you, if it's okay, I'd like to turn to Postman itself. I had a lot, I think a lot of people, most people in our audience have heard of Postman. They've made a tremendous impact over the last, you know, five to seven years.

But if for people out there, maybe they've got someone out there said, geez, I don't know that I've never heard of them. How would you describe Postman to them? Uh, description of Postman, I would say it's like a, uh, end-to-end API platform, which enables like, you know, two things for the developer and like three things for an enterprise.

The two things that it enables for a developer are, um, collaboration and automation. So when you take your APIs, making sure like, you know, any braking changes is validated through monitoring, et cetera, et cetera, like, you know, all of those things can be embedded in and automated into your CI ICD pipelines before it hits production. So Postman provides a comprehensive tool for tooling for being able to enable that in addition to it for an enterprise.

The third vector it provides is governance. So that, like, you know, any use of your APIs, any, uh, evolution of your API is any breaking changes in your APIs, you have governance on and are able to build, like, you know, visibility into it as well as reactionary, uh, solutions on top of it. I love it.

Now, among around here at Techstrong, you know, we've been covering Postman as pretty much all seven years, maybe longer than nine years years, but we always covered their state of API report, which has become something of a standard in, in, uh, in terms of a, a good, a good peak into a good kind of, uh, judge of, of where we are in this API economy, right? And API adoptions and so forth. Postman recently released its seventh annual state of the API report, 5,700 some odd developers, architects, and executives, you know, taking place.

And I think that was just this year's. Um, give us the headline first. I guess Balaji would, what do you think the big takeaway is there?

Uh, the big takeaway for, uh, me personally is that, like, you know, a, people continue to struggle with APIs and while a lot of people are talking about agents and AI journeys, like, you know, the actual API evolution itself has not happened to enable many of those agent journeys. So when I look at like, you know, just, uh, statistically looking at number of people who are aware of like, you know, CPS and are designing towards like, you know, so AI solutions versus like the actual adoption of MCP, like, less than 10% of active developers have, uh, you know, actually used MCP in their, in, in their workflows, which is a astonishing number because like, you know, if you look at like, the number of posts about like, you know, technology at this point, I feel like, you know, I read 80% about EGEN and MCP when in fact only 10% is adopted. But yet when you look at it, Hey, it's only been around for nine, 10 months, 11 months, 10 percent's pretty good.

But I think, I think what's happened is, is the, the AI adoption hype cycle has gotten so overheated that we just think everybody's doing this. Everybody's using MPC, everybody's developing or managing agents. Everyone of course uses generative, you know, and, and it bears out, you know, we see, we see other, uh, metrics surveys.

90% of developers are using ai, 40% don't trust it. 65% thinks it, they thinks that it introduces instability into the software base, the code base, but yet 90% use it. So the whole thing is kind of cockeyed, if you will, right?

The whole thing's kind of upside down. Um, but that's interesting. 10, 10%, Yep.

In 11 months, there's nothing, nothing to, to sneeze at. What else was some of the key findings, do you think? I mean, the other key finding, I actually, I, I mean, being new to Postman, this is not new for Postman, but new for me, my personally, is the fact that like, you know, I, I know that like, you know, a majority of their teams that are collaborating with like, you know, APIs and microservices tend to be under 10, 10, uh, engineers.

And so that like, you know, wasn't the astonishing number, which is like 84% of our, of, uh, overall teams are less than 10 people. What was astonishing to me is, uh, despite like, you know, so many, uh, teams being under 10, uh, several of these teams still have collaboration challenges with regards to their, like, you know, microservices and a PS. So, uh, when, when you look at like raw numbers and like, you know, we did the survey to understand what are the collaboration challenges they're running into about 55% of the developers were struggling with, uh, just documentation around those APIs.

And, uh, you know, about 34, 30 5% of them were struggling with discovering APIs that are already present within their organization. So, like, you know, despite having several tools available in the market to actually like, solve many of these problems, including our own API platform, which solves most of these prob problems, I continue to see like in our small teams, medium sized teams actually struggling to actually to utilize these tools very well. So I think that that is a key insight, which enables me to write, like, think about like, how do I make this problem completely go away, and like if I can design better for that, like, you know, identify what, what is missing for people to be able to kind of like, you know, solve this with Postman, we will continue to invest in that direction and like, you know, bridge this gap.

It's a huge opportunity because like, you know, first of all, like, APIs have existed for a while, but like, you know, APIs have always been deci designed for human consumption, not for machine consumption. And so APIs by definition are going to change over the next year or two years, uh, to be more machine consumable and like, you know, during that period, we have to solve not only for human, uh, like, you know, discovery of APIs, but also for machine discovery of APIs. So it gives us an opportunity to bridge this gap in the right way to design the right product in that space.

And, uh, I'm pretty excited about that. Absolutely. I got a couple questions on that for you.

When you say teams, you, you could have multiple small teams within a larger organization. com here, right? com and others.

You know, there is that the Spotify squad sort of, you know, 10, 12 members, the, the Amazon two pizza team. So that, that seems like the, the right size for a team of engineers, right? It seems like, like a manageable size.

Um, what's interesting is even in teams of that small size communication, 'cause I would've guessed, well maybe because everyone is remote and we have, you know, remote issues. I'm on a different time zone. I'm in India, I'm in Europe, I'm in California, I need asynchronous communication versus synchronous, you know, maybe that, but that doesn't seem to be what the issue is.

Yep. It, it it very interesting there. Um, and both of those were kind of counterintuitive too.

Like you wouldn't, you wouldn't necessarily think that. What else did you find interesting in the report? I mean, the, the positive thing that I actually was pretty excited about is, um, the fact that like, you know, when you look at, um, uh, the percentage of, uh, developers who are actually, uh, utilizing an a PF first development approach, like and I, that is continuing to increase, it's about 25% right now.

And, uh, several others are like, you know, partially API first. So that number is continuing to increase over time. So that's a very promising number.

The second part that was exciting for me is also the fact that 70% of those, uh, API first developers said that Postman helps them collab, collaborate with other developers. And, uh, the same population, 55% of them said that like Postman also enables them to collaborate with non-developers. So from that perspective, like, you know, the ones that are using our tooling already, it it is clear that like, you know, we are building the right journeys for them.

The ones that are not using our tooling and like, you know, continue to struggle with API collaboration, those are the audience that like, you know, I'm, I'm looking forward to actually like getting more in front of and having discussions on like how postman can be actually helpful for them to continue on that path. Excellent. Um, on, on that front look, I, I think we both agree that we're gonna see more and more code being developed, being written or gen written is the wrong word, generated by ai, right?

The hip. Do you think the AI generated code is going to make the AP AP like incorporate the APIs and API I calls into that? Or do you think that will maybe, so is, so is AI generated code gonna result in us using more APIs, the same amount of APIs or less APIs?

I, I do believe AI generated code will require more because like, you know, there are already solutions being proposed because of like the explosion of number of tools and the tool selection process in like the MCP protocol itself, uh, that like, you know, companies are recommending rather than directly using the tools, uh, to actually generate code to in, to invoke the tools and a like generation of code require, like, you know, will require execution through APIs, so calling APIs. So that's why, I mean like, you know, I do believe that even like, you know, an optimized solution for an agent journey started with like, you know, this assumption that LLMs will be able to directly interface with these services to then recognizing that like, you know, there is, it's a distributed system problem where you will end up with like too many services to call and you have to pick the right ones and you have limited context to do so. So better way to solve that problem is to actually generate the code that can execute and like, you know, call into those a subset of those particular APIs.

So that does gimme confidence that like, you know, I will see continued investment in every company, you know, building more mature APIs so that LLMs are, have less ambiguity in how to use those APIs. Okay. Excellent.

Bala, you're, we're probably a little over time already. These 15 minutes goes quickly for people who want to get a, uh, download and maybe dive into this report themselves, maybe even look at previous reports. Where could I, I, I imagine they could go to the Postman site.

What's the URL and where can they find this report within the site? I, when you just search in Google as well for state of the A API report, postman, you will always find it. Okay.

And I imagine you could ask your favorite, uh, ai, you Can also ask How to find it too, if you're not using Google search anymore. com/state of API state dash of dash API slash 2 20 25. Perfect.

Hey, Balaji, first of all, congratulations on the role of Postman and I think congratulations are in order to Postman for getting someone of your quality on board here, uh, heading up engineering, looking for great things going forward. You're welcome back anytime you'd like, man. Appreciate it a lot, Alan, it was great meeting you.

Appreciate you. Alrighty. Balaji Raghavan, head of engineering a Postman here on Text drunk tv.

Go check out their seventh annual state of API report. As Bji said, Google it, ai it, go to the website, whatever. Just go get it.

We're gonna take a break on text trunk tv, we'll be back in a little bit. Hey guys, thanks for the throw. We're here with Rachel Genos, chief Enterprise Platform Officer for Trend Micro, and we're having a chat about AI and maybe how it will help the defenders a little bit more than just the adversaries because we might be able to maybe see how these attack patterns are developing.

Rachel, welcome to show, Welcome to have, thank you for having me here. No worries, no worries. Um, so explain, I think we're all kind of obsessed these days with what the bad guys might be doing with ai, but is there a, a future where we might be able to say level the playing field thanks to ai because we can see what they're up to and react to it faster than they can do it?

Yeah, so, uh, I think, I think AI is really changing a lot of things and, uh, um, it's not just, uh, you know, changing our cyber defense strategies, it's also helping changing a little bit, you know, like, uh, the, uh, the attackers part. Uh, so, um, what we see is, um, what we see is, uh, so, um, like cybersecurity, LLM it is kind of evolving from, you know, the passive tools and into, uh, very active participants, um, in the threat defense. And right now, for example, you know, a lot of, most of the l lms, uh, used for summarization, enrichment and automation.

Uh, but the next frontier, what we see is the predictive modeling and the, for example, like trend micro. And we are training our, um, our models to recognize not just the, you know, non threat patterns, but the behavioral, uh, signals that indicate intent. And, uh, recently we also have, uh, some of our innovations like digital twin initiatives.

This is also major step forward and it also allow us to simulate, you know, enterprise environment. And, but you know, with that said, and LLN is also helping attackers, which we see recently, we looking at our detections and, uh, you know, in the backend we see, um, a lot of threats coming from, you know, very productive way. And the amount and the quality is also totally different.

And so, uh, we do see that, uh, uh, this is also helping redefining about a lot of attacker behaviors. So this is the interesting timing, Mike. So if I understand what you just said is a combination of not just all these gen AI models, but it's also advances in the predictive models that enable us to kind of see the patterns that the bad guys are using, even though the volume of those attacks seems to be increasing exponentially.

Is that a fair assessment? Yeah, this is fair because, uh, based on our email security detections and recently we see, you know, um, this is like, um, this is like a month of the email detections become so large and huge then, uh, much, much bigger than before. And in the past we don't see this amount of threat.

And of course this is also related to different geolocations. They have different dynamic. And the other thing that we see is not just, you know, the quantity, it's also about the quality.

And, um, you know, um, there's one very efficient attack, which is like the social efficient, you know, social related email phishing. And in the past attackers they need to take time to analyze, um, all the, you know, social related, you know, uh, context related to the person or related to the organization and related to the asset. And today with ai it's so easy to connect the dots and get all the context.

For example, AI is just so easy to get, you know, even external intelligence as well, what you are talking about in linking and what you are, you know, posting Facebook and also internally and what, what is the ongoing, you know, information is flowing and so they can jump in with the right context. And, um, the right context is kind of, you know, the fraud context to our customers. How quickly will all this be happening?

Because right now when it seems to happen is folks will get a bunch of data and they'll get an analyst in the SOC who will go looking through that and kind of try to discern some patterns and maybe apply some policies. But it's usually well after the fact, are we moving more towards a scenario where policies will be instantly applied and then we'll analyze it later to see what it was really all about? 'cause the machines are gonna run faster than we humans can keep up with.

Yeah. So, um, I think I would say this is moving very fast and, uh, let's say the, the pace of AI innovation is generally fast and, um, super, super fast that, you know, comparing to before. And the defenders, um, need to be, just need to be very agile.

And the key is to, you know, embed AI into the operational fabric of the cybersecurity. So not just as a board on a tool, but as a core capability. So, um, like, uh, what we are doing, uh, to micro is, uh, we are doing it this, uh, across multiple layers.

And for example, AI helps us triage the alerts, correlate signals across hybrid environments, surface, uh, very high confidence threats in real time. But it's not just about, you know, automation, it's also about intelligence. AI can help defenders understand why behind an alert and, um, not just the what.

It's, that's the game changer. And we are also like investing in some, um, you know, self explainable AI so teams can trust and also act on AI driven insights. And so the, the whole goal for defenders like us is, you know, using AI as a trust, trusted partner and, uh, one that can enhance human adjustment and, uh, accelerate response and reduce fatigue.

And, uh, defenders don't need more data. They need smarter data. And that's where, you know, AI shines.

And for the attackers part and ai, whatever I say in the defenders, attackers are also smart. They can also utilize AI to help them, you know, get better data, get better intelligence. So this is a really, uh, interesting time is, uh, we need to know how to utilize AI as our partner to work for Defend and, um, continue defending, you know, uh, with the attackers cyber attacks with ai.

Mm-hmm. And to your point about multiple layers, I'm assuming that we'll also see AI agents in that mix, and they will be consuming, uh, output from both predictive models and from generative AI models and causal models and all kinds of fun stuff that's out there. But how will all that get orchestrated?

Where will the intelligence be that kinda enables me to talk to the agents and have them go do something in a way that is, shall we say, cohesive and comprehensive? Yeah, so, uh, for the, I think this is about AI agent agents and also about the agent ai. And, um, there will be a lot of AI agents in the world and in different organizations, and because people say, Hey, you know, yesterday we only work with human, and tomorrow we work with AI agents and the human.

So it's, it's also the, you know, the industry evolvement. And so a lot of people, they are building their a agenda AI system, and that can act automatically and that can also incredibly, you know, powerful. Um, but they also introduce new risk.

And this, for example, these, you know, AI agents or you know, agent AI system, they can make decisions, they can take actions, they can even interact with other agents, which means their attack service is dynamic and also and often, you know, uh, unpredictable. Yeah. So to safeguard them and organizations need to rethink, uh, traditional security models.

Um, for example, we need to apply, uh, thrive modeling to AI agents just like we would for any other critical assets. And, um, we also can start to using some of the, you know, digital twin is not just the physical digital twin. It could be cybersecurity, digital twins, to simulate how these agents behave and their stress and their attack.

And also in very complex environments. And all of these agents, you need to have a orchestration, you know, layer to make sure every agent they are running, you know, beautifully together and coming up with, you know, uh, one mission and to be completed. And sometimes by one agent, sometimes by multiple agents.

That's why a lot of PE people, they put, um, orchestrator agent on top of all of these AI agents, this is already based on your need. And so, um, I think, uh, AI agent is there and, uh, even actual micro, you know, uh, a lot of our organizations, not just the technical team, they start to build their AI agent, they also build their orchestration layer on top of these AI agents to make sure, you know, all of these AI agents can, you know, be, behave, uh, can action, and, but of course always think about the risk. And this is also new risk coming from AI agent, even coming from the MCP servers as well.

And those AI agents will need to talk to, not just each other in the sense that they belong to trend micro, but third parties as well, I'm assuming. So can we get to a model that kind of looks like this, where there may be some predictive analytics that tells me that, uh, there's a wave of attacks coming that are aimed at this particular vulnerability, and then I can pass that on to an agent from the app dev or IT ops people who will then go fix that before it hits. And that's kind of the closed loop that we're trying to get to.

Yeah, that's a great question. So, um, yeah, agent is not just the, you know, trend micro thing. This is entire ecosystem and I think that's also why there's MCP coming up and this is like building, you know, the new protocol to connect all of these world.

Yeah, this is this, this is also something that I talked with the team, uh, who is doing, you know, the API, um, integration in the past. I say, Hey, this is the new world in the past, the traditional way it's API integration. Now it's all about, you know, MCP as the new protocol and how to collaborate with all the AI agents.

And so this is the whole ecosystem. It's not just the micro thing. And micro could have our AI agent to perform different things.

For example, we have our AI agent to digest the logs and also, you know, analyze, analyze logs and which is part of our genetic SIM features. And we use AI agent to do the auto coding and behind the scene so we can support so many third party logs and ecosystems, these data just getting in. And this also means that whenever we achieve anything, we need to think about ecosystem.

That's also, you know, we know customers environment, a lot of time, customer environment, they have 52, some customer has 100 tools, and all of these tools coming together that could help our customers. So I do think, you know, uh, no matter what AI agent we build actual micro and uh, it's also we need to make sure everything is e ecosystem friendly and also ecosystem fit. Alright.

What's your best advice then to folks about how to get ready for all of this? I think everybody's kind of getting the general idea that there's gonna be AI agents that need to be orchestrated and we're kind of have a new way of managing it and security. But what should they be doing today to get ready for that now?

Yeah, so I can give, I will try micro example. Yeah. For example, this is nothing related to security, but of course we want everything to be secure.

Yeah. So this is about, let's say, you know, what we are doing today, Atmic, we have half of our code is generated from AI and a lot of AI agents behind the scene. And we deliver, we build our product software and we deliver this software to our customers.

And so we actually have a lot of different AI agents today, and we have AI agents sitting in the developer side. We have AI agents sitting in product manager side, we have AI agents sitting in the marketing side. We even have AI agent to provide intelligence for our sales seller.

So this is the entire ecosystem. I'll give you one example is for example, if I understand this is the customer problem, I use my AI agent, my product manager, AI agent, to generate the requirement. And also furthermore, is the, another AI agent will help me generate the mockup, the UX mockup, how we will solve the problem.

And also furthermore, we can generate an MVP product for our customers to do. The quick validation, which I feel we still need a lot of developers involved today, is if we want to build, you know, you know, thorough and, uh, comprehensive, you know, production environment, we, today we need developers in, I, I think I can imagine the future. It'll also be, you know, uh, quite improvement, uh, have a lot of improvement as well.

But these are all how AI agents is changing us. And even our HR can build their robot today and they build some robot and looking at all their resumes, and in the past they have thousands of resumes coming in, and now AI agent helped them to filter out. So I feel for everyone, this is also my advice to my team members.

Every single, you know, person, employee, yeah, needs to start to build your AI agent to make sure you know, you know how to work with your AI agent because that productivity is like, you know, um, uh, phenomenally, you know, like changed. And also, you know, one of amazing things I really like AI is in the past, if we want to be a domain expert, it takes time. You need so many years to learn this domain.

You need to learn so many years to learn this domain. And now AI kind of lowered this bar. For example, I see some financial report, AI help me understand what's the context.

I see this kind of another domain. AI helps me understand this domain so easily. And also the interesting thing is AI is also can correlating all the different domain knowledge and tell me what's going on.

So that also reduced a lot of time and effort. So for everyone, I will really encourage everyone start to have your AI agent start to think about, you know, how you can utilize AI to make a better you. So that's my advice.

All right, I like that idea. Make ourselves a better you. But coming back to security, I think the important thing to remember is an ounce of prevention is still worth a pound of cure.

And in ai, we need to do that now in real time. Hey Rachel, thanks for being on the show. Thank you.

All right, and back to you guys in the studio. Hey everyone. We're back here at Qualys Rock on continuing day two afternoon coverage.

Our next guest is also with Qualys, a product manager. Um, I'm sorry, one second. A new ca Kapil Kapil.

Yes, I knew, I remember interviewing a new last year at, uh, Qualys Rock Island. Wasn't it? Was Qualys security Conference Yes.

In San Diego last year. Yes. But it's been a full year.

It's been a full year. Listen, what you've been doing over the year. Well, we have been building the industry's First Rock for all our customer base.

It's the first in, uh, risk operation center. And since I work in policy audit, I have been working on how you can operationalize rock from day one, leveraging policy audit. We also did a launch of policy audit.

It used to be called Policy Compliance before. And this year we rebranded and relaunched with a new lot more new capabilities that helps customers to be audit ready. And that's why policy audit.

Got it. Um, let's talk a little bit about compliance and rock, right? 'cause at first, at first blush, they don't really necessarily go together, right?

I'm, I'm looking at my risk compliance is almost a separate reporting thing, right? The GRC and, and all of that. But they're connected.

They're, they are connected. Let's talk about that connection and how ROCK is helping people with their compliance. Yeah, so compliance and executive reporting is the seventh pillar.

That is the seventh Chevron of Rock and compliance is no longer just a check box. You know, you assist your compliance and prove it to auditors one time. But now most of the evolving frameworks, they have a check that you need to be continuously assessing, and it should be risk-based assessment and compliance.

When it comes to compliance, it should always be proactive rather than reactive, that you are acting when there is a risk combined. So how policy Auditor compliance helps is it helps you assist with the unified asset inventory pillar of Rock, where it, uh, proactively finds out all the technologies that have been running in your default long default locations, helps you to prioritize and for response, provides the remediation capabilities to fix your failed controls. And with the executive compliance based reporting, you can provide those reports to auditors.

And like I said in my chart, misconfigurations are like the leading cause of security breaches. And at the same time, audit failures have a re root cause that is related to missing evidence. And both of them have the same root cause.

That is a policy that is on paper, but not in practice. And whether it's the risk of audit failure or risk of misconfiguration, both can be prevented if you implement your rock from day one with policy audit. That's how we, we connect policy, audit or compliance piece to the rock.

Sure, Sure. You know, when we look at compliance, there's talk and then there's compliance. Yes.

It, it looks like what we're seeing is a lot of compliance coming out of states, you know, California, Illinois, what have you, and then of course the European Union has compliance. Mm-hmm. And then there's sort of non-government complaints, PCI four.

Oh yes. Right. A good example from the, uh, payment card industry.

How does, for the people out here who do this for a living, right? How do you stay on top? Well, I spoke to a lot of customers yesterday and I was really surprised that there are still a lot of them doing manual processes.

They do, I think most do, I mean that's commendable. If they're putting so much hours efforts, there's always chance of failures. And now with more and more evolving requirements mandates, it's not like a one time audit a year.

If you're a big enterprise, you have five to seven audits. And if you're doing it manually, everything is critical. That means you are on a constant fire drill, continuous audit mode, and you don't even have visibility on what you're fixing.

What is the end result? You are just scanning for compliance producing these reports. So, uh, how policy audit helps is it gives you a audit readiness score from day one.

So you don't have to wait for your mandates to come or evolve. 0. We do the mapping for, uh, for our customers.

We automatically map the new requirements to compliance objectives to the reporting. So they can just rely on the tool to automatically update the reports. They can go into the system generate audit readiness report and see where they stand today.

They don't have to slog for months and months of spreadsheet, and they don't even know how the end result that is scary. And at the same time, they're not even managing the risk of misconfigurations that comes from compliance, which is as per the Verizon report, one of the leading cause of security breaches. And it can be prevented if you have your checks and policies in place.

Love it. Um, you haven't mentioned AI very much though, and AI has really been a big change this year. Yes.

How does that play into Compliance Rock and everything else? So Quality ETM platform is moving toward agent to AI yesterday. We showcase that we are now launching our own agent marketplace.

There's a AI agent that is Agent Chang for audit readiness and reporting. That's, you can assign autonomous task with, just ask it to create your risk prioritization plan or ask to onboard assets or detect technologies. It can do all those task autonomously for you.

So you don't have to do, you can just schedule those tasks. You can directly talk to the agent, you can even create your own agents. That's how we are leveraging it across the platform to uplift it for customers so they don't have to do these reporting and they, the team can spend time on other tasks.

Excellent. Anu, thank you for coming on and getting us up to speed. What else can you share with the audience that you'd think they'd be interested in?

Yeah. Uh, so I'm very excited to talk about ETM audit. That's our vision.

Okay. Um, Sumit showcased in his demo yesterday, a little bit of preview through agent and I showcased it in my demo today. ETM audit is on top of ETM, which we're going to build as the vision for ETM and how policy audit helps you with technical control, audit readiness to be audit ready, prevent the risk of your misconfiguration and audit failures.

We are uplifting it on ETM, where we already have customers, connectors, third party data coming in, quality data coming in, and we are going to provide audit readiness for customers for both of their technical as well as procedural controls automatically. 0 itself. You might have a control that ask, do you have patch in place?

Do you have vulnerability scan results? Do you have cloud scan results? Now whether you have third party tools or connectors, we will automatically map that using AI and generate the evidences and reporting for customers.

Love it. Love it. That's really exciting.

Thank you. You know what? I hope to see you next year.

We'll continue this conversation, but in the meantime, keep doing what you're doing. You're obviously doing a good job. Thank you.

Thank you. Nice seeing you. Hey, we're here live at Houston's, uh, Qualys.

Rochan. We're gonna be back. We've got a few more interviews coming your way.

You're watching Textron tv. Hey everyone, it's Alan Shimel and we're back here at Qualys Rock on in Houston, of course, rock On is risk operations, uh, conference. And we're here to talk a little risk operations with y'all.

Let me introduce you to Lesh. Yeah, you got it right. All right.

If you've watched our prior coverage of prior Qualys conferences, like the Quas Security Conference, QSA, you've seen Sheesh talk with us before. But sheesh, most people probably, if they did, they don't remember. Tell us about you, your position at Qualys, a little bit of your journey coming here.

Yeah, absolutely. Thanks so much for having me again. It's always a pleasure to talk with you and your audience so quickly.

Shelly Charle, I look at the products, go to market strategy and now solution architect team for Qualys. My job is essentially to make sure that what I'm hearing from customers is translated as product capabilities and then see to it that our teams are working with customers in making these capabilities map to their use cases and they're successful. Absolutely.

You know, Shilesh, we've done a lot of interviews today and a lot of it obviously around managing risk and risk operations. One of the areas I wanted to you to expand on was, this is more than security, right? This is about more than security.

Part of this whole reason to, to do this is to map the risk and, and the, I don't wanna just take it to dollars and cents Yeah. But to wrap, to to map the dollars and cents Yeah. Of this risk Yeah.

To business operations and how, not just security remediation, better vulnerability management, et cetera, how not just security, but all kind of business operations Yeah. Plays into this risk, right. And risk management.

Yes. So talk, if you don't mind, talk a little bit about, you know, mapping that. Yeah, absolutely.

I, I think one of the parts what, uh, risk Operations Center does is trying to move the conversation away. Like Sumit talked about it from how many vulnerabilities do I have or how many patches do I have? Or do have I implemented MFA, et cetera, to actually what is the impact of me having less number of vulnerability on business operations and the business value.

Now, how we are looking at doing that is essentially seeing that, you know, one on one side of the spectrum, like you talked about it, that there are business operatives or executives, they wanna see everything from what's my dollar value, what's my business impact, how much I'm spending on cyber insurance, and what is impacting them. Now, what impacts them is a simple checklist, is my patch management policy effective or not? Is my ransomware prevention working or not?

Is my permission management working well or not? Now, what we are doing bottoms up with our security audience is to not get overwhelmed with this dollar value and all these policies, we are bubbling up the contributing factors of this true risk, such as if you have, let's say, 10% of ransomware vulnerability, then look like Mr. Customer, you could be in your cohort of lower 50% of customer base.

That would mean when we compare all of these cohort of insurance policies and the breaches related records look like there is a 10% chance of you getting a material breach. And that means your patch management or vulnerability risk management process is of lower maturity. So that's why your true risk needs to come in, in 200 to 300 range, so that all of these upstream systems will provide the result to your executives how both of our improvements would result into me having lesser chance of a breach, lesser chance of me losing money.

So that's how we are trying to tie the cyber risk and exposures to the higher level dollar value and its impact. That was the best, uh, explanation we've had today. So you wouldn't enterprise for that one, you know, That that's one chance of looking into products and actually owning that area.

Yeah. Good for you. Um, you know, Sumit and his keynote today mentioned the phrase that I laughed actually, I spit my coffee outta my mouth, but I told him I'm gonna steal it and use it.

Huh. And that is this, uh, dashboard tourism. Yes.

Right. Or dashboard terrorism even too. Um, you know, and that is, everybody has their own unique view on a dashboard, right?

Yeah. And so whether you're on the security team, the executive team, the dev dev team, the ops team, the DevOps team, right? We're all, we're all looking at different views of the same underlying data.

Yeah. And, and I think it becomes like, uh, it's almost like a Tower of Babel where we all talk a different language. Yeah.

And I don't understand what you talk about, but your people do. And my people understand what I talk about, but not what you talk about. And you know, I think part of the, of the mission for for Rock Yeah.

Is to make sure we're all talking a similar language. Yes. An understandable language.

Yes. Right? Break down the silos that exist.

Yeah. Even in security, there's so many silos, let alone once you go outside of security. Yes.

Talk about that mission. Yeah. That, that's interesting.

Alan, you said that at the end of the day, I, I know there was, was really well put by Sume, you know, as, as an interesting witty command. But at the end of the day, if, if you see the psyche behind the dashboard is also about why am I creating it? 'cause if I don't create it and track it, there's something I'm gonna lose.

But that's something is very, very me-centric or my team centric or my org chart centric. If you have to see even the dashboard, how, what we are trying to say is how can you actually see the dashboard which whole of your company cares about, whole of your organization cares about? And that's where I think what you are trying to, yeah.

Also, what is the common language, right? Which is set by your whole of your company. And though the dollar value and the business impact is generally used as common language, there's still nuances, right?

Like the public sector might not care as much as for the dollar value. What do they care about? What's the risk to my mission statement?

And I was meeting with one of the, one of the really high profile customer in dc what they care about is my mission statement is I need to manage the risk to my agents who are in the field. 'cause that's, there's no dollar value which can be assigned to their safety. So now how we look at it, okay, if you wanna manage the risk and reduce that risk to your agents in the field, what are the contributing factors which make this as a risk?

So now how we help these bottoms up approaches of the security analyst, let's bubble up those dashboards. Let's see to it how your dashboard now maps your company's dashboard and can we actually create one unified way to track it down? And that could be, you know, from your dashboard, how well your company's mission statement, your business value is tracked.

So that's how we are looking at, you know, creating a bridge from me-centric dashboard to whole company centric dashboard. So all of us talk the same language essentially. Got it.

Excellent. Let me bring up another, sure. I'll call you.

So with this whole rocking Qualys has sort of been, some people say eating your own dog food. Some people say drinking your own champagne, whatever you wanna call it. But Qualys themselves has been, have been using it and it's helped in the, uh, Qualys enterprise tru risk kind of management.

You know, they've been learning lessons internally as the bottom line here. Can you talk a little bit about that? Yeah, great.

Great question. Actually, it's, it's a two part answer if I may. Uh, so Rock is obviously a program, and now program includes your people, technologies and tools and your processes around it.

So Qualys is transforming its own platform to be the world's first risk operation, center driven capability or the product which would help customers tie all the chevrons in the risk operation center together. So how can we get best asset inventory, which would become the base of your rock? How can you now get all these exposures together, which are typically used by these 70 plus What I'm hearing, Alan, like customers typically use 70 plus security products.

That's What I hear too. Yeah. They all generate their own.

So how do we actually bring them together? How do they then correlate your threat feed business context so that we talk the same language so that we are able to actually prioritize the risk which matters to business and then try and reduce it and produce that report as an evidence, as an outcome to our compliance auditors. Now, as all of these chevrons, we are trying to actually cater using the ETM as a product where all these capabilities will come together, where our true risk algorithm will work on all of these data indicators.

We created true risk, eliminate capability to help customers reduce the risk. How now that would come together to help customers reduce the risks. And now at the end of the day, we are not saying that you just call this product.

Well the ETM, you can just connect your other products as well. If you like your, my, i, I don't know, maybe your SCCM product to reduce your risk, it's okay. Like just create a job from ETM in your product to reduce your risk.

That's from the product side. What we are creating now, like drinking the own champagne part, as you all know, call this is the biggest FedRAMP authorized platform. Um, probably number fifth in overall IT and security spectrum.

So we have our big FedRAMP audit as well as our security teams. They all need to do, guess what? They have to all cater to each of these Chevrons in own manner.

We used to use our own inventory differently. We used to use Qualys for assessment, we used to use another tool for reporting, et cetera. As we are combining all of these data points required for say, key elements of FedRAMP, what are the key elements of FedRAMP?

We need access control related requirements, vulnerability management requirements. Now all of these are getting unified signals to go into their audit reports. So this is what b and d outcome of our ETM.

So every time, you know, customer comes in, in our data center, if you actually go in sometime Alan Niche, we should take you to our data center sometime to show you that. I'd Love it. Where is it?

So it's in two places. One is in us, the other one is in India where our teams actually have three types of monitoring. One is your knock, which is network operations, right?

On the right hand side we have soc, which is security operations and the right in the center, which now sit our rock, which is a risk operations center. Excellent. I, you know, I may take you up on that.

Alright. What do you mean? We'll go from there Sirs, we're about outta time.

These are only 15 minutes. I appreciate you as always coming on here. You know, I always, I I tell you the truth, I always listen to you talk.

This is maybe the third time we've died and I say he's the guy who gets it right. He, I, I am sure Siresh is leaning on him for a lot of these things and you have a great handle on this. Thank You so much.

Thanks For all. Appreciate Having me. Appreciate really always good.

You and your team. Thank You. Absolutely.

We're live, we're in Houston. We still got I think one or two more interviews. Two more interviews today.

So stay tuned. We'll be back on in just a moment. You're watching Textron tv.

Hey folks, we're at Atlassian Europe and we're talking with Tiffany Tow, who's executive vice president for platforms and Enterprise and we're having a little chat about cloud and ai. Tiffany, welcome to the show. Thanks So much, much for having me, Mike.

My pleasure. Um, you guys have announced that you're gonna end the life Atlassian data center, which probably doesn't come as much as a surprise to folks because you've been pushing folks towards the cloud for a while. But, um, why now?

What's the transition that you're trying to achieve and well, how far are people making that migration anyway? 'cause you've been at it for a few years. Great question, Mike.

And you're exactly right. It did not come as a surprise to any of our customers. We've been investing so much in our cloud platform the last seven years.

Um, and as folks hopefully saw in the keynote so many new things in terms of AI and all the collections and the system of work deliver all this new business value for customers. Um, but why now? A big part of it is, as we talk to our customers, many of them have been migrating to cloud.

Uh, 99% of our customers have some bit of footprint already in cloud. But what we hear from some of them is that sometimes there can be inertia in their organizations, right? Many of them have had data center for 10, 15 years.

And so being able to make a clear timeline for them that says, this is when March, 2029, it's time to be off of data center and into the cloud platform, enables these teams to start planning right backward from that timeline within their companies and start to build a business case. Because quite frankly, they're not migrating from, uh, JIRA data center to Jira Cloud. They're moving from kind of traditional behind the firewall, siloed, uh, products that work very well and have scaled, but into a cloud platform.

And that's what it's all about when it comes to ai, right? Every customer that I talk to is so excited about bringing AI to all of their workflows, but to do that, it's gonna be leveraging cloud technologies. It's gonna be leveling how these systems are built out on the cloud.

And so for many of these customers having that balance of new value by real rebuilding their workflows with AI in the cloud, and then also having new deployment models in the cloud to support even the most regulated industry customers. Um, we've announced that we have support not just for, uh, high levels of security with Atlassian Guard on top of our commercial cloud, but we now have our gov cloud for our US government customers that has FedRAMP certifications soon to be IL five as well. Uh, but we announced isolated cloud earlier this year.

And so isolated cloud gives you, um, a dedicated tenant. You have isolated, um, uh, compute storage and networking. And so that's a great environment for some of our regulated industry customers and we'll support that, not just in the US but all of our data residency regions.

So mm-hmm. So in effect, I get a private data center is just on somebody else's infrastructure. Correct.

Um, what's been the reception to that concept among folks who do have those requirements for compliance stuff? Are they willing to do that? Because a lot of them seem to, sometimes they wanna hug their servers and they're like, I own my infrastructure, but you know, psychologically speaking, that may not as be as, uh, compelling as an issue if I have a private cloud, right?

Mm-hmm. No, you're right. And I think that's also another reason why it's been great to actually put this announcement for a send out because we can start to have these conversations with these customers.

Um, what we're hearing has been really positive. I think initially we had, uh, a very small set of customers in the US that we thought were gonna be going on to isolated cloud. But once the announcement came out, we've been hearing a lot more demand for it.

And not just here in the us but you know, obviously we're here in Barcelona at the Team AMEA conference. Um, we've had a lot of impromptu meetings these this week from customers here that are excited about looking at an isolated cloud environment for them. So yes, there's gonna be a, you know, change management is, is always hard as, as you alluded to.

Um, but I think the signal we're getting from customers is that the excitement to rebuild all this with AI in the cloud and a clear timeline enables them to start putting plans together. Mm-hmm. See that point, does AI not force the issue?

Because ultimately I have all these models, I need to expose them to data, and the more data I expose to them, the smarter the models get, that all lends itself to the cloud. Because if all my data's sitting in some isolated data center somewhere, I'm really not gonna be able to do that as efficiently. You're exactly right, Mike.

Um, for, uh, customers, a lot of what we discussed with them is, look, everyone is using, uh, AI on the consumer side, and that's all one uniform data set, right? It's everything on the web is the data set that feeds Chad GT. But when you think about harnessing the power of AI for your company, how are you gonna expose all of that data?

And oftentimes that data doesn't come from one vendor. You know, they have products from Atlassian, they have products from Microsoft, maybe they have products from ServiceNow, Salesforce. And so being able to provide that rich context to customers is gonna require a lot of interoperability between these platforms.

And that's gonna be done best in the cloud, right? And you, you see that right now with, um, a lot of the conversations around MCP model, context protocol, how the agents are gonna access this data, how the agents are gonna work together. So you're spot on.

Any customer that wants to bring AI agents into their workforce is going to have to be able to build some sort of platform strategy that connects this data together. Um, and that's why we've built the teamwork graph. Um, hopefully you've heard a little bit about that.

The teamwork graph as I understand it, is the, the thing that maintains the context and discovery and the relationships between all the various components that are in the cloud or in the SaaS applications, but not just your applications, third party applications as well. So, um, a lot of folks probably don't know what a graph is, but explain, yeah. Um, a graph is really important because it's about the relationships between the data, right?

You can have all of the data sitting there in buckets, but if you don't have, uh, an understanding of how that data is related to each other, what kind of insights can you draw? What kind of insights can an agent draw? What kind of context can you give it?

And so the teamwork graph was born from, um, kind of pre all this AI stuff, but at Atlassian, customers were asking us to help them get more insights from the data that was coming into the system. And like you said, not just from, you know, Atlassian's products, JIRA, confluence, JIRA service management, but they often are using a pretty rich set of developer tools, right? And other functions, Salesforce, et cetera, bringing in data.

Mm-hmm. And so as we started to look at the relationships between that data, we saw that we could be quite opinionated about it because the way teams work, uh, is usually modeled in a specific way. Development teams have certain objects that they're using, whether it's, you know, repos, right code, et cetera.

Uh, teams work around goals that they're setting for themselves. They're managing projects in Jira. So all these data objects have relationships together and context.

And so we started to invest in making that bigger and bigger. And you, you saw in the keynote, we've got now billions of relationships now between all those objects. And so what that means is think of it as a very unique fingerprint of your company.

And so what that means is when you log into our systems and you make a search query, or you initiate some task, it knows Mike, it knows what projects you've been working on, it knows what team you're on, it knows what your team is working on. And so it doesn't just look at the structured data to answer these questions, it's actually using the teamwork graph to provide context for the query. Um, and now it has memory, as you probably saw in the keynote, right?

So it makes your agents smarter and smarter about the way you work, but also the way you work with others in the company. And that's the really hard bit, right? It's like there's personal productivity and there's team productivity, and those are at very different levels.

And I think the teamwork graph, um, is really exciting because we're starting to see not just, obviously our own teams build experiences on top of it, but we announced, um, today that we're opening it up. And so that means people can extend and add their own custom objects into it. They can pull from the graph and build their own applications off of it.

So we really see it being kind of an, an exciting piece of, uh, making AI really valuable, um, for customers. And That goes back to what you were talking about with context and my personal preferences, and everybody has a slightly different way of working. Does the AI agent in that context become, um, my primary engagement partner?

Mm-hmm. Or am I managing a hundred agents that all have different kinds of memory and different kinds of experience? How do I kind of marshal this small army of AI agents?

What's that gonna look like? That's a great question. And I feel like, uh, the whole agent strategy and what that workflow is gonna look like, has been evolving so fast the last six months, right?

I think initially it was, Ooh, everyone's gonna have an agent. You know, Mike's gonna have his personal agent. And then it became, well, no, he's gonna have hundreds of agents and they're all gonna do lots of stuff.

And then it became, okay, well, every company's gonna have thousands of agents. How are we gonna manage this? Right?

What we've been hearing from customers is they want simplification. You don't, you want to not have to think about managing a whole set of agents. So we're trying to provide a good amount of flexibility right now because we recognize customers are gonna try lots of different things.

And across the wide range of use cases we're seeing, there's probably not a one size fits all. Um, but we believe what's really important is the skills that you're endowing those agents with. So part of what we announced today is, um, a really large library of several hundred skills that an agent can have.

So you could choose to build one Uber agent for Mike that has all the skills. It can do a bunch of admin tasks for you. It could do your core work, it could do personal work, it could do all sorts of things, or maybe you don't like that and you'd prefer to have very separate siloed agents.

So we wanna give you that flexibility to be able to do, um, the model that you'd like. So I think there's gonna be a lot that shapes up over the next, um, six months year. But what's exciting for us is we're seeing customers customize, uh, tens of thousands of agents and give those agents the ability to, uh, go and actually initiate workflows in our system.

We're seeing millions of workflow automations being triggered by agents already. So, uh, we believe that probably Atlassian right now is probably one of the largest AI workflow, um, generated platforms. Mm-hmm.

To bring this full circle, a lot of folks who have their own data centers will be concerned that their data doesn't wind up training an AI model. So how does Atlassian kind of protect everybody's data or isolate that data from all the other AI models and agents that customers might be using in the cloud? That's a really important question.

I get a lot from our customers. So the models that we use right now today, we work with OpenAI, we also work with Meta and have their models. We do not share any customer data with those model providers.

So the Team Warcraft data that we're using to provide that structured context, it's only used when you're querying. And so it's providing that grounding so that you can get the right response back. But we're not sharing any of that data directly, um, with the model providers.

And it's also isolated, uh, per customer, right? So each teamwork graph instance, right, that we're training is for that particular customer. So, um, it's a really important question that I know customers, and if they wanna see the architecture diagram, we've got a lot on the website as well that kind of goes through exactly what, um, the life lifecycle of that data goes through.

So, uh, All right. Hey folks, you heard it here. You're going to the cloud and there's gonna be a lot more functionality and a lot more features and things you never imagined you could do.

So better do it sooner than later. Tiffany, thanks for being on the show. Thanks So much, Mike.

All Right, we'll be back in a minute. Hey, everybody, we're back at Atlassian Europe and we're talking to my good friend Andrew here, who's the customer, CTO for the Atlassian Williams F1 racing team. Andrew, welcome to show.

Hey, Mike, thanks for having me. How did this whole relationship between Atlassian and Williams come about? And, and, and, and why Atlassian and how did you guys like decide that Williams was the team to be?

Yeah, so, um, earlier this year we signed on as a title partner and technology partner for, uh, Williams Racing. Uh, and initially we, we were having a look at many teams and, um, it was clear that Williams had a great culture. They were, um, on the, a similar journey to, uh, to the top.

Uh, we felt like we could support them in getting there, uh, and they really felt like teamwork and technology was gonna be the key to help them get back to the top of the grid. And when you're looking for better teamwork, who do you come to, I suppose? So what were they using before they found you guys, and what have you done as the technology partner to upgrade their environment?

Yeah, so, uh, if you look at the history of Williams racing, they haven't really invested too much in technology, uh, in terms of knowledge worker technology, uh, over the past 10 years. Uh, and so they were using a variety of, of different tools. Um, however, if you look at the different software, the different collections from Atlassian, uh, we're leaders in, in every market that we play in.

Uh, and so we came in and we had a look at, um, how are they working? What kind of products are they using? How could we help?

Uh, and so we've started rolling out our teamwork collection there, uh, and the re uh, Williams are really seeing a massive uplift, uh, as a result of that. Yeah. So are they wor, are the engineers working differently now together?

I mean, you know, gimme an example of what they're doing that they probably weren't doing before, or should have been doing before. Yeah, I mean, uh, a good example is what happens at the track. Um, so a lot of people dunno that when a Formula One team turns up to a track, uh, they have a garage.

When you see it on tv, it looks great. It says Atlassian everywhere, lots of shiny cupboards, two beautiful cars inside. Um, but the reality is when a team first turns up there, it's an empty concrete box.

They, they start off by painting the floors. So that's the level of work that needs to go into it. And a lot of people don't think about what does it take to get all those things there and set it up.

Uh, and one of the, one of the things that they were doing we're tracking basically in a notes app, all the tasks that had to be done to set up a garage. Uh, and as a part of that, there are incidents and things that go wrong, uh, that they also need to keep track of. So rather than using a a Notes app for that, which, uh, wasn't really giving them a lot of insights about repeat issues and, and ways they can improve, we transitioned them onto Jira.

Uh, where now we have a repeat, uh, uh, repeatable cycle. Uh, the tasks are assigned to people when something goes wrong, they're able to, uh, log it as an incident, talk about what's happened, uh, and that way after the race, they're able to go back and see how they can improve and how do they avoid those things from happening again. Uh, an extension of that actually is they can ask Rover at the end of the day, how was the setup today in Singapore?

Uh, and Rover will give a report about what's been done, what's outstanding, uh, how many incidents happened, uh, which really helps, uh, in terms of continuous improvement, How big is the team and is it the same team that goes to every one of these cities where the race is at? Yeah, a lot of people don't really think about the size of Formula One team, and they're surprised when I say there's about 1,100 people who were at Atlassian Williams racing. Uh, I don't remember the exact number of people who traveled to a race, but I think it's like 80 people go to a race.

Uh, and so it's not always the same 80 people who go every week to different races, but, uh, they have different teams. So for the, for example, the Garage team that I spoke about earlier, uh, they have, I believe, an A and a B team. Uh, so they're setting up two different tracks at the same time.

Yeah. So how is the team doing from your perspective? Yeah, they're doing great.

I mean, it's been six months since we, uh, started working and we're already seeing massive improvements, uh, in the way that they work. Uh, we've reduced how many meetings they're having. Uh, we've been unlocking knowledge between the different teams, uh, at a, at the, at the race team, uh, predominantly using Confluence and Rvo.

Uh, they're seeing great benefits from using Loom. Um, that was one way of cutting down meetings, but also recording meetings, uh, which gives you a nice summary with nice actions, uh, automated as a result of that, uh, is also paying some big dividends for them. Um, are the engineers discovering anything or they, they didn't know before?

Or are they finding duplicate efforts or anything like that? Yeah, I mean, if you look at any company, they, they're problems that happen, uh, in any company where you have people working on the same thing or the same thing in different ways. Uh, I think it comes down to a few things.

It comes to prioritization and to, um, visibility across what people are doing in different teams. If we, if we talk about prioritization for a second, um, their, their top level goal is to improve lap time. Now, the thing about Formula One teams is they have a cost cap.

And so nearly all the people they hire are trying to contribute to reducing lap time. Uh, and so then it becomes hard to prioritize because everything is contributing to the overall goal. Uh, and so what they've been able to do using JPD is define what is value for them, uh, what does it mean to reduce lap time.

They put all of their ideas in one place with all of their data that supports that idea. They can track how much effort something will take and the impact they think it's going to have. And it becomes a really nice way for them to prioritize what's important for them to work on right now, versus something that we can work on a little bit later on.

I would imagine that they're also trying to prioritize their own efforts, but a lot of the knowledge you seem to be capturing used to be, you know, what we call wet wear between somebody's ears. So have they kind of figured out that they can now maybe, um, you know, if somebody leaves the team, it's not as catastrophic an event because there's, um, the tribal knowledge is captured. Yeah, absolutely.

I mean, um, as a part of the design of the car and when they're, when they're doing their aerodynamics, uh, a lot of the information was captured in places where it was only accessible to one or two people or, or a very small group of people, uh, which is problematic when, um, that's the very beginning of a process. 'cause that that information, uh, results in the design, which ends up in the wind tunnel, which eventually ends up as a part of a car. So there are many people who need to contribute to, um, that process.

And so having the very beginning of that process locked away, uh, doesn't enable the, a nice collaboration flow, uh, throughout that value stream. So now that it's being captured in Confluence, it's indexed by rvo, uh, and people are able, are able to surface the right information at the right time throughout the, uh, the end-to-end process. And the thing that's different about all this with the AI is that, as least as I understand it, it used to be somebody would stand around with like a clipboard and then capture data and then type it in somewhere that nobody else could access it.

Um, now it seems like the AI agent is actually capturing all that data and then sharing it with the team. So I'm not sitting there doing a lot of data entry. Yeah, I mean, so with, with the Atlassian platform, the, the most powerful thing is actually the teamwork graph.

So people don't really have to go too far out of their way to put information somewhere. We try and connect all the different elements into the teamwork graph so teams can put the information where it works for them, uh, and, and it'll still be accessible through the platform and through vo. Yeah, Because I think half the battle we see with any application is nobody actually wants to spend time putting the data in there, which kind of defeats the purpose.

So, um, are we gonna get the value out of the software investments that we've been making all these years in ways than we never could before? I Think there's a different way to think about things now. Uh, I'll be speaking to a lot of customers at this conference, uh, about standardization and why they wanna standardize the way teams work.

If you think about what a why people wanna standardize is so that information is stored in a consistent way in a, in a place that people can find it and digest it easily. But teams don't want that. Teams wanna work in a way that works for them in a way that supports them to go faster and get to their outcomes faster.

The beauty of teamwork graph and robo means teams are able to work in a way that goes faster for them, maybe with minimal standardization, uh, but other people in the company can still find that information without knowing exactly where to look and in an expected format. Uh, and so now we, we kind of solve that problem around standardization and, uh, limiting the way that teams work through the use of rvo and the graph. Are they consolidating the number of tools they have?

At least I know in my job, my issue isn't necessarily that I don't have a tool. It's more like I got too many of them and I can't quite figure out how to make them all work together. Yeah, I mean, obviously, uh, they're huge advocates of the Atlassian platform.

Uh, and so it's more around enterprise architecture and what products should we use for different things. Uh, and so they are centralizing on Atlassian. Alright.

Um, are they playing around with AI agents? Are they gonna build their own or what are you guys thinking? Yeah, they've built, uh, they've built many different Rover agents.

Uh, we had a session this morning where, uh, Richard Slaughter from a WR spoke about, uh, a wind tunnel tapping agent that he built. So he had a lot of knowledge in his head, actually. He used to be an aerodynamicist.

And, uh, he's captured all that information in the platform and built his own rover agent so that he can reduce the number of questions he's being asked, uh, about this particular thing. And people are going to the agent now, he's actually been tracking how many people are hitting the agent, and he counts that as a benefit to him. 'cause all those people would've come to him in the past.

Yeah, You hit on an interesting point, right? 'cause there are people who are specialists and they have a lot of knowledge, but I might argue they spend half their time just answering questions from the rest of the organization rather than doing what their real day job is. So will that change the way we think about general purpose workers versus specialists and, um, the way we might even organize our companies?

I I think about it in, um, this concept of low value collaboration and high value collaboration. So low value collaboration is something similar to what you described, where you have someone with deep expertise, people contact that person to extract information that's low value for the person who has the information, even if it's high value for the other person. So overall, that collaboration is low value.

'cause only one party gets, uh, gets benefit from it. High value collaboration is, uh, what I think is being enabled through ai, which is, um, they can go to an agent, they can get the information they need, then if they need to work together on something, both parties will get information because, but get value, uh, because the person who was originally asking the the question has enough information to have an informed conversation rather than asking basic questions. Yeah.

So at the end of the day, um, am I gonna get more work done or am I just gonna have less stress in my work life, per se? Uh, I think about it in terms of value, right? Like if we think about the person who is answering questions, that's low value for them.

If they're an expert in something, you want them spending as much time as they can working on whatever's, whatever's their area of expertise. Uh, so I think by uh, introducing ai, we're able to free up that person's time to spend more time probably on the thing they like doing rather than answering questions. If that reduces stress or not, I don't know, depends on the individual.

Is Williams trying to figure out, you know, how much of a productivity boost they're seeing? Or are they just kind of accepting the fact that everybody seems to be working more cohesively and with less toil and that's the benefit in its own right? Yeah, Productivity.

Productivity is an interesting one. Uh, academics have been trying to measure productivity for decades unsuccessfully. Um, but absolutely we're looking at how can we be more efficient?

So where is there time wastage in the things that they're trying to do, and how do we reduce that? And that shows up in different ways. Like it shows up in number of meetings or effective meetings, uh, you know, how many emails are being sent, things like that.

Uh, where we often see efficiency traps, um, is showing up. Yeah. So you've been working with them for a while.

What's the one thing that you know, kind of surprised you to discover? Actually, their culture is very similar to the Atlassian culture, where, uh, people are very supportive. Everybody who works there really loves their job.

Uh, they're all happy to be there and, uh, they're teams who want to collaborate. Uh, and so for me, it's an absolute pleasure to be able to enable them to do what they already want to do. All right, folks, you heard in here at Atlassian Williams is a winning team, and when they actually win the next trophy, we'll see.

Hey, thanks for coming by. Thanks a lot. All right.

Hello everybody, and thank you for attending my DevOps experience session. I'm gonna talk a little bit today about DevOps and the secure software development framework. I know I call 'em allies for security or opposing forces.

I'm not quite sure. I kind of think that the first one's true. So what we're gonna cover, um, we're gonna talk about a little bit about the secure software development framework.

However, this is not a, a session that really educates you on it. So if you have, if you haven't learned about it, take your time and go read about it. Um, because for many DevOps teams, the secure software development framework can feel a little bit more like, uh, you know, being chained or breaks on your speed and agility, but I don't think it has to be.

So we're gonna explore in this session whether DevOps and this, the secure software development framework or SSDF or allies or forces in Intentioned, and I think they are a little both. So the challenge here, you know, what is the problem I'm talking about today? And, you know, over the course of time, all of you have heard this more than once.

DevOps makes you go faster. It emphasizes speed, speed, automation, and agility. But if we think about what those things mean, it means delivering new innovation faster to our end users.

But at the same time of delivering this better product and doing it faster, we also have to be more secure. Um, and the secure software development framework is really a prescriptive, uh, a document that emphasizes prescriptive controls, very specific tasks, um, and documentation to keep the software we're delivering safe. So tensions can arise when security feels like, uh, it's really not helping, it's just a slow down.

Now, I have to, I have to tell you that, uh, at the Open Source summit back in, um, in, in Denver, in, I believe it was in June, I held a kind of an open discussion on this topic. And not everybody was that excited about doing security through the DevOps pipeline. And I wanna say, in my opinion, in my very humble opinion, and I've been doing this for a very long time, we really do have to evolve to DevSecOps, and that at least is generating an S one folks.

And we're gonna take that a little farther here. We're gonna talk about doing more than just generating an SBO m but yes, maybe sbo oms aren't completely accurate, but at least it's the beginning. So the challenge again is how do we continue to be fast?

How do we continue to innovate at the speed of DevOps and add security tooling into that? I, it seems like an impossible challenge, and it might be, but the dis the discussion is pretty critical at this point. And where does this, the friction really emerge, right?

It's, uh, many, many people at the conference talked about, um, the lack of compliance requirements after deployment. So why are they worried about it in the, the, the dev, the the CIC pipeline, other than doing some scanning? Um, they don't wanna have to do the documentation.

There's documentation overhead. So there's a, there really is a balancing act between speed and accuracy and security when we talk about adding the secure software development framework or the SSDF into the CICD pipeline. Uh, and that in essence though, to be quite honest, that's where it belongs.

We can try to do security outside of the, of the pipeline, but the software factory floor is where the game is. That is where we can stop it. That is where we can begin tracking it, we can gather evidence, we can start tracking post-deployment issues, so we understand how to respond to vulnerabilities.

There is so much that we, as DevOps engineers are not necessarily taking on that we can take on. And I hope that I can convince you that it's time to start looking at these compliance, um, uh, like the, like the SSDF and sort out, maybe you should start looking at it and start adding some tools to your pipeline that can help you achieve the compliance levels. That is pretty basic, pretty basic stuff.

So, who am I and why am I lecturing you about DevOps pipelines and SBOs and security? Um, my name is Tracy Reagan. I am the CEO of Deploy hub.

I have been around for a while. I've been doing software configuration management, um, for pretty much my entire career. Uh, I was a consultant on Wall Street, and I got a, uh, a, a job working for, um, UPS when they were building out one of their big fact, their big, um, I would call it logistics and, uh, supply chain work.

And I learned about builds at that point. I got assigned to doing builds and writing make files. And that has taken me on an amazing journey, uh, that is really specific to how software is constructed, how software components are brought into the supply chain, and what it really means to have a dependency and the impact that that dependency can have on your code.

Uh, so I, I love this space. It's given me an amazing career. Um, I've also, pre previous to Deploy hub, Steve Taylor and I started a company called Open Make Software.

We created a product called Meister, and we really enforced which libraries you can consume in the, uh, c plus plus days when we were trying to do object oriented, uh, coding. And believe it or not, that tool is still in, um, is still being used by some major companies. Uh, I, I'm also a founding board member of the Eclipse Foundation.

I've been involved with the open SSF and the Continuous Delivery Foundation, uh, for quite some time, both since their inceptions. I'm on the governing board of the open SSF, and I still serve on the Technology Oversight committee for the Continuous Delivery Foundation. I give you that background so you have some faith in what I'm telling you.

So why, why should we bother with this? Well, it's kind of important. Um, according to IBM's, uh, data breach report, uh, vulnerabilities can cost you some money, nine and a half trillion dollars globally, um, 250,000 CVEs today with over 50% of them targeting the US government.

Um, we're looking at meantime to remediations. Uh, you can exploit it in less than 10 days. Uh, but it takes us over a hundred to, to remediate.

You know, some companies are doing better, they're getting 70, 60, you know, two months. They can get it fixed, but it's still not good enough. We have all of these tools that we are working on, uh, but many of them are not in the software workflow factory.

They're not in the CICD pipeline. And oftentimes we don't even know when a new vulnerability shows up that we need to fix. It's critical or high risk.

And I do hear things like, Hey, we should fix every vulnerability, but I don't know if we have 250,000 CVEs. Is that a realistic goal? So we have some, we, we have, we have some, uh, you know, come to Jesus moments, so to speak, to really understand how we should address this problem because it can be catastrophic.

Um, you know, we all talked about long for J, but one of the most interesting, um, use cases for why it's important to secure the software, uh, supply chain is, uh, the war in Ukraine, uh, in 2022, um, after ViaSat's, uh, satellite attack, and that was on, uh, modems. It was called acid rained. Those are on edges, right?

The edge, these edge devices, another 124 cyber operations targeting a space sector were recorded in the conflict. So yeah, it's time that we really, um, address this and, uh, start thinking about it. Not that everybody is running as critical as a war, but it can be pretty essential if you are exposing your customer's data and, uh, your data has been breached.

So let's think about where DevOps and the SSDF might align. Um, first of all, automation, um, of, of these tasks within the CICD pipeline is a really, really core spot for us to have this discussion. Building out A-C-I-C-D pipeline, we have done a great job of pulling in some of these tools, but we've kind of gotten lazy, I hate to say that, but we have kind of gotten lazy.

Our pipelines are working. We have so many workflows that we would have to update even to add SOM generation. It's a lot of work.

I don't, I'm not saying that it's gonna be easy, but it's important because these are basic shift left security principles that we've all been talking about for some time and just having just, you know, code analysis one time. Maybe it's just not enough. Maybe there's some other new tooling that we should be looking at, like signing for example, at the station that is also critical.

That should be, also, should be also tracked and understood through the CICD pipeline. So both, I believe the SSDF and our DevOps community ha have a commitment to deliver secure and resilient software to their end users. Everybody wants to do that.

Nobody's out of that cycle. We all wanna do better, but it is work. It does take some understanding of the tooling, and we're going to kind of jump into that.

So you, the DevOps teams, you guys are so key to this. It is you who can do the automation of the tooling that's coming out of these security teams. Um, you're key to implementing so many aspects of the SSDF and without you, the SSDF just becomes a document, um, because you do sit at the heart of the automation, and this has to be automated.

We can't do things one at a time, and it really is about automation. Now, not every single task within the SSDF is about workflow automation and do not include task that should be in your CICD pipeline. But there are many tasks that do require automation through the, through the CICD pipeline.

And you as the DevOps team are super critical to making sure that we're transforming these practices to address the SSDF, understand what it's trying to tell us, and add these security controls into this repeatable, scalable workflow. And other words, we need real time security at DevOps speed. And how do we get there?

There's a bunch of open source tools for DevSecOps. I, um, am amazed how many tools are out there. And there's new tools coming out every day that are open source tools that are addressing some of the SSDF tasks that you can implement fairly quickly.

Most of them have ACL I. Um, some of them, um, are, are as simple as a kind of a, a tracking mechanism, but they're out there to be consumed and to be used. Now, the SSDF is broken into four primary categories.

Prepare the organization, protect the software, produce well secured software, and respond to vulnerabil vulnerabilities. There are many ways to see this information, um, and we, we need to understand that we have to break it down into some individual parts so we can apply those four principles to the DevOps pipeline. The problem becomes, there are so many tools out there, and where do the tool, where, where do the tools fit?

Are they build tools? Are they deployed tools? Are they scanning tools?

You know, do they go on the build? Do they go post-deployment? Are they responding to vulnerabilities?

There are so many tools out there, and it's time that we really understand which tools fit in what areas that support, uh, delivering the tasks of the, the software, the secure software development framework. So the good news, um, of course, if you know me, you know, I like to start things. And recently I started, um, with a group of, of folks, uh, one woman by the name of case Ella, who used to be an, a security architect at IBM.

We pitched to the Continuous Delivery Foundation, the idea of A-C-I-C-D cybersecurity sig. Um, we got some amazing people that immediately, uh, jumped on board and started looking, um, at how to solve this problem, CICD and cybersecurity. And what we decided was that we wanted this sig to play a real pivotal role in advancing security and supporting organizations in meeting modern cybersecurity demands with a focus on integration frameworks, best practices, and emerging tooling.

Emerging tooling was probably the most interesting area to us because we didn't wanna build another, um, another SSDF. There's plenty of, of, of standards and compliance that we can follow. What we wanted to do was to expand on it.

We wanted to expand on it by identifying tools that could be used to achieve the goals set out in the SSDF. We're also gonna work on cyst and do some mapping between some of the other, um, frameworks. But we started with the SSDF and we would created a guide.

So we started working first on just lists of tools that could fit into these, these seg these categories within the SSDF. So we built a guide that helps DevOps engineers build the security compliances in the CICD pipeline by mapping open source automation tools for security into, um, the SSDF identified by the SSDF framework and where it needs to go. So our SSDF guide is ready for you today.

Um, it is going to be officially launched October 1st, so you're getting it, um, a little bit early. But the point is, it's out there. It's out there for you to, to take advantage of.

It's out there for you to contribute to, it's out for there for you to say, Hey, you forgot this tool, or you got this one wrong. This is a, a live document that we all can contribute to so that we all understand how to meet the demands of these new frameworks. So important thing to note here, we segmented the chapters within this guide into three categories, code and pre-build, build and deploy and post-deployment.

Those were the categories that we saw were best represented. The workflow of the CICD pipeline, build and deploy is what we normally think of, but post-deployment, responding to vulnerabilities is a critical piece, and we're already doing some of that. So to get there, um, it doesn't have its own URL yet.

It will grow up, but it's a netlify app. Uh, I look for ci cd dash cybersecurity, and right here on the top where this arrow is pointing, that's where you can find the guide. Now, I also have to point out that you can learn how to join the team as well.

And we would love to have, uh, DevOps engineers who may not be security expert experts join this group where that's kind of who we are, except for Kate, who's our, um, our lead here in security, we're DevOps engineers, um, and we're all learning and we're all discovering new tools. And this is the place if you discover a new tool to open an issue in the GitHub, uh, in the CICD cybersecurity, uh, GitHub repo. So we know we need to add it, or you can add it yourself.

So once you drive down into the security guide, you're gonna see some things, um, that I just talked about. On the left hand side, you'll see the code and pre-build, you'll see build and deploy, and you'll see post-deployment. So you can drive down into any one of these areas to find open source tools that will meet particular actions of the SSDF.

So in this case, I, Dr. Drilled down into code and pre-build. Now notice we have, it's a chapter that e expands to secure software development framework because we wanna add additional frameworks in there, and it breaks down the frameworks that I discussed.

Protect the organization, protect the software, produce well secured software, and respond to vulnerabilities. Now, drill driving down into this even further takes us into the different tasks and actions that the SS DF has. In this case, I chose respond to vulnerabilities, and the first thing that comes up is RV dash one, identify and confirm v uh, vulnerabilities on an ongoing basis.

Yes, I checked that one because it's one of my favorite ones to talk about, because that's what I focus on so much in my own career, that how do we know when vulnerabilities are being, um, are, are, have been new vulnerabilities have been found post-deployment, and how do we respond to vulnerabilities when we, uh, across the pipeline from dev, uh, from CO at the code and pre-build state. So if I, if I was to have a live, uh, uh, demo going on, I could select post, uh, or post deploy and respond to vulnerabilities would also show up there. So how do you respond to vulnerabilities in code and pre-build?

How do you respond to them in build and deploy, and how do you respond to them post-deployment? So the goal here is to create a, uh, a, a reference document, a reference guide for these, uh, for the SSDF and soon to come, the CIS framework that shows you what tools could potentially meet that compliance level, or at least serves it in a certain way, serves it to some level. Now, we're not saying we're gonna, we're completely accurate in this, so you should take this, you know, with your, under your own understanding and your own research.

But it sure starts the conversation. And the team has put a lot of effort into coming up with these tools. It's not, it has not been an easy process.

You know, when, when I first started it, I thought we would be like three months in and we'd have this particular, we'd have a list done. Well, we started in January and we're running into October for the, its first, uh, full launch. So the team has worked very hard to deliver this, and, uh, I think you'll find it a useful guide.

I know I did, and I learned so much about the tools. I ha some tools I'd never heard of, of what they're doing. It's pretty fascinating out there.

So many people are, are concerned about security issues in their, in their code, and there's a lot of new innovation around it. But I can promise you the innovation, most of the tooling has to be generated and or has to be pushed through the CICD workflows. It's not something that you're gonna run at a command line every time you need to see it.

So the results is DevOps aligned with the secure software development framework, not adversaries, but friends. And I do believe that as we push through this process and we all learn about what the SSDF is talking about, we can understand that there are things that can be done at the early stages of development that we can prepare the organization. You know, how many people I still talk to that don't have version control?

It's a, it's silly. There are, there are companies out there who haven't done that. So let's just get that, that off the, let's just get that off of everybody's plate or how to protect the software.

Do software code scanning, generate a software bill of material report. How do we make sure when we deploy it that it, what we produced was it was well secured, and then how to respond to vulnerabilities when they show up in our production environments? Because new vulnerabilities happen every day.

This is not point in time. Solutions are great for the protecting the software, but new, new stuff shows up. So how do you fix that once it's out there?

So each one of these sections, po ps, PW, and RV have a section under code and pre-build, build and deploy and post-deployment, which means that you can begin adding these, the adding these tools or adding solutions to your DevOps pipeline to align with what the secure software development framework, um, is all about. Thank you for listening and having me lecture you about doing better and, uh, security. I know we all can do much better.

It's just understanding what tools we should use and where they go. Uh, I encourage you to, uh, give me a call if you really want to. Honestly, those are my phone, my phone numbers call me.

I would be happy to chat or just reach out to me on LinkedIn. I'm at Tracy Reagan, oms. Um, but I would love to chat and have more conversations and probably recruit you for either the Tels project, which is a, a, a project that I'm working on, or the CICD cybersecurity sig.

Thanks.