Subscribe
Share
Share
Embed
The development world is cluttered with buzzwords and distractions. Speed, focus, and freedom? Gone.
I’m Nicky Pike. And it’s time for a reset.
[Dev]olution is here to help you get back to what matters: creating, solving, and making an impact. No trend chasing, just asking better questions.
What do devs really want?
How can platform teams drive flow, not friction?
How does AI actually help?
Join me every two weeks for straight talk with the people shaping the future of dev.
This is the [Dev]olution.
Marc Hornbeek (00:00:00):
Security is a great one, right? Where AI isn't there to replace people so much, it's more to augment a need. I think those are the best cases. There are other cases as well, like for example, wherever you have things that are not possible to really perfect, there's no way you can perfect 100% security. It doesn't exist in nature.
Nicky Pike (00:00:21):
This is Devolution, bringing development back to speed, back to focus, back to freedom. I'm Nicky Pike. Okay, so everyone's talking about DevSecOps, but here's what's missing. The bad guys have AI agents now, while enterprises are still arguing about shift-left versus shift-right, 47% of organizations have already been hit by deepfake attacks in 2025. SolarWinds? Log4js? I have a feeling those are just warmup acts. The real show is when malicious agents start hijacking your own AI infrastructure to do their dirty work. And with 20% of organizations already dealing with shadow AI, this only serves to increase the danger of AI-based attacks. We know this is front and center in security minds because at Black Hat Conference this year, it felt like every vendor was either building agent defenses or admitting that they were already in attack. We're not preparing for the future anymore. We're already in it.
Marc Hornbeek (00:01:15):
Joining me today is Marc Hornbeek, affectionately known as DevOps-the-Gray. He's the CEO of Engineering DevOps Consulting and author of Engineering DevOps and his newest book, Intelligent Continuous Security. Marc's an IEEE Outstanding Engineer with 49 years in the field, a DevOps Institute Ambassador who's created nine certification courses and the architect behind frameworks like the 9 Pillars of Practice, Engineering Blueprints, and Seven-Step Transformation Blueprint. These are things that enterprises are actually using to get their DevOps right. He's here to tell us why everything we think we know about security is already obsolete and what we can do about it.
(00:01:50):
But before we jump in, here's the challenge on the table. Security is broken. We've already got a massive security skill shortage, 4.8 million unfilled positions globally, while demand outpaces training capacity. Meanwhile, 47% of organizations have already experienced deepfake attacks in 2025, with 85% of security pros saying AI is accelerating those threats. The average breach topped 4.44 million globally, but it has jumped to 10.22 million in the US. Traditional DevSecOps promised to fix this by shifting security left, but developers are drowning. SecOps teams are missing 30% of their alerts due to fatigue with an approximately two-thirds burnout rate. And now, shadow AI incidents are hitting that 20% of organizations, 16% of breaches are involving attackers using AI. So how the hell do we secure systems when attackers have the same AI superpowers that we do? Marc, welcome to the Devolution.
(00:02:48):
Oh, thank you for having me. Appreciate the opportunity to share my views.
Nicky Pike (00:02:52):
So Marc, jumping in your book, Intelligent Continuous Security, the SolarWind supply chain attack was just a wake up call for cybersecurity industry, but that was years ago. That was back in 2020 and now 45% of organizations are projected to face supply chains in 2025. Additionally, we saw huge enterprise disruptions from Log4j in 2021. What the hell happened? Why didn't we learn from this?
Marc Hornbeek (00:03:16):
Well, certainly we didn't learn enough. We're still fighting yesterday's wars with yesterday's weapons essentially. So the SolarWinds breach in 2020 and the Log4j fiasco in 2021 weren't isolated events. They were flashing red lights on a dashboard telling us the way we were approaching security fundamentally broken. Instead of pivoting to continuous adaptive defenses, most organizations doubled down on the same reactive patch and prey mentality. That's like seeing smoke in the engine room and deciding to buy more buckets instead of installing fire suppressors. The gap between DevSecOps and SecOps has actually widened. DevOps teams move faster embracing CICD and cloud native architectures. But SecOps teams stayed in the traditional ticket driven workflows, attacks, exploit that gap every day. The gap exists, adversaries are slipping through it, and secondly, developers were asked to carry security they weren't really equipped for. We've dumped vulnerability scanning, compliance checks and patch triages on developers who are really trained to build features and not defend against nation states, and the result is overload.
(00:04:24):
Burnout, critical vulnerabilities left unaddressed until they explode. We learned some lessons this year, at least nearly half of the organizations are expected to face supply chain attacks. So the price of inaction is about to get a lot steeper. This is really the reason I wrote the book, just like I wrote my other books, it was kind of a frustrating reaction to the problems that I'm seeing in my consulting work. The books are trying to be a prescription to help people with solutions, and this is really what the latest book is all about in the terms of DevSecOps and SecOps. I think even today I teach very frequently DevSecOps. Even this week I'm peaking DevSecOps to US Air Force people, and they still have this idea that DevSecOps somehow replaces the ops aspect of security until they realize what it is. And DevSecOps really is kind of a misnomer. It's really dev two ops not dev together with ops, even though it's intended to close some gaps, it really created and institutionalized some new gaps, in fact.
Nicky Pike (00:05:25):
Well, and you mentioned we asked a lot more developers and I think that is something that we're definitely seeing. We're seeing DevSecOps, SecOps in the traditional sense. We used to see developers just develop, they had to have an eye towards security within their code. But now with Kubernetes and a lot of the other platforms coming in, we are seeing more of a shift to that falling on the developer's shoulders and they're having to take responsibility for it. Do you think that's a little bit too much for developers to have to take on or is this something that you think developers are pretty anxious about?
Marc Hornbeek (00:05:52):
I have a lot of philosophies about that and certainly DevOps has a lot of complexities by itself. You add security to the mix and there are a lot of complexities. And then if you add the idea of trying to have developers understand what's going on in production security, it's yet another whole layer. But this is exactly where AI can be beneficial rather than replacing people that can help fill in the cognitive gaps or the overload. So AI isn't really, I think at least in this case, not really going to replace people. It's going to augment their capabilities so they can actually do a better job of security. And certainly developers shouldn't be afraid of security. They should be afraid of not having enough capabilities to support them as they address security concerns better. And that's where the opportunity lies, is to leverage agentic and generative AI on top of machine learning to take advantage of those new tools to really cover the ground better.
Nicky Pike (00:06:47):
So you're talking about AI and I mean that is the big talk out there, everybody. I mean it's on LinkedIn, there's swarms of posts coming out. I mean, you just came back from Black Hat where everybody was talking about AI agents and agentic AI and you made the statement that AI adds value without replacing us. So what kind of task are we seeing where AI amplifies and automates?
Marc Hornbeek (00:07:06):
So I think this is a transition's going to happen very quickly. I think the transition to machine learning with a lot of the monitoring tools took some years and generative AI has come up pretty fast, but agent AI seems like it's going to become reality with most security products and practices maybe within a single year it's really accelerating.
Nicky Pike (00:07:29):
Well, and I mean black hats kind of the conference for security mean. You've talked to a lot of people that were out there. What was the vibe? Are we seeing the same fear in the security realm that we're seeing on the developer's side where yes, there is this belief that AI is going to replace developers. I don't believe that to be true, but are we seeing excitement or fear coming from the security side of this?
Marc Hornbeek (00:07:48):
Both. Certainly there's a lot of fear and a lot of the vendors are trying to capitalize on that fear frankly, by trying to position their products as the solution. I was the product partner manager for a couple of consulting firms and of course any vendor will always say their product and be the solution to whatever the problem is. You just add a little bit of extra code and it'll work great. But yeah, it's an opportunity I would say. But there is also fear, not so much I think fear of losing their job as much, although there are junior level engineers I think are worried about that and actually struggling to get jobs. But mid-level, the senior engineers realize that AI is really a tool and they need to get on board with it, take advantage of it, and if they don't, then that's the fear they're going to be replaced by other senior engineers that have done that.
(00:08:32):
Learning about agentic AI and applying it to this problem of security and the gaps, like I mentioned between Dev SecOps and SecOps is a very real thing. I think this is a hot topic and more people are realizing that DevOps DevSecOps part of the solution, but it's not a be all and end all. We've got a gap that we need to close. AI can help us do that without AI. I don't even if it's possible, honestly, there's just too many complexities. So in that sense it's an opportunity and I think most people see that. I think it would be very difficult to close the gap between DevSecOps and SecOps if you didn't have AI to help.
Nicky Pike (00:09:07):
Well, and I mean that's a lot of what we're hearing is that AI is out there to amplify. It can help, it can add to your skillset and actually do things in a faster way than we can. But you've got to look at the converse of that when we're talking about AI and all the ways it can help. We know that there's people out there that are going to turn AI and turn it evil, and you even warn that attackers can exploit weaknesses in AI models by feeding them adversarial data design that just mislead the system. So are we building AI defenses today that become a vulnerability in the future?
Marc Hornbeek (00:09:39):
Every time we change technology, you're adding new attack surfaces and AI adds a whole lot of new attack surfaces. So the short answer is yes, and right now there's not a standard approach to even identifying attack surfaces as different organizations add AI in different means without having hard standards. And I don't know whether we're going to have any hard standards anytime soon, but having scanners for AI solutions for example might be an interesting idea, but certainly training and understanding what the possibilities are is going to be critical. So I'm bullish on things like intelligent continuous security training, understanding both sides of the AI story relative to security, and that's I think going to be important really immediately is important. I actually contributed also to a new course on intelligent continued security, so hopefully that will help the community as well.
Nicky Pike (00:10:32):
Well, I mean when we look at AI, one of the superpowers of AI is the fact that it can do things at machine speed. It can recognize patterns and see things that would take human eyes a lot longer to do. And so I wonder is that a benefit coming in because we are seeing that burnout rate, two thirds burnout rate, we're seeing the skills gap. Is this something where the AI's ability to go in and recognize these patterns and point stuff out, is that going to help or is that going to actually potentially give us even more things that we have to look at contributing to that burnout rate?
Marc Hornbeek (00:11:02):
Well, machine learning and big data have played a role for some time and now there's more data than ever. So that will continue to be true. Training machine learning models on the security relevant data is going to continue to be important with AI ops and all of that. But with gen AI, you now have an ability to create automation much better and also do further types of analysis. With agentic AI, the automation goes up another level. You don't even need the human to issue prompts or something. You can have different roles that are already automated according to goals, and that's certainly accelerating things compared to manual work. That's sort of the reality of automation in general. You get acceleration not just because you automated a task, but because the automation can run 24 7 and not get tired, and you can also scale horizontally or even vertically, you can have a more powerful version or you can have many instances running in parallel. So that amplifies in multiple ways in terms of saving time and providing an accelerator for being able to do things that we weren't able to do before. Unfortunately, that's also true for the bad guys. They can accelerate their attacks and so things like DDoS attacks are going to get a lot more interesting when you're having an agent swarm that's able to stand up thousands of attacks simultaneously on multiple targets and get harder and harder to defend against. But that's where you're really going to have to have AI battling AI.
Nicky Pike (00:12:31):
Well, and I want to put a pin in that. I want to come back to the swarms. That's a very cool point that you made, but one of the things on security, I was reading, I think it was a couple of weeks ago, I want to say it was Gemini. They ran models against some security aspects and their model ended up finding a new vulnerability that didn't exist yet, and it didn't say this is a vulnerability, but it says We suspect this will be one. And I thought that was a very big moment within AI security for AI to actually pick out things before they happen. But I wonder going back to that kind of arms race that we were talking about, the bad guys are going to be able to do this too. Do we see a division line here between where AI is helping us find things before they exist and hopefully fix them versus the bad guys coming in and trying to use AI to find those vulnerabilities and take advantage of 'em before we know how to patch 'em?
Marc Hornbeek (00:13:18):
Sure. I mean, predictive aspects of AI are certainly very attractive and important and real. Again, by training AI on data and in the DevOps world, you certainly have plenty of data to train on which can correlate field events together with development artifacts and help identify things that previously were unnoticed. So yeah, there's actually existing examples of that that I've seen where the regular scanners didn't pick up some concerns because they didn't have the scope of the whole set of artifacts across the pipeline. They were focused, let's say on just the source code or the artifacts of the builds, but AI can have a broader reach across the whole pipeline and even bring in data from the field if it's orchestrated correctly. That's exactly the kind of thing I talk about in the book.
Nicky Pike (00:14:07):
Yeah, I mean that's a scary part when we start thinking about that. And then when we bring in your other point about agent swarms and the ability to use multiple agents coming in and have them attack or have them defend, they're working in tandem. So what is the risk of malicious AI swarms, and is that something that we're already seeing today? I imagine that we are seeing AI swarms being taken into the development side and how to use multiple agents to help with coding. I got to imagine that this comes through on security.
Marc Hornbeek (00:14:35):
Follow what's going on in the dark web a little bit. You see that there's already available tools to take advantage of agent swarms. The most strong use case at the moment is like I say, agent swarms being used for DDoS attacks, but they can be used for other kinds of attacks as well. Search and destroy type activities or search and exploit following different vulnerabilities. Instead of looking at a vulnerability serially from one to the next. You can have agents worms going through a long list and parallel and when they're looking for a new client or target, walk through the existing vulnerabilities and brickley zoom in on where there are some unpatched vulnerabilities is another example of a powerful use case where agents forms are being used.
Nicky Pike (00:15:14):
And it seems like the only way we could keep up with something like that is with the use of AI. But I do worry, again, going back to the burnout, going back to some of the skills gaps that we have, are we looking to see AI fill that skills gap or do you think it's necessary that we start today training the next up and coming security people on how AI works, and what's your recommendations on that?
Marc Hornbeek (00:15:34):
Well, certainly there are many use cases and growing number of use cases, and I am a big proponent of training and even formal training. I think that's the fastest way to get up to speed. So I recommend to my corporate clients and government clients that they have formal training, not just on AI in general, but very targeted applications. And again, I think security is a great one where AI isn't there to replace people so much, it's more to augment a need. I think those are the best cases. There are other cases as well. For example, wherever you have things that are not possible to really perfect, there's no way you can perfect 100% security. It doesn't exist in nature. Similarly with testing quality performance in general, there's a lot of these things that we try to approximate get to at least the point where it's acceptable. So AI has a capability we didn't have before that can at least help us get closer to a hundred percent. Even with AI, it won't be a hundred percent because as you say, the moment you up the game, the attackers are upping the game as well. It's a constant race until we get to a nuclear option or something where if you attack me, I'll blow you up.
Nicky Pike (00:16:46):
That's taking the arms race analogy. It's a little bit more extreme there, but I hear you.
Marc Hornbeek (00:16:50):
Yeah, I don't know how we would do that, but maybe okay, if you blow me up, I'll blow you up or something. But certainly there are things like you can use AI to set up some pretty clever honeypot scenarios that would be harder for the attackers to realize that they're getting trapped because an AI agent can lead them to the trap more than just having a standard static honeypot type of arrangement. But there's a lot of interesting use cases and I think, yeah, we do need to train people on how to leverage AI for these purposes, not just learning AI in general. I don't think that's as important unless you're in an AI company.
Nicky Pike (00:17:27):
Well, and I love the fact that you keep bringing up that we're here to AI's there to augment, it's there to amplify the experience that we're already bringing to it. I think that should assuage a lot of the fears that we're hearing out there because we are getting hit from both sides. You've got the AI companies who have a business interest in kind of hyping up and over talking about what AI can do, but on the back end, at the end, we still humans in there that can make the decisions, that can look at what AI is providing us and give some guidance to that. We've got some of the junior engineers and junior security that are coming in today that have to learn something new, but that's kind of the scope of being in tech. It's always a learning process.
Marc Hornbeek (00:18:04):
The juniors do have a disadvantage. Last year sometime I wrote a blog on devops.com or no, maybe it was tech prong AI, but the seven paradoxes of AI, and certainly there is a paradox. How does the junior person become even a mid-level person without the experience when AI is taking over the junior level jobs? I do worry about the junior engineers. How are they going to get up to speed? I believe in something called an apprentice model where these senior engineers could have an apprentice next to them. I think that approach would be good for the industry if the industry is able to look past just short term cost cutting measures and look more towards the future. At some point they're going to need new senior engineers, but I do worry that in our quarter driven business models, they tend to cut out those types of future things, at least in our western world. I think this is a case where China, Japan as well, some more forward-looking societies are more likely to do that. And I do worry about good old USA whether or not we'll be able to execute an apprentice model. But on the other hand, if we don't, you're going to have a revolt.
Nicky Pike (00:19:12):
Well, and I love your apprenticeship model there. I agree with you. I think we're going to see a turning point where a lot of the companies now saying AI is going to replace all the juniors. To some aspect that's going to be true, but if you're replacing all your juniors, you don't get that chance to become a senior. And at some point we're going to need seniors. And I see this model of AI becoming a peer. Juniors are going to direct a bunch of AI models. The seniors are going to direct the juniors. That's how they're going to grow into their role, and we've got to keep that because you can't replace years of experience. AI can see patterns, it can spot things, but it can't replace that creativity or that human mind to come in and take a look at something. So I'm hopeful that what you're saying is right. Engineering is one of those things where we do see interns, but software engineering is kind of a paradox in itself because we call it engineering, but we do a lot of things different than we do in most engineering traits.
Marc Hornbeek (00:20:02):
Well also I think if you are a junior, strongly recommend that you look for mentors that have experience. There's a lot of old guys like me around that are very happy to take on a few mentees. We like to share our knowledge. We know we're not going to live forever and we'd love to have a legacy. So I do mentor a few people and I think if junior people would just reach out a little bit, find some people online that they kind of respect and trust or could develop a relationship with, that's a way to break in as well. And then they can be used as a lever to get employment or get positions and then grow. So I think a mentoring model works as well. I also think learning institutions have even more responsibility these days to be a source of current, which is tough because a lot of the learning organizations, they're not keeping all their courses up to date because things are changing so quickly.
(00:20:54):
So I'm an ambassador of the DevOps Institute, but we have to do a really strong job to keep up to date so that you can really be a source of truth if you like, or at least a source of data of the practice, if not state of the art activities. Where do people go? A lot of these things aren't standardized, but there are certainly good practices. I hesitate to say best practices, always the debate about that. Where do you go for that? Where do even the experts go to keep on top of everything? So I think communities of excellence are something that we all need to develop more and more around these topics. Obviously conferences like LAC Hat or a good community involvement in the world of DevOps that I'm immersed in. Things like DevOps days, activities in the DevOps institute or exemplars in that regard. But that's the way people will need to embrace it. Don't stay in your little bubble expecting to look at a textbook and then get a job. You've got to reach out to experienced people and work. Be open to that. It's tough for engineers because engineers, including myself, we originally went into engineering. We weren't very good at dealing with people. We thought we'd just have to deal with stuff.
Nicky Pike (00:22:05):
I feel you on that one.
Marc Hornbeek (00:22:06):
But unfortunately it turns out you still have to deal with people. Better bite the bullet and say hello to somebody and be a friend.
Nicky Pike (00:22:15):
Well, and that's a key point is that mentorship model AI, there is that hype. It's coming out there, it's going to replace. I don't think that's true. I do think it's a little bit true that if you're an engineer that's not willing to go out and learn, and let's be honest, we're in one of the greatest times in technology history that I've seen in my career right now because things are moving so fast and the potential there is so high.
(00:22:38):
If you're blindly just okay going into AI and accepting what AI tells you, you're not doing taking the accountability to learn more. If you're not going out and finding those mentors like you, if you're not going out and talking to DevOps-the-Gray and other people in the field to learn more and learn how to control and manage and work within the AI structure, then you will be replaced. I do believe that to be true, but I don't think just it's automatic that you're going to be replaced if you're willing to put in the effort, you're willing to take the accountability and you're willing to try something new. There's a lot of potential on how AI is going to be used.
Marc Hornbeek (00:23:12):
Yeah, no, I respect people that make an effort try, even if they fail, as long as they're of a nature that they pick up and show that they learned from something. Those are the people I like to mentor, right? Not just trying to hit a little goal. They have a bigger purpose in mind, kind of a life goal, particularly like working with people that see themselves as somebody that will try to make a difference in the world. Whatever that area of the world is they want to make a difference in. It's all fine no matter what it is. Whether you want to be an excellent trash collector or a top CEO somewhere, it's fine with me as long as you really make a solid effort and focus on it and try to build and help people.
Nicky Pike (00:23:52):
Yeah, I think everybody that's listening, you heard that. Go find a mentor, look for experience because yes, AI can aggregate information. It can bring information out very quickly, but it has a very hard time applying experience to what that information means and how to digest it. So you heard it from Marc here, go find a mentor, get into it.
Marc Hornbeek (00:24:10):
Yeah. One of my sons has done that. I often get job offers because they confuse me and him. Same first initial M Hornbeek, Matthew. He's chosen all of his job choices according to who's leading and who's available to mentor rather than just salary and so on. He's always looked for the next mentor or two, and Beth has done himself very well. He is now the top-notch DevOps engineer, DevOps manager, SRE, SRE manager, AI expert, security expert, and he is only, what is he now? 30, 39. They started off as a psychology major. So his human skills from his undergraduate psychology degree has actually done him very well because he's realized you reach out to people and just be human along the way while you're learning technology and helping other people being respectful and learning how to project trust that way, you're going to get a lot more done through collective efforts and collaboration and truly figuring out how to help each other rather than just trying to be the next king of the castle.
Nicky Pike (00:25:10):
Well, I got to imagine that he had a little bit of a step forward growing up with DevOps, the gray as a mentor and being close to you all the time. DevOps was probably something he was weaned off of.
Marc Hornbeek (00:25:20):
Maybe implicitly. I don't know. He did a lot on his own. I give him a lot of credit for that, but he did a lot of self-study courses. He really didn't do any technical degree, but he's done a lot of self-study courses and online courses, and mostly it was through picking good mentors. I've advised him on that idea, but honestly, you can do this without having a DevOps-the-Gray, but certainly having mentors.
Nicky Pike (00:25:42):
But having a DevOps-the-Gray makes things easier.
Marc Hornbeek (00:25:44):
Maybe. Yeah.
Nicky Pike (00:25:45):
Yeah. Well, let's get into the reality of this. So you've talked a lot about continuous security as a replacement for DevSecOps plus SecOps. What differentiates those two things?
Marc Hornbeek (00:25:55):
Well, like I said, DevSecOps is really about trying to prevent new vulnerabilities from getting deployed into production. That's really its main purpose, and it doesn't really pretend to be more than that, although some people think it's more than that, where SecOps is more about defending against attacks that are going on in production. So those two viewpoints are very different, but having information shared between the two can make both objectives better, and that's the idea. For example, a lot of tech ops folks have radically different tools they're using than the dev side, and how are they going to share information if the tools are different? If all they do is exchange information through tickets or something, that's not going to keep up with things. So tool alignment is just one example of how you get true alignment, and of course sharing data requires, especially the volume of data, requires smart tools to do that in anything close to real enough time to be practical and useful.
(00:26:54):
So this is where the AI gets to be particularly important. So commonizing monitoring tools, commonizing, the use of automation tools, those are some examples of how you can bring together SecOps and DevSecOps definitely on a basis even just recognizing that there's value in working with each other and deliberately spending time, whether you have guilds or organization structures that bring these things together. Usually I don't think it's necessary to actually put everybody under the same manager or something, but definitely having communication structures that are fluid between security and SecOps teams and DevSecOps teams is important so that you do share the latest attack information, collaborating very explicitly on certain tasks. For example, threat modeling is critical, both the dev and SecOps folks to be involved in any threat modeling efforts, and that shouldn't be just a one-time event once in a year or something could be an ongoing, almost like irregular event where you're constantly keeping up to date because these days the threat landscape is changing so darn quickly with AI and even traditional threats, right? Don't ignore the traditional ones as well. Every one of these existing as well as the new attack surfaces are still very real, and I worry about that too. Maybe the industry goes too far about worrying about AI without keeping up to date with the existing stuff. Just so much overload.
Nicky Pike (00:28:21):
Well, and I see, and you can correct me if you think differently on this, but I see the DevSecOps kind of the shift left that we were talking about where a lot of companies are looking to, for lack of a better word, put that responsibility onto the dev, so they only have to hire one. Where I see SecOps is a more specialized, and I can see benefits and pros and cons to both sides, but if I'm building a house, I'm not going to trust my general contractor to come in and completely do all the wiring. I expect him to know enough to oversee the electrician and make sure that they're doing it right, but I don't expect him to do that job. That's kind of the difference that I see between DevSecOps and SecOps itself is specialization versus generalization. I think developers should have an irate security, but do you think it's asking too much of them to really jump into full DevSecOps? Is that just a recipe for potential disaster when we're expecting too much of one person?
Marc Hornbeek (00:29:10):
It would be too much if we don't support them with training and tooling and incentives. I'm reminded of the equivalent situation in testing, which I have a big bee in my bonnet about, which I have had for many years. There's this idea that you have to have a separate quality organization in order to get quality, and the developer should not be responsible for their testing because that's a conflict of consciousness and it's a cognitive overload to expect them to do good testing. Honestly, that's bullshit. It's been many, many times I can have access to a lot of data over the years. It's almost the opposite. The highest quality products are those that have the least amount of QA teams.
(00:29:51):
The ones that have the developers responsible for quality, including all the testing and test automation. This is partly what's the root of things like test driven development and so on, and BDD, if you're doing it properly, you get the developers more involved, but you can't expect them to do it if they don't have the training and the tooling and the motivations. It's the same with security. It's bullshit to think that smart developers can't handle security unless you don't help them do it, right? If they don't have the tools, of course they can't do it. But today with the platform capabilities that are being built up, you can build in a lot of the tooling so that it's not even, you don't have to just like a pipeline, maybe have 20 or 30 tools in a DevOps pipeline. Nobody wants to deal with 20 or 30 tools. Instead, you off escapee that through platforms and make the whole CICD process a command or two rather than everybody having to log into every tool in the pipeline. Same with security. It needs training, it needs support from tooling and it needs culture support. And then I think it's fine, right? In the meantime, sure, there's going to be a lot of people objecting. Just like whenever I go into a client and tell 'em they shouldn't have such a big QA team. Some of the QA people try to kill me.
(00:31:03):
Even the developers, I've run continuous testing courses and developers and QA people are told to show up and the developers say, what the hell am I doing here? I'm not qa. By the end of the course, they realize it's the QA people that shouldn't be there.
Nicky Pike (00:31:17):
That's interesting. Well, and you brought up the infrastructure and platforms. I may have a little bit different to take than you. I do agree. You've got to start planning, especially with AI coming into this, having an AI development infrastructure, a fabric if you will, that bolts in the products that you want to use because every company's going to have different product, different tooling that they want to use. So how can you bolt those in? Where I may disagree with you a little bit is you use the word platform. Me personally, when I hear platforms, they're good, but they're opinionated, they're defined, and you've got to use things in a certain way and I would say a majority of platforms out there, which could be limiting to a lot of organizations and enterprises, or it could make them have to change the way that they work and what their flow looks like. So it seems to me you would want something a little bit more open, a little less opinionated, but having that infrastructure and the ability to bolt in whatever you want, and maybe both ends the wrong word. I think that's where we fall into a lot of problems is that we do try to bolt on security or we try to bolt on process on top of a workflow we have, and that generally fails. We've got to be thinking security first. We've got to be thinking development first, and then there's the question, okay, if you're development first and security first, how do you rectify two things supposedly needing to be first there?
Marc Hornbeek (00:32:28):
Yeah, you're right. I wouldn't disagree with you. I think that you can overdo it with platform for sure, though they need to be flexible. At the same time provide the value of not requiring the engineer, using them to know every tool under the hood and at the same time support with things like common use cases, standard templates and things that otherwise the developers or QA or whoever's using the platform may think they have to reinvent themselves. So there's an opportunity to use a platform as kind of a center of excellence that they can draw from, but there should be options that are not just one size fits all. That's pretty much impossible. I've seen it done, but only in very strict organizations that only have one type of product or something. But most large enterprises I worked with one recently had over 900 pipelines. They had 67 different tool variations for CI alone, and we did figure out how to get it down to seven tool variations over two years. But there were still variations is the point. And some of the combinations work better for some apps than others, but you definitely need to allow for some variations.
Nicky Pike (00:33:33):
And on that same line, I mean in your book you write about alert fatigue, compounding the issue, and we're seeing today 75% of managed service providers are absolutely drowning in alerts, and that's causing them to miss about 30% of them. So when we talk about platforms and we talk about pipelines, what before we add more AI tools, how do you suggest that we fix what's already broken? How do we get out of that so that we're not drowning in these alerts and we know what to do with them?
Marc Hornbeek (00:33:59):
Well, this is where this concept of observability comes into play where you want to make sure that you have a strategy. First of all, I think too many people go ahead and just build metrics and logs without really having an overall strategy. So what is it that you think is important? It's kind of the same thing as testing and QA and dirty. Again, there's no such thing as a hundred percent. So what's your strategy? What are the types of things that are the highest importance and to whom? So knowing what you're going to prioritize and who's going to deal with the different aspects that you prioritize is critical. So start with a strategy and don't just do observability for observability sake. That's just going to create a sea of alerts instead, make sure you've got a clarity around what your priorities are and review those frequently.
(00:34:45):
Right? I recommend you do the observability assessment about every six months because you'll find out your priorities do shift from time to time. But don't just blindly go ahead and just add more metrics and add more logs and so on. Focus on outcomes more than process metrics tend to be better, but also provide a way to telescope down to root cause because sometimes if you're only focusing on outcomes, you can see that you're getting worse, but you won't know why. So for every outcome metric you put in there, you better have a strategy or saying, all right, if that's a bad outcome, how are we going to figure out what the root causes are? Don't just keep adding more alerts for every type of thing you log and alert, you better have some kind of strategy, categorize it, cluster it, decide who's going to do what with it, rather than just adding yet another alert or another metric or another fancy chart on a dashboard.
Nicky Pike (00:35:41):
So let me pare it back what you said because I think that's a great point for people to hear is if I'm hearing your rights, you're talking about not just having alerts, but smarter alerts. So before you put something out there in observability, you should have a plan for what this alert means from you, from a business perspective, what it means from an operational perspective, as well as kind of a playbook for how you're going to look at that alert. And then as you said, you've got to reevaluate those on a constant basis with the fastest technology is changing your alerts from two years ago or may not even be relevant in this time and age, especially when we start adding AI and machine speed on top of this stuff.
Marc Hornbeek (00:36:16):
Architecturally, if you think about it, and this is something I do with clients, I try to make sure that we have a consistent approach for logging and alerting where there's metadata associated with every alert. So it's kind of like scanner checkers, right? I mean, sometimes certain checkers are important for an application, sometimes they're not. So you want to be able to prioritize those through some profile configuration. So same with alerts. You may find out what's critical these days is different six months from now, and you want to be able to, without recoding everything, set the priorities for those alert tags or alert. That's an idea. That's an example of a technical approach that I like. So everything you're reporting, in fact, even for things like test results, alerts, make sure that you've got a priority field that goes in there that you can then adjust over time because it's a very dynamic world these days and priorities will shift from time to time. It's not a, maybe it's the reality, and I think that happening even at a faster pace than ever before.
(00:37:16):
Once attackers figure out one approach, they're going to shift to a different one. So you're going to start seeing different priority in your threat modeling. You need to maybe adjust all the alerts and all the priorities across the whole product line.
Nicky Pike (00:37:28):
And on that line of smarter alerts, I mean also in your book, you state that cyber adversaries are leveraging AI to exploit vulnerabilities more quickly than security teams can actually respond to. I think the smarter alerts is something that's going to be critical to that because you got to kind of cut some of the noise out versus what's really actionable, what you can do. But is this a race that we've already lost or is there a way that you think to level the playing field? Is the smarter metrics the method or is it only one step for us to try to level that playing field?
Marc Hornbeek (00:37:56):
It's certainly not the be all and end all. I mean, there's a lot of steps, like I say, starting with just awareness and training and then, but having placed strong architectures that can be adjusted is critical. I see too many organizations that build in fixed architectures without really thinking through even good principles of system design. Right? Let's take an example. You build a pipeline and you put all your release policies as code inside the pipeline. That's a dumb idea. A release is kind of a control plane, right? How well are the artifacts that are going through the pipeline? Are they sufficient to satisfy your release criteria? So in other words, one of the first rules of system design is to separate a controller from the controlled. In this case, the controlled is the CICD pipeline. So you need another layer, which some people call the application release orchestration layer that's above CICD pipeline.
(00:38:53):
So you put all of those policies as code and orchestration at that layer, not inside the pipeline tools, but I see so many organizations doing that. And that's the same thing with security. Be careful how you architect things, make sure you have layers of abstraction, otherwise you're going to be in a mess of hurt as things evolve and you have to go back in and recode the fundamental level things. If you want to replace a scanner with a different one, for example, or add a scanner or add another test layer, you shouldn't have to re-architect all your release policies.
(00:39:23):
And similarly, if you're building a service that has many pipelines, a microservice-based service, you don't want to re-architect your release policy. So you need a layer above that. That's where value stream engineering comes into play. So a value stream management platform over and above application release orchestration is a layer. So it's a multi-layer system. Ag agentic AI can help with all of those layers, but be very careful about how you architect things. Are you going to dig yourself a big hole? The smart companies, the ones that are so-called elites, have learned this over time. That's how they're able to do things quickly. They don't have to redo things a lot when things change. I think I lost track of your question. Sorry.
Nicky Pike (00:40:05):
No, you actually led me into another one because you talked about extraction. I love the statement of the controlled versus what's being controlled, and that brings to mind a incident that happened here recently. It was all over LinkedIn. It was all over social about AI going in and deleting a production database. It scared the hell out of everyone, right? It gave the name sayers a reason to say you shouldn't be using AI. But when we're seeing organizations already jumping in, there's this overload of AI tools. We've got 20% of organizations that are facing shadow AI incidents today. How do we go about giving AI enough power to help without letting it burn down the house? I guess what I'm asking in simple terms, what's the difference between helpful AI and dangerous AI and security, and how do you make sure that your AI is keeping the white hat on?
Marc Hornbeek (00:40:51):
I would say that's a very important question, and I would also say is kind of a industry work in progress because there's not enough experience yet with AI at that level. But I would say at least start off by using the basic good rules, right? Test and verify as you go and build systems that are going to be resilient not only to failures, but also to change because these systems are not going to be static. They are going to evolve in multiple ways. So maintenance and reliability of the systems is just as important as getting something to work. And again, I get so frustrated with some clients that don't want to pay for that aspect of a project. They want to get something up and running, but then when you say, yeah, but that's only half of the job, you need to operationalize it. You need to make it resilient. You need to make it so that you can maintain it, and you need to have a pipeline for the system itself, not just for your application so that you can maintain it. And unfortunately, a lot of organizations don't want to. They'll say, well, we'll deal with that later when it becomes a problem. Well, it always becomes a problem.
Nicky Pike (00:41:53):
Yeah, it's a problem at the start.
Marc Hornbeek (00:41:55):
And even monitoring and measuring the benefit, this is another one that I've literally got. Maybe I've become a bit of a curmudgeon, I must admit, but I've gotten to the point where I refuse to take on new consulting work unless the client will also agree that we're going to build in metrics for both progress as well as effectiveness. If we don't do that, then it's useless. I know that it's not going to work because they will have no way to even demonstrate that it's working or that it's continuing to work.
Nicky Pike (00:42:22):
That blows my mind, Marc. I don't even see how that could be why you would need to put that in his condition. I don't see AI fundamentally changing the proper way of doing things. You still have a good architecture. You still have to have ways to measure it and adjust to it. I don't see that changing. What I do see is the speed and the scope of what we're capable of do with AI, but to me, it's the same as what we've always done. You still got to have those base foundations. You still got to think about the problem at the onset and build for it, but now you just got to consider how fast we can go and how much more we can do.
Marc Hornbeek (00:42:54):
Yeah, I worry about that. It's been true for a long time with just automation in general where I see people putting automation in places where it really ought not be right, just because I can name many examples because a couple of times in my career I was responsible for engineering VP of test systems that were being sold, things like that. And there's always a tendency to put in things like test case automation within a test tool. Sounds right. But actually, no. Usually one particular test tool is for a particular kind of test. So you really want the automation to be somewhere above that because a test for a lot of systems involve multiple types of tests. So you don't want different kinds of test automations depending on what kind of tests you're doing. You want the test automation to be common above the different tools.
(00:43:44):
So what I worry about with AI is maybe because it's so much easier now to generate automation with gen AI and agent AI, I am imagining we're going to see a whole lot of automation capabilities that are driven by AI in places that really shouldn't be there. You need to layer systems better at a better architectural design. Instead, you're going to have automation systems driving automation systems, driving automation systems, which is not good structure and is brought with many possible failure modes and maintenance problems that I do worry about. I've seen it happen too many times in, let's say the telecommunications world and enterprise where they do perfectly good projects, but at the wrong layer.
Nicky Pike (00:44:28):
Well, and that kind of goes against the fundamental principle always. There's an old statement, at least when I was coming up in the industry, you don't automate anything until you can do it well manually. You've got to know what you're looking for in order to automate it. But with AI, I think that's one of the downsides that we are seeing is that people just, they want to jump on the wave. They want to be part of the train. So they're just pushing AI into places without really thinking about it, without even seeing how do we do this from a human perspective before they put AI in. That seems like a problem. And it seems like a recipe for disaster, which is probably why we're seeing a lot of some of the AI initiatives within enterprise that's failed today is because they're doing exactly that. They're trying to be part of the phenomenon. They're not trying to solve real problems with it.
Marc Hornbeek (00:45:10):
Yeah, stand back, look at the big picture. Where does it make sense to put those functions? Just because you can do something doesn't mean you should do something. I can tell you many times in my career, I was on the verge of being fired. The president of the company would come around and say, you need to do this horn beak. We need it next week or next month or something. I said, I hear you, but you're going to get a planning report in three months because we're really needing to think this through, and we finally get a system a lot later than that person wanted. But when he finally saw it, he said, holy crap. Wow, this is amazing. And then you end up getting a president award or something. So it's worthwhile having, I use the word courage. You've got to have courage to look at the big picture, stand back and try to build a solution for the bigger problem, not just the immediate local one. And nine times out of 10, that's going to have a lot more value for everybody, even though a lot of people are going to be around just saying, I'll just do it. Just show a demo, build an MVP of something that works, rather than figuring out what you should be doing in the first place.
Nicky Pike (00:46:13):
Yeah, I'm with you. I mean, I'm going to be honest, Marc, we've kind of painted a pretty dark picture leading up to this. We've shown where this could head what some of the potential pitfalls are, but there's got to be good stories out there of people that are getting this right. What are they doing differently? Where are they applying AI into security and getting it right? Give me a little light at the end of the tunnel here.
Marc Hornbeek (00:46:34):
Yeah, there's a lot of light. I mean, definitely AI is a powerful tool that is going to create some amazing benefits. So overall, I'm optimistic. We need to take a step back, understand how to use it properly. I think we're learning as a collective industry how to do that. But I have no doubt that at the end of the road, there's going to be some pretty amazing stuff, and already we're seeing a lot of good uses of it, and we'll make a lot of failures along the way. That's not unusual. And I think if we can change the learning model for newer engineers to more like a mentoring model like I talked about, or an apprentice model, I think that'll give hope for the future as well. So I'm trying to contribute to that through my efforts to the DevOps Institute, but I hope more people get on board with that approach, not just let go junior engineers because they don't have to be senior already. Give them a chance to have a mentor. Don't just drop them for profit reasons only that I think is very short-term focus. So I'm hopeful that that will be realized, at least in the smarter companies, and hopefully they'll show the way for others overall. We'll end up with a lot more powerful technology and people with solid roles that they can grow with and build the next generation of things. Hopefully, I'll live long enough to see some of that.
Nicky Pike (00:47:52):
Yes, sir. Well, and you brought up, don't do this just for profit. We're going to see some bodies left on the floor when this is over because people jumping onto that, I do think we're going to see some really great use cases and really great success stories come out. But it's my belief that the companies that actually approach this, and we're not looking to replace people, we're looking to amplify. They keep their engineers and they build AI as a way to augment and increase the productivity of what we're seeing both on the security front and the developer front. Those are the people that are going to succeed, the ones that come in and say, Hey, we're replacing everybody with AI because AI can do it all and thinks that AI is this age. I believe they're going to be some of the ones that we see left behind.
Marc Hornbeek (00:48:32):
Yeah, agreed.
Nicky Pike (00:48:34):
Well, as part of your book, you propose continuous security as the evolution beyond DevSecOps. So tell me like I'm five, what does a developer's Monday morning look like when they come into a continuous security world versus the chaos and overload that they're seeing today?
Marc Hornbeek (00:48:49):
Well mean a lot of things, but fundamentally, it's the mindset, right? When you come in the morning, you want to think about not just the future you're going to develop, but also how you're going to make it safe, and it should be equal weighting through developing the future. So it starts with just the mindset. So it means that you need to have some training to start with, and it's not going to be a one-time shot training part of your schedule, whether it's daily or not. Learning these days, micro learning is getting to be more and more of a thing. So always have a learning objective while you're doing things, and security is not going to stand still. It's got to be part of your self curriculum and practice, right? Practice with the tools, practice with applications, and try things, because practice is the only way you can become a master of something.
(00:49:33):
So you have to be constantly upgrading your skills looking outwards, not just within your job but outwards to see what's happening. So keep an eye on the industry. Use the AI to help you with your own research. It's a great way to use AI and pretty much don't let a day go by without doing a little bit of micro-learning and then build in some measures, are you getting ahead? Do you see results in your efforts? Don't assume other people are going to recognize that unless you can demonstrate what you're doing, show some success metrics, make sure you have that. You can demonstrate results. In the case of automation is often how much time is being saved, whether it's security checks or quality or anything. So put in place in your work, something that you can demonstrate and measure and show your value, because I think the ones that show the most value are the ones that are going to get ahead and be in a position that you can go the next level with your career.
Nicky Pike (00:50:31):
There's this old statement in the development world too, fail fast and iterate. That's how you make improvements. That's how you get your customers. It feels like that's a very different connotation in security because if you fail in security that has financial implications, it's got personality and how you're presented out to the world implications. What are your thoughts on that? Does the fail fast still work with this when we're talking AI and security or just take on a completely different model?
Marc Hornbeek (00:50:56):
Well, fail fast and control the blast radius fast.
Nicky Pike (00:51:01):
Good.
Marc Hornbeek (00:51:01):
I've had a lot of cases where we had some pretty nasty failures and I thought I was going to get fired, but what saved me the get out of jail free card was always being transparent about it and running like hell to control the last radius of the damage and instead of getting fired, you end up getting an award or a promotion because everybody recognized, wow, this person really react to this and raise to the cause and plug the holes and mitigated the issue so they wouldn't happen again, and learned a few things while they were doing that, and so instead of it being a big failure, being open about it, I learned that lesson of learning from failure. When I worked at Bell Northern Research, I was presenting my projects in a monthly project status meeting, and the president walked in and I was very proud that my projects were all green, green status and I thought, oh, he is going to be happy that he sees all green. No, he was pissed, really pissed. He said, there's not enough blood on the floor around here. You guys aren't trying hard enough if it's all green, I mean, you guys, you are slackers.
Nicky Pike (00:52:00):
I don't disagree with that. I think that's a great way to start off a career is having somebody tell you that if you're not failing somewhere, you're not learning. And I think that is one of the things that separates us, the humans out from AI, is really AI can't fail. It doesn't know it's failed. It's just grab patterns and it's supplied patterns. It doesn't know if they're right. That's where we've got to teach it. That's where we've got to jump in and use our experience to tell AI, this is what good looks like, this is what it's not, and that's our failure pattern. It's not AI's failure pattern.
Marc Hornbeek (00:52:28):
And when there's failures, run, jump on it and make sure it doesn't get out of further control. I mean, make that transparent and share that lesson with other people. Don't hide it. You can be more of the hero rather than the villain if you do that properly. Communication has a lot to do with it and being transparent, building trust and respect people. Respect people that are transparent. I actually think this word respect is the most important word in any language. It's the root of many other good characteristics and it starts with being transparent. So that's true for failures as well.
Nicky Pike (00:52:59):
Oh, sage advice, sage advice. Marc, I know in your book you also talk about AI driven zero trust, something that continuously validates user behaviors. Walk me through an example of that. When AI spots something weird, what happens? Let's keep it simple. Someone logs in from a strange location. Where can AI help us in this AI driven zero trust?
Marc Hornbeek (00:53:19):
Well, I mean just because AI has access to a lot of data points and collection, it can scan things pretty quickly to figure out where there are problems. I can think of a case where I was working with a data network in Europe actually, where we couldn't figure out what the heck is going on because all the systems were working properly as far as we could tell past all the self pests and so on. But it turned out that it was an inside attack where a disgruntled employee was using his privileged access commands to take down systems at random. So we were able to scan through a lot of information to figure that, well, AI can do that in an instant. It took us a week at that time, but it would've prevented a lot of network failures. There were a lot of clients not happy, including a lot of banks and so on in Germany. So that's a great example where it can really shorten the time to detect issues and suggest solutions as well. Very quickly.
Nicky Pike (00:54:12):
Alright, let's talk about implementation. You argue that AI requires a fundamental shift from reactive to proactive, from manual to automation. With most organizations, they're barely handling keeping up with the security context today. So what's the first step they should take tomorrow to get into this intelligent continuous security?
Marc Hornbeek (00:54:30):
Read the book. That's a great plug. I love it. Well, first step is buy the book. Yep. No, seriously can go on my website. There's a discounted version, highly discounted on PDF version. But anyway, yeah, I mean, teach yourself about it. That's the first step. I always think people should educate before action, but other than that, start small. Just like any other activity, build an experiment, something that's important to you. I can't say what is important to you. You're going to have to figure that out for yourself if I build an example and build up a solution around that. So whether it's maybe some monitoring capability that's valid to both dev and ops that you're going to drill down on and try to get more information about something that failed recently would be a good example to see whether you can apply some of these principles to solve that problem.
(00:55:19):
Something that was important. Don't pick the easiest thing, pick something that's a valid use case that has meaning and is viewed to be important. I actually have a 10 point checklist for selecting use cases and then build a model around that. Don't just build it one time. Build something that you can then share with other people. Get feedback and grow together. Put together a guild or some center of practice where you bring people together or hackathon or try to build it up rather than just keeping it to yourself because that way you're going to accelerate and amplify the efforts of not just yourself, but your whole organization and be viewed as a leader one step at a time. I think a lot of the growth in my own career has been like that. Start with a simple situation and make a success out of it. Share that success. Build on it, advertise it. Don't be shy. Don't be that shy engineer in the back room that reinvents physics and never tells anybody. You're going to have to toot your own horn a little bit and then build on that success.
Nicky Pike (00:56:15):
I highly encourage that. I do want to say, when we release the episode, we'll put a link to your book down there.
Marc Hornbeek (00:56:20):
Okay.
Nicky Pike (00:56:20):
Folks, it's impossible to go through every gem that Marc has in that book in an hour's timeframe. You're only going to get this stuff by reading it. It is a good read. There were some things honestly that were over my head, Marc. There were some aha moments that I had when I was going through it.
Marc Hornbeek (00:56:34):
Oh yeah.
Nicky Pike (00:56:35):
But to your point, this is a great thing. Take the book, take it to a user group, take it to one of your team's calls or something, bring up a chapter, walk through it and see where it applies. This is a good practice in depth of how you can go through and actually use some of this knowledge. You're going to gain more from a collective knowledge than you will from your own. Marc helps provide that. So we'll make sure to put a link down there so people can go get this and read it. I highly, highly recommend it.
Marc Hornbeek (00:56:58):
And you're welcome to contact me. By the way, like I said, at this point in my life, I just like to help people. That's really why I exist. It's not about making money. It's not about trying to grow my career or something. If I can help you, I'm happy to do that. If it becomes hours of help, then maybe we need to talk about an engagement, but if it's answering...
Nicky Pike (00:57:16):
You are a consultant by trade, right?
Marc Hornbeek (00:57:18):
Right.
Nicky Pike (00:57:18):
Well, let's kind of end this on a high note before we leave. Let's do a little bit of hope here. Despite all the challenges that we talked about, why are you optimistic about AI's role in security? What future are we building towards right now?
Marc Hornbeek (00:57:29):
Well, on a high note, AI is giving us opportunities we never had before with security, things that we just couldn't even imagine. Even this idea of combining SecOps and DevSecOps probably isn't even possible without the support of AI, even though AI brings in new threats. So it makes it not only an opportunity, but also an imperative. It's a learning opportunity. It's a way that we can build a better tomorrow, and everybody that gets on the bandwagon and starts using it, it's going to find that it's a way to learn. I've always told my kids and anybody else learning, if you really think about it, is the only thing in life that is fun. That's a pretty cross treatment. But you think about it, it's all about learning. If you have to do the same old thing again and again, again, I don't care what the topic is, it gets boring. It's always about some element of learning that is enjoyable, and we might as well enjoy life. Nobody knows why we're here anyway, so let's enjoy it. Let's learn about AI. Let's build the next generation of AI solutions.
Nicky Pike (00:58:33):
When we look at the grand scheme of teams, our time here on Earth is pretty short. We might as well fill it with things that make us happy and that keep improving our mind. Your statement about we haven't even began to notice what AI is going to do for us. I agree with you. I was talking to a coworker and they made the comment, well, we're just now seeing the tip of the iceberg. I said, I don't even think we're seeing the tip of the iceberg. I think it's just now starting to snow and the temperature's dropping. I don't even know if we started the iceberg yet with all the potential that we have with AI.
Marc Hornbeek (00:58:59):
Yeah. Agreed.
Nicky Pike (00:59:01):
All right. Well, we end the show. We end each episode with a prediction. So I've got two questions for you. On the prediction front, are we living in a world where AI has made us more secure or is it amplified and extended the threats that we deal with today? What's the one thing that will determine which way we go?
Marc Hornbeek (00:59:17):
The one thing, oh, boy, that's a very difficult question. The problem with the future is it doesn't happen yet, right? So I think we're sort of in a continuing balancing act between the good and the bad actors. We need to stay ahead of the bad actors. So I think education is, at this point, is probably the most important thing. That's my own opinion. That's the way you can engage collective mindset. It's not going to be done by one person, and we're not going to have some angel engineer that solves all the world's problems. It's going to be a collective knowledge and sharing use cases and sharing information that's going to make things better and try to keep ahead of the bad actors because definitely the bad guys are very proficient also at leveraging AI. So both are progressing in parallel. Let's embrace learning, build on each other's capabilities.
Nicky Pike (01:00:12):
Love it, love everything about it. Now, the controversial take, what sacred cow in the security industry needs to be slaughtered, and why will AI be the one holding the knife on this one?
Marc Hornbeek (01:00:23):
Yeah, so this idea of separate silos, which has always been a concern, but it's now becoming more, again, imperative. This idea of organizations that have their own local goals, we need to try to bring together like the SecOps, the Dev, dev, SecOps, we need to bring together people to more of a unified view because the bad actors see it that way. They see that as an opportunity to get in between. And if you've got corporate VPs that are just trying to tout their own objectives without working with each other, and I see that again, even just recently where I was brought into a meeting with two senior VPs, one on the dev side, one on the ops side, and I might as well have not been there just because I was there. It precipitated all kinds of fights. I never got a chance to say anything, and that was the biggest hindrance to progresses. Just the fact that they have these very strict silos and they don't trust each other for various past reasons, but they need to get over it and look at the bigger picture. So that's what needs to be changed. We need to focus on the mission, not on our local goals and bring together, that doesn't mean everybody needs to report to one manager. It means that we need to have open communication and trust each other. Let folks do the right thing as long as they've given us some guidance.
Nicky Pike (01:01:37):
I like it. You heard it here, folks. AI is going to help us hopefully bring down the silos, but it only works if we start communicating. We keep up our education because things are changing so fast that it's going to become a part-time job just keeping up with them, at least in the, I'll say the midterm. I won't say the short term because short term is changing on a weekly basis, much less on a daily basis, but education, bringing down silos. I love it. Well, Marc, I appreciate you coming on. I'm glad to have you as part of the Devolution. I'm sure we'll be hearing more from you, and again, folks, go look at the book. There's a lot of things that we didn't even get to cover in there that I think would be very important for you if you've got a security mind, whether you're security-focused or you're a dev. So feel free to reach out to him or me, and we look forward to talking to you next time. Marc, any last statements?
Marc Hornbeek (01:02:22):
Great. Yeah, well, if anybody, I'm working on my next book, which is called Engineering Respect and Trust, so if anybody has any input for that, I'd love to hear from you too.
Nicky Pike (01:02:30):
Excellent. I look forward to hearing that one, because I do believe, I think respect is one of those foundational attributes that everything is built off of. Well, everybody have a good one and we'll see you next time on the Devolution.
Marc Hornbeek (01:02:41):
Take care, folks. Be secure.
Nicky Pike (01:02:44):
Thank you for listening to Devolution. If you've got something for us to decode, let me know. You can message me at Nicky Pike on LinkedIn or join our Discord community and drop it there. And seriously, don't forget to subscribe. You don't want to miss what's next.