The Evolution of DevOps: From DevSecOps to GovOps

DevOps is often framed as a modern software movement, but its roots go much deeper.

In this episode of Edge of Excellence, we’re joined by Kevin Eberman, a leader in information security, cloud operations, and compliance, to explore how DevOps has evolved into DevSecOps, and why governance (GovOps) is emerging as the next critical phase.

Drawing on lessons from manufacturing systems like Toyota’s production model, Kevin explains how DevOps is fundamentally about optimizing how work gets done. As organizations scaled, security became inseparable from operations, giving rise to DevSecOps. Now, with the rise of automation and AI, governance must be embedded directly into operational design. 

We also explore how AI is reshaping workflows in cloud environments, why risk-based thinking matters more than chasing vulnerability scores, and how leaders can navigate rapid change without losing control or visibility.

This episode is for CIOs, CISOs, IT leaders, and anyone responsible for scaling technology in a secure, compliant, and sustainable way.

In this episode, you’ll learn:

• Why DevOps is more about systems thinking than tools
• How DevSecOps changed the relationship between development, security, and operations
• What GovOps means, and why it’s the next evolution
• How AI is shifting (not eliminating) risk
• Why critical thinking is becoming the most valuable skill in tech

Resources & Links:

• Kevin Eberman on LinkedIn
• Kevin’s blog:
  From DevOps to DevSecOps to GovOps: How We Keep Getting Better at Work Without Calling It That
• Learn more about iuvo

If you’re navigating DevOps maturity, cloud transformation, or AI adoption, this conversation offers both strategic insight and a practical perspective on what comes next.

Transcript

SPEAKER_00 0:03

This is the Edge of Excellence, empowering people to shape the future. Let's inspire, innovate, and explore together. I'm Jesta Forge, and today we're talking about something that has shaped modern technology organizations, DevOps, and where it's headed next.

SPEAKER_02 0:21

And I'm Brian Beilman, and joining us today is Kevin Eberman, a leader in information security, cloud operations, and compliance, and DevSecOps expert with deep experience across security, governance, cloud platforms, networking, and highly available systems. So Kevin and I have worked together previously, and one of the things that stood out to me was how he brought DevOps thinking into the organization. Not just as a technical shift, but as a leadership and operational evolution. Kevin has a proven ability and which you will see a genuine enthusiasm for talking about IT and security in a meaningful way. Kevin, welcome to the edge of excellence. Awesome. Delighted to be here.

SPEAKER_00 1:09

Yes, Kevin, welcome. And before we get into today's topic, I'd love if you could walk us through your background and just sort of the journey that's led you to where you are today.

SPEAKER_01 1:26

But yeah, I will say that I started my career in San Francisco working for a software company called WebLogic. WebLogic was ultimately acquired by BEA, and BEA was acquired by Oracle, and that product, the WebLogic application server, which is really the first Java J2EE application that was successful in the market, yeah, has had a long shadow. And the reason why I'm drilling into that is because the software developers at that company were incredibly good. And they were doing a lot of things that we now refer to as DevOps or Agile in the mid-90s, like 1996, 97. And so at that point, they were doing automated builds, unit testing, system integration testing, um, in an automated fashion. And, you know, and as well as in terms of work and how they defined and managed work, it was all based on agile principles and focusing on, you know, what is the least we can do that is effective and useful. And all of these guys were super duper duper good at it, um, and really set the model for me for how to um interact with um development teams and how good development teams work and um you know, and and and taking those principles into operations. Um so um, you know, so over time it and when DevOps actually sort of hit the the scene as a word, which was about um 12, 15 years ago already, um right before I started working with Brian, um, yeah, for me, it really crystallized what needed to happen, and that dev and ops were two sides of the same coin. And uh but the history of all of it really goes back a lot further. But that's how I got into it. That's how that that that's that's where sort of my impression was created, and um, you know, have taken those principles to a lot of different companies to push them forward with respect to the maturity of their automation as well as the observable observer observability of their environment.

SPEAKER_00 3:54

No, that's great, and I appreciate you sharing that background of how you've gotten here today, and you started touching on this. I'm gonna dive back into it. Um, you've mentioned that the intellectual framework of DevOps is actually much older. So, can you unpack that for us a little bit?

SPEAKER_01 4:09

