Techstrong TV – March 7, 2025

Hey everyone. It's another AI Friday. You're watching Textron Gang.

Hi everyone. Alan Shimmel here on Textron Gang. Welcome to our Friday edition.

We've got our usual kind of Friday crowd here. They've become the regulars on Friday. I feel like I'm Sam and cheers, or maybe I'm coach and cheer.

Cheers. Uh, Mike could be Sam. He, he, he was a pitcher.

Um, but let me introduce you to our gang members. Our West Coast intention on Friday is our marketing person extraordinaire, expert radio host, and a bunch of other good stuff. Our friend Lisa Martin.

Hey Lisa. You're looking very, very nice in that top there. Well, thank you.

I'm very bright today. It's good. Pink and white is always a nice color.

Uh, moving on from Lisa. He's not in pink and white. Looks like he's, oh, he is.

Got a little red. I thought you were in your Warriors. Your dubs warmup suit or something out there?

Uh, John Schwartz. Hey John, how are you? Hey, I'm good.

I'm good. It's, uh, being kept busy by the Salesforce conference this week, but, uh, everything's good. Very cool.

Good for you. Okay, then moving from the West coast to Austin. Same guy, different title.

That's right. Mm-hmm. I'm now Chief analyst at Visible Impact Guy Courier Chief Analyst at Visible Impact.

Hey guy, welcome Visible Impact, part of the Future Room Group. Thanks. I'm actually in New York City.

Are you at Moment? Yes'. Oh, I you.

Lucky Dog. You good for you. Thank you.

You're not with ard, with Mike, are you? Uh, I don't know. Mike, which office are you in?

I'm in, I'm in the Harrison, New York office on the other side of the bridge from you in, we were just discussing our future locations. Well, that's cool. Very cool.

I'm in Midtown Manhattan right now. Good for you. Enjoy.

Welcome guy. And then of course from Harrison. He is the dean of, of, uh, Jack Strong, our Chief Content Officer, Mike Ard.

Mike, did you always wanna be a dean? Dean? I don't know, because, you know, that's a lot of responsibility for taking care of students and students are notoriously problematic.

So, yeah, I think I'll skip the dean. All right. But I was thinking more like Dean Wormer.

You know, I have a, I had a husband, Dean Wormer, But, but I am in the same room I was in yesterday and I haven't moved since. So. There you go.

There You are. Alright guys. Hey, it's Friday.

We, we got a lot of AI in store for us here. Uh, Mike, why don't you kick us off. We're gonna take a minute here on this a block to, um, assess where we are with ai.

There's a story over on digital CXO talking about how, um, AI has permeated everybody's thought process, even though it seems like not that many folks are actually doing it just yet. And a lot of those things they are doing are experiments. ai talking about how just about every job in the world now seems to have an AI component to it, if you wanna apply for it.

So, let's start with Guy, but what's your assessment of what's going on here? Where are we on this journey? Well, the story at digital, uh, digital CXO, could I get that right?

Um, is, uh, um, based on, um, a recent study by the St. Louis Fed of 10,000 US workers. Um, and it's interesting to me for you to say, Mike, that, um, not a lot of people are using it because I guess the headline number was like 23%, uh, of a US workers, uh, use ai, uh, on a weekly basis.

Um, 9% use it on a daily basis. Those numbers don't sound like a lot, but I'm here to tell you those numbers are astoundingly high. 23% of all US workers, I, I think they had an age cutoff of like between 23 and 65 or something like that.

But every kind of job imaginable from farm worker up to corporate CEO, 23% of them are using AI at least weekly. That is astounding adoption. If you ask me if you wanna cut it down just to knowledge workers, I didn't have a chance to look at that.

Maybe it's a higher number of 50% or more, but this is every US worker. And, uh, equally interesting is that over half of the usage of AI is employee driven according to the study. I mean, this is a serious, uh, projectable, um, uh, you know, sort of unassailable piece of market research by one of the premier research institutions in the United States.

The, the us, the, uh, St. Louis, uh, federal Bank. Um, and they're, they're showing the, the latest version or edition of BYO, whatever we had, BYOD.

Um, we sort of kind of had BYO cloud, although it wasn't our name that way. This is now BYO ai. Hey, I just coined it.

BBYO ai, um, over half of its use is employee driven. That's all. And, you know, everyone in sundry, um, going and using chat CPT to for whatever, for research to draft an email or what have you.

I mean, this, this is in a space of two years now. Um, there's one other element to this story having to do, do with productivity, but actually I wanted to hear from John also because he has taken this sort of, you know, work style lifestyle, uh, approach and some recent articles he's written about it. And I wanna see what his take is on my sort of astonishment at, at How I, I think you, I think you're spot on guy.

And, and in fact, I think that number 23% not only is, is pretty significant. I think it's gonna get higher very soon. So as part of the story that I did, um, there was a, a study done by the University of Maryland's, uh, Smith School of Business in a, a company called linkup, which is a data job fracking firm.

And they have found that since the end of 2022, the AI job listings in the US are up 68%. When you compare that to the overall job listings or postings, those have declined 17%. So in a sense, that's where the jobs are.

And in fact, there was yet another study that was done, uh, looking at a thousand jo recent job seekers by something called AI Resume Builder. And they discovered that nearly half of the applicants now use chat GPT to craft their resume and cover letters. And that the people who did do that 82% were able to get some form of an interview.

Um, they, they, one cautionary thing is you, you couldn't over rely on using chat GPT. You had to add a human element of some sort. Otherwise, it was very obvious that you hadn't written it.

But I, I think just given the whole context of what's going on, on, it's very interesting to me. So we have this AI job growth that's occurring at the same time that a lot of tech companies are slashing their workforces, and yet they're making major investments in ai. It's this, it, there's this kind of whole kind of interesting dynamic that I find that as companies are cutting back, they're also looking to hire more people to fill the gap in the AI or some sort of knowledge, which in a sense, ironically, will probably displace even more jobs.

So there's this kind of whole job churning cycle that's going on. But AI is definitely leading the pack. And, um, I think I, I think we're really gonna see significant change.

And this, this will probably bleed into our next segment about what's going on with the Gen ai, but I think it really is starting to take off. I was a little bit dubious about it, but now I'm starting to think there really is momentum coming from this area. I'm gonna say nonsense.

So here's the thing. I'm employees are driving it, no doubt, 23%, no doubt. And I'm willing to wage you that 95% of that 23% is using it to write a better memo.

Well, let me wait to see how the GDP is gonna really take off because people are writing a better memo. I don't disagree that AI is gonna have a profound impact, but we're a long, long way from actually people using that in a meaningful way that's gonna drive a, a return on investment. And you're already hearing C XOs sand around going, where is the ROI on this stuff?

Well, I have to mention that the, uh, the St. Louis Fed did their homework using data from the study and, um, pretty sophisticated analysis, uh, to, uh, come up with a figure or how many work hours are being saved each week, or not each week, sorry, it's independent of the time period. 4% of work hours are being saved.

4% of a 40 hour work week is, uh, what it's, uh, 25 minutes or something like that. So that doesn't really sound like a lot, but those are 25 minutes that are being, let's take them at face value, which I do have a fair amount of, you know, doubt about that number much as I have confidence in the St. Louis Fed.

But let's just take that at face value. And those 25 minutes are now being spent to do something else. 1% or something like that.

When you do the math, that is a big boost in productivity. It doesn't sound like a lot, but you, you, you get that productivity boost, Mike. And, um, I, I think the main doubt is that the methodology is really sound enough, especially when you're interviewing these folks and they're saying, oh, I say four hours a week, and you're just kinda like, okay, you know, uh, maybe not.

They're, you know, I have been one of the ones saying over and over again that AI isn't really a productivity booster, at least not yet. It is a quality booster liability booster. But this is the sort of thing that people can look at now and start doing measurement with.

That'll be a great comfort to me on the 10 hours a week I'm now spending, going back into the office and commuting each way that I I, it makes a huge difference right here, man. I got you. So, Sounds wore your cynics hat, again, sounds To me like commuting.

I mean, we're, we're basically though in a transition in transitionary period, it's starting to ramp up. I think it's not gonna happen overnight, obviously, but I think it's, we're definitely trending in this direction, you know, and I've, I've been skeptical about it, but I, I really do see some sort of progress going on. It's just not gonna happen as quickly as we think.

So it sounds to me like the dean's putting him on double secret probation And, and should do. One of the claims is, is so, you know, I, I didn't want to, I I am not going to trash this study or what the St. Louis Fed did.

I'm gonna read it. I think it's gonna be very useful. But one of the claims in, in, in, again, in the article, I'm not sure if it came outta the report or, or somewhere else, um, or an interpretation, but it's that, uh, CIOs who successfully formalize AI integration could, and that word could, is doing a lot of business, could unlock $200 billion or more in annual productivity gains.

And that's not walking around money. That's, that's a fair Amount of billion here. A billionaire, before you know it, you're talking real money, But yeah.

And I look at that number and I'm just like, come on. So, Well, that's across the board. But, but hear, hear me out.

I, to your point, Mike, if people are using it to polish up or speed up writing memos, making a better cover letter, resume, these, what they're doing is they're using AI to try to make their mundane faster, easier, better. And that's a worthy, that's nothing to shirk at. It's a worthy goal.

But the real AI gains are when we use AI to really accelerate beyond the mundane writing a memo or, you know, these tasks, but you know what, what we really expect it to do, which is to do go, go do things, right? Agentic ai, go take care of this, take care of that, write that code this, deploy this, right? When it, it starts becoming a digital workforce, not just, I, I think out of the 23% who use it now, 80% of that 23% view it as a, a really nice parlor trick.

A really ni look at it's magical look how great this thing is. Look, I I, I'm talking about myself even, you know, it amazes me what it comes up with and stuff, but I'm not really leveraging it as a digital workforce. And I think that's the, the switch that needs to flip.

You know, you, you know, I was get, can I, can I just interject something really quickly? Is that when I used to work, when I used to work at Dow Jones, one of my greatest frustrations was we did this formulary formulaic stories around earnings, which I hated to do, and it took up a great amount. Oh, Jesus.

It took up so much time, and I thought if only if AI came along and did that could free me up to do stuff that I really wanted to do that I thought would add incredible value. So I actually think, and I can actually see how this was, would work in the future. But anyway, I'm just saying this from selfish purposes.

I'll tell you to Alan's point, and I think Satya Nadella has it, right? He said, you know, the only metric that's gonna matter at the end of the day is whether or not these GD Ps start moving up. And we really are more productive because otherwise, to Alan's point, it's a nifty little parlor trick.

And yeah, it reduces my toil maybe, and I am less cranky as a result, but it doesn't really mean squat to the business. It just means me as an employee means I can I get to go to lunch a little bit more and not have to rush back. That's where we are.

Wait a second. Can I take a quick poll of our panel today? Is Mike A.

Little less cranky than he was before? I think we're seeing a change in Tide, Ellen. All, All right.

All right. Well then look, spring training, that's a worthy goal. Oh, So worthy girl.

I keep, I, Go ahead, Lisa. Oh, thanks guy. I'm a big fan of generative AI for, for sparking creativity.

You know, one of the things I talked about last week on the radio was, was this over-reliance on gen AI from students and teachers are getting really savvy to, to check them out. They're putting, like, like a student is, is relying on an ages between 17 and 25. And the reliant versus, um, using it are completely different things to me.

And it showed that that students were copying and pasting like, like an essay prompt into like a chat GPT and having it write the entire thing and being reliant on it, completely. Not even proofreading it for hallucinations or putting that human element in. I think that guy that you mentioned, teachers are getting savvy because they are hiding words like a funny word, like a banana that doesn't make any sense to the actual essay prompt and white text.

When you copy and paste the prompt into a chat bot and that word appears, the teacher knows right away you cheated. But we're seeing also a lot of knowledge workers reliant on it. I think that the fine line there is reliance dependence versus using it as an inspiration tool.

Something that the, the study showed me was that CIOs have to get really, they've gotta balance this tightrope as the article said about preventing hallucinations these, putting these guardrails in place, letting people be creative and more productive. But I also thought it was interesting that we're seeing, I guess this is not surprising that we're seeing gen AI adoption different across industries, but I was impressed to see that that, you know, 15% of leisure and hospitality folks, knowledge workers are using it, transportation workers. It's not just the information services and the professional services folks.

We're seeing that, I think what, what needs to be put in place is those guardrails saying this can be used to, I think, as an inspiration tool versus being overly dependent on it. That if you're writing it for a resume or a cover letter and you're not putting in any, any of your own sort of touch, I think you're gonna get rejected regardless. That's a terrific way, that's a terrific way to to, to, to describe that quality side that I talk about.

That's an inspiration tool. I love that little comment about banana. I think we all need an AI safe word.

Mine's. Mine's gonna be beer. Mine's getting strawberry, and my family knows what that means.

How can I just point out for, again, Where do we go in here? Go ahead. It's, it's really, it's gonna be really helpful for us, Mike, especially you, and this will cheer you up to think of this and the article alludes to this, but I've seen nowhere else except coming outta my own dang pie hole, which is to think of this a adoption curve and adoption cycle of AI as the same way as the adoption of the personal PC back starting in the early eighties.

It took 16 years before any productivity gains were seen from the use of personal PCs and devices. It's clear that this will be a lot shorter, but, but shorter, what, four years or something. So Mike, that's what I have to say to your complaints about there not being productivity plans.

I, which is not even what we should be using AI for anyway. So I Am, I'm a big believer in the long term, but the short term is a lot of hype and a lot of, Where, where did we go off the rails here? Where we're talking about safe words and pie holes.

That's what I Well, that's good strawberry. Alright, Let's take a break. We're gonna come back, we'll continue our AI discussion, but now we're gonna talk about AI agents.

You're watching Textron Gang, Discover Textron Group, the epicenter of tech innovation. We are your go-to for reaching IT leaders and practitioners worldwide. Our secret impactful content that sparks awareness, engagement, and top quality leads with us.

You'll access editorial websites, streaming videos, virtual events, custom content analyst research and more. Join our satisfied clients. Let's revolutionize your tech journey.

Contact us today and tell your story to the world in the most powerful way with Textron Group. All right, folks, we're back. And the gang's gonna be talking about this whole Salesforce, uh, move to create a marketplace for agents.

And it kind of continues from our last conversation 'cause well, this may be where the real action is. John, you recovering this for us over there on text dry ai, what's your take? Well, uh, Salesforce, which, uh, has a conference this week in San Francisco, uh, has made a couple of announcements.

Um, the, the highlight to me was the, uh, agent Force two dx, which is basically the next version of their digital labor platform. So one of the things that Salesforce is going after, they, they refer to it as a $6 trillion digital labor market. So this new version of Agent Force basically would autonomously perform administrative tasks across enterprise systems with minimal human supervision.

The reason why this is interesting to me is that this, this system is designed to embed AI agents that monitor data changes, anticipate needs across business processes. And then it acts previously, they, they were triggered, agent force agents were triggered from a chat interfaces and required specific directions from humans to take action. So this, this was interesting.

Salesforce made the announcement, uh, the same week that Microsoft introduced a new sales agent aimed specifically at competing with Salesforce. And, and AWS announced a new group focused on ag agentic ai. Um, Salesforce also announced this open marketplace for AI agents, for enterprises called Age Agent Exchange, which lets developers and partners build and monetize AI components.

They announced more than 200 initial partners including Google Cloud, Workday Box, DocuSign. So if all part of this kind of momentum or movement into autonomously performing tasks through these agents. Um, so we're seeing, we're seeing momentum.

There are more announcements that are about to come. Cisco's make made one on Thursday. There are some others that are under embargo that I can't really disclose.

But in a sense, this kind of builds off what we were talking about in the previous segments. Uh, it will take a while as guy and I will acknowledge, and, and I think Mike, you're right, this is gonna take several years. But again, Salesforce is, is kind of pushing this idea and they've got some partners lined up and there's some actual real applications that were discussed as part of the announcement.

You know, good. Well, let me tell you what I really liked about the agents in the marketplace. 'cause I can envision a world that looks like this.

I'm gonna go to this marketplace. I'm gonna describe a task that I would like to have done, and these agents and the people who build them are gonna bid to fulfill my task. And so instead of me sitting around going, let me license this agent on a annual contract basis, I may do this on a usage based model, and I'm only gonna pay for the agent for as long as I needed to complete that particular task.

These is, is this the AI version of driving your pickup truck by Home Depot and picking up illegal immigrants to do work for you? That is exactly what it is. Wow.

I thought the last, uh, block was, I thought a block was tough. Ended tough. You're really bringing the heat again out.

Yeah. No, I'm not, but, but you know what? I, I do think a workplace or, or, or a marketplace.

Look, it worked for the cloud, it worked for the phone, for the cell phone. Why wouldn't it work here? Right?

It it makes sense. It's, it's a tried and true model. That being said, you know, I, I mentioned it yesterday on yesterday's gang.

I, I, I did a customer or user experience feedback with an AI product that I'm playing with called Hoop, HOOP ai. And, um, and I was talking to one of the co-founders. These are the people from cello and, um, well, they're not, they were, they helped start cello.

They're not at cello anymore. Um, and I asked them about, you know, it's great to make these tasks for me, but I'd like to have an agent that goes, does these things, are you gonna have an agent? And they said, you know, why would they make an agent?

'cause their belief is we're all gonna have so many agents that the last thing we want is another agent. So maybe what they wanna have is, it's not quite an API, but maybe a way to plug into your existing agents to go do things. And I think that is something that the agent marketplace kind of model we, we've gotta think about is how many agents, are they single use agents?

Are they disposable? Do I get a Mr. Smith, like in the matrix, who does everything right?

Um, what is the nature of these agents? Are they ephemeral? Are they, are they permanent?

Are they my digital butler? Right. That You might have like a contract agent, right.

To do specific job as, which is kind of like the disposable i, uh, concept. Right? Exactly.

I'm gonna have a mini mic agent that will manage all those other agents. I like that agent. You know, well, you're gonna need that an an orchestrator agent perhaps, right?

Or do you have one super agent that has many different facets? I I, you know, where does the, I mean, this could go all over the place. I mean, and, and I'm sure it will over the course of time, but at least initially to me, it seems unwieldy.

And, and in talking to these folks at Hoop, I, you, I'm trying to put myself in their shoes as a developer of, of this AI platform, AI empowered tool they're building and are they making the right choice? Not building an agent, You know? Yeah.

I, Alan I think the questions are even answered. I mean, uh, you know, the great AI bungee jump that we've been experiencing, you know, uh, was built around generative ai, but turns out that was phase one. I thought multimodal was gonna be phase two, but multimodal is just, it's just now like, it's a, it's a marketing word now.

It's, it's real. But, you know, phase two of the great AI bungee jump, um, is agentic ai. And what I mean by that is people are, well, it's obvious what I mean, they're just jumping into it.

So is it a mistake not to have, uh, your own marketplace or plug into other marketplace? I mean, there's tons of marketplaces now Salesforce, uh, but they debated Agent Force last year, right? It was, it's relatively new.

So they're developing it rapidly. But, uh, uh, you know, uh, uh, Boomi, which is not a super well-known company, but one that is really right in the heart of where something like Ag agent AI agents in general, um, can be really helpful. We're talking about enterprise workflow roughly.

Um, they had, they have theirs, uh, uh, Cisco, uh, as John mentioned, um, SAP with their recent announcements, uh, Google Cloud, a WSI mean, there's ton, even the, the big cis integrators, like Capgemini, I think is debuting their agent AI marketplace. I mean, we didn't say agentic AI until like a year ago or something like that. And then now we've got these full blown marketplaces appearing.

Um, it's, uh, it's, it's gonna be adopted and used. Everybody's gonna get on the train just like they did with generative ai. Well, 23% anyway.

There's Been a fear factor with AI for a while, right? Like, yes. Like, I mean, fomo last few years, total fomo.

Every conference I went to, the message was really clear from whether it was a, a Michael Dell or, um, an Jess Wong and his cool leather jacket. If you're not already in the AI game, you're too late and you're gonna be behind. So I think that fear factor is there, that fomo, um, guys, you're calling it is there for organizations to say, we've gotta dip our toes in.

And what Salesforce is doing with Agent Exchange and their go to market, they launched this with over 200 partners. We're talking Google Cloud, Workday, DocuSign box. So we're seeing that momentum really carry forward here on day one with these big names saying, this is what you need to be doing.

Company A, company B, company Z, You know, the one of you talk, when you talk about foam of Salesforce, they were Exhibit A, right? They were considered the, the la the laggards. So in a sense, they've really been ratcheting it up.

So anyway, in a sense, they were considered the ones on the outside looking in. Now they're, they're kind of trying to, they're a little bit overcompensating, I'll put it that way. They always do this.

It's a very heavy duty marketing company, you know, first and foremost. Yeah, exactly. Sorry, To Lisa's point, this is the marketing battle of the decade.

It's whoever controls the front end experience through that agent owns the hearts and minds. And 90% of what's on the back end is gonna be, you know, for lack of a better phrase, a headless agent that other agents are calling and no one's ever gonna see or know. So ultimately, who owns that desktop is where, or the smartphone or whatever that first agent in line is, owns the game.

I bet. Yep. com under research reports on maximizing ROI with agentic ai, why Agent forces the fast path to enterprise value.

So clearly Salesforce is, seems to be staking out a leadership position here. We, we, we discussed the SAP announcements around it. It'll be interesting.

Look, here's, you know, don't count out Microsoft. Oh, Azure's got, Azure's got an agent AI tool service. No, no.

But in terms of an agent, uh, uh, uh, marketplace. Oh, yeah, yeah. Or open AI or anything for those guys.

Oh, any of them. Mm-hmm. We'll see, I, you know, place your bets.

Maybe that's what we should do, Mike. We should become like a, a bookkeeper for, that's on the, we talked About that before. Oh, we, okay.

Look, I'm just trying to be creative and innovative here to pay, pay some of these tariffs. All we, all we gotta do is, you know, hook up with somebody in England where they have these services anyway, and an agent on the front end of it, and we're good to go. There You go.

Lad Brooks. Yeah, there you go. I thought you meant kinda like Sunday night football or whatever.

I mean Yeah. Where we, where, you know, all the panelists, uh, placed their bed and I mean, look later and see who was right and who was wrong. We, We could, could, we could work on that if you want.

We could do that. We could work on that. Yeah.

But then we let other people bet on which analyst they think is right. Oh, yeah. There you go.

Mm-hmm. God, you're not allowed to get off to bet on you. Right?

No family and friends. Anyway, let's take a break. We're gonna come back here.

We've got C Block. And believe it or not, I don't think we're gonna talk about AI in C Block. I hope not.

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

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

All right, folks, we're back with the next block. And we're talking about a case involving insider threat in cybersecurity terms. That means somebody who was on the inside who hacked something to gain some advantage.

And a lot of the time we're so focused on preventing attacks from the outside that we forget that the inside's an issue. In this case, uh, in New York, a couple of folks have been charged with the hacking into the StubHub network to grab some tickets from, uh, Taylor Swift concerts, and then reselling them at a much higher markup, which of course is a really annoying thing to all those Swifty fans out there, which includes our own own Lisa Martin. But what's your take on all of this?

I think that this is the tip of an iceberg, but I could be wrong. No, you're right, Mike. It is the tip of the iceberg.

7 billion. But what we saw is, is these two people, to your point, Mike, were insiders. They worked for an outsourcing company, um, of StubHub called Sutherland Global Services out of Jamaica.

What they did was they got access to an unauthorized part of StubHub where they store electronic information about ticket purchases, and they only got about 350 different, um, purchases, but it accounted for about a thousand tickets. And what they did was they redirected, normally when you buy a ticket up through a, a ticketing service like this, you get the email, you get a unique URL with the email to download your tickets, put 'em in your wallet. Well, they went in there and manipulated the email addresses, punted, um, what accumulated to $635,000 worth of Taylor Swift tickets to accomplices, who then resold them.

And we're seeing issues like this, not just from StubHub, who said, yep, we've been, we've been hacked. They got in, we're working on this Live nation at Ticketmaster, what they're, but these people are prying on me. I you can't even call it a cybercrime ring with two people, two people did this in between June, 2022 and July of 2023.

So about a year they were able to make $635,000. They did it with Adele and Sheeran US Open. But because the Taylor Swift tour is the highest grossing tour of all time, I think it's getting a lot of headlines.

We're seeing it in the US and Canada and the uk, but it's showing a bigger problem that these ticket resellers are going to have. And that is the, the vulnerabilities that they have in their systems that they need to identify, and the fact that they've got folks who are vulnerable, like super fans, who are vulnerable to scammers. So this is a growing problem that the Live nations, the StubHubs, the Ticket Masters and the like, have got to fix.

So look, as Bill Clinton would say, this is simple arithmetic, simple arithmetic. When you've got tickets that are going for thousands, thousands of dollars, the the temptation to make a buck like that, to make big bucks, $600,000 plus here to make big bucks is too great. And, and it's gonna corrupt people.

You know, I, I was having a conversation with some friends of mine the other day. You know, there's this new Led Zeppelin movie out the making of Led Zeppelin or whatever is, it's an imax. I haven't gone to see it yet, unfortunately, but it's on my list to go see.

And, um, I thought back, I was talking with my friends that I grew up with. We went to see Led Zeppelin, 1977 or 78, 77, I think it was in Madison Square Garden. One of my friends still has the ticket stub, because it wasn't electronic.

We didn't have it in our phone. We didn't have votes, but we had tickets, and he still had the ticket stub. You know how much that ticket cost us?

$35. You know how you got it? You had to send in an envelope with a check made out to whatever it was, led Zeppelin tickets or whatever for the amount.

You are only allowed to get three or four tickets, had to send in a real check with a postage page, self-addressed, stamped envelope. Right? And it was, and if they picked envelope, they mailed you back your tickets in that self-addressed stamped envelope.

It was a sucky system, but I got tickets to led Zeplin for 35 bucks. And you, and you didn't have, How much do you think those would've cost now? Right.

If they were, you know, if they were selling Priceless, priceless. Hey, this, this is making me nostalgic for that sketchy guy I used to meet in a bar and buy World Series tickets off of, you know, yeah, I did that. But maybe that's a safer Transaction.

But isn't, aren't these guys from Jamaica, his, his Yes. Descendants in some way, right? Yes.

Look, there is Mr. Ware Is from Jamaica, where there's a market where there's a will, there's a way, right? I Mean, we were, We were meeting in New York, Alan, you went to a Knicks game, right?

Yes. And we were talking about the ticket prices. You know what?

That's why I don't go to as many sporting events as I used to. I used to go to dozens, or I used to go to 40 baseball games a year. And for the Warriors, I used to go four or five times a year.

I can, I can go once maybe a year, because it's cost Prohibited. Well, but that's the problem with pro sports in general, is yes, they've almost priced it out of the working man's, you know, working man would take his family, Mike, when you were younger, they took you to Yankee Stadium, right? Gave you beer.

You were eight years old, drinking a couple beers and hot dogs. That's why it's a safe word. The day camp people took us.

Yeah. I mean, I, I used to go with the day camp people too. You're right.

But it was cheap. I mean, now, you know, a dad wants to take his, his two kids and wife to a ball game. I don't care whether it's a a football game.

It's crazy. Basketball, hockey, even baseball, which used to be the cheapest. You are dropping a couple of hundred dollars easily, if not a thousand, easily At least.

Yes. This is, this is turned into the, this turned into the Crank podcast. 'cause Yeah, it's very much, You know what we're doing.

We're not Harry, get on Go Play Talking your own about the breach. Yeah, we're not talking about the breach. We're talking about back in the day.

I only had to to spend, but No, but, but let me go back in the day to Mike's guy, where he bought those shady, the shady guy at the World Series tickets. Didn't it always used to bother you? Where the hell did these guys get their tickets?

Mm-hmm. How did they get those tickets? What, who did they know?

How did they get 'em? Well, in some ways, this is the path to the tickets a little clearer here, right? Mm-hmm.

It's an electronic digital path that we, we could forensically see how the hell it worked and, and what happened. This to me Makes we could, but will we, Alan, because that's what's really interesting to me here. Well, we know how this one went down, Right?

Well, we know that a Stub Hub partner accessed a protected Stub Hub database. We don't know how they accessed. Oh, I, I'm sure they do.

And they haven't said it. I'm sure they do. They probably not that you making people, I mean, StubHub and whoever they hired, CrowdStrike or whoever did their forensics, they, they not, you know, look, the people stealing Taylor Swift tickets aren't sophisticated enough to not leave hand fingerprints, right.

Digital fingerprints in what they're doing. They, they know how they got in here. That took nearly two years to come to light.

Well Be, because guide, the average hack doesn't get discovered for anywhere from nine to 13 months. That's across the board. Not just Swifty Or Cyber.

Everyone up. But Mike brings up a great insurance. Well, yeah.

You know, you, you, you bring that up. I just interviewed the CEO of cow, or one of the co-founders of Cowbell, which is one of the leading cyber insurance companies in the world. They're moving in not just to cyber insurance, but to cyber products now, to make sure that they pay less claims, right?

That you're actually using, because cyber insurance has become the big stick. You want cyber insurance for these kinds of things. They're gonna insist the same way.

Homeowner insurance, make sure you have a good roof and your windows don't leak, and, and you have your safety equipment. Same thing with cyber insurance. I'm not giving you cyber insurance if you don't have a good policy and a resilience plan and blah, blah, blah, all in place.

And now here I'll sell you the resilience plan and that, that's become big business. But in the Taylor Swift case, let's not forget the poor Schnuck who paid the money for the, for that ticket. And, you know, in in law, there's this concept guy, you know, there's this law of specific performance, right?

No amount of money's gonna compensate me. I, my daughter is a Swifty and I promised her I'm taking her, and those tickets are gone. I can't get another ticket.

And, And what's the, what these folks are exploiting, sorry, Alan is the emotional element of what ended up being this tour and parents doing everything they could. I mean, there were videos from like, when the tickets first went on sale of Swifties just sobbing because they couldn't get access to tickets. There were issues with Live Nation and Ticketmaster.

And so people are preying on the emotional element of some of these, um, artists who are really creating experiences. I went to the concert, it was an actual amazing experience. But that's what's happening, is when you get the emotion involved and the fact that it's so easy for this two people to gain access to the Stu Hub system, it's a huge problem.

But Mike brought up this in the very beginning of the block, and that is, this is, this is the tip of the iceberg. I think Live Nation said last year that they were investigating a data breach that dis that, uh, displayed access to over 500 million Ticketmaster customers data. So this is something that these organizations have got to get under control ASAP, because you know what, millions of transactions occur on these sites every day for expensive items.

Look, I I think those, do they Have an incentive to, to get them under control? No, they don't. And that's the problem.

They're monopolies. They do. They they do, they do have an incentive.

'cause here's how it will play out. So let's say I am the dad with the kids who are Yankee fans, but I can't take 'em to go to a Yankee game. You know what those kids are gonna wind up doing?

They're gonna go watch soccer or something else, or they're gonna go concert, or they're gonna have a different experience, Will sell those tickets too. Or StubHub will sell those tickets too. Let me tell the, the whole, you are out of order, your Honor.

The whole system is rotten. This whole thing that we have, these, you know, the Ticketmaster, stub Hub, SeatGeek, and all, all of the other ones, the whole system is rotten. It's people making money on the backs of the artists and the athletes, right?