Yeah, so uh um it was only just recently that I read a really fabulous book called uh The Phoenix Project, um, which is uh um a fictionalized account uh of a VP of operations that's sort of thrown under the bus of a project that's gone completely out of control. That's the phone. And uh you know what he has to do to sort of get himself up from underneath it all. And and it's really about implementing DevOps within an enterprise. Um and in and in the course of the discussion about that, um they talk about manufacturing and how efficiently are or how modern manufacturing organizations and um plants were designed to limit bottlenecks, identify constraints, and manage the overall output of the factory. And that goes back to yet another book that was popular in the 70s called The Goal, um, which is really actually the better book of the two, also a fictionalized count, but taking on um manufacturing in the 70s and problems that manufacturing companies had with excessive inventory within their factories, inability to get orders out quickly, and and and fundamentally, um all of it is about you know managing work effectively and focusing on what matters, which is the goal. And what's the goal? To be profitable. So, how do you get there? You're efficient, and so this same principles, uh you know, going back from the 70s all the way through to what we're doing today, uh, it's about managing work and less about technology and tools.

SPEAKER_00 6:05

Yeah, no, absolutely. And when we chatted before you know this recording, you had used an example of the Toyota production system. Could you talk about that a little bit?

SPEAKER_01 6:15

Yeah, so uh, you know this concept uh of um it really boils down to um a very specific concept about uh um you know output and managing throughput. So everybody has always measured the productive productivity of their systems and their you know their environment, their manufacturing environment. And the mistake that people made was maximizing the efficiency of every workstation, which actually creates bottlenecks. Um, because you know, not every workstation is moving at the same speed. And so you wind up piling up work in front of some workstations and starving other works for other workstations for work. And and and it and so so it's a detriment to your overall output to maximize the efficiency of each individual station. And what you want to do is maximize the output of the entire system, and and that's what Toyota did, right? And so they got really good at um you know getting good cars out of the system. And let me give you a specific example. So, you know, and and this speaks to like QA and DevOps and early testing. So um, you know, they would build a component for the car that was comprised of a whole bunch of different parts, and then they would test it. And if the part failed, right, then they have to sort of rebuild all of those components and put it all together. But when they looked at it, they realized that all of the failures sort of broke down to two different parts within this thing that they were building. And so instead of building it first and then testing it, they tested the parts that typically fail. And so in that way, they identified the problems before they had built something that was useless. And it's really that same methodology over and over in an iterative fashion that gets you Toyota cars of the 70s that I remember that were, you know, like that were little tanks, right? That were excellent cars and really inexpensive. And that's where you want to be.

SPEAKER_02 8:41

Well, that you know, makes me think uh saying back to when I grew up and I had American cars, and I in my trunk I carried an extra quart of oil, uh, extra tools and everything because just in case it broke down. But when Toyota started, you know, in that era, like started bringing out cars that were like much more reliable than a typical car, right? And so how does that I mean, let's let's step forward a little bit, and how does this concept kind of connect to modern DevOps thinking? What how does that relate to I think?

SPEAKER_01 9:11

Yeah, so it it really comes from what I sort of um agile and and scrum and those methodologies for prior identifying and prioritizing work, um and breaking things down into smaller, doable, and useful chunks. Um and and and and fundamentally that's that's what we're doing, right? In terms of our Jira uh um storyboards, Kanbans, and and and you know, it can ban uh to connect words that we use today back to the Toyota production system is a Japanese word for card. Um and that's how they decided, you know, they literally put cards up next to workstations to identify which orders would they would work on next. And and and you know, you can only do one thing at a time. So they well, they had one thing in the production queue and everything else in the backlog. And uh um, so so it mirrors exactly how we're doing things today down to the words we're using.

SPEAKER_00 10:18

Oh, that's cool. I now I've learned a fun fact for today. So thank you for that, Kevin. Um, so a lot of what you're talking about are some really strong ideas. And, you know, change is hard for people, it's certainly hard for organizations. So, why do you think that even strong ideas can take so long to be absorbed into how these organizations are actually operating?

SPEAKER_01 10:40

Yeah, and um so so this is not just a DevOps problem and a modern problem of adapting these kinds of ideas. Um, you know, while Toyota was very successful with their process, um, not other car manufacturers tried and failed to implement DevOps. And um, and it it it's so because it's because it's actually hard. You know, transformation and change is actually hard. And there's incredible pressure to meet your immediate goals and objectives that undermine your ability to make uh structural and systemic changes.

SPEAKER_00 11:21

Yeah, I know that makes a lot of sense. Um, and when I think about you know how fast things are changing now, I think this is going to be just a continuing problem that organizations are going to be having to look at and face. And when we chatted originally, you know, we started talking about DevOps and then we kind of moved into this conversation about DevSecOps. So I'd love to kind of shift focus to that a little bit and ask you at what point do you feel security became impossible to treat as something separate from operations?

SPEAKER_01 11:52

So it's an interesting question. Um and I'm not sure the premise of it is completely true because in a lot of smaller organizations that can't afford a dedicated security function, um, ops is doing security uh alongside with keeping you know the wheels of the bus. Um now it and it's typically as organizations get larger that they implement a dedicated security function. Um and and in those large organizations, uh it has the same problem that dev had with ops, which is that they were unaligned and working towards different goals. And I tend to think of SEC as being much more closely aligned with ops in terms of keeping the wheels on the bus, providing guardrails, and um, and it's more operational. Um and and and often at times uh uh at odds with with with dev. Um and so so in so much as dev and ops need to be working together, dev second ops really need to be working together. And and you know, like a lot of other things get thrown into that DevOps formulation too, like Dev QA ops. Um, and um, you know, it gets because because people realize that that you cannot separate these things. They're a part of a whole.

SPEAKER_02 13:25

It makes me think a little bit about, I mean, some of this areas when I think of DevOps at scale, I think of companies uh like Facebook, for example, who were like just moving fast, breaking things, and and and because it wasn't like it used to be like, okay, we have a release on Friday, and everybody's got to get together on a Friday night. We're gonna do this big, very monolithic step-by-step step, and then you know it became a little more automated, and and you know, there's companies that really uh were able to scale, were able to do this really well. And you mentioned this, this, this, there's also a little bit of conflict sometimes between maybe dev and sec because uh sometimes you want to move fast, but you don't, but you want to open security vulnerabilities, and you got to make sure that they're all very tightly together. And I, you know, so can you can you elaborate on that a little bit?

SPEAKER_01 14:12

Yeah, it it's really hard. Um, you know, ultimately, dev teams are driven by the business to sell product and features engage customers and help them make decisions to buy products. Um so like there's an implicit need for operations and security, but um you know, but not necessarily um um a conscious or you know, top of mind need for that. And um and in in and particularly when you're thinking about what people call a minimally viable product, the there's a real motivation to skip whatever, you know, you know, that whatever's whatever can not be done. And and often that means resiliency, often that means security, often that means stability.

SPEAKER_00 15:08

Now, Kevin, in our previous conversation, I remember you speaking to this idea that you know people had once predicted DevOps would lead to no ops. Can you speak to that a little bit and why you think that didn't end up happening?

SPEAKER_01 15:22

Yeah, yeah. And you know, I think it speaks also to like the tension between developers and operations and um, you know, that developers, not all developers, but but um that they would prefer not to have ops at all. Um and you know, and in so much as they're making products and driving businesses, uh, they like to have things under their control. And so, in so much as DevAOps was being implemented with automation, code, and scripting and um software, um, you know, it it lowered the bar for or for what developers could do themselves. Um, and so there were tasks and things that developers can now do without relying on ops. And that um and that, particularly in smaller environments, you probably didn't need a dedicated ops person in the same way. But the fact of the matter is, is that you know, ultimately dev is what you're putting inside the box, so to speak, and ops is how the box connects to the rest of the world. And um that requires sort of eyeballs on two different things. And you really can't get rid of ops. So the irony of it all is now as we are entering into this AI world um and automated coding is becoming a real thing, that we're actually getting a place where it's actually no dev, um, and it's only ops. Um and um and and and that's not true either, right? Because in the same fashion, um the automation of the technology lowers the bar for people that are not software developers to develop software. When we think about vibe coding, that's exactly what's happening. And that ultimately doesn't mean that we eliminate software development or even people that know um you know software languages like Python um or C, but that specialized knowledge um is going to be more focused in specific places, and that um the bar is lowered for anybody to do some kind of coding.

SPEAKER_02 17:36

Yeah, I want to go back a little bit, give Kevin some props for when he when we were working together at this company, and he came in and uh you know, we were consulting and and you know, it was introducing DevOps into this function. And there was there's there was a natural conflict really between development would push something out, and then if it failed in operations, then operations would get woke up at the three o'clock in the morning, so it was this broken, and then you gotta flick, and then you try to bring dev you know developers into it, and they weren't they that didn't have as much ownership in that, you know, and I think what this paradigm helped was that there's mutual ownership in this, that by the time it gets out to the world, and we're not, you know, we're all gonna sleep at night because it went through some processes. It went through uh build test deploy, oh, and and different, you know, QA and Dev and went through uh a bunch of great, really great processes, which uh I think that it helps, I think it helped the relationship across the the organization as well as it overall give a better, better product, better, better experience for the customer. So yeah, you're making more money because you're you know it's more reliable, it's better. So I think um that mindset uh it's not always apparent, but uh you certainly brought it to the place we work together. So I think that's the one.