And, and I, look, you could argue that athletes shouldn't make the money they make, or that artists shouldn't make the money they make, but I'd rather my, if I'm gonna go see them play or whatever, I'd rather my money go to them than go to these leaches and vultures who, who bring it on, including StubHub themselves, the fees they charge over and above what someone's selling their te I'm a season ticket holder to the Dolphins. I'm not a Dolphins fan. I gave up selling my tickets because, you know, if I sell my, so first of all, they're crazy exp I gave up the tickets, period.

I'm a Gearless fan. But the, the tickets themselves are crazy expensive. You could hardly sell them for what you cost.

And then when you put them in for basically what they cost, by the time StubHub puts their fees on, it's, it's, it's one and a half times the the cost. Yeah. Yeah.

It's crazy. The whole, the system's run It, it is, it, it's that. And we thought we addressed that with the Biden, you know, the, the push to, to eliminate those fees.

But, um, they Have it, what they do now is they, they do include the fees. It used to be you'd search for tickets, you'd say, oh, these are only $250 each. That sounds good.

And then you'd go in and those two, $250 tickets are $700. Well, where's the math? Well, there's fees and taxes and delivery and blah, blah, blah.

So they did. Now they show you the fees included in the price, but it's still a bad system. And so when you have a, an unjust law, right?

Natural law theory here, another law school thing for you guy, natural law theory, if you've got an unjust law or an unjust system, people are gonna hack it. People are gonna do this. So, so my, my crank contribution to this is way back in the day, we had political actors and a Congress willing to put consumer protections in place.

And that's what they did with the credit card companies, such that the credit card companies are the ones liable for this kind of fraud. Now, I don't know what, how you can compensate someone for a missed once, you know, once in a lifetime event, but there is no such protection anymore, and it can't be passed through any recent Congress, you know, I'm aware of. So that is something that used to be better.

And I don't know if we're ever gonna get back to this kind of protection of the, the poor consumer. Yes. Alan?

No, no. Are you done your Head act to crank number two? No.

No, guy, thank you for telling us that. I'd like an email from you with the five things you did last week. No problem.

Alright. Hey, let's leave it. One of Them was, was to join Textron Gang, or should I say Textron Cranks.

Textron Cranks. Hey, Hey, hey, Alan. A little spoiler alert.

I I, I went to see the Led Zeppelin documentary. They go on to be huge rock stars at the end. Oh.

Oh, wow. I had a film. Well, look, Don't you get away the ending.

Raise Your hand if you saw them live. Oh, I'm probably alert. Probably the only one here who, who actually a buddy, A buddy of mine saw their last show in North America, which was in Oakland.

Really? Oh, that's cool. Yes.

So, Yeah, no, that was, that was a concert. Yes. All right.

On that note, whole lot of love, stairway to heaven, all that love led Zeplin. But we're, we're gonna call an end to the Textron gang today. Have a great weekend, everyone.

We have a full text, drunk tv, as usual schedule behind us here. So stay tuned on that. If you're watching this not on our text Drunk TV broadcast, go check out Textron tv or our Text Strong tv YouTube channel.

And, uh, you could watch this and past episodes of The Gang and about 8,000 other videos on there. So check that out. Thanks a lot, gang members.

Have a great weekend, everyone. For now, this is Alan Shimmel for Text Strong. We're out.

This is Textron tv. Hey, everyone, welcome back here to Tech Drunk tv. My next guest is Mr.

Rajiv Gupta. Rajiv is the cow co-founder of Cowbell. You may have heard of Cowbell.

If not, we'll tell you more about him. But first, let's welcome Rajiv, find out a little bit about him. Hey, Rajiv, welcome to Tech Drunk tv.

Uh, thanks, Alan. Uh, glad to be here. Absolutely.

So, Rajiv Rajiv, as I mentioned, you are co-founder of Cowbell, but give us an idea what exactly is cowbell and, uh, You know? Yeah, absolutely. I'll, uh, I'll talk both.

Uh, I'll give you a little bit background myself, and then also about the Kabul, just to give perspective of, uh, you know, why, why I started, um, decided to start Kawell, uh, along with the two of my other partners. Um, so my background actually is more from cybersecurity space. Uh, or if I go even more further back, uh, I'm, uh, ex alum, uh, sun alumni.

A lot of my roots, uh, uh, go deep into the operating system layers. And, uh, I know there's some, there's a lot of alumni out there on Sun, and, uh, I know Sun has fed a lot of, uh, interesting technology and a lot of entrepreneurs into the industry. Sure It did.

And, uh, so I, I go back, uh, you know, uh, you know, the, I think if I go back about 10 years or so ago, I, you know, was part of a startup where we were trying to shift left, uh, on, uh, how do you do better? com, you know, trying to shift left in terms of how mm-hmm. How to do things better, faster, cheaper, you know, find defects.

Sure. They make their way into the, uh, development mainstream. And then, uh, the startup before Cowbell, I was helping shifting security left and trying to see how we can actually build more secure software, uh, from the get go.

And, uh, so my background is primarily, I'm a more of a techie, a tinkerer, uh, a builder. Um, you know, there's a lot of ways to describe. I spend all my free time, uh, you know, uh, building, uh, some small AI things, robots, uh, you know, I'm, I'm a tinkerer at heart.

It means I, I like to build things, break things, rebuild them. And, um, so about, uh, five, six years ago, uh, I ran into Jack, uh, I've known Jack for about a decade or more about since 2010. Uh, you know, we started talking about, uh, you know, how things are shifting.

You know, uh, everybody who's from cybersecurity, we all know that it's not a matter of if, it's a matter of when somebody gonna get attacked. So we, you know, even in my discussions with my customers, we used to always come, started to talk about the cyber insurance. And it was very intriguing because, and say, you know what?

That's, that's the thing. Because if we do get attacked, uh, the most important thing, as you mentioned Alan, is resiliency. How do I spring back up on my feet and, uh, get back to work?

Right? And insurance, uh, is perfect play. And you started looking into what options are out there in the market.

You know, I had gone through the buying process myself, uh, you know, and saying, you know, what does it take to buy a cyber insurance? And it was painful, it was lengthy paperwork, lot of questions. And I, I actually cushioned the entire process because there was no way the insurance company understood my security posture based on the q and a.

And, uh, you know, the, the kind of discussion I had, and I felt like, looks like, uh, this underwriting is being done, uh, with a big black box and just throwing it, and it's just not uncommon in insurance, right? You know, generally most people do a portfolio writing and, you know, making big strokes and whatnot. But with cyber such a big, you know, such a core of the tech, we have to use tech to underwrite tech.

I felt like, you know, with the advent of ai, with everything that was going on, you know, it made sense to, um, uh, you know, use the data for our advantage, uh, for the advantage of the underwriters to really do a better job in, uh, assessing the risk and, uh, underwriting the risk, and then not knowing a lot about insurance that time. I felt like insurance is, is all about risk transfer, if you think about it, right? I mean, if I'm taking on the risk as an insurance company from a policy holder, I need to be, to quantify that risk, then, then only I can take it on.

Sure. You know, if I can't even quantify what am I taking on the risk? Like what is the transfer happening?

Um, so that, uh, kind of, uh, is the starting of the journey and, uh, now, uh, five, six years later, Kawell is, um, is a force. I think we help a lot of SMEs. We, we are, um, we cater to a small medium enterprises up to a billion dollar in revenue.

We have close to about 30,000 customers, uh, in the United States. And you, and, uh, we, we believe that we are part of the security fabric. We are, uh, uh, part of this, um, you know, helping businesses stay, stay afloat, stay resilient, make sure they can actually open up the doors on Monday morning if they get attacked on a Friday night, right?

How we can actually do things to help, you know, keep, keep, uh, keep them on their feet, keep them, uh, you know, whatever the goal the, you know, of that business is, whatever they're trying to achieve, you know, they shouldn't have to worry about shutting down doors just because they got a ransomware attack. Fair enough. You know, a funny thing happened on the way to market with these cyber insurance companies, though, IV is, I, I always like to tell people this, that somehow the, the cyber insurance companies became the big stick, right?

We, we exist unfortunately, and is at least here in the us less so in Europe, where the government, it's very hard for the government to get anything done from a cyber perspective. You get some executive orders, you've got the csa, you had the CSA organization putting some stuff out. But in terms of real legislation and regulation, our government, we, we can't rely on the federal government it seems, 'cause they don't have the will to do anything about it.

And then when you start getting in a state government regulation, you very quickly get a patchwork, a quilt where you could do this in that state, but you can't do it in this state. And vice versa. It's that, that's hard.

Now, in years past, we relied on some big regulatory bodies, like for instance, PCI, right? Mm-hmm. Payment card industry.

They said, if you're gonna use credit cards, this is minimum. And this is how we, you know, this is what good security looks like mm-hmm. In the, especially the SMB market, but even bigger where cybersecurity has become such a, uh, a must have, right?

Because the risk is too great. It, it gave the cyber insurance like cowbell a chance to say, Hey, if you want us to ensure you, you need to be doing, you gotta have good resiliency plans, you've gotta have, you know, a good security architecture and strategy and, and so forth. And so the cybersecurity insurance companies became the big stick, the enforces of security best practices, and we needed that.

Yeah. I, we, we do run into that where I have discussions with CSOs and they tell me that, Hey, rajiva, I've been trying to roll out, uh, you know, uh, enterprise wide MFA policy, and I have been unsuccessful for the last two years. I am so happy that you put it as a subjectivity in the insurance policy.

And it has now given me a stick to go really make sure is enterprise buy. Yeah. So there is definitely that, uh, piece to it.

You know, you can, you can use the analogy of, uh, you buy a home insurance and home insurance sends you a letter saying that, Hey, you need to cut down those, trim down those trees around your house. Otherwise, and before you know it, the, the, the thing that you were laying for a year, year and a half, where you call the gardener and get them trimmed right away, right. Those, no, look, I live in Florida, it's even worse.

They're sending drones over houses Yeah. And telling you you need a new roof or whatever. So, uh, I think It's real.

We as human beings, as enterprises, we tend to delay it. Uh, just puts a little bit of a spotlight, makes it happen. And, uh, end result is it's a more, uh, secure, uh, business, more resilient business.

And, uh, it's good for everybody. Absolutely. Now, of course, you know, security is always moving.

Mm-hmm. And, you know, the big, well, the big thing in technology in general is AI now, right? Everybody's talking about how AI's changing the game and generative ai, agentic ai, all, all of these things.

Um, you know, but the in, in security and cyber in particular, the bad guys are as smart as we are, and they're really well organized. And any new technology like this, they're, they're harnessing it and using it too, Even at a faster pace than us because, um, you know, for a business, I have to run my business, cater to my, you know, I'm, I'm not in the business of, uh, figuring it out how to use ai. And my goal is to actually deliver the business outcome, whatever that is, right?

And, uh, security just happened to be one of the things I need to worry about. But there are gazillion other things as an entrepreneur, as a business owner, I have to worry about. But for a bad actor, that's the only thing they worry about.

That's, you know, they get better every day. And AI has given them this automation, the speed accuracy, and, you know, they don't have to try a thousand times to see which one they're gonna get in. Now they can run simulations and they can actually be more, more precise in their attacks.

And, uh, so I think, uh, definitely both the frequency, the severity is going up in terms of the attack as a result of the AI used by the bad actors. I agreed. I agree with you, ed.

Yeah. Um, so now again, the big stick has to talk right in, in light of these new attack methods and technologies. You know, cowbell, I assume is, is asking companies to do more or to, to be aware of this.

Um, what, what are, and, and, and as I, we were talking, you know, before we got online, look, a lot of the action today is around the resiliency aspect of it. How do I respond? How do I bounce back from these things?

So what are the kinds of things you are recommending to cowbell customers for, you know, to remain resilient in the face of this whole new class of threats? Yeah, it's a great question. So I think, you know, it's, uh, it's not entirely new stuff.

Uh, you know, the things that, uh, cybersecurity industry and insurance, uh, we've been preaching for a while. You know, the basic hygiene, like continuous monitoring of your, uh, you know, uh, internet facing compute, uh, you know, threat assessment, somebody watching, uh, you know, the whole, um, threat intelligence and the telemetry of, uh, data that gets generated from your routers and systems to see if there's a threat actor already present or trying to get in, uh, basic, uh, cybersecurity awareness training, you know, believe it or not, means the human still remains the, you know, the weakest link in the cyber cybersecurity kill chain. Uh, you know, it's very easy, especially with the AI crafted, uh, emails and whatnot to get through the spear phishing campaign and make the, make a human click in or, uh, you know, do something that, uh, used to be hard because we used to train, uh, you know, uh, everybody saying that, Hey, look for spelling mistakes, other things, you know, the, the craft of the email.

But now these emails are, they look perfect, right? There's no error. Yeah, they are perfect.

You know, even, even most of these bad actors are not in a natively English speaking countries, you know, before they used to make mistakes in just grammar, in just spelling and whatnot. But now these emails are perfect. So I think the, the bar is higher.

What that means is the companies have to do more. Uh, and that's the reason, by the way, we just launched last month, uh, Kabul Resiliency Services, and we are, uh, trying to figure it out. How do, how do we help these SMEs even even more, right?

Try to bring in, uh, a suite of free services that can help, uh, policy holders, uh, stay up to speed with their continuous monitoring and, uh, whatnot. We provide a full one year of, uh, free cybersecurity, uh, training to all our policy holders, no matter whether you're 20 employees or 20,000 employees. You know, it's, uh, it's all free for the first year.

So we were trying to, you know, make the barriers to entry lower so that, uh, more and more policy holders can actually do the basic stuff like, you know, a a a pen testing, for example. It's a, something that we all know that, uh, uh, checklist is one thing, right? I can say that, yep.

I can fill the questionnaire, all the things I have gone through. I can look at the, the NIST or any of the CSF benchmark and say, yep, I, you know, I'm, I'm good, good, good, good. But that doesn't really, you know, do the job.

We have to employ a third party to see if, uh, you know, we can do a, a penetration testing that helps us really understand those, uh, weak points in our infrastructure so that we can fix it before the bad guys actually exploit those things. So, you know, uh, to, to net it out, basically we are, we are still talking about, uh, uh, you know, cybersecurity training, regular pen testing, um, tools like, uh, managed detection and response. Um, no enterprise, you know, especially in the SME space, has the time or the manpower to employ cybersecurity expertss, uh, who are there 24 by seven.

Even if I'm a business with five, 700 employees, uh, decent size, um, I, you know, I could have a cybersecurity people employed, but you know, these, uh, it's hard to do a 24 by seven, um, view of what's happening in the environment. And that's why these managed services work really, really well. Um, think about most of the attacks happen in the evenings, the weekends, and the, uh, holidays, long weekends, and that's the time where employees are taking time off, where all the cyber security teams we hire, they also take time off, and that's exactly the time where, uh, the attacks mostly spike up.

So we, we need to use the best of the technology out there, best of the services that are available, and that's exactly what we are trying to do with our resiliency services, trying to bring these, uh, best of the breed, uh, solutions and services to our policy holders. Now, is this Rajiv, is this crossing a line though, from just providing insurance and giving best practices that people should use to actually providing security services? Yeah, so more and more insurance companies are realizing that, you know, to staying on the, uh, right side of the boom, uh, on the aftermath of an event, uh, it works, but, uh, because of, as you mentioned, you know, there's more AI driven attacks and things that are happening, the speed at which things are rising up, uh, they're finding that it behooves us to partner with the cybersecurity industry to bring the best of the breach solutions to our policy holders.

Uh, SME doesn't have a, uh, the kind of time to really evaluate, oh, there are so many, so many solutions out there. What, which one is the right one? You know, should I buy this?

Should I buy that one? And then, okay, I did the evaluation, but then I need somebody to configure it, right? You know, then I need to find an MSP to say, okay, I have found the solution.

It's, I deployed correctly, but then that doesn't end it there. I need to now keep an eye on the, uh, telemetry data that it generates. Now I need see some security experts to be able to look at the data and say, well, is it a real threat or is it a false positive?

So if you think about it, it is too much for a SME to take on, and that's where I think, uh, you know, it makes sense for the insurance companies to your point, right? It's not just about the stick. It's not about me saying that, Hey, you need to trim down the tree, but I also tell you that, hey, here is the, the best, uh, person to trim that, uh, tree down, uh, to mitigate the risk, right?

So we, we bring these services, uh, to make it easier for the policy holders so they don't have to go shopping around, go, don't have to waste time, get the job done as ASAP. Love it. Rajiv, I don't think we mentioned the website for cowbell.

Oh, yeah. So cowbell insure, um, you know, it's, um, a lot of information there for anybody who's interested, uh, including the resilience services. Uh, you know, it's a great place to, to learn.

And by the way, we also have Kabul Academy, uh, which is a really, really good place for even the brokers and the agents to go, uh, learn more about cyber, uh, security and cyber insurance. They can even take, uh, some of those credits that they can apply towards their, um, you know, um, the license renewals and, you know, the, the credits they need, uh, to stay on top of, uh, the tech and everything. Love it.

Thanks for coming on Tech Truck TV and making us a little smarter today. Keep us posted. You gonna be at RSA conference?

Uh, probably gonna be, yeah. I'll be visiting, yeah. A couple of days there.

Yeah, absolutely. Well, we'll be there, live on Broadcast Alley. Maybe come by and say hello.

Absolutely. I would love to. All righty.

Rajiv Gupta, co-founder Cowbell, cowbell Cyber Insurance, uh, check it out. We're watching Techstrong. We'll be back in a minute.

Hello and welcome to the digital CXO podcast. I'm Amanda Ani, and with me today I am excited to have Curtis Spar. He is the principal of spar.

How are you doing? I'm great, and thanks for having me. Yes, I'm happy to have you on the show.

Can you share a little bit about Bpar? What services do you provide? Bpar is the politely pushy tech and oh, I don't even know.

We're not just tech. We're FinTech, we're ai, we're pharmaceutical. It's like hard for me to just say, you know, the boilerplate, you know, elevator answer when we're doing so much.

But we've been remote since we started in 2015, and as a result, 10 years later, we have some thoughts on what makes an agency or any company really good when they have a remote first workforce. And I was hoping we could talk about it. Absolutely.

Well, I see a, a wall of a awards behind you there, Ta-da. And, you know, we won these awards to prove that remote work works better, and that's because we invest in people and not buildings. And at first people were like, Hey, you need a water cooler if you're going to have a creative agency.

And what happened is we kept on winning awards so much that we are the most awarded agency in the United States. And I think that goes to show what remote work can truly do. In fact, our research shows that it's better for many companies, bottom lines.

Wow. Well then you are the person to speak with today about remote work and the future of remote work and how it's going. You recently put together a study, so can you share a little bit about that study and then we can go into the results?

Yeah, you know, we did this as a point of view of what not only do employees get from remote remote work, which I think is kind of obvious, but what people who are hiring remote workers get, because we think there has not been enough research done there. And what we discovered is that oftentimes people reported better results when they hired remote workers or remote firms such as ours. And we think that this is a powerful part of the bigger story that other people are telling.

For example, the San Francisco Federal Reserve put out research that said fundamentally there was no difference between a remote workforce versus one that was in an office. And so this research shows that not only is there no difference in productivity, there is however, a difference in outputs. And that's, you know, having employees who are more 24 7.

Uh, it's for people who are more proud of the work they do, and when it comes to results, it's people, uh, reporting better results on work product than if they were in an office. And I think there are several reasons for that, including all the time wasted in an office. Like when someone wants to talk to you about what happened on White Lotus, which is definitely a crucial conversation, but perhaps one that doesn't really impact the work product as much.

Absolutely. Well, I know I started working remotely, gosh, about 10 years ago now, and I could never look back. So I look at some of these, um, uh, call to office initiatives and I completely understand the buck back there because I just don't think there's any way I could find myself going back into a brick and mortar setting.

So what are your thoughts on that? So we are seeing a lot of, uh, mandates to come back to the office, but we also are seeing some buck back. I wanna hear your thoughts on that, and then definitely I wanna get into some of the details of the report and, and what that means for business leaders.

You know, a lot of different executives are trying to realize the investment that they made in a brick and mortar building, and I think that's a lot of it. I also think, and I hate to say this, it's a little bit of some old fashioned thinking where whenever we have disruption, there are those that challenge the disruption itself and say, no, back in the day it was better. And they might not have any other reasons other than their memories or, you know, some warm feelings about office, you know, camaraderie.

But there's nothing that proves that. And so I think those kind of feelings are really what we're seeing. This is a sentimental return to the office, if you will, where people's emotions are getting the better of themselves.

But just from a fiscal number sense, it absolutely is not a good idea. And then when you think about the environmental cost, it's not a good idea. And when you think of the time lost, it's not a good idea.

The other thing is, is that it's a good idea if you could get workers from anywhere as long as they're talented. And by getting a talented workforce that is not shackled by their geography, you get rid of location think, you make sure that you are getting the best minds no matter what. And so there's really just so much to be gained.

Now, I'm not saying that every place has to be remote. I think there's some places like a hospital that make a lot of sense, and there are certain places where engineers have to gather and build things that makes sense. But for knowledge workers, overwhelmingly, it makes sense for those people to be working from home because you're really going to get a lot more out of happier employees.

Absolutely. I agree. So what are some of the key findings from this study?

Well, I would say the key findings are, you know, twofold. One is the self-reporting part where people say that they're more productive working from home. Um, you know, in fact, only 5% said that they had lower productivity when they worked at home.

So overwhelmingly working from home is better. Um, and I think the other thing that is important is over 80% report a improved work-life balance. And I think that is seen in the investment that they can make where they would be commuting, they can instead be working, and thus, you know, they don't have to kill themselves when it comes to their families, when it comes to, uh, making sure that, you know, young families get the support they need.

I think the other thing is that we're seeing interesting pushback on the mandates. We're seeing 73% of consumers would less likely purchase something from companies requesting full-time office work. Uh, 63% would be less likely to apply for jobs, and 60% believe companies to encourage remote work to reduce the environmental impact.

And so I think that those are, you know, the key sort of stats that are important in thinking about this conversation, especially as the next generation comes along, be becomes online because that next generation is going to be viewing these companies with a lens of what have you done for the environment? And we are right now running out of time environmentally in terms of how we can fix our, uh, footprint and remote work. If you do it five days a week has been shown to reduce that impact by more than 50%.

So I think that any argument about no, you need to come back to the office kind of falls apart when you're faced with the real live crisis we're in. And you know, I hear magical thinking about returning to the office and how it's better for, you know, the economy, but you don't have an economy if you don't have a species. Yeah, absolutely.

Some good points there. And it's very interesting that people are fighting back in that manner. I feel like we weren't focused on these sorts of things back in the day when we were shopping or looking for products.

We weren't thinking, okay, let's do some research. Do they have to have all their workers in the office or remote? You know, how are they with environmental missions and sustainability?

We weren't looking at these things, but now, um, these results are showing more and more people are making decisions based on this. So that's interesting. Yeah, and I think that, you know, every time these events like Earth Day come along, that you know, reminds people about it.

And a lot of companies try to lean into Earth Day because their research shows that younger generations really care about the planet and are very alarmed. But it's hard to square that with these, you know, return to work mandates that are pretty draconian. And the other thing that we have to consider is that each time the environment creates another huge problem we all have to deal with, that's when all sorts of people are gonna be thinking, how can we, you know, rectify the situation?

How can we improve it? So, you know, returning to working from home is going to become more important year over year, and I expect that to be the case. I also expect it to be the case, the, the better the economy performs.

When the economy performs really strongly, that puts, you know, the most talented employees in the driver's seat when it comes to making demands. And our research shows overwhelmingly that the most talented employees want to work from home. No one truly talented aspires to grow up and be managed in an office.

They want to be able to have that level of freedom to take an afternoon nap when they want, for example, or to take care of their kids. And that's, you know, part of what we're seeing with working from home is that people see it as a means of freedom. Absolutely.

That work-life balance. And it's interesting that you found, um, the quality of work is much better. Uh, you said there wasn't maybe a lot of difference in productivity, but the output of the work was better, uh, with remote workers.

And I would tend to completely agree. I would even say from my own experience, even my output of work was probably, uh, better because I felt when I had the flexibility and I had the room to work, uh, in my best environment, I was able to flourish in my career. That's when I flourished, was when I had that space and the ability to work in my best environment with flexibility to take care of my child if they needed to be picked up from school, um, not be begging, you know, to get off.

Uh, you know, so when that, when that stress is removed from your workday, it's so much easier to get more work done, better work done. It just makes sense to me. I I don't understand, I guess quite why some people haven't picked up on that yet.

Well, not only that, the thing that we're seeing from some of our Boomerang employees who said, oh, I want to try an office, and we said go, is they come back and say, you know, the thing is, is a lot of people are taking those work from home behaviors and they're putting them in the office. One person that reported that he would go in, everyone would be in, you know, their own separate rooms doing zoom calls and that no one would really talk to each other. And so all the things that, you know, people thought would happen when you return to office, that you have all this, you know, collaborations, et cetera, has really disappeared from, you know, just the expectation to get stuff done.

And that's what working from home really does, is you really have to be accountable for the work that you are offering. And so I think we're gonna see that more and more. Absolutely.

Yeah, when you're at home, you're just really cracking out the work and focused. And while the comradery side of it, I do understand there is a lot less, uh, less wasted time or standing around at the water cooler, as you said, uh, in the office because you're really focused and you can get so much more done and more quickly and efficiently. I've had so many good ideas destroyed because some coworker would come up and say, Hey, did you see what was on TV last day?

Oh my God. Or they would gossip or no one would come up to me and say, Hey bro, let's collaborate on a really good idea. Usually those collaborations were scheduled, they were timed.

And so a lot of the kind of chaotic kismet that people are talking about that happens only in a physical office, really didn't happen all that much. But what did happen is someone would come in and get everyone sick. What did happen is someone would come in and gossip or create a toxic work environment, you know, those problems with a physical office are rife from, you know, fighting over who has the bigger office with a better window to the condition of the bathrooms.

And, you know, don't get me started on the condition of American bathrooms and offices. I mean, they're just gross. So there's really nothing to be said about working, forcing people to work in an office, except that it somehow suggests you don't trust your staff.

Absolutely. I agree. And I wanna say I do understand some people actually missed working in the office, and I understand that for some people, they really, um, felt they lacked that, that social aspect that they needed.

Uh, but I do feel that a lot of strides have been made, uh, from remote, from the remote aspect with, um, being able to bring that social aspect in and the comradery. There's a lot of tools and technology and, um, communication channels like Slack and, um, various other methods, zoom, et cetera, that have been able to help in that area. But I do understand that there are some people who do still prefer in-person work.

Well, you know, of course I think there are people who, who appreciate that. And usually we find the people who like it the most are at the very start of their careers where they need some sort of handholding. And so oftentimes when someone needs that level of handholding, we will fly that person out to a mentor who can help train them so that they can get that feeling of, you know, one-to-one, uh, bonding and team building.

But I think the other thing when it comes to that sort of needing to be with people is that's what coworking spaces are for. Some people just pathologically need to be with someone else in the room to get work done. That's, you know, what they're for.

You know, one of my friends said she just likes going to a library just to feel other people there. And I could appreciate that. For me, I have pretty stacked days, so I don't have that sense of loneliness.

In fact, I don't think anyone at our company does. But there are ways that working around that, I just think the point about forcing people to go to work and or go to an office is not really well thought out, and there's just no scholarship that supports that, you know, it's better in any way, shape or form, but there's plenty of research to show how bad it is. Yeah, I agree.

And we even have a, a remote working space here in my city. And, um, at our all hands meeting a few weeks ago, we all met at a remote working facility for our, for our meeting. So that's really great.

And that does provide that. Well, if there were any other things you wanted to share from the study, I know you had a companion study by reputation leaders, um, found, let's see, 73% of consumers would be less likely to purchase from companies. You mentioned that.

Um, so what do you think, let's talk about that for a second. Um, as more people are looking at this and determining who they're gonna go to, what do you think business leaders need to take from this survey moving forward? I think that this is a serious, uh, reputational issue for a lot of companies because companies are not looking at the big picture about how the next generation and the generation to come are going to view these decisions.

And that's why I think it's super important for us to have these conversations about what the impact is for companies that insist on returning to the office or how those demands are couched. And so that's why we've been raising the alarm on this because we know working from home for knowledge workers works, and we know that a lot of people are, you know, evaluating companies that are not buying into this future. I think that, yeah, of course we're having some push and pull, but I suspect in the next few years, working from home is going to be the norm for a majority of Americans and a majority of knowledge workers.

All right. Well, if there was one key takeaway you could leave our audience with today, what would that be? I would say that you should trust your staff.

If you don't trust your staff, you're not gonna be able to really have a work from anywhere environment. And, you know, trusting your staff is the bedrock of working from home. Absolutely.

All right. Well, thank you so much for coming on our show and sharing your insights with us today. Oh, thanks so much, Amanda.

I'm glad you put up with me. It was a great conversation and thanks to our audience. Stay tuned.

There's more. This is Textron tv. Hey guys, thanks for the throw.

We're here with Christian Rodriguez, who is field CTO for CrowdStrike, and we're talking about a new report they have about the threat landscape, and in particular, what's going on with all these attacks against Sarah identities. Christian, welcome the show. Hey, thanks for having me.

What exactly is the challenge with identities? Because we've been using passwords for as long as anybody can remember to identify a friend from foe, and here we are in 2025, and basically people are realizing that that's not working anymore. But why?

Well, I mean, identities are the path of least resistance for the bad guys. If a, if an adversary gets a hold of an identity, it ultimately means that, uh, the adversary can blend in the environment, uh, as much as possible that they can emulate a legitimate user. They don't necessarily have to drop a piece of malware in an effort to gain their initial access or, or, or stay persistent.

Um, and it's just very easy. It's, it's, it's just a very simple way to get yourself into an environment as the bad guy and, and stay for as long as possible while not alerting a defender to your presence. To your point, are the bad guys, they don't break in anymore.

They simply log in, right? Yeah, exactly. They're just logging in and they're, they're trying to, they're trying to be like an everyday user.

So how pervasive is this? I mean, you guys did this report, but how big a problem is this? Yeah, I mean, it's, it's been an increasing issue.

I mean, from, from everything from, you know, access brokers that are, that are basically selling that initial, you know, list of identities or the actual access into these environments, there's been a, uh, a, a 50% year over year increase in the amount of access broker advertisements, which basically allows for a bad guy to kind of waltz into the environment with, again, without having to drop a piece of malware. So that's been an increase, uh, an interesting, uh, increase, uh, year over year where, um, you know, identities are kind of the focal point of in, in an interesting ECR ecosystem or marketplace of, of allowing someone to basically buy that access. And so that's an interesting trend that we've noticed.

And then we've noticed also that there's been a major increase in, uh, the amount of, uh, of voice phishing or ving attacks that we've seen where there's a roughly 442% increase, uh, that we saw between the first and second half of 2024. And what that ultimately means is that, uh, adversaries are calling in to enterprises under the guise of a legitimate user that is having problems resetting their passwords, and they're emulating, or they're pretending to be this specific user and they're asking for credentials to be reset. You, you mentioned passwords and, and that's an interesting way, way or, or method that adversaries are, you know, again, just kind of pretending, you know, and social engineering, they're their way into an environment in an effort to gain access to those legitimate credentials so that they can log in and, and then kind of have free rein of, of access to anything that that user has access to.

Ultimately, what is the cure for all this? 'cause we see everybody tossing around things from, uh, pass keys to biometric authentication involving your eyeball. It seems to be a lot of choices, and I'm not quite clear.