SPEAKER_01 18:51

Yeah, I'll I'll add two things here. One about standardization and one about who gets you know a pager. Um and um yeah, when there were chronic outages uh for every deployment of one of the applications we were managed, uh I finally said to the lead developer, you're now on call. You know, we're tired of waking up to fix your thing. And uh, you know, like it's just too much, you know, like you have to do better. Um and setting some real expectations for quality. And and I'll tell you, you know, like people, developers don't like that, right? You know, they don't actually want to be up in the middle of the night fixing their broken code, and and that certainly made a shift in that particular application that was perpetually having problems. And then the other thing that was interesting about um where we worked together was that there was um a lot of infrastructure that was already there when I got there. And um, and it was actually consolidated from a number of different um groups and teams, and and which seems like efficiency, and to some extent it is, but the reality is that each of those groups and teams had built their own little cottage industry of a tech stack. And so we had Linux tech stacks, we had Unix tech stacks, we had Windows tech stacks, we had different versions of these things. Everything was heterogeneous, it was incredibly difficult to update and patch anything. Um and it was just hard. And um, and and you know, the biggest thing that we started to work on, you know, out of the box was server configuration management so that we knew what tools were on what systems and had automated abilities to update and manage them. And ultimately we converted much of that chat uh tech stack onto Linux VMs running on um VMware on homogeneous systems with homogeneous, um you know homogeneous operating systems and the same um tools on those boxes so that now we go from um it takes weeks and a lot of you know fingers crossing that we don't blow things up when we update the operating system because daylight savings time you know has changed and you need to install a new um time package and reboot every computer on your your your network and you have no idea what's actually kind of gonna come back up or blow up because it's just so old. So um you know that homogenization and standardization is huge where we work together.

SPEAKER_00 21:42

No, absolutely. Now, Kevin, you've talked about GovOps as the next evolution. What exactly does that mean?

SPEAKER_01 21:51

Yeah, so GovOps, not government ops, um to be clear.

SPEAKER_00 21:55

Um that's what I thought. I'll be honest. I'm not a technical person, but that is where my mind went.

SPEAKER_01 22:00

But uh governance operations. Um, and and maybe this reflects some of my own career trajectory um in terms of ops to information security to governance. Um but but you know, notwithstanding my biases, what's happening with the automation, um, and we're talking about this already, is like lowering the bar for um people that are not software developers traditionally to do software development. And and the AI itself, like, you know, the automation um is is becoming so much more important, and especially when you think of agents. And so what that really means in my own mind is that the prompt is becoming more and more important because those prompts are going to run agents that are going to do things over a course of a period of time. And so those prompts have to be very well written. And fundamentally, you know, the way I think about those prompts is the infrastructure of your governance program, and it is the breakdown of policies and standards directly into prompts that will run your business. And so it is in the articulation of your governance policy and standards, which will then actually run your business without the need for large software development teams and operations teams that you get from devsecOps to GovOps, where you're really obscuring dev and sec and focusing on the business needs and governance.

SPEAKER_02 23:44

That's one thing uh that important that you said there is I think um what I well because we have covet customers who have um regulatory compliance and and essentially governance, uh, those are typically more powerful business drivers than just make it secure. And we we don't want to get hacked. It's more like we need to be uh this meet this regulatory requirement, and I need to know sure I need to know for sure. And then when an audit comes, I need to be really be able to very clearly articulate that we are meeting these or or not, or whatever it may be, but I want to it has to be really easy. And um and so I mean I guess the good thing about thinking about this way is that because there are clear business drivers that that a business can be behind and not just it's not just technology.

SPEAKER_01 24:33

Yeah, absolutely. And and you know, like what the automation is also doing is traditionally audits were very um labor-intensive things. You needed um from the auditor specialized knowledge and understanding of how to do an IT audit that requires certification and training. Um and then the process of the audit typically involved a lot of manual steps, like gather a sample of information systems and provide these particular outputs that we want to inspect. Now that things have been automated with respect to DevOps, DevSecOps, and automated um CICD, uh continuous integration, continuous deployment, we now have the ability to hook in our um compliance controls and our observability directly into these platforms. And so we're sort of leapfrogging the need to have a dedicated auditor and a dedicated team servicing audits because the the outputs and reports can be baked into the DevOps um the DevOps flow directly.

SPEAKER_00 25:49

Now you're mentioning prompts and AI, and we're talking a lot about automations. Can you speak a little bit to how AI is changing operational workflows in like AWS and Azure environments?

SPEAKER_01 26:02

Yeah, so all these things that we're talking about are getting baked into these um you know cloud service providers. So that um, you know, you're i i if you you and it's not there yet, right? But but this is where it's going. So you say, like, you know, our environment needs to be PCI certified, and it spits out a list of controls that you need to implement or test the controls that you have to see if they're the that that you're compliant. And and it, you know, that's removing a lot of work that used to happen manually.

SPEAKER_00 26:40

Yeah, and that's huge. I'm curious, do you think AI reduces risk at all, or is it just shifting where the risk lives?

SPEAKER_01 26:49

Well, you know, there's a truism about a lot of things that says, you know, if you make one thing better, you're making something else worse. Um, or if you solve one problem, you create a new problem. Uh, if you mitigate one risk, you create a new risk. And and that's a thousand percent true with um AI, or you know, and it's it's a little like Pandora's box, right? It's incredi, it's it's capable of doing amazing things, fabulous things, things beyond our imagination, but it also, you know, releases all the suffering and curses of the world. So, um, so so, you know, like tread carefully. And frankly, you know, like because the tools are so advanced and complicated, it's it's again, it's what pushing um the automation into governance and the need to operate from a governance standpoint and and and sort of articulate why I think GovOps is you know where the juice is going to be for the for the next while.

SPEAKER_02 27:50

Well, and I've seen some on this note, I think about um some of the uh uh watching the development process for some of the things we that we where our people use AI and having these um series of of of checks. So I think if you if you think about it and you really I mean I think you know you uh you can become a coder or you be you can write code as AI without knowing anything about Python or whatever, but but it does take that systems thinking of saying, well, I'm gonna do this and I want to make sure this check, this, you know, you can go through a series and and AI will help you do that much faster as long as but you gotta know to put these in place, right? Okay, and and you gotta make sure that AI is not lying to you, and you gotta make sure that all of these factors go along there and check and double check. And I but you can put these framework checks and these compliance checks in easier, but you still have to that's where that's where a kind of uh maybe an experienced person who thought about it, going, okay, let's put this in place, um, instead of just saying, write me some cool code, you know, like so.

SPEAKER_01 28:50

Yeah, right. And you know, like um even before AI, people often wrote bad code, um, you know, that that barely worked and was insecure. Um, and they were software developers. And so now you have people that have no training, um, you know, getting in there and doing things. And and you're absolutely and and and it's fundamentally the same truism that we all know, like garbage in, garbage out. Um, and that that that um you know it takes more than just vibes to to make good software. And it does really take an understanding of these kinds of frameworks to to make them work well. Yeah.

SPEAKER_00 29:33

Now, how do you think AI and these automations are impacting the expectations that are placed on developers and operations leaders?

SPEAKER_01 29:42

Um, so so I I I think it's you know, it's it's a huge shift. Um, and and I would describe it is um even though AI is here and people are are interacting it, we're still in the pre-AI world. Um some people are living in the future, but most of us are not. Um, and the impacts and changes that this is going to bring about are going to be huge. Um, that's my expectation. And and there are a few examples that I can give you that people are like, wow, this changes everything. Um, one of them was um in the film industry, where there's this um Keanu Reeves and um um Tom Cruise fighting it out, and and it's all AI generated. Um, it's incredibly well done. It's funny, it's cute. It was like, and and the person was um a director, and he's like, you know, this is the end, you know, this is the beginning of the end. And um, and and then Atlassian uh recently announced that they let go of 4,000 people within their company because of AI. Now, there's a lot of AI washing uh of bad performance and issues within companies, but fundamentally, I you know, like like I think what's happening is true and it's gonna happen more and faster.

SPEAKER_00 31:14

Yeah, my husband is a videographer and he's you know had some concerns um about what you're speaking to as well. So with all these changes, you know, that you're talking about, what skills then become more critical?

SPEAKER_01 31:28