Everybody knows, uh, what to do or, and when to do it, You know, so I think it's a multi-pronged approach of, of first and foremost having the ability to, in real time understand who's accessing or authenticating into what resource, understanding what your policies are around, um, uh, who, who should have access to different resources, but more importantly, in real time, having the, the ability to understand what an outlier is. If I, if I see someone, for example, trying to authenticate to a system that they've historically logged into from, let's just say Miami, Florida, and all of a sudden they're, they're trying to log in to that system from Oxford, for example, within an hour's timeframe, that's, that's what's called an impossible travel, for example. And so there are use cases where you can emulate, or you can ultimately create real time, uh, analysis that says like, this is not legitimate, or this is suspicious at, uh, at least.

And from there, doing things like step up authentication or having the ability to even assess the endpoint and the system that the user is making that authentication request from in an effort to, to in real time stitch together what is real authentication versus what could be stolen credential versus what is, you know, maybe even a service account or some outlier, uh, authentication attempt that you could ultimately start to, to mitigate against or prevent. I also feel like in a lot of ways, we are our own worst enemy because we seem to give end users access to everything. And some of that is just kind of being lazy and somebody says, well, here's my new hire, what should he have access to?

I don't know, he is probably gonna need this and this someday. So give him everything. And then the next thing you know, their credentials go missing and the blood guys have access to everything.

So are we a little sloppy in how we grant privileges? Yeah, I mean, there's, there's a hygiene issue. Undoubtedly.

We see this every day when enterprises call us in and they, for example, even use our technology to do an assessment of like active directory. What's interesting about, um, an authentication system like active directory is that no one, no one built it yesterday, right? Like usually active directory is inherited.

And there are, to your point, there's an excessive amount of privileges that are granted to users over the course of their careers. And then a lot of times those privileges are just simply copied into, uh, these roles. And these roles are then kind of issued down into users as they're onboarded.

And that has historically created this problematic hygiene issue where, um, users just have just excess permissions into resources or roles that they really shouldn't in the grand scheme of, for example, like a zero trust framework. And so because of that, um, there are lots of issues where, uh, no one's really assessing or reassessing and reevaluating the, the permission sets and the hygienes of those users, or things like even password expiration dates or, you know, the fact that maybe a user that should, that is accessing certain servers, um, you know, that's not really part of their job and maybe they, there needs to be a new policy that ultimately enforces control around, you know, what those resources are. And then even what happens after they authenticate in terms of authorizing access to other applications.

So that's something that a lot of enterprises are being, uh, challenged with, is ensuring that there's a hygiene of the users, their identities, their permissions, and then, uh, a list of available resources that, um, that the user should have access to. I also feel like we obsess a lot about onboarding 'cause we're trying to make somebody productive, but, um, I would suspect that you and I probably still have access to any number of systems from previous jobs that nobody off boarded us from. And so is that also part of the issue here?

Sure. I mean, I think it goes back to that hygiene issue of saying, when's the last time someone did a reassessment of that user's, uh, I identity and their, their role that they've been assigned. And, um, we, we have this amazing capability of, of understanding, um, what those permissions are, is that ultimately excessive?

And what is a user actually doing in real time, right? Once, once once they authenticate onto a system, and then where, where could they possibly go? And so I think, you know, the offboarding concept, it's, it's harder for larger enterprises that have, you know, you know, tens if not hundreds of thousands of employees, uh, that they need to revisit each of those different business units and do analysis of, again, the identity of the user, what those permissions are, where they should have access to, how they should have access to.

But then even enforcing multifactor across those, uh, those applications, I think is a really big, uh, you know, step up in terms of, of how they can control or have some compensating controls around that hygiene problem. Because if I can enforce in real time additional, uh, multifactor and conditional access controls, I can, I can force that user to validate that they are who, who they say they are in real time as they're making those requests, you know, uh, to, to those different resources. So you guys have this report, and I know you've been around the block a couple of times.

Anything in here that kind surprised you that you went, wow, I, I I thought we were better than that? Uh, I would say, um, that's a, that's a really, really great question. Um, so there's some really interesting points around the amount of vulnerabilities that we've seen.

There's a 52%, um, you know, uh, really 52% of the vulnerabilities that we observed rather were tied to like initial access, which basically means that adversaries are trying to find their way into your environment by any means necessary. And so that includes a, obviously an identity that includes also vi vulnerability. But I think the, the major, the major number or the major, you know, uh, factoid if you will, that that really stands out is this concept of breakout time.

And we've been tracking this breakout time, uh, number for probably since 2016 when we started to do analysis on how much time it takes for an adversary to move, uh, from the, the, the system of compromise into a neighboring machine. Basically, think of lateral movement, right? So how long does it take an adversary to move, you know, once they've compromised one system onto another set of machines?

And there was at one point, the average time would be roughly like four hours, and that number started to decrease substantially. This, uh, last year we, we averaged out based upon an assessment and observations of various at, uh, attacks, hundreds of them, uh, breakout time was roughly 48 minutes, right? And so think of the amount of time that, you know, it takes for an adversary to now move from a system, uh, that's compromised into neighboring devices or even cloud assets or anything that they essentially have connectivity to.

It's roughly 48 minutes, which is a staggering number, but the fastest time that we saw was 51 seconds. And so that's a pretty substantial increase in, in terms of speed and velocity, which, which from a defender perspective, you also need to become faster, right? So I think that's a very staggering and, and very worrisome number that we're observing and we're keeping an eye on.

And there's so many different, um, facets that contribute to that, that increase in velocity. AI could be one area. Identities are a massive area where that initial access is simply gained by having a list of ident identities that can be used for further authentication.

Um, you know, the velocity at which adversaries are running their scripting on these systems. Those are all major contributors to that number being smaller and smaller every year. When we get to the point where we can track from the moment the breach to remediation, what the actual cost was to the organization, and we could have this like little meter that's just going click, click, click, click, click while we've looked for this particular resolution.

Yeah, I think, you know, I think this could have begs or, or, or leads us into conversations around like even AI where like how does the defender get faster? I think there's like AI that can help augment and, uh, help give a little more context around the impact of, of a series of events, right? Whether it's a breach or whether it's a initial endpoint that gets compromised.

And I think as with every business, there needs to be, uh, an assessment and understanding of what risk means and what is your appetite for risk, and then what is the impact to the business throughout a variety, variety of different attack types. So there's everything from ransomware costs to the cleanup of identities being compromised to things like data theft and intellectual property being stolen. And those are all, um, you, it's just varying, uh, attack types that ultimately have very different figures, uh, at attached to them.

And I think that we can probably leverage the AI to help us get to those answers a lot faster. To your point, we are rapidly moving to an era where the bad guys are using AI to launch attacks in volume and sophistication that no mere mortal is ever gonna be able to defend against. Sure.

And so we need AI to defend against that, but, um, we also need people who know how the AI works. So we getting to a point soon where maybe most organizations should just rely on some sort of AI driven service rather than trying to fight the fight themselves because they're just never gonna win it on their own. I, I don't think there's a concept right now of, of solely relying on ai.

I think that AI is there to augment the SOC analyst experience. It, it's there to increase the velocity at which you can defend. I think it's there for providing a lot more context into things like identities and the misuse of identities and the fact that, uh, someone logging into one system trying to authenticate against applications that they've historically not accessed that can be, uh, supplemented, if you will, with AI specific intelligence and kind of like an overlay that, that helps a defender get their arms around things like outliers and what's anomalous.

And essentially think of a combination of AI and machine learning. So I think in the grand scheme of the defender, you know, we, there's a saying here at Crosscheck that you don't have a malware problem, you have an adversary problem, which means that there is a human on the other side of that keyboard launching the attack. Ensure they may have AI as part of their tool set, but I think as a defender, you know, you'll have AI as part of, you know, the list of, of, of tools in your tech stack that will help you respond faster.

I don't think we're getting to a point anytime soon where it will be, uh, just ai. Um, but there's gonna be dependencies that that will help you as a human respond to the events that require a lot more prioritization. And I think that's where AI will, will start to lend some help.

But to your point, as an organization, should I invest in getting my own SOC analysts or should I just rely on somebody else's to do that who is being augmented by ai? And maybe, you know, we still need cybersecurity people. It's just a question of who they're gonna work for.

Yeah, that's a great, that's a great question actually. I think, um, I think, you know, when you are building out your own soc I think that you are going to be challenged with, um, you know, how, how much you can stretch a resource, right? I mean understanding, I mean, the crowd in CrowdStrike, for example, is us crowdsourcing this telemetry from over 2 trillion events every single day that we get to analyze and apply machine learning and AI models against.

And ultimately that also, uh, includes a huge human element of threat hunters and threat researchers and intelligence analysts that, um, can understand this data and can do a lot with that information in the form of behavioral patterns and machine learning patterns and, uh, understanding new trade craft and techniques that adversaries employ in their respective campaigns. And so if you're building out your own soc yeah, you, you will have someone that is locally available to help prioritize and help respond. But I think leveraging a resource that understands globally, for example, at the scale that, for example, crowd side could, could, could analyze these events at, I think that naturally benefits you as a defender to have access to that information versus having someone that is gonna be very focused on activity that's within your respective environment, which is still good.

But as an extension of that, you still need this top of the funnel perspective into everything that's happening globally. You, you know, a a way to help operationalize the intelligence that's being captured. And, and, and a lot of times enterprises are challenged with having the right resources to accommodate that type of scale.

Now, of course, the bad guys are weaponizing this stuff into various services and it's all highly automated, and from their perspective they're kinda like, why would I do anything more complicated when what we have today works just fine? But are there any particular new threats on the horizon that you're looking at that go, wow, we need to pay more attention to this? Yeah, I think one, one of the biggest areas we're seeing now is tied to insider, uh, uh, risk and insider threat, right?

We, there's, um, you know, if identities are being a major focal point of, of adversaries in an effort to stay, you know, sticky and, and, and get quick access, we've also seen an increase in insider threat use cases where from a nation state perspective, countries like North Korea have been embedding agents into enterprises in the form of employees that are software developers. And so we're seeing an interesting increase where these nation states may place, may have someone go through, uh, an interview process and they may leverage things like AI to build fake profiles on, uh, job posting sites like LinkedIn, for example. And they will go through these interview processes using fake identities, and they will ultimately, um, you know, go through a very rigorous interview process where once they get the job, they will have their laptop sent to like a laptop farm.

You know, there's a whole process behind essentially how they gain access onto the system using, um, remote management and monitoring tools. And then from there they have the ability to embed, you know, malware or something malicious into the code that they're developing on behalf of that enterprise that hired them. And so we're seeing that ai, for example, is being used to, uh, weaponize hiring processes so that there's an actual people component to, you know, getting into an enterprise and then having access to sensitive data or, you know, or just being on a payroll to, you know, further, uh, you know, send those funds into something like new North Korea's, you know, weapons program.

And so that's, that's an interesting trend that we, we probably anticipate seeing more of, uh, this year And other countries will probably follow suit. Absolutely. Lemme ask you, is there something that you see organizations doing that just makes you shake your head a little bit and go, folks, we need to be a little smarter than that?

Yeah, yeah. I think any organization that is depending for thinking, if we're talking about identities, I think any organization or enterprise that has defaulted to like a, a text based, uh, or SMS based two factor authentication schema, um, I think that is, is antiquated at this point, especially given the way that adversaries can leverage sim swapping as a mechanism for stealing your identity. Meaning that they will call up your cell phone provider and they will pretend to be you, and they will get, uh, that cell phone provider to convert your SIM or your eim into their phone, and now they have access to all of your text messages and your phone calls.

And if you have that as your multifactor authentication mechanism, then it's very easy for, for someone to call up and, or, or reset a password, get that MFA prompt on their phone as a bad guy or bad girl and, you know, and then actually gain access to the resources that you have access to, um, based upon your identity. So I think any, any organization that is still leveraging an SMS based MFA tool, um, I think needs to really start looking into things like hardware, tokens and, um, you know, something that is a little more, you know, individualized to the, to the end user. So what is your best advice for folks who, I think everybody nods their head and says, yeah, zero trust, we need to get to zero trust.

Yeah. But the, the journey between where they are today and achieving zero trust, which may never be perfect, um, is very far. So how do I kind of get down this path in a way that I think a lot of folks look at this and they just get overall and they do nothing.

Yeah, I think it's, it's having a technology that can start to stitch together in real time. You know, what does an attack really look like these days? And it's, it's gonna be identity based naturally as kind of your initial access.

Um, but it's also this ability to understand that adversaries are, um, becoming enterprising. There's this theme that we have in our report of the enterprising adversary, and it ultimately means that adversaries are, are very opportunistic and they will find their way into your environment given the resources that you've invested in. And so understanding that an adversary may target your endpoint or your cloud infrastructure, or once they have access to that identity, they have the ability to navigate, you know, everything that's in your enterprise.

I think that organizations need to invest in capabilities that can stitch that in real time, those data points, that what is my, what are my identities doing? What are my endpoints doing? What are my cloud assets?

Doing? What, what do I see from a third party perspective? And then how do I start to add behavioral analysis to understanding what's real versus what's an outlier versus maybe what's a broken business process or a process that needs improvements?

And, uh, and then re and understanding every business unit in terms of, you know, how they access data and where that data should go to and who are your actual partners and business partners. So I think, you know, if I were to, to to say, let's, let's be a little, you know, consultative, I think it's really more of ensuring that you have a technology that bridges and, and brings all that data together in a cohesive fashion, but more importantly, can in real time give you that visibility into what is, what is an outlier, what's bad, um, how do you mitigate against it in real time naturally. And then ultimately, how do I start to build a trending view into what, what did I see a week ago versus where am I going, you know, in the next, in the next few weeks, Right?

Folks, you heard in here, it's a never ending battle, and the tactics and the techniques used by the bad guys continue to evolve. So, so do we. And if we don't, bad things are gonna happen.

Christian, thanks for being on the show. Thanks for having me, Michael. All right, and back to you guys in the studio.

Hey everyone, it's Alan Shimel here for another Shimmy says, you know, I love doing these, shimmy says, to tell you the truth, it's kind of cathartic. But, um, this week I want to talk to you about tariffs and tech. Lot of talk going on about tariffs.

We're taring here in the US our three biggest trade partners probably, and, uh, talk of trade wars and, and retaliatory measures and all kinds of stuff going on. We could talk into about it at the macro level, but I want to talk to you today about what effect these tariffs are gonna have on our tech market. You know, the tech market's been quite frankly, shaky since the end of Covid.

We've had so many layoffs, more layoffs than many of us remember in the tech space. A lot of it is the result of hiring binges during Covid where we probably overhired and things now have kind of evened out. But what effect will these tariffs or could they potentially have on the tech market?

I think if we look at it, we gotta start at the semiconductor market because so much of tech starts at the semicon, you know, revolves around the, the hardware and the, the chips that are running all this software and AI and everything we're doing. And let's be clear, 80 to 90% of the semiconductors that we use in the US come from Taiwan and ti uh, China and Taiwan. Now, I know I, last week I talked about $2 trillion, and President Biden had this chips act where they had hundreds of billions of dollars set aside.

But the fact is, as we stand today, we don't have a big capacity to produce these chips here in the us and to build that kind of capacity, it's gonna take a minimum of three to five years. And quite frankly, we've never produced that quality and quantity of chip here in the us. It three to five years is the minimum.

We may find that it takes retraining an entire workforce or doing something pretty drastic. So what do we do for three to five years? Are we at the mercy of these tariffs and the 20 to 25% cost that may be involved in, in, in importing them?

That's anyone's guess, but to think that this is gonna force us to use us made semiconductors, yeah, it might, but we've got a five year gap to, to fill in there in the meantime. Um, what, what does it mean for the other tech industries? Well, first of all, let's remember how much of our technology, you know, revolves around those semiconductors, those servers.

What's it, what's cloud cost gonna be when they gotta pay more for their, for their hardware, data center costs, AI costs everything. You know, all this money pouring into ai, we're going to need it if it's 20 to 25% more. So, you know, the, the, the, the, the cost of the basic semiconductor, it ripples through the entire tech sphere, but forget semiconductors even for a second.

What about other materials that go into computers, other services, rare earths and minerals and so forth that you need raw materials, right? We get a lot of raw materials from Canada that's gonna cost more energy. We actually, though we're kind of energy independent in the amount of energy we produce here in the us we actually do share energy grid with Canada.

What is, what is that going to mean? Um, it, it's, you know, it, it's a ripple through the entire tech sector. On top of that though, there's, there's other, there's other macro conditions to worry about.

If car manufacturing slows down because of tariffs or, uh, uh, other imported kind of goods slowed down and it slows down the economy, inflation goes up, interest rates go up, people start buying less tech again, that's gonna have a very, very chilling effect on, on the tech sector. So our domestic tech economy and, and, and, you know, tech has become a big chunk of our economy is, is at the mercy of these tariffs, at least for the short term of three to five years. Now, on top of that, there's another aspect we've gotta think about, and that is, what about when countries retaliate against us for our tariffs by raising their own tariffs?

So now all of a sudden it becomes much harder to sell US technology in Europe and China and India and Taiwan and Canada and Mexico. I will tell you that most tech companies, at least 40% of their business is international non-US. If, if countries reciprocate against our tariffs by having tariffs of their own, you are talking about, all of a sudden it becomes really hard for us tech companies to sell their technology to foreign markets.

And what does that mean for the tech sector? What does that mean for the tech sector? Do we have tech companies move out of the US over it?

Do we bifurcate tech companies into US based versus foreign based and split 'em up? You know, how much money does a company like Apple or Meta or Google make from foreign markets and, and, you know, those companies are ripe targets for countries and nation states that wanna reciprocate and retaliate against our own tariffs. I've always been a proponent of free trade.

I, I think I have a lot of faith in the American ingenuity, the American industrial engine, that given a level playing field, we could out innovate outproduce and outcompete any competitors or at least hold our own. At the very least. I'd like to see us make more level playing fields, not erect barriers and turn inward in some sort of isolationist stance because it's not, it's not good for our tech sec sector, it's not good for our economy as a whole.

It's not good for our nation as a whole. So I'm hoping that a lot of this ta tariff stuff winds up just becoming posturing for, for trade negotiations. But I fear, I fear it isn't.

And it could be we're in for some rough rides in the tech sector in the next three to five years, or at least until this administration's over and maybe some, some new kind of blood and new way of looking at global trade comes into power. That's it for this week, for Shimmy says, I hope you've enjoyed it. It's, uh, it's interesting times we live in.

com page doing the Textron Gang. So I look forward to seeing you then. But until then, this is Alan Hummel, we're out.

Hi, I'm Peter Smore and I will talk about agent AI hype or the way to unlock productivity gains in software engineering. Today you will learn about the path from AI assistance to agents. We look into use cases, maturity of agents and processes for using them to gain productivity in software engineering.

Finally, we will dive into an example of how to use agents for unit test generation. Some words about myself. I started my career as a software architect in the field of, uh, internet of Things, IOT.

Then I did a PhD in static analysis, verification of embedded systems. I then continued my research at, um, university of Oxford, became a lecture in computer science, and then, uh, co-founded the AI for Codes of Startup. And as a fun fact, I'm a keen background here.

So in the last couple of years, AI assistance gained widespread attention and many companies have rolled them out across the teams. However, reports on productivity impacts have been mixed so far. 2025 could be the year of agent ai as assistance will evolve into agents able to reliably perform large tasks on their own.

Let's look at the common definition. An AI agent is an autonomous intelligent system that performs tasks without human intervention. Well, we don't really know what intelligent exactly means, so The core of this definition is autonomous and human without human intervention.

So we'll see it. Assistance and agents support different use cases. So as systems are useful in the course of the creative process of developing something, the usage is highly inactive and iterative in drafting solutions to small tasks.

Also, they don't really need to produce perfect results all the time because the user can immediately fix the output at at low cost. So, however, in uh, autonomous agents, they require a little to no induction. There's, they scale to large tasks, which of course require them to be most more trustworthy for the outputs to be correct.

So we'll see that there is actually a continuum from assistance, uh, to agents. So they require level of position to depends on the use case. So sometimes good enough is 80%, sometimes it means a hundred, a hundred percent.

So if you want to have a fully autonomous AI agent, then it needs to be trusted a hundred percent of the time, whereas an AI assistant can really deliver value when they are only right 80% of the time, or even less. So. The car industry has experience in developing agent systems for a long time.

The Society of Automotive Engineers as a, has developed a maturity model for driving automation, which consists of six levels in levels zero to two. The user, which is the car driver, is in charge of driving the car and is assisted by various automation features in levels three to five. The user is not driving the car, but the car is actually driven by the AI system autonomously.

Still at level three, the system might ask the driver to jump in when it can't handle the situation. So this is my take on a maturity model for AI systems. We have a couple of levels, um, and we distinguish these levels based on properties such as TEX initiative, which kind of task to handle human action, whether the system has actually the authority to execute for real, um, the required accuracy and the ability to adapt and, uh, improve over time.

So level zero would be manual work. Then on level one, we have assistance on level two, we delegate work to an agent on these two levels. The initiative comes from the user, which is usually the case for doing some creative work.

So assistance a set can handle small tasks, whereas to an agent that can delegate also larger pieces of work, the in action with an assistant is in a tight, iterative, interactive loop. And since it's supervised by the user at all times, the required accuracy for the assistant is not too high. Of course, I'm going to be more productive with a more reliable agent.

The larger the piece of work delivered by an agent, the more expensive it is to understand and thoroughly check its output, amend and rework it manually. So generally, the more autonomous the agent, the higher the power for accuracy. Hence, already a delegative agent is required to be much more reliable than assistant.

A delegative agent might also ask clear questions about the task to the user, but such interactions need to be minimized because otherwise the productivity benefit is lost by constant context. Switching on the user side, on level three and four, we have agents that listen to the environment to take actions on their own, whereas the level three proactive agent may still ask questions to the user and require approval. The level four autonomous agent doesn't require any interaction and can act without you on approval.

Of course, to trust an agent with such permissions requires perfect accuracy. Maintenance tasks are typical examples for proactive agents, where the agent identifies the needs to perform the task and delivers the results to the user for approval. The accuracy bar for such unsolicited work is higher than in the delegation case, because the user needs their bit weakly convinced about the utility and the quality of the work, and has little motivation to rework the output.

The right most column is traditional automation like we used, for example, in continuous integration and delivery systems, uh, CICD. So traditional, uh, traditional automation is very similar to autonomous agents, but are dis is is distinguished by the nature of the tasks that it can handle, which is usually very well defined and and specific. So they, uh, also, they traditional automation is usually has no ability to automatically adapt and improve all the time.

So the cost for adaption is expected to be much higher for such a, uh, traditional, uh, automation system. So why on, uh, autonom reliability so important for unleashing productivity gains? So in this chart, we compare the difference in index.

When using an AI system to handle a certain task on the horizontal ask, uh, axis, we have the time and the different, uh, colors, uh, distinguish different kinds of, uh, parts of the task that need to be done to achieve, uh, the task. For example, when I use an assistant, I need to first instruct the tool, uh, what it needs to do. Then I wait a bit for to receive an output, and if the result is not acceptable, then I have to rework and fix it and finally check and approve the work.

So when I deliver a piece of work manually, then most all of the time is attended, which means a per person is actually sitting there and working towards delivering the task. So with an assistant, the work can potentially be achieved, uh, faster, but they way the work achieved is achieved is much, uh, is very different. So it usually, uh, consists of multiple cycles of interactions with, uh, the tool.

And, um, all this time is, again, is, is fully attended. So the advantage of using an agent is that a big portion of the time is actually unattended, which means I can go away, um, do some other work, uh, in the meanwhile, but if the agent is unreliable and the work is is not acceptable, then I actually have to spend time in actually maybe reinst instructing the agent or even fully understanding the output and reworking it manually, which quickly results in the effort exceeding any productivity gains. However, with a reliable agent, it, they attend, attended time will be tiny, and the productivity gains can be traumatic.

So with our autonomous agents, the at attend time will even be zero. So agents only yield or or proportional productivity gains when handling rather large tasks and only unattended, asynchronous, uh, operation allows me to productively use the time while the tool is operating. So therefore, interactions must be minimal to avoid determining context switching, uh, to the user.

So assistance speed up part of the work, but, and, but everything is fully attended. So the productivity gains through agents depend on their reliability to produce accurate results, or in other words, how much rework is acceptable so that there is still a productivity increase. The larger the output produced, meaning the larger the task handled by the agent, the more expensive it is to fix incorrect output.

So only a reliable agents yield actual consistent productivity gains. However, assistance are already useful with lower accuracy because I can fix the output at low cost immediately, but the gains will also be not as big as for agents. So from what we have learned so far, there are two different effects on the productivity of software engineering that we need to understand.

The first one is the so-called booster. So let's take the example, uh, depicted in the upper half of the slide. So we need to fit, uh, three tasks, task, 1, 2, 3 into a, a sprint with, um, bounded capacity, let's say two weeks.

So here, task three doesn't fit in on the sprint, so we, we can't deliver it. However, if we have an, uh, automation booster, it'll shorten the delivery times for each of the tasks and we can actually fit it. So the booster helps us to deliver tasks by increasing, uh, velocity.

So another scenario is shown in the lower half. So here again, we need to fit three tasks. Task one and two have priority, and task three has lower priority and is also quite large.

So typically such task will, um, never be deliberate because it, the higher priority tasks will always take precedence. So to deliver such a task, we, we need an enabler to, uh, and which yeah, uh, which allows us to shrink task three to a reasonable size and fit it into the sprint and, and get it done. So, difficult example for such task, like task three are, um, take debt or cleaning up or modernizing the code base.

Such tasks will always take a backseat in comparison to features that deliver immediate value to customers. So having an enabler to take a such tasks not only allow us to, to get them done, but also gives a secondary boost to delivery of, uh, actual customer features. So next, let's have a look at where there are automation use cases in the software development lifecycle.

This table shows various stages of the lifecycle from environments analysis to maintenance and and modernization. So environments analysis and validation are the hardest to fully automate because they require talking to the users together with design and planning. They are at the core of the creative process, requir a lot of human intervention interaction and integration.

So however, we can already see tools emerging there that, for example, produce mockups of user interfaces based on requirements then build integration delivery and deployment are already fully automated because they were the target of traditional automation endeavors through CICD pipelines. Currently, the hottest area that receives most attention is implementation. So we already have level one assistance there, like gigabot, for example, and we are seeing the emergence of level two delegated agents.

These agents are not as mature and can only handle small well-defined tasks. Uh, at the moment, use cases in other areas are more mature. For example, in the area of of unit testing, there are proactive agents such as deep blue cover that automatically write tests on polygraphs and where they see need.

Also for UI testing, there are agents such as fix AI that can automatically walk through user interface and find bug automatically similar. There are tools that can, uh, automatically pinpoint root causes of system fails in production, and there are tools that can perform complex maintenance tasks as automatically upgrading software dependencies, keeping the code base brain removing cold smells and fixing security vulnerabilities. Today, none of these tools are really deployed in a fully autonomous way, in the sense that they still require human approval to merge code into production.

So gaining the necessary trust into this system takes some time, even if they're already operating at a very high, uh, at very high accuracy levels. So, for example, the use case of human test generation for legacy systems can be considered level four autonomous, but enterprise company processes still require code pass through review processes and approvals. Uh, today in the last part of this talk, let's talk, let's look at, uh, agents for writing units.

So I've identified here three use cases where we need to write unit tests. In the first one, we have a untested code base, typically legacy base code base where we, the task is to write a regression unit test suite so that we can then make changes with, uh, more confidence. The problem is that this is usually a multi-person new project and doesn't have high priority because it doesn't really solve any immediate, uh, customer problem.

The solution is here, uh, to have an inhaler that take this problem like a level two or three or four agents, such as deep blue cover that can write the required, uh, tests fully automatically at scale, shrinking and some mountable task inter effectively and no-brainer. The second use case here is writing new code for a feature where I need tests to check whether my implementation works fine. So writing this test is not the most insurable task for developers and slows down the delivery of the feature.

Here, a level one assistant can give us a boost. GitHub cover load can do this, for example, but also the, uh, difficult cover inte login helps me. The first case is continuous testing, where the goal is to maintain the level of testing of a code base.

This involves fixing tests that start breaking, making sure the tests are written for all the code changes that make their way into the code base. The problems we're facing here are the, the lack of team discipline and also slow downs in, uh, feature delivery. Here, a level three agent such as deep blue cover can help to maintain the test automatically, uh, within the continuous integration system.

So we conducted a study to compare coding assistance, uh, with agents. So you can think of that like a race between a assistant enhanced experienced developer and an autonomous agent to write unit tests for 20,000 lines of code within an available time box of 260 minutes. At the end of this time, the autonomous agent, in this case, D Blue cover, was able to achieve a coverage of 53%, whereas the GitHub colo enhanced, uh, developer only achieved uh, 15%.

The main difference there is that they or developer had to work hard for the whole time period, whereas the agent ran completely unattended and the developer could spend the time working on something else or just go for lunch on the business Logic code for which, uh, tests were written. They test quality measured by coverage, and test strength was about the same. The difference though, is that, uh, the, um, agent was, uh, completely unattended.

What makes this huge productivity differences happen is the higher reliability and accuracy 100% for the agent, versus 64% for the assistant, which then in turn reduces the time in spent in interacting with the tool and reworking the results that the tool produced. So in the case of the agent here, no human induction is required apart from a few seconds for kicking off the tool. This also allows for higher scalability.

4 million lines of code in a whole year, provided that they don't quit before that because of the sold this drawing drudgery that is involved in this task and agent in contrast, can write tests for 25 million lines per year on a single laptop. And it is also cheap to scale up even further for parallelization because it's just compute. So, whereas with a coding assistant, one would require to use more expensive engineering stuff to scale.

To summarize the takeaways of this, uh, talk, so agents and assistants are already part of the engineer landscape today. Reliability and accuracy are crucial for smooth interactions and through productivity gains come ultimately from such reliable autonomous agents. And unit testing is the most advanced use case on the agent material scale.

And if you're interested in the deep blue cover tool that I mentioned, we have recently released a developer edition for which you get a 50% uh, discount with this discount code. So thanks for your intention. Hey everyone, welcome to DevOps Unbound.

I'm Alan Schell, CEO and founder of, uh, tech Strong Group. And DevOps Unbound is a, uh, semi monthly, which means it's twice a month, I think, uh, video series that we've been doing now for about three years. And we explore every nook and cranny of the DevOps universe.

Um, for three years we've been producing and putting on the show in partnership with our good friends at t Tricentis, who I couldn't think of a better partner and a partner on this kind of thing, where if they, if you're not familiar with Tricentis worldwide leader in continuous testing and so much more today, um, and as I said, we do these shows twice a month and then maybe once a month or once every month and a half, we do what we call a live round table version of these shows where we invite you, our studio audience to come in and participate and kinda lead the discussion. Unfortunately, this is not a live one. This, this is a, a prerecorded version that we did here at Tech Trunk Studios.

But, um, you should pay attention. Well, we'll, if you ever go to Textron TV and you can see the schedules of our live events of, of these, and we'd love to see you at the next live round table. We do actually, Mitch, while I'm talking, maybe if you can grab a, a time and date and when I come to you, you can even we'll do that with a little plugin.

But, um, before we come to Mitch though, besides thanking Chiantis, I want to introduce what this particular episode is about and introduce our panel. Today's episode is API first and API testing. We're going to explore all things around API here.

You know, API traffic represents the majority of the traffic on the internet. I've seen numbers as high as 83%, which is the last one that came out of Akamai. Uh, I've seen Cloud flare.