Yeah, so that's a great question. And you know, one of the things that that uh um you know in the market right now, you know, there's a lot of interest in tools. Um, you know, do you know how to use this tool? Are you familiar with this tool? You know, we need to plug in somebody who's really deep in this tool in order for them to be productive. Um, my understanding, the half-life of usability of tools now is two and a half years. So, you know, like what are you learning? How quickly, and what is it not going to be useful anymore? And um on that kind of cycle, you know, ultimately you can't come up, can't keep up. And and frankly, what it comes back down to, and and we were just talking about this in terms of what makes a good software developer in this world, and and you know, there's an understanding of how things are supposed to work, but I also think the most important thing is critical thinking. So, like, is my AI lying to me? You know, like uh is it just shining me on and making stuff up or not? Um, hugely important. Um and um yeah, yeah. So so that's so it and and those are people skills, uh um and and and sort of attributes of humans. Um and I think those are going to be more and more important. You can't sort of uh um um jargon your way through being a subject matter expert at a specific tool or technology. You know, you you actually have to be a critical thinker.

SPEAKER_02 33:00

Yeah, that that makes me think too a little bit about um, you know, I'm I I think about culture quite a bit and and and all of these changes that come about, you know, as as people uh and as a way companies, you talked about Alassia and probably were thinking about well, we can do more with less or or whatever. But I do think that any leader um and and I I struggle with this myself. I'm I'm uh uh Jess may be able to relate to this, but we're you know, I'm part of this re RevOps team and and and we're moving forward on this on a new initiative, and I'm always I have to stop myself to like what you know, it's always like uh this is the way we've always done it, or should we do it this way? People come up with new ideas, and I'm like, I'm like that gotta pause, like because I and I'm and and even oh, I feel like I'm a forward thinker, uh it's it's hard for all of us to get out of our own way sometimes. And I think that you know the skills that we know we all need to think about, you know, I think the critical thinking is right on, Kevin, because like those that's a really valuable skill. It applies to every everything, looking at the future, looking at uh it applies to any any aspect of what people are doing. Um and then I just to dial back a little bit, what you were talking about, you know, making sure that AI is not lying to you. We have a podcast that just released with Justin, uh, one of our uh people, and he was just talking about his battles that he's been trying to develop this app, and and you know, and when Claude just keeps lying to him all the time, you know, and and just wants to it just wants to please him. And he's like, I don't want you to please me, I want you to give me the right answer, you know. So if you don't, if you don't, if you just don't think about that, it you're gonna get some stuff down the road that that's not doing what you think. So uh all of these it causes our brain, we have to just do things differently.

SPEAKER_01 34:51

Yeah, and you know, let's take it a step further, like in terms of dangers of AI, um, you know, AI psychosis, where you know, like you're just so wrapped up and involved in your AI and your relationship with your AI that you're not thinking straight anymore. So like it is, it's it's um, you know, it we're all sort of going through this is this experiment uh uh in human behavior uh in real time.

SPEAKER_00 35:20

Yeah, no, it's it's wild and it's amazing how it's impacting those of us as adults. I am just so curious, you know, the impact it will have on the younger generation that won't know a world without AI. Right. It's interesting to see, you know, how things, you know, progress with this new world, as you will.

SPEAKER_01 35:39

Um But you know, I I I do want to jump in, you know, we do survive things. Like I was told when I was a kid that my brain would rot if I kept playing video games. I kept playing video games. I love video games, I still do. So uh um, you know, we all have a tendency to uh um overdramatize our own um our own situation, but we all tend to muddle our way through in some fashion.

SPEAKER_00 36:04

No, that's so true. That's so true.

SPEAKER_02 36:07

I wanna I wanna I wanna get us back on a different topic because that's just something that you're very passionate about and that we've spoken about, and you wrote a blog and we worked on this uh together about you know basically risk and security. And so um, you know, talking about um you were you were doing a lot of research uh on on risk scoring with models like qual as true risk and and and so I wanted to uh make sure we cover this because it uh you know, I want to find out what what kind of questions that this raised for you and how do we you know in around this.

SPEAKER_01 36:37