I think they had it around 70%. So no matter whose statistic you go with, it's still a majority of the traffic on the internet. Um, we're gonna talk about, you know, API first development, and we are going to talk about, um, API testing and, and more.

Um, our crackerjack production team has already gotten me the date of for our next live round table. And if you're interested in attending this market calendars now, it's on July 24th at 11:00 AM and we're gonna be talking about a adopting a DevOps culture for cloud migration success. Is there such a thing as cloud migration success?

We'll talk about that July 24th. Let's stick to APIs today. Um, for now though, let me introduce to you our, our panel.

Um, first I wanna, well, he's a, a repeat meaning he's been here before with us. I wanna introduce you to Chris Climo. I hope I pronounced that right, Chris, Chris, tell, tell our audience a little bit about yourself, if you don't mind.

Thanks, Ellen. Yeah, so I'm Chris Kmo. Um, for the last 12 years I've been working specifically in the API testing and service virtualization space.

Um, joined the Tricentis team recently, kind of tasked with the responsibility of uplifting and modernizing some of the service virtualization, uh, tooling. Um, and as a natural part of that, there's, uh, some API testing, uh, pieces of it. But I've been kind of enjoying that and having fun, imagining what this tooling could look like if we started from fresh.

So happy to be here. Uh, happy to have you on Chris. Thanks, and welcome back.

Next up the kind of queen of the ball here. She, you know what, I, I just feel like she should move to Florida already. Um, our good friend Tracy Reagan, who's also a CEO of Deploy hub and many other things, ccra.

Tracy, why don't you introduce yourself? Well, Alan, thank you for having me here. I always enjoy this.

It's, I feel like I should have a PhD though on some of the topics that you bring me in on. Oh, what we do just about, uh, sometimes, Sometimes I have a kind of blow, I blow myself away. I understanding more than I realize, I guess.

I've been in this business for quite some time, to be quite honest. Um, I started at, as a programmer on Wall Street, started a company called Open Makes software that automated builds. And now I am the, um, CEO of Deploy hub, and we're doing an evidence store around security and DevOps data.

I've been involved in the Eclipse Foundation, the open SSF, um, and the, the Continuous Delivery Foundation, and have embraced open source for quite some time and have some opinions on API first. And so I'm happy to talk about it. Doesn't surprise me.

You have some opinions, Tracy. Thanks and, and welcome. Our third panel member is Chris Lindsay, and this is Chris's first time.

I haven't yet told him of what first time guests have to do when they first come on here, but we'll, we'll tell 'em in a little bit. Hey, Chris, welcome. Introduce yourself to the audience, Alan.

Thank you for having me. My name is Chris Lindsay. I am an application security evangelist over at Mend.

My job is just to talk about application security in general. My history, I wrote software for 35 years, so been there and done it in the trenches and APIs are near and dear to me, and I've been in security for over 15 and plus. So thank you.

Good, and welcome. Always nice working with the folks at Vent. Um, our last panel, well, he's not really a panel member, but our last person I'm gonna introduce is my co-host for DevOps Unbound.

He's our CPO here at techron. He's also a CTA for Futurum Group, which is a company we are in the process of combining with. Mitchell can explain what the CPA role is, but let me introduce you to Mitchell.

Ashley Mitchell, take it. Good to be here, Alan, and what a, what a group. Um, what a fantastic group.

Yeah, I'll, I'll be your panelists. I'll be your co-host. I'll be the the chat guy.

I'll be the bottled watch. Whatever you need me to be, Alan, I'll be, so no. Just recently, as part of our, um, acquisition process with Futurum, my role's expanded in addition to the doing the analyst work that I was doing with Textron Research.

It's, uh, I have a new, you know, we had to create a new, new title, right? But I'm one of, uh, five people that are Chief Technology Advisors, which is kind of a, a glorified analyst on steroids doing advisory work and analyst work and, and things like that. So it's, it's a lot of fun that, that, uh, being part of the acquisition and, you know, still, but still working with all my old friends as well as new friends.

So it's good to be here with everybody. And yes, I started as a developer and yes, I've designed some really bad I APIs and a few good ones. So we have some lessons that, that I can bring Learned more on the, on the bad ones.

But anyway, um, thanks Mitch. And welcome. So, as I mentioned, API traffic today represents a clear majority, if not a critical mass of traffic on the internet.

And I'm gonna ask someone to explain what that means to the lay folks out there who may not, we don't have that many lay folks, but people who may not understand I'm not, it's, it's either API generated or API to API kind of thing, or, or, you know, somewhere along the line there's an API involvement there in that traffic. Um, but, you know, the effect that an API first mentality has had on the development process in general on testing and security in particular is, has been pretty profound, right? I remember the first time, like this whole thing became clear to me.

I had that eureka sort of moment. I was at a CA world, so I should give you an idea of how long ago this was. Um, and, and, uh, they had done an acquisition, a company based in Texas, and the folks from that got up and said, you know, it's an API driven economy.

And I was like, wow, an API driven economy. What, what the heck did that mean? And I, you know, I I, I learned more and I, I dove in with it and I realized it was an API, you know, we were moving into an A API driven economy when we talk about, you know, digital transformations and, and stuff like that.

And, you know, I think the next logical extension to that was API first, right? That's the default. And, and of following from that, of course, you, you, if you're gonna have that kind of API footprint, you damn well better be doing API testing, right?

To make sure this stuff works and make sure, and then in the last four, five years, API security has become paramount in many ways, right? API security is replacing web application firewalls and stuff like that because WAFs, that API traffic kind of flows under the radar of the wa, right? And so we need something else to kind of make sure our APIs are secure and locked down enough to make your head spin.

Um, Chris C, if it's okay, right, we'll say Chris C and Chris l Chris C why don't you take a crack at explaining in your mind what API first means when we, when we use it in this context. Absolutely. And, you know, um, to get there, I think I wanna talk, I wanna touch a little bit on that API economy, because that's really like, first and foremost for me, what's driving the API first initiative and just, uh, unironically About an hour ago, I was just talking with ESRI.

Um, they're the guys that do a lot of the map, the MAP APIs. Um, they were kind of behind MapQuest back in the day, and I was talking to the guy and he was saying that before that, way before that they were the ones that powered the Thomas guides. You remember those things that were under your sheet?

Sure. You were In your car, right? Mm-hmm.

We were a logistics company, right? We, we, we, we had a database full of rich maps that we would then compile into a book. And we were a logistics company.

Let's ship them. And then eventually, at some point, that just went away. And now they are an API first company.

They sell their API to Google Maps and to Apple Maps. And so their entire economy is based around their map, API. And so, uh, to me, that's what the API economy really means is, is businesses are building their brands.

And a lot of what's powering that is the API. And if that is the critical path to your business, you really have to have an API first mentality when it comes to building them, securing them, testing them, validating them, and really, most importantly, securing them. And so that's, to me, what API first kind of means Panel thought on that.

If I can jump, I'm gonna jump in on that too. I love how you set it up, Christie. Um, 'cause you think about it, historically, APIs were the things you might add for the exterior of your application or your software to kind of the ingress and egress.

But everything inside of it was your app, right? And, and A-P-I-A-P-I first is just the opposite. Your app is all run through APIs.

Even if you don't have a gui, your ui use your interface. Um, and matter of fact, if you do have a u ui, the UI talks APIs to your app. So the same APIs that you might share with, um, providers or people that are buying your service, matter of fact, your service may be just the APIs like Chris is talking about.

Um, and in doing that, I remember APIs just getting kind of unwieldy and getting outta control just 'cause we added 'em where we needed 'em here. And how long are they gonna be good? And do, do, do we, as they evolved, how do we grandfather old versions of 'em?

And now we have whole philosophies around the lifecycle A of APIs and how you manage them. And they're, they think of, we think of APIs as the product because almost all, every app now is exposing those APIs either in a, in a microservices world, very heavily API or we're also to the external world, to people that are buying our products and services. So I, I hope that does justice to what you were talking about, Christy.

And while you know that, um, there are, I mean, companies do rely on external APIs. I, if I'm thinking about what our architectural looks like, we probably have 20% or 25, maybe 30% of external APIs. But most of what we do is internal APIs and building internal APIs has a, you know, there is some, um, and when I think of API first, I think about what APIs do we need?

Let's think about what that looks like. And I like to refer to, uh, you know, I preach often this concept of domain driven design and understanding what are your domains? What APIs do you need?

What are the, you know, what are the, uh, what are the connection points? What does that need to look like before you ever start writing an application? But for the most part, we, you know, to, to be quite honest, this is not a new, uh, concept.

We tried to do this in, um, c plus plus and common libraries. A lot of companies, uh, when I was working for Discover Card, we did a ton of work around initially defining what that com, those common libraries should be, should look like. And that's really what APIs are.

They're common libraries, what we can reuse. And really taking the time to understand what those high level domains are and what we need to create is super critical in building a, um, a true kind of API burst forward thinking model. And that's because if you don't do that, and if you don't manage them well, and you don't communicate and collaborate well, everybody writes their own APIs that do the same thing.

Mm-hmm. And that's what we don't there. And that's what generally happens.

And we've done, we've made this mistake as developers over and over and over. We constantly make this mistake, you know, everybody has their own login routine. Everybody has their own error routine processing.

Everybody has their own access to get the customer address. Um, so understanding domains and understanding how APIs should be structured within your organization and how you can break it out and allow ownership of certain domains is critical to an API API first, um, architecture. I agree.

I, yes. So, you know, the other thing I want to just tack onto it is, you know, what, what are your APIs doing? What, what's the purpose?

And in the old days, you would just write your software. You would be in a ui, you would be, you know, either, you know, web-based, where everything's all self-contained, and then you started pulling apart doing the APIs to now when you're developing software, you're thinking about it, there's multiple facets You have to think about, are you gonna expose any aspect of it for reporting or part, uh, you know, business to business or, uh, you know, are you gonna be consumed by other tools internally, um, for, for any reason? Or, you know, what's the UI gonna be?

The UI In today's world, when you're, when you're thinking of an application, if you're thinking of just web, you're, you're being very shortsighted. Do you wanna go web-based? Do you want to go mobile based or, you know, other technologies out there?

And as, as Chris said, you know, talking about, you know, you may have an application that is nothing pure, but pure a, a, you know, APIs. And that's okay because it, again, it's, you know, just, it's all about the usage and what you're actually trying to accomplish. Agreed.

You know, when when I hear API first, to me, the sort of a chicken in the egg question there, right? What comes before the API or is the API the first, the chicken and no, it's not the chicken. I think first before you, you don't start with the API first.

You start with sort of plan of, Hey, I, I want an application that does this, that, or this and this, right? And then we think about, okay, how am I gonna go about doing that, right? So I, I think the, the planning and, you know, laying out storyboarding, if you will, or, uh, designing of the app is, is first.

But certainly once we get into that design, we start thinking about APIs and potential APIs, I think before we start coding, certainly. Would you agree that, that that is the essence of API first, right? Before we even start coding, we're thinking about how APIs are going to make or break, or how they're gonna work within the app that we're designing.

Yeah. Because that, that's how APIs are gonna pay for themselves. You know, me as a young developer, I would've loved to had, you know, been a, you know, we talk about feature teams now, you know, instead of application teams, you have feature teams.

Well, me as a feature team working on a particular, what would be delivered as an application, I get to go talk to other teams that are doing features, which means I don't have to write all those queries. I can figure out what they already have, if it's a well organized API structure, and everybody can share those APIs. So that pace is for itself.

It's, you know, APIs can save a whole lot of cash when it comes to development because you're reusing objects. So a hundred percent. And it's has to do with money too.

Yeah. Yeah. It, it does do that.

If I could talk that what's just, just because the plan triggers me, right? Is it immediately makes me go to the service definition, which I'm sure a lot of the season guys here are gonna roll their eyes, right? Mm-hmm.

The service definition is not a plan, but a lot of organizations say, this is the beginning of the process, right? Let's, let's write our service definition. Let's write our contracts, let's start putting in place the actual semantics of what this API is going to do.

And what's interesting, if I kind of double click on what Tracy was saying about the domain, and specifically what Mitch was saying about sprawl, this creates a problem because you're not doing that upfront ideation work to say, what is the minimum set of APIs that we need in order to provide the value that will ultimately provide the money to our organization? And this leads to something which I'm seeing a ton right now, which is API and new API is the answer to everything, right? Okay, we got this new functionality, let's just add another API, let's add another API.

And before you know it, you have this massive API sprawl. And so I really do think coming back to the domain of, and the why and the, and, and, and the, the minimum set is super critical to this, to the planning phase before the service definition is even put in place. So you're saying we can replace the phrase, there's an app for that.

That too. There's an API for that. There's an a P for that.

Yeah. Yeah. Well, you know, and, and Chris, the thing that comes to mind when you were talking about that is solid programming principles, right?

So, you know, when you create a class, you create a method. The goal is, I've created it, I can add to it, but I cannot change it. And when you look at APIs, you know, you may run into, I need a little bit more or a little bit changed or a little bit something.

2, you know, and so on and so forth. And then all of a sudden, you know, to to everybody's comment here, all of a sudden you may have started off with, you know, 150, 200 API endpoints, and now you're well over a thousand. Yeah, Absolutely.

So I mean, it really, APIs, even though they save a lot, um, like microservices, it's complex 'cause you're decoupling pieces. And when you decouple pieces, you cra you know, it's your, your puzzle now is in, you don't have, you don't have the top of the box to tell you what that puzzle's supposed to be. And you have all these components, all these tiny puddles of pieces laying on the, you know, on the table.

And you gotta figure out what it is that you're creating. So that's, you don't have This, the blast gradus gets really large Tracy, Right? Yes, it Does.

Okay, Last, yes, Here we go. Um, But that's an interesting, that's an interesting aspect too, right? And it becomes that yes, I have this giant inventory of APIs and I may want to Chris's point, sort of just add incremental functionality to it and, and change its version number.

But in a lot of cases, the APIs are used by disparate teams. And so they might not know, uh, the, the major difference between the UI and the, and the API is the UIs are designed to explicitly tell you what it's doing. You go to the screen, you get it, okay, I'm logging in, I'm creating an account.

APIs will do the same thing, but they're not explicit. And unless you love reading swagger definitions, you can't immediately know what an API is doing. And so that's where that, I think a part of that sprawl comes through is people go, Hey, I don't think this functionality exists.

Like, well, actually yes it is. It's a subset of this other API that, and, and so I think this is one of the challenges that I think the contracts and service definitions, and definitely to trace, uh, to Tracy's point, the, the conversationing around what exactly are these APIs for becomes paramount to an organization's API success, Right? Well, and as an API matures, then what happens too, just like you were saying, you may have certain aspects of multiple pieces of APIs, Hey, to accomplish this task, I have to hit seven different APIs to get all the data.

And one API may take forever to run, and I just need one aspect of its data. However, a lot of it is actually tied to the same background or, you know, the back backend. And so instead, maybe I just create a new endpoint to pull what I need.

And the next thing you know, again, sprawl And it's a collaboration that will prevent the sprawl. Yes. You have to have the collaboration.

You have to be, if you don't know an API exists, and you, and there's no way to find out. You're gonna write it yourself. 'cause you might go, this is gonna take me, oh, it'll take, it'll take me 30 minutes to write it.

Even though that's not true. We do that as opposed to go hunt down somebody who's already written one. So the collaboration is essential just, um, across teams, much less really building out a collaborative API structure.

Couple things there. First of all, I think that was job one. Um, in the API security arms race, when API security started becoming a thing.

I think the first thing these API security solutions were doing was say you, it's 10 o'clock. Do you know what APIs you have? Right?

Because, you know, the API sprawl gave us so many APIs, APIs, talking APIs, talking APIs that most organizations really did not have a handle on what APIs were interacting in, in and within their system or on their system. And let alone what their settings were, their security posture, et cetera. You can't defend what you don't even know is there.

Mm-hmm. And that, that was, you know, that was phase one of API security. I think it's expanded beyond that.

It's matured. But that was certainly the first, the first, you know, kind of thing about it. Um, the first part of, of, of API security, I wanna turn, you know, beyond the blast radius of API security of API first And talk about API testing, right?

Because, you know, that's the logical next step. Okay? So now we are going with an API first mentality.

We're gonna have a APIs, they're, you know, in, in the right from the, from the design phase, we, we are designing APIs in. But of course, these APIs need to be tested, don't they? Um, you hope.

And so you have to get into API testing, but yet I, when I hear the phrase API testing, I still think of, oh, I'm using APIs to do my testing, right? I, it, it, it sort of adds a layer of automation to my testing. But no, that's not really what I think we're talking about.

Yeah. I think Chris most, Oh, I'm sorry. No, no, you go Chase.

I was, I was just gonna say, I think when we talk about API testing from a developer's perspective, I think about functional testing and validation testing. I don't worry about performance testing or security testing or load balancing or any of those other pieces. I assume automate that developer.

That's What we do, right? I wanna validate my endpoints. I'm gonna do my functional testing if that's good.

I'm going That security testing. Yeah. Um, Chris, Chris LI I'm hoping you have a different attitude towards it.

I Do. I'm sorry, Tracy. It's okay.

My attitude is, you know, it's, it's a view into your system. And as such, you need to do multiple things. You know, I, I go to conferences, I see applications.

I talk to people I, I with, with penetration testing software. I enjoy going out and attacking and breaking things. I love seeing, you know, what kind of data I can get back.

You know, some systems, you know, you can easily break simply because improper security, improper logging, and proper a lot of things. And so when, when you're looking at APIs from, you know, a, a a standpoint, there's multiple aspects that you have to consider. You know, the, you know, how does it perform?

Because I can come in and do a denial of service attack. If you have a poor performing, performing a PII can call it multiple times from thousands of endpoints simultaneously, if you have an API endpoint that shares data that it shouldn't be sharing, now I can steal data. If you have an API endpoint that is just not well put together, it it, it's very obvious from a security standpoint.

And so, whenever I was actually doing my, my development days and doing senior tech reviews, I would look at, you know, how do they perform? I would look at using tools to look at the payload as it goes in, as it comes out, what kind of things, time to run the time on the backend, on the, on the database, all the way down to that level, just to ensure that, you know, is this performing? Is it doing what it has?

And, and beyond that, you know, you also have the security things that you can throw in there, such as SQL injection and, and other various things that can, that can happen. I'll stop. I can keep going, but, No, I get it.

Chris c you're the real tester here. What do you think? Okay, first off, I'm in the vendor space, right?

And so nobody knows less about testing than the actual testing vendors. But I will say this, um, I, I am encouraged that we're talking about development forward API testing. Because quite often in the testing industry, that's put firmly on qa.

And there's these really interesting conversations. Whenever we go to a, a first time API tester where they go, well, whose responsibility is it? Is it, is it the developer?

Is it the tester? Now we all know it's both, but it's at a spectrum. And the notion is that, hey, I'm a developer.

I created a service definition. I should be able to hand that to the, to the tester. They should be able to ingest that and use it.

And the tester says, Hey, you're a developer. You're building the API, you should test it before you give it to me. And there's this constant back and forth.

And I think to both Tracy and Chris's points, there's different levels of testing that you do as it's maturing through the cycle. And the, and the first one to me is contract testing, right? I wanna make sure that my service that I'm building is not only complying to my business expectations that I've set forth, uh, for the, for the function of this API, but also that the consumers of IT are not going to be affected if I change it.

Right? And so, I don't know if anybody's really, um, uh, grasped onto, um, uh, uh, uh, contract testing quite like some companies like PACT have, but it's this, it's this really strong grassroots movement that's happening right now 'cause it's developer forward that basically says, I'm only gonna write into this test from a development coded perspective that are my expectations of an API. That way I can continue to do what I'm doing and know that if the producer of the API makes a change, they're gonna run my contract and know that they've broken me, which fosters collaboration and communication.

Those contracts are the seed for everything. Because you can mature those into greater and greater levels of more complicated functional and integration testing. And then once you have all of those contracts, you have all the attack vectors that you need for your security testing.

So I really think that this whole testing thing starts from the moment that first line of code is written against a contract, write the contract. But again, it's all predicated on whether the service definition exists. Isn't, isn't also, 'cause I remember us using kind of contract with APIs in a little more general way before this, this movement you're talking about.

And really a contract in that sense was here's how you use the API, here's the, here's the expected behavior in terms of how you interface with it, and here's the expected behaviors of what it's going to do when you use it in the specified ways. And I think to your point is if you go wacky and do some SQL ingestion, or you do something else and pass different parameters that aren't part of the API, it's not gonna respond or it's gonna give you an error or some, some definition that's out, out of bounds of the contract, is that still consistent with the movement? You're talking the developer forward?

I, yes. The contract is, um, again, it's an overloaded term as are many things in our industry, but it, to me, the contract of the API is the service definition that defines semantically and logically what this API is supposed to do. And you can use that both as a human document to read, to understand, but probably more handing it to the business to to, to the, uh, to the appliance so that it can ingest it and create clients to actually communicate with the API.

Um, that same, that contract needs to be tested. Is it semantically valid? Does it, does it follow all of this?

The the spec definitions that we have for service definitions, has it changed recently, et cetera, et cetera. Um, and then that, that component is then used to test the function of the API in its entirety. This is a, this is a, a, a second piece to that, which is I'm using the API in a very specific way, and I have complied to the service definition.

I'm doing everything right. I wanna know if anything has changed, um, or if what I'm trying to do and what's critical to my business. I'm Bank of America, I'm communicating with a PayPal, API, I'm only using like three fields of it.

Don't change those three fields and do whatever you want with it, as long as you don't change those three fields. And if you do change those three fields, you gotta talk to me and say, I'm changing the three fields. What can we do about it?

What can we do about it? That's the, that's the difference between those two types of testing. And, and there's something that happens when APIs aren't really tested well.

Um, there is a trust factor that we have to always keep in mind if you're an API developer, uh, to make sure that you're doing that testing and that you're maintaining those contracts. Because what happens is, in that example that Chris just gave, that consumer may decide not to take on that new version of an API and that causes a DevOps nightmare called Drift, which means you have multiple versions of your API that are out in the world or being consumed internally by many different application teams that you have to support, maintain, and make sure are secure. So the API testing, if it is so critical in building that trust so you don't end up with so much drift, you know, we talked about sprawl, sprawls a problem, but drift is as big a problem, if not bigger, when it comes to trying to secure the, the, the environment, Right?

And then one of the things that I've seen is a lot of QA departments use automated, uh, regression tools, and their thought is, Hey, my, my tool passed it regression tested. That must mean the APIs are good. Let's move on and let's, let's, let's, you know, consider it good.

And to both Chris and, and Tracy, you know, their point is, look, the contracts possibly could change internally, something could get added, modified a a definition may change. 0 and now you're version 30 and you can't get off of it. And by default, most people who are writing APIs are not logging or doing any metrics.

And when you're not doing any metrics, you're not knowing what API endpoints are being used, how they're being used. You don't know the details. And so the problem becomes, you know, you're sitting there, you're creating drift sprawl, and, and you don't know that, hey, guess what?

Version one is still being used, but versions two through 15 aren't and haven't been for a given time. And so those could be deprecated. So instead at c at a certain point, depending on design and what's going on, you may have to go make 30, 40, 50 changes, you know, spread that same change out across all the API endpoints where if you were paying attention and, and doing good development practices and, and, and analytics would tell you, Hey, you know, you have people that aren't moving off version one, why?

Ask the why, what's going on there? And then determine, you know, can, can they move up? Or is it just a, a breaking code change for them?

And if it is, you know, how do you deal with that and, and how do you work with that? Because at a certain point you need to move forward. So, but this, this is, this is a bigger problem.

You're touching on Chris, right? This, this is the, the sprawl aspect of it. We see it cloud sprawl, API sprawl, you know, are all developers and IT people hoarders at their core, maybe because none of us seem to wanna delete anything.

Me, I, I find a certain joy in like cleaning out my closet and throwing out things that, you know, I have a rule in the house. If it hasn't been used in the last year and a half, we're probably not going to use it. There's better things to do with that space.

Do we need, and that's, by the way, that's something we could automate with APIs. And if that forces people to move off of version one to version five because they've been sleeping through the last four upgrades, or refuse to do it, so be it. Right?

Apple people used to knock Apple for that because they did, they stopped with the backwards compatibility for five years old software. If you didn't have the last version or two back with you, you couldn't run the latest stop. Mm-hmm.

You know, Microsoft stuck to that backwards compatibility thing for too long, in my opinion. Should we, is good API hygiene, meaning adopt something like that? Wow.

That's a, a cultural shift. Because I do think that, uh, developers tend to be a bit order as you explain. I mean, think about even, um, building a cont a container for an API, you're probably gonna bring in stuff that you don't even need because you don't, you're not sure if there's a dependency on it.

Um, which is part of the, our current security problems, um, is these transit or dependencies and what APIs calls what API, uh, becomes more of an issue. So it would be hard to get folks to start really cleaning house. I Like, and you think about SBUs, you, you mentioned SBUs.

SBUs. I was not gonna say SBUs, but, Well, no, we're not Thinking SBUs. Okay.

But I do think that AI could help solve our blast radius. Okay. Blast radius.

It is. So we're talking about blast radius. We could use AI to do that.

We could use AI to limit the blast radius, but shouldn't we use AI to just limit API sprawl And drift? Yes. And drift.

I mean, it's good security, I think. Well, and AI is doing so many amazing things today. You know, from a standpoint, when you're looking at using AI against your APIs, you know, it now creates a lot of, you know, background.

It, it gives you a lot of visibility in the things that you didn't have before. It makes it so much easier to, you know, to connect, to get that information, to know what's happening behind the scenes, and to be able to detect anomalies. You know, you may be up and running and, and AI can go, Hey, guess what?

I'm noticing something interesting. Or, you know, if you are doing logging or whatever, AI can also pick, you know, pinpoint and go, Hey, wait a second. Something's happening.

Tracy, you know, she, she lives here. And somewhere on the other side of the globe, Tracy logged in again. Problem.

You know, I wanna, I wanna bring up ballon. Is there, there's also kind of some, we're talking about some challenges with managing this whole ecosystem, right? Of APIs.

One of the things that I think is really great about APIs, Tracy, you were talking about c plus plus remembering back in the day of, of stubbing, uh, stubbing off methods. You know, we would like, here's the structure and I don't have time to write that yet, so I'll just put a return in there and pass some data back. And, and, and now we have such a better way of not just stubbing, but actually creating the API creating some logic behind it.

We could have, you know, some tests actually built into that code that isn't fully been written there yet. Um, but maybe it's generating responses, right? That we wanna to, uh, be able to test with as part of that API as well as we add the, the function, the service of what it is.

And so you can, I think you can build software faster through this API first approach. Um, 'cause you're not managing a big structure, you know, a big object structure with parts stubbed out and some parts not. And who's got what part of that tree?

And I'm using this version of this microservice, this, this API, and it's, it is, it's just stubbed there. It's great for building and testing, and I'm gonna replace it with the, with, uh, Chris's, whichever Chris wrote it, Chris, CRL. And, uh, you know, I can continue to just evolve the app that way.

Agree. Don't agree. Am I, I agree.

Fun doing funny stuff in Colorado, or I gotta, I gotta jump in here. Like, one of the things I said at the beginning with my introduction was that I, I, I am over two products, right? API testing and service virtualization.

I don't get to say this very often, but service virtualization doesn't get the love that it needs, um, in our space. And I think that from an API first perspective, it is massively important for jump starting, you know, any API initiative. And to kind of wrap this into the sprawl and the drift thing, observability can be a huge benefit here, right?

Because what, what we're finding when we're going to a lot of our companies is they're like, we wanna do this. We wanna go API first. We wanna test what we existing what we currently have, we wanna understand what people are using, but we have no idea what APIs we have anymore, right?

Because everybody's kind of cycled out, et cetera. And, um, observability allows you to not only observe the system under motion to understand the actual APIs that are there. 'cause guess what?

A lot of those internal ones that, that Tracy was mentioning earlier, they're not documented. There's no service definition for them. And the observability is the only way you're gonna pick up on those.

And that same traffic can be used to generate those initial service tests, those initial vir virtual services, which is so much more valuable. 'cause it's not just a dumb stub. It's one that actually simulates the business logic and the, and, and, and, and the expectations of the system under motion.

And then you use, and you kind of build your new API scaffolding around that. And it's a great way to get started is leverage your existing observability for service test and service virtualization creation. I love that term.

Your service under motion. It's a great visual IT service in motion. Under motion.

So it's in motion. Yes. No, no.

It's under motion. It's great. Just running Something, an Eighties song.

Anyway. It makes sense, right? Yeah, it does.

It's, it does. There's another part to this too, and that is the API security. API sec, uh, part of security is one of the first things is the API discovery.

So if things are going through a proxy or something that's, you know, flow flowing through, um, whether you call a firewall a proxy, whatever it might be, that's another collection point, if you will. Like you're talking about Chrissy, where okay, what is that? You know, there's 25 things that happened today.

Nobody knows what that thing is, or didn't know somebody else was using that way. We didn't know that was going externally. So that's another kind of data point you can pull into figuring out what's Happening.

Well, AI had mentioned that earlier. You can't defend what you don't know. You most people don't know what APIs have.

Well, and, and from the ads bomb, I'm saying. But the SBO piece of it, you don't know what dependencies that API is calling into play here. Chris, Chris l you've got something to say.

Go ahead. Yes. Yes.

So, you know, when, when you're looking at the APIs and, and the data coming in, it's just like a ui. You have no idea what kind of crap people are gonna throw at it, what length of information people are gonna throw at it. What kind of information is, is inbound outbound?

Because, you know, crafting a good attack, you know, you, you can do things and, and, and skirt under the radar depending on design. And, and I love the, you know, what, what Mitch was saying, you know, the very first thing, if I'm gonna come attack you guys and look at what's going on, you know, I'm gonna figure out what API endpoints you have, I'm gonna figure out what's going on there, and then I'm gonna start, you know, overloading 'em, seeing what I can come up with. And it's, it's amazing how many people overlook the role-based access.

You know, if you get a JWT token, you get in the door, guess what? Now I can do a lot of things that I shouldn't be able to. Fair enough.

Guys, we, we try to keep these sessions to 40, 45 minutes, and I think we're up against the clock here. Um, first of all, great conversation, great conversation. I, I think look for our audience at home.

Takeaways. Three, three things. I always like lean these kinds of things are three key takeaways.

Number one, we absolutely do live in an API economy, right? APIs are driving the internet, it seems, if we look at traffic loads, number two, an API first mindset in, in how we plan and, and develop our applications is, I think the norm, not the exception to that, right? Do we all agree with that?

And the third thing is, if all of these APIs are out there, you're not doing API testing. And that includes API security testing. You know, the, the, the, the, what's it, what comes home to roost?

Mitchell Chickens can loan drew the chickens, come home to roost. I knew it was some foul. That's the Nebraska boy.

That's the Nebraska boy right there. And of course, it expands, expands your blast radius. But, um, Hold On.

I realize we gave nobody any context at the beginning as to why we are doing that, and I love it. No, we have a very, very sharp audience they picked up right away on it, but it's not the first time they've played this drink game. Um, anyway, Chris and Chris, thank you so much for being our guest today on, uh, DevOps Unbound.

Tracy is, as always, it's a pleasure to have you on here. Love having you part of, you know, not just DevOps Unbound, but you're on the, you're one of the gang members, some tech strong gang, and, and of course, uh, tech strong women and everything else you guys do. So thank you.

Thank you, Mitch. As always, you take the last word. Um, I just party thought is, there's an API for that said, very fair enough.

No doubt. Hey, many thanks to T Tricentis, as I said in the beginning of the show for sponsoring this. They're a great company to work with.

com. Until next time, this is Alan Shimmel for Techstrong. Quick reminder.

July 24th is our next live round table. Go miss it. But until then or until our next show here, we're out.

Thank you. Bye-bye. Hey everyone, it's another AI Friday.

You're watching Textron Gang. Hi everyone. Alan Shimmel here on Textron Gang.

Welcome to our Friday edition. We've got our usual kind of Friday crowd here. They become the regulars on Friday.

I feel like I'm Sam and cheers. Or maybe I'm coach and cheer. Cheers.

Uh, Mike could be Sam. He, he, he was a pitcher. Um, but let me introduce you to our gang members.

Our West Coast inte on Friday is our marketing person extraordinaire, expert radio host, and a bunch of other good stuff. Our friend Lisa Martin. Hey Lisa.

You're looking very, very nice in that top there. Well, thank you. I'm very bright today.

It's good. Pink white is always a nice color. Uh, moving on from Lisa.

He's not in pink and white. Looks like he's, oh, he is. Got a little red.

I thought you were in your Warriors, your dubs warmup suit or something out there? Uh, John Schwartz. Hey, John, how are you?

Hey, I'm good. I'm good. It's, uh, being kept busy by the Salesforce conference this week, but, uh, everything's good.

Good. Very cool. Good for you.

Okay, then moving from the West coast to Austin. Same guy, different title. That's right.

Mm-hmm. And now chief analyst at Visible Impact, Guy Courier, chief Analyst at Visible Impact. Hey guy, welcome Visible Impact, part of the Futureum Group.

Thanks. I'm actually in New York City. Are you at Moment?

Oh, I'm you. Lucky dog. You good for you.

Thank you. You're not with ard, with Mike, are you? You, uh, I don't know.

Mike, which office are you in? I'm in, I'm in the Harrison, New York office on the other side of the bridge from you. And we were just discussing our future locations.

Well, that's cool. Very cool. I'm in Midtown Manhattan right now.

Good for you. Enjoy. Welcome guy.

And then of course from Harrison. He is the dean of, of, uh, Jack Strong, our Chief Content Officer, Mike Ard. Mike, did you always wanna be a dean?

Dean? I don't know, because, you know, that's a lot of responsibility for taking care of students and students and notoriously problematic. So yeah, I think I'll skip the dean All like, I was thinking more like Dean Wormer, you know, have a, I a husband Dean Wormer, But, but I am in the same room I was in yesterday and I haven't moved since.

So there you go. There you Are. All right, guys.

Hey, it's Friday. We, we got a lot of AI in store for us here. Uh, Mike, why don't you kick us off.

We're gonna take a minute here on this, a block to, um, a assess where we are with ai. There's a story over on digital CXO talking about how, um, AI has permeated everybody's thought process, even though it seems like not that many folks are actually doing it just yet. And a lot of those things they are doing are experiments.

And John has a story also up on, uh, tech Strong AI talking about how just about every job in the world now seems to have an AI component to it, if you wanna apply for it. So let's start with Guy, but what's your assessment or what's going on here? Where are we on this journey?

Well, the story at digital, uh, digital CXO, could I get that right? Um, is, uh, um, based on, um, a recent study by the St. Louis Fed of 10,000 US workers.

Um, and it's interesting to me for you to say, Mike, that, um, not a lot of people are using it because I guess the headline number was like 23% percent, uh, of, uh, US workers, uh, use ai, uh, on a weekly basis. Um, 9% use it on a daily basis. Those numbers don't sound like a lot, but I'm here to tell you those numbers are astoundingly high.

23% of all US workers, I, I think they had an age cutoff of like between 23 and 65 or something like that. But every kind of job imaginable from farm worker up to corporate CEO, 23% of them are using AI at least weekly. That is astounding adoption.

If you ask me if you wanna cut it down just to knowledge workers, I didn't have a chance to look at that. Maybe it's a higher number, 50% or more. But this is every US worker.

And, uh, equally interesting is that over half of the usage of AI is employee driven according to this study. I mean, this is a serious, uh, projectable, um, uh, you know, sort of unassailable piece of market research by one of the premier research institutions in the United States. The, the us, the, uh, St.

Louis, uh, federal Bank. Um, and they're, they're showing the, the latest version or edition of BYO, whatever we had, BYOD. Um, we sort of kind of had BYO cloud, although it wasn't our name that way.

This is now BYO ai. Yeah, I just coined it. BBYO ai, um, over half of its use is employee driven.

That's all. And, you know, everyone in sundry, um, going and using chat CBT to for whatever, for research to draft an email or what have you. I mean, this, this is in a space of two years now.

Um, there's one other element to this story having to do, do with productivity, but actually I wanted to hear from John also because he has taken this sort of, you know, work style lifestyle approach in some recent articles. He's written about it. And I wanna see what his take is on my sort of astonishment at, at How I, I think you, I think you're spot on guy.

And in fact, I think that number 23% not only is, is pretty significant. I think it's gonna get higher very soon. So as part of the story that I did, um, there was a, a study done by the University of Maryland's, uh, Smith School of Business in a, a company called linkup, which is a data job fracking firm.

And they have found that since the end of 2022, the AI job listings in the US are up 68%. When you compare that to the overall job listings or postings, those have declined 17%. So in a sense, that's where the jobs are.

And in fact, there was yet another study that was done, uh, looking at a thousand jo recent job seekers by something called AI Resume Builder. And they discovered that nearly half of the applicants now use chat GPT to craft their resume and cover letters. And that the people who did do that 82% were able to get some form of an interview.

Um, they, they, o one cautionary thing is you, you couldn't over rely on using chat GPT. You had to add a human element of some sort, otherwise, it was very obvious that you hadn't written it. But I, I think just given the whole context of what's going on, it's very interesting to me.

So we have this AI job growth that's occurring at the same time that a lot of tech companies are slashing their workforces, and yet they're making major investments in ai. It's just, it, there's this kind of whole kind of interesting dynamic that I find that as companies are cutting back, they're also looking to hire more people to fill the gap in the AI or some sort of knowledge, which in a sense, ironically, will probably displace even more jobs. So there's this kind of whole job churning cycle that's going on.

But AI is definitely leading the pack. And, um, I think, I think we're really gonna see significant change. And this, this will probably bleed into our next segment about what's going on with the Gen ai, but I think it really is starting to take off.

I was a little bit dubious about it, but now I'm starting to think there really is momentum go coming from this area. I'm gonna say nonsense. So here's the thing, um, employees are driving it, no doubt, 23%, no doubt.

And I'm willing to wage you that 95% of that 23% is using it to write a better memo. Well, let me wait to see how the GDP is gonna really take off because people are writing a better memo. I don't disagree that AI is gonna have a profound impact, but we are a long, long way from actually people using that in a meaningful way that's gonna drive a, a return on investment.

And you're already hearing CXOs standing around going, where is the ROI on this stuff? Well, I have to mention that the, uh, the St. Louis Fed did their homework using data from the study and, um, pretty sophisticated analysis, uh, to, uh, come up with a figure for how many work hours are being saved each week, or not each week, sorry, it's independent of the time period.

4% of work hours are being saved. 4% of a 40 hour work week is, uh, what it's, uh, 25 minutes or something like that. So that doesn't really sound like a lot, but those are 25 minutes that are being, let's take them at face value, which I do have a fair amount of, you know, doubt about that number much as I have confidence in the St.

Louis Fed. But let's just take that at face value. And those 25 minutes are now being spent to do something else.

1% or something like that. When you do the math, that is a big boost in productivity. It doesn't sound like a lot, but you, you, you get that productivity boost, Mike.

And, um, I, I think the main doubt is that the methodology is really sounding enough, especially when you're interviewing these folks and they're saying, oh, I say four hours a week, and you're just kinda like, Hey, you know, uh, maybe not there. The, the, you know, I, I have been one of the ones saying over and over again that AI isn't really a productivity booster, at least not yet. It is a quality booster liability booster.

But this is the sort of thing that people can look at now and start doing measurement with. That'll be a great comfort to me on the 10 hours a week I'm now spending, going back into the office and commuting each way that I I, it makes a huge difference right here, man. I got you.

So, Sounds they wore your cenex hat, again, sounds to me like the, I mean, we're, we're basically though in a transition in transitionary period, it's starting to ramp up. I think it's not gonna happen overnight, obviously, but I think it's, we're definitely trending in this direction, you know, and I've, I've been skeptical about it, but I, I really do see some sort of progress going on. It's just not gonna happen as quickly as we think.

So it sounds to me like the dean's putting him on double secret probation And, and should do. One of the claims is, is so, you know, I, I didn't want to, I I am not going to trash this study or what the St. Louis Fed did.

I'm gonna read it. I think it's gonna be very useful. But one of the claims in, in, in, again, in the article, and I'm not sure if it came outta the report or, or somewhere else, um, or an interpretation, but it's that, uh, CIOs who successfully formalize AI integration could, and that word coulds, doing a lot of business, could unlock $200 billion or more in annual productivity gains.

And that's not walking around money. That's, that's a fair Amount. A billion here, a billion there before you know what you're talking real money.

But Yeah. And I look at that number and I'm just like, come on. So, Well, that's across the board.

But, but hear, hear me out. To your point, Mike, if people are using it to polish up or speed up writing memos, making a better cover letter, resume, these, what they're doing is they're using AI to try to make their mundane faster, easier, better. And that's a worthy, that's nothing to shirk at.

It's a worthy goal. But the real AI gains are when we use AI to really accelerate beyond the mundane writing a memo or, you know, these tasks. But you know what, what we really expect it to do, which is to do go, go do things right?

Ai, go take care of this, take care of that, write that code this, deploy this, right? When it, it starts becoming a digital workforce, not just, I, I think out of the 23% who use it now, 80% of that 23% view it as look a, a really nice parlor trick, a really nice look at it's magical look how great this thing is. Look, I I, I'm talking about myself even, you know, it amazes me what it comes up with and stuff, but I'm not really leveraging it as a digital workforce.

And I think that's the, the switch that needs to flip. You Know, you, you know, I was get, can I, can I just interject something really quickly? Is that when I used to work, when I used to work at Dow Jones, one of my greatest frustrations was we did this formulary formulaic stories around earnings, which I hated to do, and it took up a great amount.

Oh, Jesus. It took up so much time, and I thought if only if AI came along and did that could free me up to do stuff that I really wanted to do that I thought would add incredible value. So I actually think, and I can actually see how this was, would work in the future.

But anyway, I'm just saying this from selfish purposes. I'll tell you to Alan's point, and I think Satya Nadella has it, right? He said, you know, the only metric that's gonna matter at the end of the day is whether or not these GD Ps start moving up.

And we really are more productive. Otherwise, Alan's point, it's a nifty little parlor trick. And yeah, it reduces my toil maybe, and I am less cranky as a result, but it doesn't really mean squat to the business.

It just means me as an employee, it means I I get to go to lunch a little bit more and not have to rush back. That's where we are. Wait a second.

Can I take a quick poll of our panel today? Is Mike A. Little less cranky than he was before?

I think we're seeing a change in time, Ellen. All right. All right.

All well then look, spring training, that's a worthy goal. Oh, It's a worthy goal. I Keep, I, Go ahead, Lisa.

Oh, thanks guy. I'm a big fan of generative AI for, for sparking creativity. You know, one of the things I talked about last week on the radio was, was this over reliance on gen AI from students and teachers are getting really savvy to, to check them out.

They're putting, like, like a student is, is relying on an ages between 17 and 25. And the reliant versus, um, using it are completely different things to me. And it showed that that students were copying and pasting like, like an essay prompt into like a chat GPT and having it write the entire thing and being reliant on it, completely.

Not even proofreading it for hallucinations or putting that human element in. I think that guy that you mentioned, teachers are getting savvy because they are hiding words like a funny word, like a banana that doesn't make any sense to the actual essay prompt in white text. When you copy and paste the prompt into a chat bot, and that word appears, the teacher knows right away you cheated.

But we're seeing also a lot of knowledge workers reliant on it. I think that the fine line there is reliance dependence versus using it as an inspiration tool. Something that the, the study showed me was that CIOs have to get really, they've gotta balance this tightrope as the article said about preventing hallucinations these, putting these guardrails in place, letting people be creative and more productive.

But I also thought it was interesting that we're seeing, I guess this is not surprising that we're seeing gen AI adoption different across industries, but I was impressed to see that that, you know, 15% of leisure and hospitality folks, knowledge workers are using it, transportation workers. It's not just the information services and the professional services folks. Were seeing that, I think what, what needs to be put in place is those guardrails saying this can be used to, I think, as an inspiration tool versus being overly dependent on it.

That if you're writing it for a resume or a cover letter and you're not putting in any, any of your own sort of touch, I think you're gonna get rejected regardless. That's a terrific way, that's a terrific way to to, to, to describe that quality side that I talk about as an inspiration tool. I love that little comment about banana.

I think we all need an AI safe word. Mine's. Mine's gonna be beer.

Mine's getting strawberry, and my family knows what that means. How can I just point out for again, Where we go in here? Go Ahead.

It's, it's really, it's gonna be really helpful for us, Mike, especially you, and this will cheer you up to think of this, and the article alludes to this, but I've seen nowhere else except coming outta my own dang pie hole, which is to think of this a adoption curve and adoption cycle of AI as the same way as the adoption of the personal PC back starting in the early eighties. It took 16 years before any productivity gains were seen from the use of personal PCs and devices. It's clear that this will be a lot shorter, but, but shorter, what, four years or something.

So, Mike, that's what I have to say to your complaints about there not being productivity plans. I, which is not even what we should be using AI for anyway. So I'm, I'm a big believer in the long term, but the short term is a lot of hype and a lot of, Where, where did we go off the rails here?

Where we're talking about safe words and pie holes? That's what I wanted. Well, that's a strawberry.

All right, let's take a break. We're gonna come back, we'll continue our AI discussion, but now we're gonna talk about AI agents. You're watching Textron Gang, Discover Textron Group, the epicenter of tech innovation.

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

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

All right, folks, we're back. And the gang's gonna be talking about this whole Salesforce, uh, move to creating a marketplace for agents. And it kind of continues from our last conversation.

'cause well, this may be where the real action is. John, you recovering this for us over there on text ai. What's your take?

Well, uh, Salesforce, which, uh, has a conference this week in San Francisco, uh, has made a couple of announcements. Um, the, the highlight to me was the, uh, agent Force two dx, which is basically the next version of their digital labor platform. So one of the things that Salesforce is going after, they, they refer to it as a $6 trillion digital labor market.

So this new version of Agent Force basically would autonomously perform administrative tasks across enterprise systems with minimal human supervision. The reason why this is interesting to me is that this, this system is designed to embed AI agents that monitor data changes, anticipate needs across business processes. And then at acts previously, they, they were triggered, agent force agents were triggered from a chat interfaces and required specific directions from humans to take action.

So this, this was interesting. Salesforce made the announcement, uh, the same week that Microsoft introduced a new sales agent aimed specifically at competing with Salesforce. And, and AWS announced a new group focused on ag agent ai.

Um, Salesforce also announced this open marketplace for AI agents for enterprises called Age Agent Exchange, which lets developers and partners build and monetize AI components. They announced more than 200 initial partners including Google Cloud, Workday Box, DocuSign. So all part of this kind of momentum or movements into autonomously performing tasks through these agents.

Um, so we're seeing, we're seeing momentum. There are more announcements that are about to come. Cisco's make made one on Thursday.

There are some others that are under embargo that I can't really disclose. But in a sense, this kind of builds off what we were talking about in the previous segments. Uh, it will take a while as guy and I will acknowledge, and, and I think Mike, you're right, this is gonna take several years.

But again, Salesforce is, is kind of pushing this idea and they've got some partners lined up and there's some actual real applications that were discussed as part of the announcement. You know, good. Well, let me tell you what I really liked about the agents in the marketplace.

'cause I can envision a world that looks like this. I'm gonna go to this marketplace. I'm gonna describe a task that I would like to have done, and these agents and the people who bill them are gonna bid to fulfill my task.

And so instead of me sitting around going, let me license this agent on a annual contract basis, I may do this on a usage based model, and I'm only gonna pay for the agent for as long as I need to complete that particular task. So Is is this the AI version of driving your pickup truck by Home Depot and picking up illegal immigrants to do work for you? That is exactly what it is.

Wow. I thought the last, the block was, I thought the a block was tough. Ended it tough.

You're really bringing the heat again out. Yeah. No, I'm not, but, but you know what?

I, I do think a workplace or, or, or a marketplace, look, it worked for the cloud, it worked for the phone, for the cell phone. Why wouldn't it work here? Right?

It it makes sense. It's, it's a tried and true model. That being said, you know, I, I mentioned it yesterday on yesterday's gang.

ai. And, um, and I was talking to one of the co-founders. These are the people from cello.

And, um, well then I, they were, they helped start Trello. They're not at Trello anymore. Um, and I asked them about, you know, it's great to make these tasks for me, but I'd like to have an agent that does, does these things.

Are you gonna have an agent? And they said, you know, why would they make an agent? 'cause their belief is we're all gonna have so many agents that the last thing we want is another agent.

So maybe what they wanna have is, and it's not quite an API, but maybe a way to plug into your existing agents to go do things. And I think that is something that the agent marketplace kind of model we, we've gotta think about is how many agents, are they single use agents? Are they disposable?

Do I get a Mr. Smith, like in the matrix, who does everything right? Um, what is the nature of these agents?

Are they ephemeral? Are they, are they permanent? Are they my digital butler?

Right? That You might have like a contract agent, right. To do specific job as, which is kind of like the disposable I a concept, right?

Exactly. I'm gonna have a mini mic agent that will manage all those other agents Of Agents. I, you know, well, you're gonna need that an, an orchestrator agent perhaps, right?

Or do you have one super agent that has many different facets? I I, you know, where does, I mean, this could go all over the place. I mean, and, and I'm sure it will over the course of time, but at least initially to me, it seems unwieldy.

And, and in talking to these folks at Hoop, I, you know, I'm trying to put myself in their shoes as a developer of, of this AI platform, AI empowered tool they're building and are they making the right choice? Not building an agent, You know? Yeah.

I, Alan I think the questions are even answered. I mean, uh, you know, the great AI bungee jump that we've been experiencing, you know, uh, was built around generative ai, but turns out that was phase one. I thought multimodal was gonna be phase two, but multimodal is just, it's just now like, it's a, it's a marketing word now.

It's, it's real. But, you know, phase two of the great AI bungee jump, um, is agentic ai. And what I mean by that is people are, well, it's obvious what I mean, they're just jumping into it.

So is it a mistake not to have, uh, your own marketplace or plug into other marketplace? I mean, there's tons of marketplaces now, Salesforce, uh, but they debuted Asian Force last year, right? It was, it's relatively new.

So they're developing it rapidly. But, uh, uh, you know, uh, uh, boomy, which is not a super well-known company, but one that is really right in the heart of where something like Agen AI agents in general, um, can be really helpful. We're talking about enterprise workflow, roughly.

Um, they had, they have theirs, uh, uh, Cisco, uh, as John mentioned, um, SAP with their recent announcements, like Google Cloud, a WSI mean, there's to even the, the big system integrators like Capgemini, I think is debuting their agentic AI marketplace. I mean, we didn't say agentic AI until like a year ago or something like that. And then now we've got these full blown marketplaces appearing.

Um, it's, uh, it's, it's gonna be adopted and used. Everybody's gonna get on the train just like they did with generative AI continue. Well, 23% anyway.

There's been a fear factor with AI for a while, right? Like, yes. I mean, fomo, the last few years, total fomo, every conference I went to, the message was really clear from whether it was a, a Michael Dell or, um, a Jess Wong in his cool leather jacket.

If you're not already in the AI game, you're too late and you're gonna be behind. So I think that fear factor is there, that fomo, um, guys, you're calling it is there for organizations to say, we've gotta dip our toes in. And what Salesforce is doing with Agent exchange and their go to market, they launched this with over 200 partners.

We're talking Google Cloud, Workday, DocuSign box. So we're seeing that momentum really carry forward here on day one with these big names saying, this is what you need to be doing. Company A, company B, company Z, You know, the one of you talk, when you talk about foam of Salesforce, they were Exhibit A, right?

They were considered the, the la the laggards. So in a sense, they've really been ratcheting it up. So anyway, in a sense, they were considered the ones on the outside looking in.

Now they're, they're kind of trying to, they're a little bit overcompensating, I'll put it that they always do this. It's a very heavy duty marketing company, you know, first and foremost. Yeah, exactly.

Sorry, To Lisa's point, this is the marketing battle of the decade. It's whoever controls the front end experience through that agent owns the hearts and minds. And 90% of what's on the backend is gonna be, you know, for lack of a better phrase, a headless agent that other agents are calling that no one's ever gonna see or know.

So ultimately, who owns that desktop is where, or the smartphone or whatever that first agent in line is, owns the game Bet. Yep. com under research reports on maximizing ROI with ai, why agent forces the fast path to enterprise value.

So clearly Salesforce seems to be staking out a leadership position here. We, we, we discuss the SAP announcements around it. It'll be interesting.

Look, here's, you know, don't count out Microsoft. Oh, Azure's got, Azure's got an agent AI tool service. No, no.

But in terms of an agent, uh, uh, uh, marketplace. Oh, yeah, yeah. Or open AI or any those guys.

Oh, any of 'em? Yeah. Mm-hmm.

We'll see, I, you know, place your bets. Maybe that's what we should do, Mike. We should become like a, a bookkeeper for bets on the, we've Talked about that before.

Oh, we, okay. Look, I'm just trying to be creative and innovative, you know, pay, pay some of these tariffs. Oh, we, all we gotta do is, you know, hook up with somebody in England where they have these services anyway.

Yeah. And an agent on the front end of it, and we're good to go. There you go.

Lad Brooks. Yeah, There you go. I thought you meant kinda like Sunday night football or whatever.

I mean, you know, where we, where, you know, all the panelists, uh, place their bed and you look later and see who's right and who was wrong. We, We could, could, we could work on that if you want. We could do that.

We could work on that. Yeah. But then we let other people bet on which analyst they think is right.

Oh, yeah. There you go. Mm-hmm.

God, you're not allowed to get mom to bet on you. Right? No.

Family and friends. Anyway, let's take a break. We're gonna come back here.

We've got C Block. And believe it or not, I don't think we're gonna talk about AI in C Block. I hope not.

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

com to learn more. com. Home of Security Bloggers network.

All right, folks, we're back with the next block. And we're talking about a case involving insider threat in cybersecurity terms. That means somebody who was on the inside who hacked something to gain some advantage.

And a lot of the time we're so focused on preventing attacks from the outside that we forget that the inside's an issue. In this case, uh, in New York, a couple of folks have been charged with, uh, hacking into the StubHub network to grab some tickets from, uh, Taylor Swift concerts, and then reselling them at a much higher markup, which of course is a really annoying thing to all those Swifty fans out there, which includes our own Lisa Martin. But what's your take on all of this?

I think that this is the tip of an iceberg, but I could be wrong. No, you're right, Mike. It is the tip of the iceberg.

7 billion. But what we saw is, is these two people, to your point, Mike, were insiders. They worked for an outsourcing company, um, of StubHub called Sutherland Global Services out of Jamaica.

What they did was they got access to an unauthorized part of StubHub where they store electronic information about ticket purchases, and they only got about 350 different, um, purchases, but it accounted for about a thousand tickets. And what they did was they redirected, not normally. When you buy a ticket up through a, a ticketing service like this, you get the email, you get a unique URL with the email to download your tickets, put 'em in your wallet.

Well, they went in there and manipulated the email addresses, punted, um, what accumulated to $635,000 worth of Taylor Swift tickets to accomplices, who then resold them. And we're seeing issues like this, not just from StubHub, who said, yep, we've been, we've been hacked. They got in, we're working on this Live nation at Ticketmaster, what they're, but these people are prying on me.

I, you can't even call it a cybercrime rang with two people, two people did this in between June, 2022 and July of 2023. So about a year they were able to make $635,000. They did it with Adele, ed Sheeran US Open.

But because the Taylor Swift tour is the highest grossing tour of all time, I think it's getting a lot of headlines. We're seeing it in the US and Canada and the uk, but it's showing a bigger problem that these ticket resellers are going to have. And that is the, the vulnerabilities that they have in their systems that they need to identify, and the fact that they've got folks who are vulnerable, like super fans, who are vulnerable to scammers.

So this is a growing problem that the Live Nations, the StubHubs, the Ticketmaster and the like, have got to fix. So look, as Bill Clinton would say, this is simple arithmetic, simple arithmetic. When you've got tickets that are going for thousands, thousands of dollars, the the temptation to make a buck like that, to make big bucks, $600,000 plus here to make big bucks is too great.

And, and it's gonna corrupt people. You know, I, I was having a conversation with some friends of mine the other day. You know, there's this new Led Zeppelin movie out the making of Led Zeppelin or whatever.

It's an imax. I haven't gone to see it yet, unfortunately, but it's on my list to go see. And, um, I thought back, I was talking with my friends that I grew up with.

We went to see Led Zeppelin, 1977 or 78, 77, I think it was in Madison Square Garden. One of my friends still has the ticket stub, because it wasn't electronic. We didn't have it in our phone.

We didn't have votes, but we had tickets, and he still had the ticket stuff. You know, how much that ticket cost us? $35.

You know how you got it? You had to send in an envelope with a check made out to whatever it was, led Zeppelin tickets or whatever for the amount. You are only allowed to get three or four tickets, had to send in a real check with a postage page, self-addressed, stamped envelope, right?

And it was, and if they picked your envelope, they mailed you back your tickets in that self-addressed stamped envelope. It was a sucky system, but I got tickets to Ledge Upland for 35 bucks. And, and you didn't Have, how much do you think those would've cost now?

Right? If they were, you know, if they were Priceless, priceless. Hey, this, this is making me nostalgic for that sketchy guy I used to meet in a bar and buy World Series tickets off of, you know, yeah, I did that, But maybe that's a safer transaction.

But isn't, aren't these guys from Jamaica, his, his Yes. Descendants in some way, right? Yes.

Look, there is Mr. Re is from Jamaica, Where there's a market where there's a will, there's a way, right? I mean, We were, when we were meeting in New York, Alan, you went to a Knicks game, right?

Yes. And we were talking about the ticket prices. You know what?

That's why I don't go to as many sporting events as I used to. I used to go to dozens, or I used to go to 40 baseball games a year. And for the Warriors, I used to go four or five times a year.

I can, I can go once maybe a year, because it's cost Prohibited. Well, but that's the problem with pro sports in general, is yes, they've almost priced it out of the working man's, you know, working man would take his family, Mike, when you were younger, they took you to Yankee Stadium, right? Gave you a beer.

You were eight years old, drinking a couple beers and hotdog. Yeah. That's why Safe word, the day camp people took us.

Yeah. I mean, I, I used to go with the day people too. You're right.

But it was cheap. I mean, now, you know, a dad wants to take his, his two kids and wife to a ball game. I don't care whether it's a, a football game's, crazy basketball, hockey, even baseball, which used to be the cheapest.

You are dropping a couple of hundred dollars easily, if not a thousand, easily At least. Yes. This is, this is turned into the, this is turned into the Crank podcast, because Yeah, it is very much No, what we're doing, we're not Harry, Get on Go Play.

We're not Talking about the breach. Yeah, we're not talking about the breach. We're talking about back in the day, only Spend, but No, but, but let me go back in the day to Mike's guy, where he bought those shady, the shady guy with the World Series tickets.

Didn't it always used to bother you? Where the hell did these guys get their tickets? Mm-hmm.

How did they get those tickets? What, who did they know? How did they get 'em?

Well, in some ways, this is the path to the tickets a little clearer here, right? Mm-hmm. It's an electronic digital path that we, we could forensically see how the hell it worked and, and what happened.

This to me. We could, but will we, Alan, because that's what's really interesting to me here. Well, we know how this one went down, Right?

Well, we know that a Stub Hub partner accessed a protected Stub Hub database. We don't know how they accessed. Oh, I, I'm sure they do.

And they haven't said it. I'm sure they do. They Probably given, no, not that you making people, I mean, StubHub and whoever they hired, CrowdStrike, whoever did their forensics, they, they not, you know, look, the people stealing Taylor Swift tickets aren't sophisticated enough to not leave hand fingerprints, right?

Digital fingerprints and what they're doing, they, they know how they got in here. That took nearly two years to come to light. Well be because Guy, the average hack doesn't get discovered for anywhere from nine to 13 months.

That's across the board. Not just Swift's what's Everyone up. But Mikes up a cybersecurity insurance Point.

Well, yeah, you know, you, you, you bring that up. I just interviewed the CEO of cow, or one of the co-founders of Cowbell, which is one of the leading cyber insurance companies in the world. They're moving in not just to cyber insurance, but to cyber products now, to make sure that they pay less claims, right?

That you're actually using, because cyber insurance has become the big stick. You want cyber insurance for these kinds of things. They're gonna insist the same way.

Homeowner insurance, make sure you have a good roof and your windows don't leak, and, and you have your safety equipment. Same thing with cyber insurance. I'm not giving you cyber insurance if you don't have a good policy and a resilience plan and blah, blah, blah, all in place.

And now here I'll sell you the resilience plan and that, that's become big business. But in the Taylor Swift case, let's not forget the poor Schnuck who paid the money for the, for that ticket. And, you know, in in law, there's this concept guy, you know, there's this law of specific performance, right?

No amount of money's gonna compensate me. I, my daughter's a swifty. I promised her I'm taking her jr.

He and those tickets are gone. I can't get another ticket. And What's the, what these folks are exploiting, sorry, Alan is the emotional element of what ended up being this tour.

And Karen's doing everything they could. I mean, there were videos from like, when the tickets first one on sale of Swifties just sobbing because they couldn't get access to tickets. There were issues with Live Nation and Ticketmaster.

And so people are pre preying on the emotional element of some of these, um, artists who are really creating experiences. I went to the concert, it was an actual amazing experience. But that's what's happening, is when you get the emotion involved and the fact that it's so easy for this two people to gain access to the Stu Hub system, it's a huge problem.

But Mike brought up this in the very beginning of the block, and that is, this is, this is the tip of the iceberg. I think Live Nation said last year that they were investigating a data breach that dis that, uh, displayed access to over 500 million Ticketmaster customers data. So this is something that these organizations have got to get under control ASAP, because you know what, millions of transactions occur on these sites every day for expensive items.

Look, I I think those, do They have an incentive to, to get them under control? No, they don't. And that's the problem.

They're monopolies. They Do. They they do, they do have an incentive.

'cause here's how it will play out. So let's say I am the dad with the kids who are Yankee fans, but I can't take 'em to go to a Yankee game. You know what those kids are gonna wind up doing?

They're gonna go watch soccer or something else, or they're gonna go go concert, or they're gonna have a different experience. Yeah. But Live Nation will sell those tickets too.

Or stop public sell those tickets too. Let me tell the, the whole, you are out of order, your Honor. The whole system is rotten.

This whole thing that we have these, you know, the Ticket Master, stub Hub, seat geek, and all, all of the other ones, the whole system is rotten. It's people making money on the backs of the artists and the athletes, right? And, and I, look, you could argue that athletes shouldn't make the money they make, or that artists shouldn't make the money they make, but I'd rather my, if I'm gonna go see them play or whatever, I'd rather them buy money, go to them than go to these leches and vultures who, who bring it on, including StubHub themselves, the fees they charge over and above what someone's selling their te I'm a season ticket holder to the Dolphins.