Yeah, I I appreciate you bringing it up. Uh and um it's uh it's a very interesting topic. I I gotta set the set the stage a little bit when we talk about vulnerability management. And and and usually what that means is that we get these reports, these CVEs that indicate um, you know, there's some indication of compromise or vulnerability within some piece of software. And they'll give you some idea of how severe that vulnerability is. And then we go uh back in patch systems um to eliminate those vulnerabilities. Um the problem is that there's so many vulnerabilities, you know, tens of thousands, hundreds of thousands that have been identified. And that um in really large environments, and you know, you think of a company like um a staples, um, you know, where they might have tens of thousands or hundreds of thousands of devices under their management, um, if they're reacting to everything that's quote unquote, you know, a C VSS score of 10, you know, the highest criticality, um they may not, you know, like that's a huge work effort to patch all those systems. And and so really what you want to do is instead of patching things based upon the severity of the threat, you want to pace it patch based on the actual risk to your environment and to your, you know, what you're trying to do. Uh, and so in that way, you could say, like, well, we have two systems with the same critical vulnerability. One of them is serving up peanuts in the cafeteria, um, you know, like a little like peanut vending machine, but you know, it's connected to the internet, and the other is running our Oracle database. And so I think there's pretty clear, you know, which one you should patch first and um you know, expand that same idea to hundreds of thousands of systems, and risk-based vulnerability management becomes a huge benefit to prioritize and focus and to limit the amount of work it takes to mitigate the risks of critical vulnerabilities. And and a lot of um and in in in and so vendors like Koalis are moving away from just scoring vulnerabilities and the threat based upon the vulnerability, but mirroring that um you know to to the likelihood and the impact that that would actually have and and generating a risk score. And with the risk score, that guides you to how to you know how to prioritize your teams to to do patching. Um and the problem is, is like all this stuff is complicated, and you know, Qualas, to their credit, publishes their formula. Um, but you know, looking at it at face value, it's it's hard to understand. Um, how exactly does it score? And it's when I was introduced to this that I was like, I can't figure it out. And I started to test, you know, different scenarios, like, you know, if there's this vulnerability on this system, you know, what is the risk score? And that's when things got really interesting and problematic because like, because so we were I was looking at QuAS Enterprise Threat Management, which is a new product that QuAS has been pushing out in the last year or two, which is meant to give senior executives a view into their risk spot posture throughout the organization, and to do this risk-based virtual uh risk-based vulnerability management at scale and for the benefit of senior executive leaders. The problem is that the formula that uses it seems to be out of whack, and that for systems that have a lot of critical vulnerabilities and threats and that are your most sensitive, important, and exposed to the internet, you know, it it takes what I would consider too many vulnerabilities to put it into the critical threshold. And then it turns out that in another product, uh their vulnerability management detection and response product, which is sort of their bread and butter baseline, sort of, you know, what made Qualas Qualas? It the same true risk calculation, and that's T-R-U-R-I-S-K-T-M true risk, Qualas True Risk, uh, scores the same system with the same vulnerabilities differently and much more aggressively. And so like, okay, Qualas, what's up? You know, like is it, you know, is it the rosy picture for the executives, or is it the you know, the grim picture for um for your your patching teams? Um and and and it turns out that Qualas has two versions of the true risk formula, one that was their sort of legacy one that's on VMDR that scores risk more aggressively, and another one that is for their ETM project. And and it's like, you know, that's just a mess. And um and and and not clearly visible, um, not transparent that this drift between the scoring happened from version one to version two, because the primary benefit in what they sell with that product with ETM is is is your is prioritization. And so, in so much as that there are ranked scores, everything looks great, you know. We, you know, it functionally is is is working. And you know, it's like the old joke, it's uh, you know, it's not a bug, it's a feature. And um, and and you know, it's like, but like, yeah, we're gonna need to do some work on coalescing these things. And there were other changes that he made too that were important and meaningful, but this regression in terms of the output is pretty significant, uh, you know, not a good block.

SPEAKER_02 42:49

I'll also say that in for our listeners, we'll have we'll have uh Kevin's uh credentials in his blog and various things about him uh you know in the show notes later on. So you want to dig deeper into this true risk and and and and even reach out to Kevin about this because he's done a lot of research in this area, and I think it's important to businesses to really be able to rely on these types of you know, these true risk scores uh and things like that. So uh just 100%.

SPEAKER_01 43:16

Yeah, and and it goes back to like critical thinking, you know, like you know, like you know, do you accept at face value that it's transparent because they showed me the formula? I did it. Uh, and and then lo and behold, like there's some real significant problems. And that really goes back to like pushing security left, pushing it into the design phase, and um and and and security becoming more like governance, and that at design time you need to be thinking about the negative implications of what you're doing and um putting controls in as soon as possible, and way before we typically think about it these days.

SPEAKER_00 44:00