I'm not a Dolphins fan. I gave up selling my tickets because, you know, if I sell my, so first of all, they're crazy exp I gave up the tickets, period. I'm a steel list fan, but the tickets themselves are crazy expensive.

You could hardly sell them for what you cost cost. And then when you put them in for basically what they cost, by the time StubHub puts their fees on, it's, it's, it's one and a half times the the cost. Yeah.

Yeah. It's crazy. The whole, the system's rotten.

It, it is, it, it's that. And we thought we addressed that with the Biden, you know, the, the push to, to eliminate those fees. But, um, Not they have it.

What they do now is they won't, they do include the fees. It used to be you'd search for tickets, you'd say, oh, these are only $250 each. That sounds good.

And then you'd go in and those two, $250 tickets are $700. Well, where's the math? Well, there's fees and taxes and delivery and blah, blah, blah.

So they did. Now they show you the fees included in the price, but it's still a bad system. And so when you have a, an unjust law, right?

Natural law theory here, another law school thing for you guy, natural law theory, if you've got an unjust law or an unjust system, people are gonna hack it. People are gonna do this. So, so my, my current contribution to this is way back in the day, we had political actors and a Congress willing to put consumer protections in place.

And that's what they did with the credit card companies, such that the credit card companies are the ones liable for this kind of fraud. Now, I don't know what, how you can compensate someone for a missed once, you know, once in a lifetime event, but there is no such protection anymore, and it can't be passed through any recent Congress, you know, I'm aware of. So that is something that you used to be better.

And I don't know if we're ever gonna get back to this kind of protection of the, the poor consumer. Yes. Alan?

No, no. Are you done Your head act to crank number Chip? No.

No, guy, thank you for telling us that. I'd like an email from you with the five things you did last week. No problem.

Oh, alright. Hey, let's leave it on. That.

One of them Was, was to join Textron Gang, or should I say Textron Cranks. Textron Cranks. Hey, hey, Hey, Helan.

A little spoiler alert. I I, I went to see the Led Zeppelin documentary. They go on to be huge rock stars at the end.

Oh, Wow. I had a film. Well look To get away the ending.

Raise your hand if you saw them live. Ah, I'm probably probably the only one here who, who actually A buddy, a buddy of mine Saw their last show in North America, which was in Oakland. Really?

Oh, that's cool. Yes. So, Yeah, no, that was, that was a concert.

Yes. All right. On that note, whole lot of love, stairway to heaven, all that love led Zep.

But we're, we're gonna call an end to the Text on gang today. Have a great weekend, everyone. We have a full text on TV as usual schedule behind us here, so stay tuned on that.

If you're watching this not on our text, on TV broadcast, go check out Text on TV or our text on tv, YouTube channel. And, uh, you could watch this and past Episodes of The Gang and about 8,000 other videos on there. So check that out.

Thanks a lot, gang members. Have a great weekend. Everyone.

For now, this is Alan Shimmel for Textron. We're out. This is Textron tv.

Hey everyone, welcome back here to Textron tv. My next guest is Mr. Rajiv Gupta.

Rajiv is the cow co-founder of Cowbell. You may have heard of Cowbell. If not, we'll tell you more about him.

But first, let's welcome Rajiv and find out a little bit about him. Hey, Rajiv, welcome to Text Drunk tv. Uh, thanks Alan.

Uh, glad to be here. Absolutely. So, Rajiv, Rajiv, as I mentioned, you are co-founder of Cowbell, but give us an idea what exactly is cowbell and, uh, You know?

Yeah, absolutely. I'll, um, I'll talk about, uh, I'll give you a little bit background myself, and then also about the cowbell. Great.

Just to give perspective of, uh, you know, why, why I started, um, decided to start cowbell, um, along with the two of my other partners. Um, so my background actually is more from cybersecurity space. Uh, or if I go even more further back, uh, I'm, uh, ex alum, uh, sun alumni.

A lot of my roots, uh, uh, go deep into the operating system layers. And, uh, I know there's some, there's a lot of alumni out there on Sun, and, uh, I know Sun has fed a lot of, uh, interesting technology and a lot of entrepreneurs into the industry. Sure It did.

And, uh, so I, I go back, uh, you know, uh, you know, the, I think if I go back about 10 years or so ago, I, you know, was part of a startup where we were trying to shift left, uh, on, uh, how do you do better? com, you know, trying to shift left in terms of how mm-hmm. How to do things better, faster, cheaper, you know, uh, find defect.

They make their way into the, uh, development mainstream. And then, uh, the startup before Cobell, I was helping shifting security left and trying to see how we can actually build more secure software, uh, from the get go. And, uh, so my background is primarily, I'm a more of a techie, a tinkerer, uh, a builder.

Um, you know, there's a lot of ways to describe. I spend all my free time, uh, you know, uh, building, uh, some of small AI things, robots, uh, you know, I'm, I'm a tinkerer at heart means I, I like to build things, break things, rebuild them. And, um, so about, uh, five, six years ago, uh, I ran into Jack, uh, I've known Jack for about a decade or more about since 2010.

Uh, you know, we started talking about, uh, you know, how things are shifting. You know, uh, everybody who's from cybersecurity, we all know that it's not a matter of if, it's a matter of when somebody gonna get attacked. So we, you know, even in my discussions with my customers, we used to always come, started to talk about the cyber insurance.

And it was very intriguing because, and say, you know what? That's, that's the thing. Because if we do get attacked, uh, the most important thing, as you mentioned Alan, is resiliency.

How do I spring back up on my feet and, uh, get back to work? Right? And insurance, uh, is perfect play.

And you started looking into what options are out there in the market. You know, I had gone through the buying process myself, uh, you know, and saying, you know, what does it take to buy a cyber insurance? And it was painful, it was lengthy paperwork, lot of questions.

And I, I actually cautioned the entire process because there was no way the insurance company understood my security posture based on the q and a. And, uh, you know, the, the kind of discussion I had, and I felt like, looks like this underwriting is being done, uh, with a big black box and just throwing it, and it's just not uncommon in insurance, right? You know, generally most people do a portfolio writing and, you know, making big strokes and whatnot.

But with cyber such a big, you know, such a, uh, core of the tech, we have to use tech to underwrite tech. I felt like, you know, with the advent of ai, with everything that was going on, you know, it made sense to, um, uh, you know, use the data for our advantage, uh, for the advantage of the underwriters to really do a better job in, uh, assessing the risk and, uh, underwriting the risk, and then not knowing a lot about insurance at that time. I felt like insurance is, is all about risk transfer, if you think about it.

Right? I mean, if I'm taking on the risk as an insurance company from a policy holder, I need to be able to quantify that risk, then, then only I can take it on. Sure.

You know, if I can't even quantify what am I taking on the risk? Like what is the transfer happening? Um, so that, uh, kind of, uh, is the starting of the journey and, uh, now, uh, five, six years later, Kabul is, um, is a force.

I think we help a lot of SMEs. We, we are, um, we cater to a small medium enterprises up to a billion dollar in revenue. We have close to about 30,000 customers in the United States and uk.

Wow. And, uh, we, we believe that we are part of the security fabric. We are, uh, uh, part of this, um, you know, helping businesses stay, stay afloat, stay resilient, make sure they can actually open up the doors on Monday morning if they get attacked on a Friday night.

Right. How we can actually do things to help, you know, keep, keep, uh, keep them on their feet, keep them, uh, you know, whatever the goal the, you know, of that business is whatever they're trying to achieve, you know, they shouldn't have to worry about shutting down doors just because they got a ransomware attack. Fair enough.

You know, a funny thing happened on the way to market with these cyber insurance companies, though, IV is, I, I always like to tell people this, that somehow the, the cyber insurance companies became the big stick. Right. We, we exist unfortunately, and as at least here in the us less so in Europe where the government, it's very hard for the government to get anything done from a cyber perspective.

You get some executive orders, you've got the csa, you had the CSA organization putting some stuff out. But in terms of real legislation and regulation, our government, we, we can't rely on the federal government it seems 'cause they don't have the will to do anything about it. And then when you start getting in a state government regulation, you very quickly get a patchwork, a quilt where you could do this in that state, but you can't do it in this state.

And vice versa. It's that, that's hard. Now, in years past, we relied on some big regulatory bodies, like for instance, PCI, right?

Mm-hmm. Payment card industry. They said, if you're going to use credit cards, this is minimum.

And this is how we, you know, this is what good security looks like mm-hmm. In the, especially the SMB market, but even bigger where cybersecurity has become such a, uh, a must have, right? Because the risk is too great.

It, it gave the cyber insurance like cowbell a chance to say, Hey, if you want us to ensure you, you need to be doing, you gotta have good resiliency plans. You've gotta have, you know, a good security architecture and strategy and, and so forth. And so the cybersecurity insurance companies became the big stick, the enforces of security best practices.

And then we needed that. Yeah. I, we, we do run into that where I have discussions with CSOs and they tell me that, Hey, rajiva, I've been trying to roll out, uh, you know, uh, enterprise wide MFA policy, and I have been unsuccessful for the last two years.

I am so happy that you put it as a subjectivity in the insurance policy. And it has now given me a stick to go really make sure is enterprise wide. So there is definitely that, uh, piece to it.

I mean, know, you can, you can use the analogy of, uh, you buy a home insurance and home insurance sends you a letter thing that, hey, you need to cut down those, trim down those trees around your house. Otherwise, and before you know it, the, the, the thing that you were laying for a year, year and a half, where you call the gardener and get them trimmed right away, right. Those, Yeah.

I live in Florida, it's even worse. They're sending drones over houses Yeah. And telling you you need a new roof or whatever.

So, uh, I think it's real. The, as human beings as enterprises, we tend to delay it, uh, just to, puts a little bit of a spotlight, makes it happen. And end result is it's a more, uh, secure, uh, business, more resilient business.

And, uh, it's good for everybody. Absolutely. Now, of course, you know, security is always moving.

Mm-hmm. And, you know, the big, well, the big thing in technology in general is AI now, right? Everybody's talking about how AI's changing the game and generative ai, agent ai, all all of these things.

Um, you know, but the in, in security and cyber in particular, the bad guys are as smart as we are, and they're really well organized. And any new technology like this, they're, they're harnessing it and using it too, Even at a faster pace than us because, um, you know, for a business, I have to run my business, cater to my, you know, I'm, I'm not in the business of, uh, figuring it out how to use ai. And my goal is to actually deliver the business outcome, whatever that is, right?

And, uh, security just happened to be one of the things I need to worry about. But there are a gazillion other things as an entrepreneur, as a business owner, I have to worry about. But for a bad actor, that's the only thing they worry about.

That's, you know, they get better every day. And AI has given them this automation, the speed accuracy, and, you know, they don't have to try a thousand times to see which one they're gonna get in. Now they can run simulations and they can actually be more, more precise in their attacks.

And, uh, so I think, uh, definitely both the frequency, the severity is going up in terms of the attack as a result of the AI used by the bad actors. Agreed. I agree with you, ed.

Yeah. Um, so now again, the big stick has to stalk right in, in light of these new attack methods and technologies. You know, how Bell, I assume is, is asking companies to do more or to, to be aware of this.

Um, what, what are, and, and, and as I, we were talking, you know, before we got online, look, a lot of the action today is around the resiliency aspect of it. How do I respond? How do I bounce back from these things?

So what are the kinds of things you are recommending to cowbell customers for, you know, to remain resilient in the face of this whole new class of threats? Yeah, it's a great question. So I think, you know, it's, uh, it's not entirely new stuff.

Uh, you know, the things that, uh, cybersecurity industry and insurance, uh, we've been preaching for a while. You know, the basic hygiene, like continuous monitoring of your, uh, you know, uh, internet facing compute, you know, threat assessment, somebody watching, uh, you know, the whole, um, threat intelligence and the telemetry of, uh, data that gets generated from your routers and systems to see if there's a threat actor already present or trying to get in, uh, basic, uh, cybersecurity awareness training, you know, believe it or not, means the human still remains the, you know, the weakest link in the cyber cybersecurity kill chain. Uh, you know, it's very easy, especially with the AI crafted, uh, emails and whatnot to get through the spear phishing campaign and make the, make a human click in or, uh, you know, do something that, uh, used to be hard because we used to train, uh, you know, uh, everybody saying that, Hey, look for spelling mistakes, other things, you know, the, the craft of the email.

But now these emails are, they look perfect, right? There's no error. Yeah, you are perfect.

You know, even, even most of these bad actors are not in a natively English speaking countries, you know, before they used to make mistakes and just grammar and just spelling and whatnot. But now these emails are perfect. So I think the, the bar is higher.

What that means is the companies have to do more. Uh, and that's the reason, by the way, we just launched last month, uh, resiliency Services, and we are, uh, trying to figure it out. How do, how do we help these SMEs, even b even more, right?

Try to bring in, uh, a suite of free services that can help, uh, policy holders, uh, stay up to speed with their continuous monitoring and, uh, whatnot. We provide a full one year of, uh, free cybersecurity, uh, training to all our policy holders, no matter whether you're 20 employees or 20,000 employees. You know, it's, uh, it's all free for the first year.

So we, we are trying to, you know, make the barriers to entry lower so that, uh, more and more policy holders can actually do the basic stuff like, you know, a a a pen testing, for example. It's a, something that we all know that, uh, uh, checklist is one thing, right? I can say that, yep.

I can fill the questionnaire, all the things I have gone through, I can look at the, the NIST or any of these CSF benchmark and say, yep, I, you know, I'm, I'm good, good, good, good. But that doesn't really, you know, do the job. We have to employ a third party to see if, uh, you know, we can do a, a penetration testing that helps us really understand those, uh, weak points in our infrastructure so that we can fix it before the bad guys actually exploit those things.

So, you know, uh, to, to net it out, basically we are, we are still talking about, uh, uh, you know, cybersecurity training, regular pen testing, um, tools like, uh, managed detection and response. Um, no enterprise, you know, especially in the SME space, has the time or the manpower to employ cybersecurity exports, uh, who are there 24 by seven. Even if I'm a business with five, 700 employees, uh, decent size, um, I, you know, I could have a cybersecurity people employed, but you know, these, uh, it's hard to do a 24 by seven, um, view of what's happening in the environment.

And that's why these managed services work really, really well. Um, think about most of the attacks happen in the evenings, the weekends, and the holidays, long weekends, and that's the time where employees are taking time off, where all the cybersecurity teams we hire, they also take time off. And that's exactly the time where, uh, the attacks mostly spike up.

So we, we need to use the best of the technology out there, best of the services that are available. And that's exactly what we are trying to do with our resiliency services, trying to bring these, uh, best of the breed, uh, solutions and services to our policy holders. Now, is this Rajiv, is this crossing a line though, from just providing insurance and giving best practices that people should use to actually providing security services?

Yeah, so more and more insurance companies are realizing that, uh, you know, to staying on the, uh, right side of the boom, uh, on the aftermath of an event, uh, it works. But, uh, because of, as you mentioned, you know, there's more AI driven attacks and things that are happening, the speed at which things are rising up, uh, they're finding that it behooves us to partner with the cybersecurity industry to bring the best of the breach solutions to our policy holders. Uh, SME doesn't have a, uh, the kind of time to really evaluate, oh, there are so many, so many solutions out there.

What, which one is the right one? You know, should I buy this? Should I buy that one?

And then, okay, I did the evaluation, but then I need somebody to configure it, right? You know, then I need to find an MSP to say, okay, I have found the solution, it's deployed correctly, but then that doesn't end it there. I need to now keep an eye on the, uh, telemetry data that it generates.

Now I need see security experts to be able to look at the data and say, well, is it a real threat or is it a false positive? So if you think about it, it is too much for SME to take on, and that's where I think, uh, you know, it makes sense for the insurance companies to your point, right? It's not just about the stick.

It's not about me saying that, Hey, you need to trim down the tree, but I also tell you that, hey, here is the, the best, uh, person to trim that, uh, tree down, uh, to mitigate the risk, right? So we, we bring these services, uh, to make it easier for the policy holders so they don't have to go shopping around, go, don't have to waste time, get the job done as ASAP. Love it.

Rajiv, I don't think we mentioned the website for cowbell. Oh, yeah. So cowbell insure, um, you know, it's, um, a lot of information there for anybody who's interested, uh, including the resilience services.

Uh, you know, it's a great place to, to learn. And by the way, we also have Cowbell Academy, uh, which is a really, really good place for even the brokers and the agents to go, uh, learn more about cyber security and cyber insurance. They can even take, uh, some of those credits that they can apply towards their, um, you know, um, the license renewals and, you know, the, the credits they need, uh, to stay on top of, uh, the tech and everything.

Love it. Thanks for coming on Tech Truck TV and making us a little smarter today. Keep us posted.

You're gonna be at RSA conference? Uh, probably gonna be, yeah. I'll be visiting, yeah.

A couple of days there. Yeah, absolutely. Well, We'll be there, live on Broadcast Alley, maybe come by and say hello.

Absolutely would love to Alrightyy Rajiv Gupta, co-founder Cowbell, cowbell Cyber Insurance. Uh, check it out. We're watching Techstrong.

We'll be back in a minute. Hello and welcome to the digital CXO podcast. I'm Amanda Ani, and with me today I'm excited to have Curtis Spar.

He is the principal of spar. How are you doing? I'm great, and thanks for having me.

Yes, I'm happy to have you on the show. Can you share a little bit about Spar? What services do you provide?

Spar is the politely pushy tech, and, oh, I don't even know. We're not just tech. We're FinTech, we're ai, we're pharmaceutical.

It's like hard for me to just say, you know, the boilerplate, you know, elevator answer when we're doing so much. But we've been remote since we started in 2015, and as a result, 10 years later, we have some thoughts on what makes an agency or any company really good when they have a remote first workforce. And I was hoping we could talk about it.

Absolutely. Well, I see a, a wall of a awards behind you there, Ta and, you know, we won these awards to prove that remote work works better, and that's because we invest in people and not buildings. And at first people were like, Hey, you need a water cooler if you're going to have a creative agency.

And what happened is we kept on winning awards so much that we are the most awarded agency in the United States. And I think that goes to show what remote work can truly do. In fact, our research shows that it's better for many companies, bottom lines.

Wow. Well then you are the person to speak with today about remote work and the future of remote work and how it's going. You recently put together a study, so can you share a little bit about that study and then we can go into the results?

Yeah, you know, we did this as a point of view of what not only do employees get from remote remote work, which I think is kind of obvious, but what people who are hiring remote workers get, because we think there has not been enough research done there. And what we discovered is that oftentimes people reported better results when they hired remote workers or remote firms such as ours. And we think that this is a powerful part of the bigger story that other people are telling.

For example, the San Francisco Federal Reserve put out research that said fundamentally there was no difference between a remote workforce versus one that was in an office. And so this research shows that not only is there no difference in productivity, there is however, a difference in outputs. And that's, you know, having employees who are more 24 7.

Uh, it's for people who are more proud of the work they do, and when it comes to results, it's people, uh, reporting better results on work product than if they were in an office. And I think there are several reasons for that, including all the time wasted in an office. Like when someone wants to talk to you about what happened on White Lotus, which is definitely a crucial conversation, but perhaps one that doesn't really impact the work product as much.

Absolutely. Well, I know I started working remotely, gosh, about 10 years ago now, and I could never look back. So I look at some of these, um, uh, call to office initiatives, and I completely understand the buck back there because I just don't think there's any way I could find myself going back into a brick and mortar setting.

So what are your thoughts on that? So we are seeing a lot of, uh, mandates to come back to the office, but we also are seeing some buck back. I wanna hear your thoughts on that, and then definitely I wanna get into some of the details of the report and, and what that means for business leaders.

You know, a lot of different executives are trying to realize the investment that they made in a brick and mortar building, and I think that's a lot of it. I I also think, and I hate to say this, it's a little bit of some old fashioned thinking where whenever we have disruption, there are those that challenge the disruption itself and say, no, back in the day it was better. And they might not have any other reasons other than their memories or, you know, some warm feelings about office, you know, camaraderie.

But there's nothing that proves that. And so I think those kind of feelings are really what we're seeing. This is a sentimental return to the office, if you will, where people's emotions are getting the better of themselves.

But just from a fiscal number sense, it absolutely is not a good idea. And then when you think about the environmental costs, it's not a good idea. And when you think of the time lost, it's not a good idea.

The other thing is, is that it's a good idea if you could get workers from anywhere as long as they're talented. And by getting a talented workforce that is not shackled by their geography, you get rid of location think, you make sure that you are getting the best minds no matter what. And so there's really just so much to be gained.

Now, I'm not saying that every place has to be remote. I think there's some places like a hospital that make a lot of sense, and there are certain places where engineers have to gather and build things that makes sense. But for knowledge workers, overwhelmingly, it makes sense for those people to be working from home because you're really going to get a lot more out of happier employees.

Absolutely. I agree. So what are some of the key findings from the study?

Well, I would say the key findings are, you know, twofold. One is the self-reporting part where people say that they're more productive working from home. Um, you know, in fact, only 5% said that they had lower productivity when they worked at home.

So overwhelmingly working from home is better. Um, and I think the other thing that is important is over 80% report a improved work-life balance. And I think that is seen in the investment that they can make where they would be commuting, they can instead be working, and thus, you know, they don't have to kill themselves when it comes to their families, when it comes to, uh, making sure that, you know, young families get the support they need.

I think the other thing is that we're seeing interesting pushback on the mandates. We're seeing 73% of consumers would less likely purchase something from companies requesting full-time office work. Uh, 63% would be less likely to apply for jobs, and 60% believe companies to encourage remote work to in reduce the environmental impact.

And so I think that those are, you know, the key sort of stats that are important in thinking about this conversation, especially as the next generation comes along, be becomes online because that next generation is going to be viewing these companies with a lens of what have you done for the environment? And we are right now running out of time environmentally in terms of how we can fix our, uh, footprint and remote work. If you do it five days a week has been shown to reduce that impact by more than 50%.

So I think that any argument about no, you need to come back to the office kind of falls apart when you're faced with the real life crisis we're in. And you know, I hear magical thinking about returning to the office and how it's better for, you know, the economy, but you don't have an economy if you don't have a species. Yeah, absolutely.

Some good points there. And it's very interesting that people are fighting back in that manner. I feel like we weren't focused on these sorts of things back in the day when we were shopping or looking for products.

We weren't thinking, okay, let's do some research. Do they have to have all their workers in the office or remote? You know, how are they with environmental missions and sustainability?

We weren't looking at these things, but now, um, these results are showing more and more people are making decisions based on this. So that's interesting. Yeah, and I think that, you know, every time these events like Earth Day come along, that you know, reminds people about it.

And a lot of companies try to lean into Earth Day because their research shows that younger generations really care about the planet and are very alarmed. But it's hard to square that with these, you know, return to work mandates that are pretty draconian. And the other thing that we have to consider is that each time the environment creates another huge problem we all have to deal with, that's when all sorts of people are gonna be thinking, how can we, you know, rectify the situation?

How can we improve it? So, you know, returning to working from home is going to become more important year over year. And I expect that to be the case.

I also expect it to be the case that the better the economy performs, when the economy performs really strongly, that puts, you know, the most talented employees in the driver's seat when it comes to making demands. And our research shows overwhelmingly that the most talented employees want to work from home. No one truly talented aspires to grow up and be managed in an office.

They want to be able to have that level of freedom to take an afternoon nap when they want, for example, or to take care of their kids. And that's, you know, part of what we're seeing with working from home is that people see it as a means of freedom. Absolutely.

That work-life balance. And it's interesting that you found, um, the quality of work is much better. Uh, you said there wasn't maybe a lot of difference in productivity, but the output of the work was better, uh, with remote workers.

And I would tend to completely agree. I would even say from my own experience, even my output of work was probably, uh, better because I felt when I had the flexibility and I had the room to work, uh, in my best environment, I was able to flourish in my career. That's when I flourished, was when I had that space and the ability to work in my best environment with flexibility to take care of my child if they needed to be picked up from school, um, not be begging, you know, to get off.

Uh, you know, so when that, when that stress is removed from your workday, it's so much easier to get more work done, better work done. It just makes sense to me. I I don't understand, I guess quite why some people haven't picked up on that yet.

Oh, not only that, the thing that we're seeing from some of our Boomerang employees who said, oh, I want to try an office, and we said go, is they'd come back and say, you know, the thing is, is a lot of people are taking those work from home behaviors and they're putting them in the office. One person that reported that he would go in, everyone would be in, you know, their own separate rooms doing zoom calls and that no one would really talk to each other. And so all the things that, you know, people thought would happen when you return to office, that you have all this, you know, collaborations, et cetera, has really disappeared from, you know, just the expectation to get stuff done.

And that's what working from home really does, is you really have to be accountable for the work that you are offering. And so I think we're gonna see that more and more. Absolutely.

Yeah, when you're at home, you're just really cracking out the work and focused. And while the comradery side of it, I do understand there is a lot less, uh, wasted time or standing around at the water cooler, as you said, uh, in the office because you're really focused and you can get so much more done and more quickly and efficiently. I've had so many good ideas destroyed because some coworker would come up and say, Hey, did you see what was on TV last day?

Oh my God. Or they would gossip or no one would come up to me and say, Hey bro, let's collaborate on a really good idea. Usually those collaborations were scheduled, they were timed.

And so a lot of the kind of chaotic kismet that people are talking about that happens only in a physical office really didn't happen all that much. But what did happen is someone would come in and get everyone sick. What did happen is someone would come in and gossip or create a toxic work environment, you know, those problems with a physical office are rife from, you know, fighting over who has the bigger office with a better window to the condition of the bathrooms.

And, you know, don't get me started on the condition of American bathrooms and offices. I mean, they're just gross. So there's really nothing to be said about working, forcing people to work in an office, except that it somehow suggests you don't trust your staff.

Absolutely. I agree. And I wanna say I do understand some people actually missed working in the office, and I understand that for some people, they really, um, felt they lacked that, that social aspect that they needed.

Uh, but I do feel that a lot of strides have been made, uh, from remote, from the remote aspect with, um, being able to bring that social aspect in and the comradery. There's a lot of tools and technology and, um, communication channels like Slack and, um, various other methods, zoom, et cetera, that have been able to help in that area. But I do understand that there are some people who do still prefer in-person work.

Well, you know, of course I think there are people who, who appreciate that. And usually we find the people who like it the most are at the very start of their careers where they need some sort of handholding. And so oftentimes when someone needs that level of handholding, we will fly that person out to a mentor who can help train them so that they can get that feeling of, you know, one-to-one, uh, bonding and team building.

But I think the other thing when it comes to that sort of needing to be with people is that's what coworking spaces are for. Some people just pathologically need to be with someone else in the room to get work done. That's, you know, what they're for.

You know, one of my friends said she just likes going to a library just to feel other people there. And I could appreciate that. For me, I have pretty stacked days, so I don't have that sense of loneliness.

In fact, I don't think anyone at our company does. But there are ways of working around that. I just think the point about forcing people to go to work and or go to an office is not really well thought out, and there's just no scholarship that supports that, you know, it's better in any way, shape or form, but there's plenty of research to show how bad it's, Yeah, I agree.

And we even have a, a remote working space here in my city. And, um, at our all hands meeting a few weeks ago, we all met at a remote working facility for our, for our meeting. So that's really great.

And that does provide that. Well, if there were any other things you wanted to share from the study, I know you had a companion study by reputation leaders, um, found, let's see, 73% of consumers would be less likely to purchase from companies. You mentioned that.

Um, so what do you think, let's talk about that for a second. Um, as more people are looking at this and determining who they're gonna go to, what do you think business leaders need to take from this survey moving forward? I think that this is a serious, uh, reputational issue for a lot of companies because companies are not looking at the big picture about how the next generation and the generation to come are going to view these decisions.

And that's why I think it's super important for us to have these conversations about what the impact is for companies that insist on returning to the office or how those demands are couched. And so that's why we've been raising the alarm on this because we know working from home for knowledge workers works, and we know that a lot of people are, you know, evaluating companies that are not buying into this future. I think that, yeah, of course we're having some push and pull, but I suspect in the next few years, working from home is going to be the norm for a majority of Americans and a majority of knowledge workers.

All right. Well if there was one key takeaway you could leave our audience with today, what would that be? I would say that you should trust your staff.

If you don't trust your staff, you're not gonna be able to really have a work from anywhere environment. And, you know, trusting your staff is the bedrock of working from home. Absolutely.

Alright, well thank you so much for coming on our show and sharing your insights with us today. Oh, thanks so much, Amanda. I'm glad you put up with me.

It was a great conversation and thanks to our audience. Stay tuned. There's more.

This is Textron tv. Hey guys, thanks for the throw. We're here with Christian Rodriguez, who is field CTO for CrowdStrike, and we're talking about a new report they have about the threat landscape and in particular, what's going on with all these attacks against our identities.

Christian, welcome to the show. Hey, thanks for having me. What exactly is the challenge with identities?

Because we've been using passwords for as long as anybody can remember to identify a friend from FOE, and here we are in 2025, and basically people are realizing that that's not working anymore. But why? Well, I mean, identities are the path of least resistance for the bad guys.

If a, if an adversary gets a hold of an identity, it ultimately means that, uh, the adversary can blend in the environment, uh, as much as possible that they can emulate a legitimate user. They don't necessarily have to drop a piece of malware in an effort to gain their initial access or, or, or stay persistent. Um, and it's just very easy.

It's, it's, it's just a very simple way to get yourself into an environment as the bad guy and, and stay for as long as possible while not alerting a defender to your presence. To your point are the bad guys, they don't break in anymore. They simply log in, right?

Yeah, exactly. They're just logging in and they're, they're trying to, they're trying to be like an everyday user. So how pervasive is this?

I mean, you guys did this report, but how big a problem is this? Yeah, I mean, it's, it's been an increasing issue. I mean, from, from everything from, you know, access brokers that are, that are basically selling that initial, you know, list of identities or the actual access into the environments, there's been a, uh, a a 50% year over year increase in the amount of access broker advertisements, which basically allows for a bad guy to kind of waltz into the environment with, again, without having to drop a piece of malware.

So that's been an increase, uh, an interesting, uh, increase, uh, year over year where, um, you know, identities are kind of the focal point of in, in an interesting ePrime ecosystem or marketplace of, of allowing someone to basically buy that access. And so that's an interesting trend that we've noticed. And then we've noticed also that there's been a major increase in, uh, the amount of, uh, of voice phishing or vishing attacks that we've seen where there's a roughly 442% increase, uh, that we saw between the first and second half of 2024.

And what that ultimately means is that, uh, adversaries are calling in to enterprises under the guise of a legitimate user that is having problems resetting their passwords and they're emulating or they're pretending to be this specific user and they're asking for credentials to be reset. You, you mentioned passwords and, and that's an interesting way, way or, or method that adversaries are, you know, again, just kind of pretending, you know, in social engineering their, their way into an environment in an effort to gain access to those legitimate credentials so that they can log in and, and then kind of have free rein of, of access to anything that that user has access to. Ultimately, what is the cure for all of this?

'cause we see everybody tossing around things from, uh, pass keys to biometric authentication involving your eyeball. It seems to be a lot of choices, and I'm not quite clear. Everybody knows, uh, what to do and when to do it, You know, so I think it's a multi-pronged approach of, of first and foremost having the ability to, in real time understand who's accessing or authenticating into what resource, understanding what your policies are around, um, uh, who, who should have access to different resources, but more importantly, in real time, having the, the ability to understand what an outlier is.