Right. And Kevin, I'm curious, is there any advice that you would give a CIO or a security leader that's navigating some of the transitions that we've chatted about today?

SPEAKER_01 44:12

I think that everybody is grappling with AI in some fashion or another. And everybody recognizes that they're on a journey. And that, you know, I'll take it back to a DevOps thing. You know, break it down into small chunks, break it down into manageable bits of work that gives you incremental improvement and benefit. And um and generate a waterfall. So that at some point, all these little improvements that you're making, you know, make a substantial change in how you operate and how effective you are. I think that I've seen this at a number of different places. Um the worst thing you can do is try to build the the end, you know, is try to implement where you expect to be. Um because you wind up um tripping over your own feet and you never get there.

SPEAKER_00 45:14

Yeah, I think that's great advice. Brian, before I ask my final, more fun question to Kevin, is there anything that you would like to ask?

SPEAKER_02 45:24

Uh I I think no, I think we covered a lot. And I think uh the the uh although we may, you know, when we first thought of the what would this this whole thing be about, um I think uh the theme throughout the whole thing is critical thinking. Yes. And and breaking things down in in ways that it makes sense, whether it's you know, DevOps, DevSecOps, GovOps, AI, this this whole, and you know, I think and sometimes just gotta pause and and really think about these things because we're moving so quickly all the time. We just move to the next thing, move to the next thing, and just pause and and often the answer is right there. But um, so I that's the that's kind of the thread of throughout this whole conversation that I've I've taken I've picked up um amidst all this really awesome information. So um I think that's a great point.

SPEAKER_01 46:11

Uh and you know, sometimes like that's that's a real challenge, right? Because we're moving very quickly, we need to move quickly, our minds are built to move quickly. Um, but sometimes, like, you know, maybe you should pause before you hit the send button, you know? Yeah.

SPEAKER_00 46:30

Yeah, I think that's um great advice for all of us and for so many different aspects of life. So, Kevin, we like to wrap um our guest first episode with us with a question um to see if there's a fun fact about you that might surprise people that you could share with our audience.

SPEAKER_01 46:51

Yes, yes. Um, I was prepared for this, uh uh, you know, came with a pop. Um so this is this, but I don't know if you can see it, but this is my uh this is my trumpet. Um I'm a trumpet player. I I I play in a band. Uh um and uh I I I picked it up during COVID, um, or picked it back up during COVID. I was a trumpet player when I was in middle school. And so that's been a really fun thing, a fun journey. It's keeping me really busy and humble because it's really hard to play good music.

SPEAKER_02 47:25

Yeah.

SPEAKER_00 47:26

That's amazing. That's amazing. Do you play out with your bands?

SPEAKER_01 47:29

Yes, yes, we do.

SPEAKER_00 47:31

Oh, fantastic.

SPEAKER_02 47:32

Well, maybe uh maybe we'll have to include the your your band schedule in your show in our show notes. You can people can go down to uh the Providence area and uh and check out your shows. For sure, for sure. Cool, that's awesome. Um, so Kevin, this has been such a thoughtful conversation. And as I mean, and we we wanted to have you on here because we when you and I speak, we always have these types of conversations. I know there's listeners out there who are gonna want to continue it with you directly. So if someone wants to connect, uh follow your network and engage with you, um uh what's the best way for them to reach out to you?

SPEAKER_01 48:05

I think the easiest way is to uh message me on LinkedIn, um and um yeah, which I track and I'll get back to you. I would love to hear from anybody who has questions or interested in anything.

unknown 48:17

Cool.

SPEAKER_02 48:18

Yeah, we'll we'll include your LinkedIn profile on the on the on the on the show notes and so people would find that.

SPEAKER_00 48:23

Today's conversation reminded us that DevOps isn't about speed alone, it's about designing how work happens. And as automation and AI continue to reshape operations, governments, visibility, and critical thinking are foundational. If you'd like to learn more about how IUVO helps organizations turn technology into real business outcomes, you can visit iuvotech.com. You'll also find this episode and every other conversation from Edge of Excellence there.

SPEAKER_02 48:52

DevOps, DevSecOps, and GovOps aren't just evolving technical models, they're reflections of organizational maturity. As leaders who embrace that evolution, we'll be the ones who scale confidently and responsibly. And thank you for listening. And until next time, stay curious.

SPEAKER_00 49:11

Thank you for tuning in to the edge of excellence. We hope today's insights empower you to shape your future and rise to your full potential. Let's continue to grow, innovate, and lead, pushing the boundaries of excellence.