If I, if I see someone, for example, trying to authenticate to a system that they've historically logged into from, let's just say Miami, Florida, and all of a sudden they're, they're trying to log in to that system from Oxford, for example, within an hour's timeframe. That's, that's what's called an impossible travel, for example. And so there are use cases where you can emulate, or you can ultimately create real time, uh, analysis that says like, this is not legitimate or this is suspicious at, uh, at least.

And from there, doing things like step up authentication or having the ability to even assess the endpoint and the system that the user is making that authentication request from in an effort to, to in real time stitch together what is real authentication versus what could be stolen credential versus what is, you know, maybe even a service account or some outlier, uh, authentication attempt that you could ultimately start to, to mitigate against or prevent. I also feel like in a lot of ways we are our own worst enemy because we seem to give end users access to everything. And some of that is just kind of being lazy and somebody says, well, here's my new hire, what should he have access to?

I don't know, he is probably gonna need this and this someday. So give him everything and then the next thing you know, their credentials go missing and the blood guys have access to everything. So are we a little sloppy in how we grant privileges?

Yeah, I mean there's, there's a hygiene issue. Undoubtedly. We see this every day when enterprises call us in and they, for example, even use our technology to do an assessment of like active directory.

What's interesting about, um, an authentication system like active directory is that no one, no one built it yesterday, right? Like usually active directory is inherited. And there are, to your point, there's an excessive amount of privileges that are granted to users over the course of their careers.

And then a lot of times those privileges are just simply copied into, uh, these roles. And these roles are then kind of issued down into users as they're onboarded. And that has historically created this problematic hygiene issue where, um, users just have just excess permissions into resources or roles that they really shouldn't in the grand scheme of, for example, like a zero trust framework.

And so because of that, um, there are lots of issues where, uh, no one's really assessing or reassessing and reevaluating the, the permission sets and the hygienes of those users, or things like even password expiration dates or, you know, the fact that maybe a user that should, that is accessing certain servers, um, you know, that's not really part of their job and maybe they, there needs to be a new policy that ultimately enforces control around, you know, what those resources are. And then even what happens after they authenticate in terms of authorizing access to other applications. And so that's something that a lot of enterprises are being, uh, challenged with is, um, ensuring that there's a hygiene of the users, their identities, their permissions, and then, uh, a list of available resources that, um, that the user should have access to.

I also feel like we obsess a lot about onboarding 'cause we're trying to make somebody productive, but, um, I would suspect that you and I probably still have access to any number of systems from previous jobs that nobody off boarded us from. And so is that also part of the issue here? Sure.

I mean, I think it goes back to that hygiene issue of saying, when's the last time someone did a reassessment of that user's, uh, I identity and their, their role that they've been assigned. And, um, we, we have this amazing capability of, of understanding, um, what those permissions are, is that ultimately excessive? And what is a user actually doing in real time, right?

Once, once once they authenticate onto a system, and then where, where could they possibly go? And so I think, you know, the offboarding concept, it's, it's harder for larger enterprises that have, you know, you know, tens if not hundreds of thousands of employees, uh, that they need to revisit each of those different business units and do analysis of, again, the identity of the user, what those permissions are, where they should have access to, how they should have access to. But then even enforcing multifactor across those, uh, those applications I think is a really big, uh, you know, step up in terms of, of how they can control or have some compensation controls around that hygiene problem.

Because if I can enforce in real time additional, uh, uh, multifactor and conditional access controls, I can, I can force that user to validate that they are who, who they say they are in real time as they're making those requests, you know, uh, to, to those different resources. So you guys have this report, and I know you've been around the block a couple of times. Anything in here that kind of surprised you that you went, wow, I, I I thought we were better than that?

Uh, I would say, um, that's a, that's a really, really great question. Um, so there's some really interesting points around the amount of vulnerabilities that we've seen. There's a 52%, um, you know, uh, really 52% of the vulnerabilities that we observed rather were tied to like initial access, which basically means that adversaries are trying to find their way into your environment by any means necessary.

And so that includes a, obviously an identity that includes also vulnerability. But I think the, the major, the major number or the major, you know, uh, factoid if you will, that that really stands out is this concept of breakout time. And we've been tracking this breakout time, uh, number for probably since 2016 when we started to do analysis on how much time it takes for an adversary to move, uh, from the, the, the system of compromise into a neighboring machine.

Basically, think of lateral movement, right? So how long does it take an adversary to move, you know, once they've compromised one system onto another set of machines? And there was at one point, the average time would be roughly like four hours, and that number started to decrease substantially.

This, uh, last year we, we averaged out based upon an assessment and observations of various at, uh, attacks, hundreds of them, uh, breakout time was roughly 48 minutes, right? And so think of the amount of time that, you know, it takes for an adversary to now move from a system, uh, that's compromised into neighboring devices or even cloud assets or anything that they essentially have connectivity to. It's roughly 48 minutes, which is a staggering number, but the fastest time that we saw was 51 seconds.

And so that's a pretty substantial increase in, in terms of speed and velocity, which, which from a defender perspective, you also need to become faster, right? So I think that's a very staggering and, and very worrisome number that we're observing and we're keeping an eye on. And there's so many different, um, facets that contribute to that, that increase in velocity.

AI could be one area identities are a massive area where that initial access is simply gained by having a list of ident identities that can be used for further authentication. Um, you know, the velocity at which adversaries are running their scripting on these systems. Those are all major contributors to that number being smaller and smaller every year.

When we get to the point where we can track from the moment the breach to remediation, what the actual cost was to the organization, and we could have this like little meter that's just going click, click, click, click, click while we've looked for this particular resolution. Yeah, I think I, you know, I think this kind of begs or, or, or leads us into conversations around like even AI where like how does the defender get faster? I think there's like AI that can help augment and, uh, help give a little more context around the impact of, of a series of events, right?

Whether it's a breach or whether it's a initial endpoint that gets compromised. And I think as with every business, there needs to be, uh, an assessment and understanding of what risk means and what is your appetite for risk, and then what is the impact to the business throughout a variety, variety of different attack types. So there's everything from ransomware costs to the cleanup of identities being compromised to things like data theft and intellectual property being stolen.

And those are all, um, and it's just varying, uh, attack types that ultimately have very different figures, uh, attached to them. And I think that we can probably leverage AI to help us get to those answers a lot faster. To your point, we are rapidly moving to an era where the bad guys are using AI to launch attacks in volume and sophistication that no mere mortal is ever gonna be able to defend against.

Sure. And so we need AI to defend against that, but, um, we also need people who know how the AI works. So are we getting to a point soon where maybe most organizations should just rely on some sort of AI driven service rather than trying to fight the fight themselves because they're just never gonna win it on their own?

I, I don't think there's a concept right now of, of solely relying on ai. I think that AI is there to augment the SOC analyst experience. It, it's there to increase the velocity at which you can defend.

I think it's there for providing a lot more context into things like identities and the misuse of identities and the fact that, uh, someone logging into one system trying to authenticate against applications that they've historically not accessed that can be, uh, supplemented, if you will, with AI specific intelligence and kind of like an overlay that, that helps a defender get their arms around things like outliers and what's anomalous. And essentially think of a combination of AI and machine learning. So I think in the grand scheme of the defender, you know, we, there's a saying here at Crosscheck that you don't have a malware problem, you have an adversary problem, which means that there is a human on the other side of that keyboard launching the attack.

Ensure they may have AI as part of their tool set, but I think as a defender, you know, you'll have AI as part of, you know, the list of, of, of tools in your tech stack that will help you respond faster. I don't think we're getting to a point anytime soon where it will be, uh, just ai. Um, but there's gonna be dependencies that that will help you as a human respond to the events that require a lot more prioritization.

And I think that's where AI will, will start to lend some help. But to your point, as an organization, should I invest in getting my own SOC analysts or should I just rely on somebody else's to do that who is being augmented by ai? And maybe, you know, we still need cybersecurity people.

It's just a question of who they're gonna work for. Yeah, that's a great, that's a great question actually. I think, um, I think, you know, when you are building out your own sock, I think that you are going to be challenged with, um, you know, how, how much you can stretch a resource, right?

I mean understanding, I mean, the crowd and crowds check, for example, is this crowdsourcing, this telemetry from over 2 trillion events every single day that we get to analyze and apply machine learning and AI models against. And ultimately that also, uh, includes a huge human element of threat hunters and threat researchers and intelligence analysts that, um, can understand this data and can do a lot with that information in the form of behavioral patterns and machine learning patterns and, uh, understanding new trade crafts and techniques that adversaries employ in their respective campaigns. And so if you're building out your own soc yeah, you, you will have someone that is locally available to help prioritize and help respond.

But I think leveraging a resource that understands globally, for example, at the scale that for example, crowd side could, could, could analyze these events at, I think that naturally benefits you as a defender to have access to that information versus having someone that is gonna be very focused on activity that's within your respective environment, which is still good. But as an extension of that, you still need this top of the funnel perspective into everything that's happening globally. You know, you know, a a way to help operationalize the intelligence that's being captured.

And, and, and a lot of times enterprises are challenged with having the right resources to accommodate that type of skill. Now, of course, the bad guys are weaponizing this stuff into various services and it's all highly automated and from their perspective they're kinda like, why would I do anything more complicated when what we have today works just fine? But are there any particular new threats on the horizon that you're looking at that go, wow, we need to pay more attention to this?

Yeah, I think one, one of the biggest areas we're seeing now is tied to insider, uh, uh, risk and insider threat, right? We, there's, um, you know, if I identities are being a major focal point of, of adversaries in an effort to stay, you know, sticky and, and, and get quick access, we've also seen an increase in insider threat use cases where from a nation state perspective, countries like North Korea have been embedding agents into enterprises in the form of employees that are software developers. And so we're seeing an interesting increase where these nation states may place, may have someone go through, uh, an interview process and they may leverage things like AI to build fake profiles on, uh, job posting sites like LinkedIn for example.

And they will go through these interview processes using fake identities, and they will ultimately, um, you know, go through a very rigorous interview process where once they get the job, they will have their laptop sent to like a laptop farm. You know, there's a whole process behind essentially how they gain access onto the system using, um, remote management and monitoring tools. And then from there they have the ability to embed, you know, malware or something malicious into the code that they're developing on behalf of that enterprise that hired them.

And so we're seeing that ai, for example, is being used to, uh, weaponize hiring processes so that there's an actual people component to, you know, getting into an enterprise and then having access to sensitive data or, you know, or just being on a payroll to, you know, further, uh, you know, send those funds into something like the North Korea's, you know, weapons program. And so that's, that's an interesting trend that we, we probably anticipate seeing more of, uh, this year. Other countries will probably follow suit.

Absolutely. Lemme ask you, is there something that you see organizations doing that just makes you shake your head a little bit and go, folks, we need to be a little smarter than that? Yeah, I think any organization that is depending for thinking, if we're talking about identities, I think any organization or enterprise that has defaulted to like a, a text-based, uh, or SMS based two-factor authentication schema, um, I think that is, is antiquated at this point, especially given the way that adversaries can leverage sim swapping as a mechanism for stealing your identity.

Meaning that they will call up your cell phone provider and they will pretend to be you, and they will get, uh, that cell phone provider to convert your SIM or your eim into their phone, and now they have access to all of your text messages and your phone calls. And if you have that as your multifactor authentication mechanism, then it's very easy for, for someone to call up and, or, or reset a password, get that MFA prompt on their phone as a bad guy or bad girl and, you know, and then actually gain access to the resources that you have access to, um, based upon your identity. So I think any, any organization that is still leveraging an SMS based MFA tool, um, I think needs to really start looking into things like hardware, tokens and, um, you know, something that is a little more, you know, individualized to the, to the end user.

So what is your best advice for folks who, I think everybody nods their head and says, yeah, zero trust, we need to get to zero trust. Yeah. But the, the journey between where they are today and achieving zero trust, which may never be perfect, um, is very far.

So how do I kind of get down this path in a way that I think a lot of folks look at this and they just get overall and they do nothing. Yeah, I think it's, it's having a technology that can start to stitch together in real time. You know, what does an attack really look like these days?

And it's, it's gonna be identity based naturally as kind of your initial access. Um, but it's also this ability to understand that adversaries are, um, becoming enterprising. There's this theme that we have in our report of the enterprising adversary, and it ultimately means that adversaries are, are very opportunistic and they will find their way into your environment given the resources that you've invested in.

And so understanding that an adversary may target your endpoint or your cloud infrastructure, or once they have access to that identity, they have the ability to navigate, you know, everything that's in your enterprise. I think that organizations need to invest in capabilities that can stitch that in real time, those data points, that what is my, what are my identities doing? What are my endpoints doing?

What are my cloud assets? Doing? What, what do I see from a third party perspective?

And then how do I start to add behavioral analysis to understanding what's real versus what's an outlier versus maybe what's a broken business process or a process that needs improvements? And, uh, and then re and understanding every business unit in terms of, you know, how they access data and where that data should go to and who are your actual partners and business partners. So I think, you know, if I were to, to to say let's, let's be a little, you know, consultative, I think it's really more of ensuring that you have a technology that bridges and, and brings all that data together in a cohesive fashion, but more importantly, can in real time give you that visibility into what is, what is an outlier, what's bad, um, how do you mitigate against it in real time naturally.

And then ultimately, how do I start to build a trending view into what, what did I see a week ago versus where am I going, you know, in the next, in the next few weeks, Right? Folks, you heard in here, it's a never ending battle and the tactics and the techniques used by the bad guys continue to evolve. So, so do we.

And if we don't, bad things are gonna happen. Christian, thanks for being on the show. Thanks for having me, Michael.

All right, and back to you guys in the studio. Hey everyone, it's Alan Shimmel here for another Shimmy says, you know, I love doing these, shimmy says, to tell you the truth, it's kind of cathartic. But, um, this week I want to talk to you about tariffs and tech.

Lot of talk going on about tariffs. We're taring here in the US our three biggest trade partners probably, and, uh, talk of trade wars and, and retaliatory measures and all kinds of stuff going on. We could talk into about it at the macro level, but I want to talk to you today about what effect these tariffs are gonna have on our tech market.

You know, the tech market's been quite frankly, shaky since the end of Covid. We've had so many layoffs, more layoffs than many of us remember in the tech space. A lot of it is the result of hiring binges during Covid where we probably overhired and things now have kind of evened out.

But what effect will these tariffs or could they potentially have on the tech market? I think if we look at it, we gotta start at the semiconductor market because so much of tech starts at the semicon, you know, revolves around the, the hardware and the, the chips that are running all this software and AI and everything we're doing. And let's be clear, 80 to 90% of the semiconductors that we use in the US come from Taiwan and t uh, China and Taiwan.

Now, I know I, last week I talked about $2 trillion and President Biden had this chips act where they had hundreds of billions of dollars set aside. But the fact is, as we stand today, we don't have a big capacity to produce these chips here in the us And to build that kind of capacity is gonna take a minimum of three to five years. And quite frankly, we've never produced that quality and quantity of chip here in the us.

It three to five years is the minimum. We may find that it takes retraining an entire workforce or doing something pretty drastic. So what do we do for three to five years?

Are we at the mercy of these tariffs and the 20 to 25% cost that may be involved in, in, in importing them. That's anyone's guess. But to think that this is gonna force us to use us made semiconductors.

Yeah, it might, but we've got a five year gap to, to fill in there in the meantime. Um, what, what does it mean for the other tech industries? Well, first of all, let's remember how much of our technology, you know, revolves around those semiconductors, those servers.

What's it, what's cloud cost gonna be when they gotta pay more for their, for their hardware, data center costs, AI costs everything. You know, all this money pouring into ai, we're going to need it if it's 20 to 25% more. So, you know, the, the, the cost of the basic semiconductor, it ripples through the entire tech sphere.

But forget semiconductors even for a second. What about other materials that go into computers, other services, rare earths and minerals and so forth, that you need raw materials, right? We get a lot of raw materials from Canada that's gonna cost more energy.

We actually, though we're kind of energy independent in the amount of energy we produce here in the us, we actually do share energy grid with Canada. What is, what is that gonna mean? Um, it, it's, you know, it, it's a ripple through the entire tech sector.

On top of that though, there's, there's other, there's other macro conditions to worry about. If car manufacturing slows down because of tariffs or, uh, uh, other imported kind of goods slowed down, and it slows down the economy, inflation goes up, interest rates go up, people stop buying less tech. Again, that's gonna have a very, very chilling effect on, on the tech sector.

So our domestic tech economy, and, and, and, you know, tech has become a big chunk of our economy is, is at the mercy of these tariffs, at least for the short term of three to five years. Now, on top of that, there's another aspect we've gotta think about, and that is, what about when countries retaliate against us for our tariffs by raising their own tariffs? So now all of a sudden it becomes much harder to sell US technology in Europe and China and India and Taiwan and Canada and Mexico.

I will tell you that most tech companies, at least 40% of their business is international non-US. If, if countries reciprocate against our tariffs by having tariffs of their own, you are talking about, all of a sudden it becomes really hard for us tech companies to sell their technology to foreign markets. And what does that mean for the tech sector?

What does that mean for the tech sector? Do we have tech companies move out of the US over it? Do we bifurcate tech companies and US based versus foreign based and split 'em up?

You know, how much money does a company like Apple or Meta or Google make from foreign markets? And, and, you know, those companies are ripe targets for countries and nation states that wanna reciprocate and retaliate against our own tariffs. I've always been a proponent of free trade.

I, I think I have a lot of faith in the American ingenuity, the American industrial engine, that given a level playing field, we could out innovate out produce and outcompete any competitors, or at least hold our own. At the very least, I'd like to see us make more level playing fields, not erect barriers and turn inward in some sort of isolationist stance, because it's not, it's not good for our tech SEC sector. It's not good for our economy as a whole.

It's not good for our nation as a whole. So I'm hoping that a lot of this ta tariff stuff winds up just becoming posturing for, for trade negotiations. But I fear, I fear it isn't.

And it could be we're in for some rough rides in the tech sector in the next three to five years, or at least until this administration's over and maybe some, some new kind of blood and new way of looking at global trade comes into power. That's it for this week, for Shimmy says, I hope you've enjoyed it. It's, uh, it's interesting times we live in.

com page doing the Textron Gang. So I look forward to seeing you then. But until then, this is Alan Hummel, we're out.

Hi, I'm Peter Smore and I will talk about agentic AI hype, or the way to unlock productivity gains in software engineering. Today you will learn about the path from AI assistance to agents we're look into use cases, maturity of agents and processes for using them to gain productivity in software engineering. Finally, we will dive into an example of how to use agents for unit test generation.

Some words about myself. I started my career as a software architect in the field of, uh, internet of things, IOT. Then I did a PhD in static analysis verification of embedded systems.

I then continued my research at, um, university of Oxford, became a lecture in computer science, and then, uh, co-founded the AI for codes of startup. And as a fun fact, I'm a keen back current here. So in the last couple of years, AI assistance gained widespread attention and many companies have rolled them out across the teams.

However, reports on productivity impacts have been mixed so far. 2025 could be the year of agent ai as assistance will evolve into agents able to reliable to perform large tasks on their own. Let's look at the common definition.

And AI agent is an autonomous intelligent system that performs tasks without human intervention. Well, we don't really know what intelligent exactly means. So the core of this definition is autonomous and human without human intervention.

So we'll see IT assistance and agents support different use cases. So assistance are useful in the course of the creative process of developing something. The usage is highly inactive and iterative in drafting solutions to small tasks.

Also, they don't really need to produce perfect results all the time because the user can immediately fix the output at at low cost. So, however, in uh, autonomous agents, they require a little to no induction. There's the scale to large tasks, which of course require them to be most more trustworthy for the outputs to be correct.

So we'll see that there is actually a continuum from assistance, uh, to agents. So the required level of precision depends on the use case. So sometimes good enough, it's 80%, sometimes it means a a hundred percent.

So if you want to have a fully autonomous AI agent, then it needs to be trusted a hundred percent of the time. Whereas an AI assistant can really deliver value when they are only right 80% of the time, or even less so. The car industry has experience in developing agent systems for a long time.

The Society of Automotive Engineers, SAE, has developed a maturity model for driving automation, which consists of six levels in levels zero to two. The user, which is the car driver, is in charge of driving the car and is assisted by various automation features in levels three to five. The user is not driving the car, but the car is actually driven by the AI system autonomously still at level three.

They system might ask the driver to jump in when it can't handle the situation. So this is my take on a maturity model for AI systems. We have a couple of levels, um, and we distinguish these levels based on properties such as TEX initiative, which kind of faster handled human action, whether the system has actually the authority to execute for real, um, the required accuracy and the ability to adapt and, uh, improve over time.

So level zero would be manual work. Then on level one, we have assistants on level two, we delegate work to an agent on these two levels. The initiative comes from the user, which is usually the case for doing some creative work.

So assistance is set, can handle small tasks, whereas to an agent that can delegate also larger pieces of work, the interaction with an assistant is in a tight, iterative, interactive loop. And since it's supervised by the user at all times, the required accuracy for the assistant is not too high. Of course, I'm going to be more productive with a more reliable agent.

The larger the piece of work delivered by an agent, the more expensive it is to understand and thoroughly check its output, amend and rework it manually. So generally, the more autonomous the agent, the higher the power for accuracy. Hence, already a delegative agent is required to be much more reliable than new system.

A delegated agent might also ask clearer questions about the task to the user, but such interactions need to be minimized because otherwise the productivity benefit is lost by constant context. Switching on the user side. On level three and form, we have agents that listen to the environment to take actions on their own, whereas the level three proactive agent may still ask questions to the user and require approval.

The level four autonomous agent doesn't require any interaction and can act without you. Unapproval, of course, to trust an agent with such permissions requires perfect accuracy. Maintenance tasks are typical examples for proactive agents where the agent identifies the needs to perform the task and delivers the results to the user for approval.

The accuracy bar for such unsolicited work is higher than in the delegation case because the user needs to be weakly convinced about the utility and the quality of the work, and has little motivation to rework the output. The right most column is traditional automation, and like we used, for example, in continuous integration and delivery systems of CICD. So traditional, uh, traditional automation is very similar to autonomous agents, but are dis is is distinguished by the nature of the tasks that it can handle, which is usually very well defined and and specific.

So the, uh, also the traditional automation is usually has no ability to automatically adapt and improve all the time. So the cost for adaption is expected to be much higher for such a traditional, uh, automation system. So why on, uh, autonom reliability so important for unleashing productivity gains?

So in this chart, we compare the difference in index when using an AI system to handle a certain task on the horizontal ask, uh, Xs, we have the time and the different, uh, colors, uh, distinguish different kinds of, uh, parts of the task that need to be done to achieve, uh, the task. For example, when I use an assistant, I need to first instruct tool, uh, what it needs to do. Then I wait a bit for to receive an output.

And if the result is not acceptable, then I have to rework and fix it and finally check and approve the work. So when I deliver a piece of work manually, then most all of the time is attended, which means a per person is actually sitting there and working towards delivering the task. So with an assistant, the work can potentially be achieved, uh, faster, but the way the work achieved is achieved is much, uh, is very different.

So it usually, uh, consists of multiple cycles of interactions with, uh, the tool. And, um, all this time is, again, is, is fully attended. So the advantage of using an agent is that a big portion of the time is actually unattended, which means I can go away, um, do some other work, uh, in the meanwhile.

But if the agent is unreliable and the work is is not acceptable, then I actually have to spend time in actually maybe reinst instructing the agent or even fully understanding the output and reworking it manually, which quickly results in the effort exceeding any productivity gains. However, with a reliable agent, uh, the attended time will be tiny and the productivity gains can be traumatic. So with an autonomous agents, the at attend time will even be zero.

So agents only yield, uh, or proportional productivity gains when handling rather large tasks and only unattended, asynchronous, uh, operation allows me to productively use the time while the tool is operating. So therefore detect actions must be minimal to avoid determin context switching, uh, to the user. So assistance speed up part of the work, but, and, but everything is fully attended.

So the productivity gains through agents depend on their reliability to produce accurate results, or in other words, how much rework is acceptable so that there is still a productivity increase. The larger the output produced, meaning the larger the task handled by the agent, the more expensive it is to fix incorrect output. So only a reliable agents yield actual consistent productivity gains.

However, assistance are already useful with lower accuracy because I can fix the output at low cost immediately, but the gains will also be not as big as for agents. So from what we have learned so far, there are two different effects on the productivity of software engineering that we need to understand. The first one is the so-called booster.

So let's take the example, uh, depicted in the upper half of this slide. So we need to fit, uh, three tasks, task, 1, 2, 3 into a a sprint with, um, bounded capacity, let's say two weeks. So here, task three doesn't fit in on the sprint, so we, we can't deliver it.

However, if we have an, uh, automation booster, it'll shorten the delivery times for each of the tasks and we can actually fit it. So the booster helps us to deliver tasks by increasing, uh, velocity. So another scenario is shown in the lower half.

So here again, we need to fit three tasks. Task one and two have high priority, and task three has lower priority and is also quite large. So typically such task will, um, never be deliberate because it, they higher priority tasks will always take precedence.

So to deliver such a task, we we need an enabler to, uh, and which yeah, uh, which allows us to shrink task three to a reasonable size and fit it into the sprint and, and get it done. So, difficult example for such tasks like task three are, um, take debt or cleaning up or modernizing the code base. Such tasks will always take a backseat in comparison to features that deliver immediate value to customers.

So having an enabler to tackle such tasks not only allow us to, to get them done, but also gives a secondary boost to delivery of, uh, actual customer features. So next, let's have a look at where there are automation use cases in the software development lifecycle. This table shows various stages of the lifecycle from requirements analysis to maintenance and and modernization.

So requirements analysis and validation are the hardest to fully automate because they require talking to the users together with design and planning. They are at the core of the creative process requiring a lot of human intervention interaction and integration. So however, we can already see tools emerging there that, for example, produce mockups of user interfaces based on requirements then build integration delivery and deployment are already fully automated because they were the target of traditional automation endeavors through CICD pipelines.

Currently, the hottest area that receives most attention is implementation. So you already have level one assistance there, like GitHub Coot, for example. And we are seeing the emergence of level two delegative agents.

These agents are not as mature and can only handle smaller well-defined tasks. Uh, at the moment, use cases in other areas are more mature. For example, in the area of of unit testing, there are proactive agents such as deep blue cover that automatically write tests on polygraphs and where they see need.

Also for UI testing, there are agents such as fix AI that can automatically walk through user interface and find bug automatically. Kelly, similar, there are tools that can, uh, automatically pinpoint root causes of system fails in production. And there are tools that can perform complex maintenance tasks as automatically upgrading software depend is keeping the curb base brain removing cold smells and fixing security vulnerabilities.

Today, none of these tools are really deployed in a fully autonomous way, in the sense that they still require human approval to merge code into production. So gaining the necessary trust into this system takes some time, even if they're already operating at a very high, uh, at very high accuracy levels. So, for example, the use case of view inter generation for legacy systems can be considered level four autonomous, but enterprise company processes still require code to pass through review versus and approvals.

Uh, today in the last part of this talk, let's talk, let's a look at, uh, agents for Writing Unit. So I've identified here three use cases where we need to write unit tests. In the first one, we have a untested code base, typically legacy based copays where we, the task is to write a regression unit test suite so that we can then make changes with, uh, more confidence.

The problem is that this is usually a multi-person new project and doesn't have high priority because it doesn't really solve in the immediate, uh, customer problem. The solution is here, uh, to have an inhaler that tackle this problem like a level two or three or four agents, such as deep blue cover that can write the required, uh, tests fully automatically at scale, shrinking and mountable task inter effectively and brainer. The second use case here is writing new code for a feature where I need tests to check whether my implementation works fine.

So writing this test is not the most insurable task for developers and slows down the delivery of the feature here. A level one assistant can give us a boost. GitHub cover lot can do this, for example, but also the, uh, difficult cover intelligent login helps me.

The first case is continuous testing, where the goal is to maintain the level of testing of a code base. This involves fixing tests that start breaking, making sure the tests are written for all the code changes that make the way into the code base. The problems we are facing here are the, the lack of team discipline and also slowdowns in, uh, feature delivery.

Here, a level three agent such as deep blue power can help to maintain the test automatically, uh, within the continuous integration system. So we conducted a study to compare coding assistance, uh, with agents. So you can think of that like a race between a assistant enhanced experienced developer and an autonomous agent to a unit tests for 20,000 lines of code within an available time box of 260 minutes.

At the end of this time, the autonomous agent in this case, D Blue cover, was able to achieve a coverage of 53%, whereas the GitHub co coot enhanced, uh, developer only achieved uh, 15%. The main difference though is that the, uh, developer had to work hard for the whole time period, whereas the agent ran completely unattended and the developer could spend the time working on something else or just go for lunch on the business Logic code for which, uh, tests were written. The test quality measured by coverage and test strength was about the same.

The difference though, is that, uh, the, um, agent was, uh, completely unattended. What makes this huge productivity differences happen is the higher reliability and accuracy 100% for the agent, versus 64% for the assistant, which then internally reduces the time in spent in injecting with the tool in the reworking the results that they tool produce. So in the case of the agent here, no human induction is required apart from a few seconds for kicking off the tool.

This also allows for higher scale scalability. 4 million lines of code in a whole year, provided that they don't quit before that because of they sold this drawing drudgery that is involved in this task. And agent in contrast can write tests for 25 million lines per year on a single laptop.

And it is also cheap to scale up even further for ation because it's just compute. So, whereas with a coding assistant, one would require to use more expensive engineering stuff to scale. To summarize the takeaways of this, uh, talk.

So agents and assistants are already part of the engineer landscape today. Reliability and accuracy are crucial for smooth interactions and through productivity gains come ultimately from such reliable autonomous agents. And unit testing is the most advanced use case on the agent material scale.

And if you're interested in the diff blue cover tool that I mentioned, we have recently released a developer edition for which you get a 50% uh, discount with this discount code. So thanks for your attention. Hey everyone, welcome to DevOps Unbound.

I'm Alan Shimel, CEO and founder of, uh, tech Strong Group. And DevOps Unbound is a, uh, semi-monthly, which means it's twice a month, I think, uh, video series that we've been doing that for about three years, and we explore every nook and cranny of the DevOps universe. Um, for three years we've been producing and putting on this show in partnership with our good friends at t Tricentis, who I couldn't think of a better partner and a partner on this kind of thing, where they, if you're not familiar with Tricentis worldwide leader in continuous testing and so much more today.

Um, and as I said, we do these shows twice a month and then maybe once a month or once every month and a half, we do what we call a live round table version of these shows where we invite you, our studio audience to come in and participate and kinda lead the discussion. Unfortunately, this is not a live one. This, this is a, a prerecorded version that we did here at Tech Trunk Studios.

But, um, you should pay attention. Well, we'll, if you ever go to Tech Trunk TV and you can see the schedules of our live events of, of these, and we'd love to see you at the next live round table. We do actually, Mitch, while I'm talking, maybe if you can grab a, a time and date and when I come to you, you can even we'll do that, put a little plug in.

But, um, before we come to Mitch though, besides thanking Chiantis, I want to introduce what this particular episode is about and introduce our panel. Today's episode is API first and API testing. We're going to explore all things around API here.

You know, API traffic represents the majority of the traffic on the internet. I've seen numbers as high as 83%, which is the last one that came out of Akamai. Uh, I've seen Cloud flare.

I think they had it around 70%. So no matter whose statistic you go with, it's still a majority of the traffic on the internet. Um, we're gonna talk about, you know, API first development, and we are gonna talk about, um, API testing and, and more.

Um, our Cracker Jack production team has already gotten me the date of for our next live round table. And if you're interested in attending this market calendars now, it's on July 24th at 11:00 AM and we're gonna be talking about adopting a DevOps culture for cloud migration success. Is there such a thing as cloud migration success?

We'll talk about that July 24th. Let's stick to APIs today. Um, for now though, let me introduce to you our, our panel.

Um, first I wonder, well, he's a, a repeat meaning he's been here before with us. I want introduce you to Chris Kmo. I hope I pronounced that right, Chris, Chris, tell tell our audience a little bit about yourself, if you don't mind.

Thanks Ellen. Yeah, so I'm Chris Kmo. Um, for the last 12 years I've been working specifically in the API testing and service virtualization space.

Um, joined the Tricentis team recently, kind of tasked with the responsibility of uplifting and modernizing some of the service virtualization, uh, tooling. Um, and as a natural part of that, there's, uh, some API testing, uh, pieces of it. But I've been kind of enjoying that and having fun, imagining what this tooling could look like if we started from fresh.

So happy to be here. Uh, happy to have you on Chris. Thanks, and welcome back.

Next up the kind of queen of the ball here. She, you know what, I, I just feel like she should move to Florida already. Um, our good friend Tracy Reagan, who's also a CEO of Deploy hub and many other things.

Tracy, why don't you introduce yourself? Well, Alan, thank you for having me here. I always enjoy this.

It's, I feel like I should have a PhD though on some of the topics that you bring me in on. Oh, what we do about sometimes, Sometimes I've kind of blown, I blow myself away by understanding more than I realized, I guess. I've been in this business for quite some time, to be quite honest.

Um, I started at, as a programmer on Wall Street, started a company called Open Make Software at Automated Build. And now I am the, um, CEO of Deploy hub, and we're doing an evidence store around security and DevOps data. I've been involved in the Eclipse Foundation, the open SSF, um, and the, the Continuous Delivery Foundation, and have embraced open source for quite some time and have some opinions on API first.

And so I'm happy to talk about it. Doesn't surprise me. You have some opinions.

Tracy. Thanks and, and welcome. Our third panel member is Chris Lindsay, and this is Chris's first time.

I haven't yet told him of what first time guests have to do when they first come on here, but we'll, we'll tell him in a little bit. Hey, Chris, welcome. Introduce yourself to the audience, Alan.

Thank you for having me. My name is Chris Lindsay. I am an application security evangelist over at Mend.

My job is just to talk about application security in general. My history, I wrote software for 35 years, so been there and done it in the trenches and APIs are near and dear to me, and I've been in security for over 15 and plus. So thank you.

Good and welcome. Always nice working with the folks at Men. Um, our last panel, well, he's not really a panel member, but our last person that we're gonna introduce is my co-host for DevOps on Bound.

He's our CPO here at Textron. He's also a CTA for Futurum Group, which is a company we are in the process of combining with. Mitchell can explain what the CTA role is, but let me introduce you to Mitchell.

Ashley Mitchell. Take it. Good to be here, Alan, and what a, what a group.

Um, what a fantastic group. Yeah, I'll, I'll be your panelist. I'll be your co-host.

I'll be the the chat guy. I'll be the bottle. Watch, whatever you need me to be, Alan.

I'll be So no. Just recently, as part of our, um, acquisition process with Futurum, my role's expanded in addition to the doing the analyst work that I was doing with Textron Research. It's, uh, I have a new, you know, we have to create a new, new title, right?

But I'm one of, uh, five people that are Chief Technology Advisors, which is kind of a, a glorified analyst on steroids doing advisory work and analyst work and, and things like that. So it's, it's a lot of fun that, that, uh, being part of the acquisition and, you know, still both, still working with all my old friends as well as new friends. So it's good to be here with everybody.

And yes, I started as a developer and yes, I've designed some really bad I APIs and a few good ones. So we have some lessons that, that I can bring Learned more on the, on the bad ones. But anyway, um, thanks Mitch.

And welcome. So, as I mentioned, API traffic today represents a clear majority, if not a critical mass of traffic on the internet. And I'm gonna ask someone to explain what that means to the lay folks out there who may not, we don't have that many late folks, but people who may not understand I'm not, it's, it's either API generated or API to API kind of thing, or, or, you know, somewhere along the line there's an API involvement there, that traffic.

Um, but, you know, the effect that an API first mentality has had on the development process in general on testing and security in particular is, has been pretty profound, right? I remember the first time, like this whole thing became clear to me. I had that eureka sort of moment.

I was at a CA world, so I should give you an idea of how long ago this was. Um, and, and, uh, they had done an acquisition, a company based in Texas, and the folks from that got up and said, you know, it's an API driven economy. And I was like, wow, an API driven economy.

What, what the heck did that mean? And I, you know, I I, I learned more and I, I dove in with it and I realized it was an API, you know, we were moving into an API driven economy when we talk about, you know, digital transformations and, and stuff like that. And, you know, I think the next logical extension to that was API first, right?

That's the default. And, and of following from that, of course, you, you, if you're gonna have that kind of API footprint, you damn well better be doing API testing, right? To make sure this stuff works and make sure, and then in the last four, five years, API security has become paramount in many ways, right?

API security is replacing web application firewalls and stuff like that because WAFs, that API traffic kind of flows under the radar of the wa right? And so we need something else to kind of make sure our APIs are secure and locked down enough to make your head spin. Um, Chris C, if it's okay, right, we'll say Chris C and Chris l Chris C why don't you take a crack at explaining in your mind what API first means when we, when we use it in this context.

Absolutely. And, you know, um, to get there, I think I wanna talk, I wanna touch a little bit on that API economy, because that's really like, first and foremost for me, what's driving the API first initiative and just, uh, unironically About an hour ago, I was just talking with ESRI, um, they're the guys that do a lot of the map, the MAP APIs. Mm-hmm.

Um, they were kind of behind MapQuest back in the day, and I was talking to the guy and he was saying that before that, way before that they were the ones that powered the Thomas guides. You remember those things that were under your sheet Sure. In your Car, right?

Mm-hmm. We were a logistics company, right? We, we, we, we had a database full of rich maps that we would then compile into a book, and we were a logistics company, let's ship them.

And then eventually, at some point, that just went away. And now they are an API first company. They sell their API to Google Maps and to Apple Maps.

And so their entire economy is based around their map, API. Mm-hmm. And so, uh, to me, that's what the API economy really means is, is it build businesses are building their brands.

And a lot of what's powering that is the API. And if that is the critical path to your business, you really have to have an API first mentality when it comes to building them, securing them, testing them, validating them, and really most importantly, securing them. And so that's to me, what API first kind of means.

Jump panel on that jump go. If I can jump, I'm gonna jump in on that too. I love how you set it up, Christie.

Um, because you think about it, historically, APIs were the things you might add for the exterior of your application or your software to kind of the ingress and egress. But everything inside of it was your app, right? And, and API IAPI first is just the opposite.

Your app is all run through APIs. Even if you don't have a gui, you UI use your interface. Um, and matter of fact, if you do have a u ui, the UI talks APIs to your app.

So the same APIs that you might share with, um, providers or people that are buying your service, matter of fact, your service may be just the APIs like Chris is talking about. Um, and in doing that, I remember APIs just getting kind of unwieldy and getting outta control just 'cause we added them where we needed 'em here. And how long are they gonna be good and do, do, do we, as they evolved, how do we grandfather old versions of 'em?

And now we have whole philosophies around the lifecycle A of APIs and how you manage them. And they're, they think of, we think of APIs as the product because almost all, every app now is exposing those APIs either in a, in a microservices world, very heavily API or, or also to the external world, to people that are buying our products and services. So I, I hope that does justice to what you were talking about, Christy.

And while you know that, um, there are, I mean, companies do rely on external APIs. I, if I'm thinking about what our architecture looks like, we probably have 20% or 25, maybe 30% of external APIs. But most of what we do is internal APIs and building internal APIs has a, you know, there is some, um, and when I think of API first, I think about what APIs do we need, let's think about what that looks like.

And I like to refer to, uh, you know, I preach often this concept of domain driven design and understanding what are your domains? What APIs do you need? What are the, you know, what are the, uh, what are the connection points?

What does that need to look like before you ever start writing an application? But for the most part, we, you know, to, to be quite honest, this is not a new, um, concept. We tried to do this in, um, c plus plus and common libraries.

A lot of companies, uh, when I was working for Discover Card, we did a ton of work around initially defining what that com, those common libraries should be, should look like. And that's really what APIs are. They're common libraries, what we can reuse.

And really taking the time to understand what those high level domains are and what we need to create is super critical in building a, um, a true kind of API burst forward thinking model. And that's because if you don't do that, and if you don't manage them well, and you don't communicate and collaborate, well, everybody's writes their own APIs to do the same thing. Mm-hmm.

And that's what we don't there, and that's what generally happens. And we've done, we've made this mistake as developers over and over and over. We constantly make this mistake, you know, everybody has their own login routine.

Everybody has their own error routine processing. Everybody has their own access to get the customer address. Um, so understanding domains and understanding how APIs should be structured within your organization and how you can break it out and allow ownership of certain domains is critical to an AP API first, um, architecture.

I agree. I, yes. So, you know, the other thing I want to just tack onto it is, you know, what, what are your APIs doing?

What, what's the purpose? And in the old days, you would just write your software. You would be in a ui, you would be, you know, either, you know, web-based, where everything's all self-contained, and then you started pulling apart doing the APIs to now when you're developing software, you're thinking about it, there's multiple facets You have to think about, are you gonna expose any aspect of it for reporting or part, uh, you know, business to business or, uh, you know, are you gonna be consumed by other tools internally, um, for, for any reason?

Or, you know, what's the UI gonna be? The UI In today's world, when you're, when you're thinking of an application, if you're thinking of just web, you're, you're being very shortsighted. Do you wanna go web-based?

Do you want to go mobile based or, you know, other technologies out there? And as, as Chris said, you know, talking about, you know, you may have an application that is nothing pure, but pure a, a, you know, APIs. And that's okay because it, again, it's, you know, just, it's all about the usage and what you're actually trying to accomplish.

Agreed. You know, when when I hear API first, to me, there's sort of a chicken in the egg question there, right? What comes before the API or is the API the first the chicken and no, it's not the chicken.

I think first before you, you don't start with the API first. You start with sort of plan of, Hey, I, I want an application that does this, that, or this and this, right? And then we think about, okay, how am I gonna go about doing that, right?

So I, I think the, the planning and, you know, laying out storyboarding if you will, or, uh, designing of the app is, is first. But certainly once we get into that design, we start thinking about APIs and potential APIs, I think before we start coding, certainly. Would you agree that, that that is the essence of API first, right?

Before we even start coding, we're thinking about how APIs are going to make or break or how they're gonna work within the app that we're designing. Yeah. Because that, that's how APIs are gonna pay for themselves.

You know, me as a young developer, I would've loved to had, you know, been a, you know, we talk about feature teams now or you know, instead of application teams, you have feature teams. Well, me as a feature team working on a particular, what would be delivered as an application, I get to go talk to other teams that are doing features, which means I don't have to write all those queries. I can figure out what they already have, if it's a well organized API structure and everybody can share those APIs.

So that pace is for itself. It's, you know, APIs can save a whole lot of cash when it comes to development because you're reusing objects. So a hundred percent.

And it's has to do with money too. Yeah. Yeah, it does do that.

If I could tell on that, what's just, just because the plan triggers me, right? Is it immediately makes me go to the service definition, which I'm sure a lot of the season guys here are gonna roll their eyes, right? Mm-hmm.

The service definition is not a plan, but a lot of organizations say, this is the beginning of the process, right? Let's, let's write our service definition. Let's write our contracts, let's start putting in place the actual semantics of what this API is going to do.

And what's interesting, if I kind of double click on what Tracy was saying about the domain and specifically what Mitch was saying about sprawl, this creates a problem because you're not doing that upfront ideation work to say, what is the minimum set of APIs that we need in order to provide the value that will ultimately provide the money to our organization? And this leads to something which I'm seeing a ton right now, which is API and new API is the answer to everything. Alright?

Okay, we got this new functionality, let's just add another API, let's add another API, and before you know it, you have this massive API sprawl. And so I really do think coming back to the domain of and the why and the, and, and, and the, the minimum set is super critical to this, to the planning phase before the service definition is even put in place. So you're saying we can replace the phrase, there's an app for that, that to, there's an API for that.

There's an a P for that. Yeah. Yeah.

Well, you know, and, and Chris, the thing that comes to mind when you were talking about that is solid programming principles, right? So, you know, when you create a class, you create a method. The goal is I've created it, I can add to it, but I cannot change it.

And when you look at APIs, you know, you may run into, I need a little bit more or a little bit changed or a little bit something. 2, you know, and and so on and so forth. And then all of a sudden, you know, to to everybody's comment here, all of a sudden you may have started off with, you know, 150, 200 API endpoints and now you're well over a thousand.

Yeah, Absolutely. So I mean, it really, APIs, even though they save a lot, um, like microservices, it's complex 'cause you're decoupling pieces. And when you decouple pieces, you cram, you know, it's your, your puzzle now is in, you don't have, you don't have the top of the box to tell you what that puzzle's supposed to be.

And you have all these components, all these tiny puddles of pieces laying on the, you know, on the table and you gotta figure out what it is that you're creating. So you don't Have this when the blast radius gets really large Tracy, Right? Yes It does.

Okay. Blast radius. Here we go.

Um, But that's an interesting, that's an interesting aspect too, right? And it becomes that yes, I have this giant inventory of APIs and I may want to Chris's point, sort of just add incremental functionality to it and, and change its version number. But in a lot of cases, the APIs are used by disparate teams.

And so they might not know, uh, the, the major difference between the UI and the, and the APIs. The UIs are designed to explicitly tell you what it's doing. You go to the screen, you get it, okay, I'm logging in, I'm creating an account.

APIs will do the same thing, but they're not explicit. And unless you love reading swagger definitions, you can't immediately know what an API is doing. And so that's where that, I think a part of that sprawl comes through is people go, Hey, I don't think this functionality exists.

It's like, well, actually yes it is. It's a subset of this other API that. And, and so I think this is one of the challenges that I think the contracts and service definitions and definitely to trace, uh, to Tracy's point, the, the conversationing around what exactly are these APIs for becomes paramount to an organization's API success, Right?

Well, and as an API matures, then what happens too, just like you were saying, you may have certain aspects of multiple pieces of APIs, Hey, to accomplish this task, I have to hit seven different APIs to get all the data. And one API may take forever to run, and I just need one aspect of its data. However, a lot of it is actually tied to the same background or, you know, the backend.

And so instead, maybe I just create a new endpoint to pull what I need. And the next thing you know, again, sprawl And it's a collaboration that will prevent the sprawl. Yes.

You have to have the collaboration. You have to be, if you don't know an API exists. And, and there's no way to find out.

You're gonna write it yourself. 'cause you might go, this is gonna take me, oh, it'll take, it'll take me 30 minutes to write it, even though that's not true. We do that as opposed to go hunt down somebody who's already written one.

So the collaboration is essential just, um, across teams, much less really building out a collaborative API structure. Couple things there. First of all, I think that was job one.

Um, in the API security arms race, when API security started becoming a thing. I think the first thing these API security solutions were doing was say you, it's 10 o'clock. Do you know what APIs you have?

Right? Because, you know, they, a p sprawl gave us so many APIs and APIs, talking APIs, talking APIs that most organizations really did not have a handle on what APIs were interacting in, in and within their system or on their system. And let alone what their settings were, their security posture, et cetera.

You can't defend what you don't even know is there. Mm-hmm. And that, that was, you know, that was phase one of API security.

I think it's expanded beyond that. It's matured. But that was certainly the first, the first, you know, kind of thing about it.

Um, the, the first part of of, of API security, I wanna turn, you know, beyond the blast radius of API security of API first Talk about API testing. Right? Because, you know, that's the logical next step.

Okay? So now we are going with an API first mentality. We're gonna have these a APIs that are, you know, in, in the right from the, from the design phase, we, we are designing APIs in.

But of course these APIs need to be tested, don't they? Um, you hope. And so you have to get into API testing, but yet I, when I hear the phrase API testing, I still think of, oh, I'm using APIs to do my testing, right?

I, it, it, it sort of adds a layer of automation to my testing. But no, that's not really what I think we're talking about. Chris.

Yeah, I think most, Oh, go ahead. Oh, I'm sorry, chase. No, no, go Chase.

I was, I was just gonna say, I think when we talk about API testing from a developer's perspective, I think about functional testing and validation testing. I don't worry about performance testing or security testing or load balancing or any of those other pieces. I assume somebody's Gonna automate that.

Like developer. That's, That's what we do, right? I wanna validate my endpoints.

I'm gonna do my functional testing if that's good. I'm going that Security testing. Yeah.

Um, Chris, Chris LI I'm hoping you have a different attitude towards it. I do. I'm Sorry, Tracy.

It's okay. My attitude is, you know, it's, it's a view into your system and as such, you need to do multiple things. You know, I, I go to conferences, I see applications, I talk to people I, I with, with penetration testing software.

I enjoy going out and attacking and breaking things. I love seeing, you know, what kind of data I can get back. You know, some systems, you know, you can ea easily break simply because improper security, improper logging and proper a lot of things.

And so when, when you're looking at APIs from, you know, a, a a standpoint, there's multiple aspects that you have to consider. You know, the, you know, how does it perform? Because I can come in and do a denial of service attack.

If you have a poor performing, performing a PII can call it multiple times from thousands of endpoint simultaneously, if you have an API endpoint that shares data that it shouldn't be sharing, now I can steal data. If you have an API endpoint that is just not well put together, it it, it's very obvious from a security standpoint. And so whenever I was actually doing my, my development days and doing senior tech reviews, I would look at, you know, how do they perform?

I would look at using tools to look at the payload as it goes in, as it comes out, what kind of things, time to run the time on the backend, on, on the database, it all the way down to that level just to ensure that, you know, is this performing? Is it doing what it has? And then beyond that, you know, you also have the security things that you can throw in there, such as SQL injection and, and other various things that can, that can happen.

I'll stop. I can keep going, but No, I get it. Chris c you're the real tester here.

What do you think? Okay, first off, I'm in the vendor space, right? And so nobody knows less about testing than the actual testing vendors.

But I will say this, um, I, I am encouraged that we're talking about development forward API testing. Because quite often in the testing industry, that's put firmly on qa. And there's these really interesting conversations.

Whenever we go to a, a first time API tester where they go, well, whose responsibility is it? Is it, is it the developer? Is it the tester?

Now we all know it's both, but it's at a spectrum. And the notion is that, hey, I'm a developer. I created a service definition.

I should be able to hand that to the, to the tester. They should be able to ingest that and use it. And the tester says, Hey, you're a developer.

You're building the API, you should test it before you give it to me. And there's this constant back and forth. And I think to both Tracy and Chris's points, there's different levels of testing that you do as it's maturing through the cycle.

And the, and the first one to me is contract testing, right? I wanna make sure that my service that I'm building is not only complying to my business expectations that I've set forth for the, for the function of this API, but also that the consumers of IT are not going to be affected if I change it. Right?

And so, I don't know if anybody's really, um, uh, grasped onto, um, uh, uh, uh, contract testing quite like some companies like PACT have, but it's this, it's this really strong grassroots movement that's happening right now 'cause it's developer forward that basically says, I'm only gonna write into this test from a development coded perspective that are my expectations of an API. That way I can continue to do what I'm doing and know that if the producer of the API makes a change, they're gonna run my contract and know that they've broken me, which fosters collaboration and communication. Those contracts are the seed for everything.

Because you can mature those into greater and greater levels of more complicated functional and integration testing. And then once you have all of those contracts, you have all the attack vectors that you need for your security testing. So I really think that this whole testing thing starts from the moment that first line of code is written against a contract, write the contract.

But again, it's all predicated on whether the service definition exists. Isn't, isn't also, 'cause I remember us using kind of contract with APIs in a little more general way before this, this movement you're talking about. And really a contract in that sense was here's how you use the API, here's the, here's the expected behavior in terms of how you interface with it, and here's the expected behaviors of what it's going to do when you use it in the specified ways.

And I think to your point is if you go wacky and do some SQL ingestion or you do something else and pass different parameters that aren't part of the API, it's not gonna respond or it's gonna give you an error or some, some definition that's out, out of bounds of the contract, is that still consistent with the movement you're talking the developer forward? I, yes. The contract is, um, again, it's an overloaded term as are many things in our industry, but it, to me, the contract of the API is the service definition that defines semantically and logically what this API is supposed to do.

And you can use that both as a human document to read, to understand, but probably more handing it to the business to to, to the, uh, to the appliance so that it can ingest it and create clients to actually communicate with the API. Um, that same, that contract needs to be tested. Is it semantically valid?

Does it, does it follow all of the, the, the spec definitions that we have for service definitions? Has it changed recently, et cetera, et cetera. Um, and then that, that component is then used to test the function of the API in its entirety.

This is a, this is a, a, a second piece to that, which is I'm using the API in a very specific way, and I have complied to the service definition. I'm doing everything right. I wanna know if anything has changed, um, or if what I'm trying to do and what's critical to my business.

I'm Bank of America, I'm communicating with a PayPal, API, I'm only using like three fields of it. Don't change those three fields and do whatever you want with it, as long as you don't change those three fields. And if you do change those three fields, you gotta talk to me and say, I'm changing the three fields.

What can we do about it? What can we do about it? That's the, that's the difference between those two types of testing.

And there's something that happens when APIs aren't really tested well. Um, there is a trust factor that we have to always keep in mind if you're an API developer, uh, to make sure that you're doing that testing and that you're maintaining those contracts. Because what happens is, in that example that Chris just gave, that consumer may decide not to take on that new version of an API and that causes a DevOps nightmare called Drift, which means you have multiple versions of your API that are out in the world or being consumed internally by many different application teams that you have to support, maintain, and make sure are secure.

So the API testing if is so critical in building that trust so you don't end up with so much drift. You know, we talked about sprawl, sprawls a problem, but drift is as big a problem, if not bigger, when it comes to trying to secure the, the, the environment, right? And then one of the things that I've seen is a lot of QA departments use automated, uh, regression tools and their thought is, Hey, my, my tool passed it regression tested.

That must mean the APIs are good. Let's move on and let's, let's, let's, you know, consider it good. And to both Chris and, and Tracy, you know, their point is, look, the contracts possibly could change internally, something could get added, modified a a definition may change.

0 and now you're version 30 and you can't get off of it. And by default, most people who are writing APIs are not logging or doing any metrics. And when you're not doing any metrics, you're not knowing what API endpoints are being used, how they're being used.

You don't know the details. And so the problem becomes, you know, you're sitting there, you're creating drift sprawl, and, and you don't know that, hey, guess what? Version one is still being used, but versions two through 15 aren't and haven't been for a given time.

And so those could be deprecated. So instead at c at a certain point, depending on design and what's going on, you may have to go make 30, 40, 50 changes, you know, spread that same change out across all the API endpoints where if you were paying attention and, and doing good development practices and, and, and analytics would tell you, Hey, you know, you have people that aren't moving off version one, why? Ask the why, what's going on there?

And then determine, you know, can, can they move up? Or is it just a, a breaking code change for them? And if it is, you know, how do you deal with that and, and how do you work with that?

Because at a certain point you need to move forward. So, but this, this is, this is a bigger problem. You're touching on Chris, right?

This, this is the, the sprawl aspect of it. We see cloud sprawl, API sprawl, you know, our old, the developers and it people hoarders at their core, maybe because none of us seem to want to delete anything. Me, I, I find a certain joy in like cleaning out my closet and throwing out things that, you know, I have a rule in the house.

If it hasn't been used in the last year and a half, we're probably not gonna use it. There's better things to do with that space. Do we need to, and that's, by the way, that's something we could automate with APIs.

And if that forces people to move off of version one to version five because they've been sleeping through the last four upgrades, or refuse to do it, so be it. Right? Apple people used to knock Apple for that because they did, they stopped with the backwards compatibility for five years old software.

If you didn't have the last version or two back with you, you couldn't run the latest stop. Mm-hmm. You know, Microsoft stuck to that backwards compatibility thing for too long, in my opinion.

Should we? Is good API hygiene meaning adopt something like that. Wow.

That's a, a cultural shift. Because I do think that, uh, developers tend to be a bit order as you explain. Yes.

Mm-hmm. I mean, think about even, um, building a cont a container for an API, you're probably gonna bring in stuff that you don't even need because you don't, you're not sure if there's a dependency on it. Um, which is part of the, our current security problems, um, is these transit of dependencies and what APIs calls what API, uh, becomes more of an issue.

So it would be hard to get folks to start really cleaning house. I think You buy SBUs, you, you mentioned that's SBUs. I was not gonna say US bombs, but, Well, no, we're not Anything bombs.

Okay. But I do think that AI could help solve our blast radius. Okay.

Blast radius. It is. So we're talking about blast radius.

So we could use AI to do that. We could use AI to limit the blast radius. But shouldn't we use AI to just limit API Sprawl And drift?

Yes. And drift. I mean, it's good security, I think.

Well, and AI is doing so many amazing things today. You know, from a standpoint when you're looking at using AI against your APIs, you know, it now creates a lot of, you know, background. It, it gives you a lot of visibility in the things that you didn't have before.

It makes it so much easier to, you know, to connect, to get that information, to know what's happening behind the scenes, and to be able to detect anomalies. You know, you may be up and running and, and AI can go, Hey, guess what? I'm noticing something interesting.

Or, you know, if you are doing logging or whatever, AI can also pick, you know, pinpoint and go, Hey, wait a second. Something's happening. Tracy, you know, she, she lives here.

And somewhere on the other side of the globe, Tracy logged in again. Problem. You know, I wanna, I wanna bring up Alan.

Is there, there's also kind of some, we're talking about some challenges with managing this whole ecosystem, right? Of APIs. One of the thing that I think's really great about APIs, Tracy, you were talking about c plus plus remembering back in the day of, of stubbing, uh, stubbing off methods.

You know, we would like, here's the structure and I don't have time to write that yet, so I'll just put a return in there and pass some data back. And, and, and now we have such a better way of not just stubbing, but actually creating the API creating some logic behind it. We can have, you know, some tests actually built into that code that isn't fully been written there yet.

Um, but maybe it's generating responses, right? That we wanna to, uh, be able to test with as part of that API as well as we add the, the function, the service of what it is. And so you can, I think you can build software faster through this API first approach.

Um, 'cause you're not managing a big structure, you know, a big object structure with parts stubbed out and some parts not. And who's got what part of that tree? And I'm using this version of this microservice, this, this API and it's, it is, it's just stu there, it's great for building and testing and I'm gonna replace it with the, with, uh, Chris's, whichever Chris wrote it, Chris CL.

And, uh, you know, I can continue to just evolve the app that way. Agree. Don't agree.

Am I, I agree. Fun doing funny stuff in Colorado. Or I Gotta, I gotta jump in here.

Like, one of the things I said at the beginning with my introduction was that I, I, I am over two products, right? API testing and service virtualization. I don't get to say this very often, but service virtualization doesn't get the love that it needs, um, in our space.

And I think that from an API first perspective, it is massively important for jump starting, you know, any API initiative. And to kind of wrap this into the sprawl and the drift thing, observability can be a huge benefit here, right? Because what we, what we're finding when we're going to a lot of our companies is they're like, we wanna do this.

We wanna go API first. We wanna test what we existing, what we currently have. We wanna understand what people are using, but we have no idea what APIs we have anymore, right?

Because everybody's kind of cycled out, et cetera. And, um, observability allows you to not only observe the system under motion to understand the actual APIs that are there. 'cause guess what?

A lot of those internal ones that, that Tracy was mentioning earlier, they're not documented. There's no service definition for them. And the observability is the only way you're gonna pick up on those.

And that same traffic can be used to generate those initial service tests, those initial vir virtual service says, which is so much more valuable. 'cause it's not just a dumb stub. It's one that actually simulates the business logic and the, and, and, and, and the expectations of the system under motion.

And then you use, and you kind of build your new API scaffolding around that. And it's a great way to get started is leverage your existing observability for service test and service virtualization creation. I love that term.

Your service under motion. It's a great visual Service in motion. Under motion.

So it's in motion. Yes. No, no, it's under motion.

It's great. Just running Something 80 song, it Makes sense, right? Yeah, it does, it Does.

There's another part to this too, and that is the API security. API sec, uh, part of security is one of the first things is API discovery. So if things are going through a proxy or something that's, you know, flow flowing through, um, whether you call a firewall, a proxy, whatever might be, that's another collection point if you will.

Like you're talking about Chrissy, where okay, what is that? You know, there's 25 things that happened today. Nobody knows what that thing is or didn't know somebody else was using that way.

We didn't know that was going externally. So that's another kind of data point you can pull in to figuring out what's happening. Well, I had mentioned that earlier.

You can't defend what you don't know. You most people don't know what APIs you have. Well, and, and from the sbo I'm sorry, from the SBO piece of it, you don't know what dependencies that API is calling into play here.

Chris, Chris l you got something to say? Go ahead. Yes.

Yes. So, you know, when, when you're looking at the APIs and, and the data coming in, it's just like a ui. You have no idea what kind of crap people are gonna throw at it, what length of information people are gonna throw at it.

What kind of information is inbound outbound, because, you know, crafting a good attack, you know, you, you can do things and, and, and skirt under the radar depending on design. And, and I love the, you know, what, what Mitch was saying, you know, the very first thing, if I'm gonna come attack you guys and look at what's going on, you know, I'm gonna figure out what API endpoints you have, I'm gonna figure out what's going on there, and then I'm gonna start, you know, overloading 'em, seeing what I can come up with. And it's, it's amazing how many people overlook the role-based access.

You know, if you get a JWT token, you get in the door, guess what? Now I can do a lot of things that I shouldn't be able to. Fair enough.

Guys, we, we try to keep these sessions to 40, 45 minutes and I think we're up against the clock here. Um, first of all, great conversation, great conversation. I, I think look for our audience at home.

Takeaways three, three things. I always like lean these kinds of things, or three key takeaways. Number one, we absolutely do live in an API economy, right?

APIs are driving the internet, it seems, if we look at traffic loads, number two, an API first mindset in, in how we plan and, and develop our applications is I think the norm, not the exception today, right? Do we all agree with that? And the third thing is, if all of these APIs are out there, you're not doing API testing.

And that includes API security testing. You know, the, the, the, the, what's it, what comes home to roost? Mitchell Chickens can loan drew the chickens, come home to Roo.

I knew it was some foul. That's the Nebraska boy chickens come, that's the Nebraska boy right there. And of course it expands, expands your blast radius.

I realize we gave nobody any context at the beginning as to why we are doing that, and I love it. No, we have a very, very sharp audience. They picked up right away on it, but it's not the first time they played this drinking game.

Um, anyway, Chris and Chris, thank you so much for being our guest today on DevOps. I'm Unbound. Tracy is, as always, it's a pleasure to have you on here.

Love having you part of, you know, not just DevOps Unbound, but you're on the, you're one of the gang members, some tech strong gang, and, and of course, uh, tech strong women and everything else you guys do. So thank you. Thank you, Mitch.

As always, you take the last word. Um, I just party thought is there's an API for that said, fair enough. No doubt.

Hey, many thanks to T Tricentis, as I said in the beginning of the show for sponsoring this. They're a great company to work with. com.

Until next time, this is Alan Shimmel for Techstrong. Quick reminder. July 24th is our next live round table.

Don't miss it. But until then or until our next show here, we're out. Thank you.

Bye-bye.