The CISO’s AppSec Dilemma: What Matters Most in the Age of AI

[0:00]  I came up on the developer side and started in the first half of my career as an engineer. So glad to be talking about this. Welcome. Joye, please introduce yourself.

[0:11]  Hi everyone. I’m Joye Purser, the field CISO at Cohesity, which makes data backup software and solutions. And before that I have 18 years of experience in the US federal government really with a national and global security background.

[0:31]  Very cool. I’m excited to to have your uh information and insights here today. Heather, please introduce yourself.

[0:38]  I’m going to do this just because I want to show that women rule. Uh my name is Dr. Heather Hinton. I am the CISO at Sitecore. I have been previously CISO at uh three other companies. Uh, I grew up technical, but I grew up on the architecture um and academic side of the of the house.

[0:57]  Amazing. Amazing. Doug, please introduce yourself.

[1:00]  Hi, my name is Doug Kersten. I’m the CISO of Appfire. Um, my background is in banking, financial services, and law. And most recently, I’ve been working in B2B SAS startups, uh, creating multiple security programs and dealing with regulatory compliance and other issues, including a stint at a stock exchange where I helped design trading wireless trading systems there.

[1:26]  Amazing guys, I’m glad you’re on today’s panel. This is going to be amazing. I’ll introduce myself real quick and we’ll get started. So, my name is Chris Lindsey. I am a field CTO here at OX Security. I have 35 years of software development background uh of which has all been in healthcare applications such as medication prescribing systems. I ran a large uh a security program for a large enterprise that was uh doing 2.9 billion lines of source code scans per month. Uh just kind of just a small little tidbit. Um so I enjoy both sides. I do a lot of conference speaking and uh I do a lot of travel. So with that, let’s get started. So topic one, where should CISOs really focus in AppSec? So with this Joye, I’m going to start with this. We know Cohesity is a software company. If a CISO could focus on one thing in AppSec, what should it be and why?

[2:18]  It’s important for CISOs to hold software companies accountable for the quality and security of the code that they develop. CISOs should ask questions uh about the people and the process and the technologies involved in how that code is produced. Chris, I think we really need to get beyond a check the box culture even you know requiring a software bill of materials which is its own topic is one thing but also just getting to know how that company views software development. So for example for us we have mature organizations with mature processes that are just for the security of our products that are overlays. So we have engineering but then we have a product security group which is the bad cop if you will to engineering just to ensure that there is a consistent uh strategy and processes that bake in security uh by design. In other words, that our software and products are designed with security in mind and that are tested um that we have tools and specifically trained teams that really scrutinize that code development to help ultimately protect customers.

[3:50]  No, very true. Uh Pieter, what do you think?

[3:56]  You know, I think that um Joye’s got a good place that she’s coming from. I think that um that bad cop mentality is sometimes what creates a lot of the friction here. And I look to hire product security folks who I say, “Look, I want you to have zero escaped critical and high findings going out, but I need you to do that without anyone ever coming and complaining to me.” And there’s occasionally someone who will just try to kill themselves and fix all the defects. But that’s not really what I’m looking for, right? What I’m looking for is people who understand engineering, understand development, and can sit in the room from the beginning and help them build things that are going to not produce critical findings and high findings. And if they do produce them, they’re going to help engineer and solve the problems with them. And I think part of the friction that we create in appsec um is that it is this layer on top and it really needs to be a layer that is uh intermingled with engineering from the beginning. Um some people call it shift left but I really think it’s a mentality shift for CISOs. It’s not really a mentality shift for engineering. Engineering is there creating products. What they’re doing is not changing. What we do has to change.

[5:15]  Can I jump in? I want to sort of double down on that one. Right. I’ve never met a developer that doesn’t want to do the right thing. I’ve never met a developer that says, “I’m going to build insecure code because I can.” That’s not how developers think. And so if we are going in and we are partnering very aggressively, and I love the zero escaped critical, right? And for me, I’m really fixating on escaped, but that zero escaped, critical, and high signals to people that I’m willing to work with them to make sure that what we’re building is going to be the right thing. And also that I’m going to partner with them to go to the business to unlock the time, the energy, the deadlines to get things done. Right? The reason that we’re viewed as the bad cop is because the developers don’t take direction from us, right? They report up through a different line and that line has very different priorities. So, we need to make sure that we are aligning with their priorities and then partnering with them to do the right thing and by focusing just on the stuff that really matters and not getting our knickers in a twist about, you know, 75 lows that are important, right? That’s not, I’m not saying they’re not important, but by focusing on what matters and partnering with the developers and with the developer reporting chain, that’s how we build that partnership. And if I’m focusing on one thing, it’s that partnership to make sure that we’re driving security.

[6:48]  Yeah. And I think on my side I look at it a very similar way. And I think um we’re totally right here in saying that developers don’t want to do the wrong thing. Um but it’s how they look at what’s the right thing and when they’re talking about what is the right thing they’re looking at their process and their requirements and their priorities and so I think as a CISO you need to embed yourself into their process and their priorities to make sure that that work gets done. If you don’t do that then they do see you as an outsider. They don’t see you as part of the team. And if you’re effective at that, um, they start doing the work themselves and you’re just there to say, “Hey, good job.” You know, the best way to get it done is to say, “Okay, we’re not going to throw something fancy and unexpected on you. We’re going to actually say, we want to work with you the same way you work today, and here’s how we’re going to do that.”

[7:41]  Very true. And it’s rare that developers hear directly from the CISOs or even have more of that direct communication coming down to them. You know, one of the things, and I’m kind of getting ahead of myself on the next question, but I’ll share this. One of the things that worked really well for me when I ran my program was I always said no new highs or criticals. And if you had 10 critical vulnerabilities going into the release, the new one you just released, you had 10, and you’re starting the next release and you’re going to QA and you have 10, but you cleaned one up. You cleared one but created a new one. QA automatic fail. And by doing so, that changes your threat model by adding that additional one that you’re not aware of. And when you do that QA, go ahead and not allow the release to go forward with anything new, then you’re slowly chipping away at the security debt, the tech debt that comes along with it. And you’ll find that you’ll have that natural progression of the vulnerability counts going down. And it works really well.

[8:44]  All right. Question number two, how can security leaders integrate security by design principles without overwhelming development teams? Heather.

[8:52]  So I think we sort of already touched a little bit on this, but get in early and really focus on, I think we’re good enough now with AppSec tools that I’m not worried about the OWASP stuff that’s going to turn up in coding, right? It shouldn’t be turning up, but the tools are going to catch that. Get in early and help at the design stages and help people understand like why we want to put all of our credentials in a vault, why we want to pay attention to all of those secrets, how to think about and design for fraud if I’ve got something that’s got a sign up. So getting in early and being part of the exploration and design process because now we’ve established ourselves as partners right from the very beginning in order to then build the relationship that we need to go further and we’ve also established that hey these things that we’re talking about from a design point of view they are going to manifest as security things so let’s get rid of them right away.

[10:03]  Yeah, I’ll jump in. Well, I think the customer is employing more tools and focused effort to increase their awareness of these vulnerabilities. So, if your teams as a software company or developer doesn’t catch it or don’t care, the customer will see that and then that’s a business value problem.

[10:28]  Yeah. Exactly. And I think on my side, I was thinking more of it as how do you encourage security by design? And so there has to be an aspect of enforcement. And what I mean by that is as you’re going through the process and you’re developing code and code comes out that has these vulnerabilities that haven’t been addressed, then it becomes a “you must fix this now, you must prioritize this now.” But also part of that is the learning experience of “if you had done this before we wouldn’t be doing this now” and then helping them take ownership of doing that security by design early rather than waiting until things are in a much tougher spot for the organization to resolve. So there is, even though security, as he says, we don’t like the enforcement piece because we know that our internal customers don’t like the enforcement aspect of it. You still have to do that somewhere and if you’re doing it at the end and saying okay if you had done this at the beginning we wouldn’t be here and you wouldn’t have to do this work now then that builds a learning cycle where the engineers start to learn okay if I did do this then I wouldn’t be talking to the CISO or the information security team later on.

[11:38]  I also think that, you know, piggybacking on what’s been said, to Heather’s earlier point of developers don’t want to do the wrong thing, I think developers often don’t know what the right thing is to do. And I don’t think that’s just a security matter, right? I don’t think that any VP of engineering wants someone to hardcode a secret into code. There’s fragility and other problems with that besides the security issues, right? And so well-secured code is often simplified in complexity and it’s also more resilient, right? And so there is an uplift in general in this partnership and securing by design often produces a better product and better code overall um which is easier to maintain. And so I think that if you lean into that and demonstrate that you’ll get the partnership in return, right? You’re not kind of the alien in the room. It’s kind of like, hey, listen to them. They know what they’re doing. They’re helping you make a better product. And even if you’re making a point about security, using those resiliency and maintainability words instead of the security words, right? You’re getting the same result, but you’re speaking a language that is a little bit more applicable or better understood because there’s always the “it’s not going to happen to me” with security. But we all know, we’ve all seen what happens with availability, with modularity, with patching, right? We all know how that really hurts us. So use those words when you’re having the conversation and use real life examples. We all have security events. Hopefully they have not turned into security incidents. A lot of times the engineers don’t see that. They just see, oh, I did push my code out and everything is great. They don’t see that, oh, something happened because I didn’t do something right. So again, having another feedback loop there saying, “Hey, we had these security events, didn’t hurt us, but look what could have happened if you guys had changed something that you’re doing,” right? So continuing to build those feedback loops so they understand. They don’t want to do it, but they don’t understand why they have to do it. And that’s usually when I have an engineer pushing back on me saying, “I don’t want to, I don’t have to do that. It’s not a high priority. It’s wasting our time. We’re not able to innovate as fast as we want to.” Building those feedback loops and helping them understand that 99% of the time will change their behavior and attitude.

[14:00]  No, those are all excellent points. What really hit home to me as I was listening to this was, you know, when the customer finds a security issue, how does it look to a company when I reach out to a company and say, “Hey, I just realized that you have this going on and you should be aware of it.” The developer, when that funnels down to them, it’s interesting to see how that would be communicated. In some companies, the security team has a great relationship with developers and in other companies the relationship is struggling and it’s kind of an us versus them and that’s for another conversation. But that is a good point. You don’t want a customer to find out, hey, there’s a security thing that we’re seeing with this or with the library, or if there is, how quickly does the company respond and react to that to remediate it, because that goodwill that the customers have is still there within a short window, but it could either be grown or quickly diminished.

[15:11]  Yeah. I agree. It’s like how responsive you are to these things externally and internally makes a huge difference. I mean when we look at incident response that’s our thing, you know, it’s like no matter what comes our way we’re going to respond as fast and effectively as possible and then making sure that those engineers are involved in helping us address those issues as well and we’re working with their communications and support teams as well so that everybody’s aware what’s going on and why it’s going on and we’re able to communicate effectively with our customers. If you don’t respond effectively and quickly, you lose that goodwill very quickly.

[15:48]  Yeah. So, next question. What are the early signs that an organization’s application strategy is ineffective or misaligned? Pieter.

[15:58]  I mean, if, like we’ve been saying, you should be partnering with developers, right? So, if you’re resorting to chasing down developers, you’re banging on doors, you’re nagging, you’re coming over the top, something’s broken, right? And you can do that if you need to get something fixed, but realize you’re going to give up a bunch of political capital. I wish politics didn’t exist, but that’s the reality of where we live in the world. And you’re going to have to use that and something else is broken, right? I think oftentimes people feel like the development organization is broken and I guarantee you the development organization is not broken. There might be broken people, there might be issues, but you’re a leader in the company and so your job is to find those issues and help fix them, right? And so your job is not just to task people to fix security bugs. So that’s where I would leave it. If you’re chasing developers, you’ve already gone down a bad path.

[16:58]  Yeah, I think it needs to be at the leadership level and a bottom up as well as a top down approach. So I know our head of engineering, and our product security group reports to him, and I know that he is a very security aware and skeptical person and the head of our product security group has been doing this for a long time and he understands regulation and compliance and why those regulations are as they are for software products and it’s not an adversarial relationship of the product security group but it is an independent organization. So I do believe that it’s very important for security awareness and tailored training of your people to occur throughout the organization especially in your product development and software developers. But then for people to know their role and I think that is an element of organizational maturity that really can help as a stop gap before really bad things could happen in terms of software code.

[18:14]  Yeah, I think Joye makes a good point. The leadership aspect of it, leadership knowledge and support are critical. If you have leaders that don’t support security, you’re going to have a really hard time. You need aware leadership as well as aware teams and their leaders need to be aware of the impact of security. Not only be aware of it, but understand it and support it. And if you go into an organization that has leaders that don’t do that, as a CISO, your job becomes vastly more complex and harder. So you really want to make sure wherever you can that you’re working with that and where you identify that you may have issues in that regard. You need to approach those individuals and make sure they are on your side if you can, and in some cases you can’t and then you have to think about what you want to do. And I think it comes down to: how do you know your strategy is ineffective or misaligned? If you have an issue and nobody takes ownership, the leaders don’t take ownership, the managers don’t take ownership, the engineers don’t take ownership and say “oh we made a mistake and we own it”, sometimes you don’t even know who owns certain things. If you don’t have that then something is wrong with your strategy because that means that nobody really understands what their role is. So you need to make sure that someone takes ownership. If you see no one is taking ownership, that should immediately be a red light or a siren. It should be something that says to you, hey, there’s something wrong here because no one is taking ownership for this. I should obviously own security, but who owns resolving that issue across my organization? If no one is doing that, then you have a problem.

[20:05]  I was going to actually approach the question slightly differently, right? We can all think of examples where it’s very clear that it’s broken, right? Those ones are kind of easy because when it’s broken, it’s really obvious. The one that is a lot more challenging is when it’s not clear that it’s broken, and so we’ll use the word it’s not as effective as it should be, right? And how do you figure that out? If it’s really ineffective, your customers are going to find it; if they see repeat findings in pentests, for example. But you’re going to see it when you have those escaped vulnerabilities, when you have those metrics, and if you are not already a data driven CISO, you need to figure out how to become one really quickly because that’s how we tell the story in a partnership way, but that’s also how we surface how effective we’re actually being, right? What’s my, how many have I identified? What’s my mean time to resolve? How many are repeat? There’s all of these things which I can use to tell a story about the effectiveness of the discipline because the only thing that’s worse than a discipline that just plain old doesn’t work is one that everybody thinks works but doesn’t.

[21:24]  Exactly. I say trust and verify, not trust but verify, trust and verify for that very reason because people learn the language, people learn how to talk security, but are they really doing what they say they’re doing? And I’d love to trust everybody and that would be it. My job would be a lot easier. But you have to do the verify. You have to design the metrics and the KPIs and the monitoring and everything to verify and validate that what you think is going on is really going on. And it’s not, I don’t think it’s always intentional. I think when you talk to different parts of the organization their window is very narrow. They’re looking at what they’re doing and say yes we’re doing a great job here but they don’t take in that wider view. And so they’re looking narrow, so you’re getting narrow information, so you’re thinking everything is fine. But in reality when you take that broader view, that broader look, you find issues. And when you see that, that’s when you need to start really monitoring, start really understanding what’s going on, and start making sure that compliance is actually effective.

[22:29]  You know, a common theme that came up that I can’t help but just go ahead and talk about is the educational aspect of it. They may think that they’re solving a problem but not realize that they’re not. And with that education aspect, the developers are constantly being hammered, “Hey, get this out the door. Get this out the door.” They’re hearing from you, the security team, “Be more secure. Be more secure.” And you have these forces taking the developer’s time and effort and energy and the developer may think, “Oh, well, I can just do this and I’m done.” And maybe solutions and suggestions always change as time has progressed. How you fix certain aspects definitely changes and what was acceptable as they fixed early on may have changed. And so the education aspect that you guys have, I’m really sensing that underlying theme. I just wanted to bring it up to the top, education to the developers so that they understand when they see certain types of vulnerabilities how to resolve it and also knowing what certain vulnerabilities look like so that as they see it during the development process they can stop doing that and realign to a better methodology.

[23:54]  Okay, you have scope creep, right? So you expect the developer to do something and they’ve decided they want to do more than that or something different than that and they realign their work to that and they tell you “I can’t deliver this for 12 months” because they’ve allowed scope creep to go into what they’re doing in their process because they become misaligned. They’re not aware of the risk they’re truly trying to address and need to refocus. So I find myself often, especially as a program is maturing, going back and saying “no, no, no, you’re doing more than you need to do right now. You’re going outside of the scope of what we’re asking you to do. We’re asking you to focus on this specific type of vulnerability, this specific risk level and that’s what we want you to work on.” And so a lot of that’s again back to awareness, pulling them back in. We don’t really talk a lot in our awareness training about scope and what the limits are and addressing risk. A lot of it’s pretty basic stuff about “oh don’t click on this phishing link.” But when you start looking at people who want to do the right thing, like Heather was saying, they want to do the right thing but then they get carried away because their awareness is not there.

[25:05]  And I think it’s important too to add to that, the combination of the awareness and the metrics is really important especially in building that partnership. I had one particular story where we had a great partnership with a CTO and we had a certain group and we were asking them to fix a certain pile of findings that needed to be seriously eradicated and it wasn’t happening, and then the CTO was asking them and he was pushing on them and pushing on them and after about four or five weeks of their own boss pushing down on them, that’s when it finally came out where they said, “Hey, I don’t know if you guys are aware but this was written a long, long time ago in Ruby and we don’t have any developers on our team anymore who know Ruby. So, we’re trying, but this is really bad.” And sure enough, we happened to have some contractors that are rolling off another project. And when we looked at the list of skills those contractors had, Ruby was on there. And all we did was say, “Hey, don’t leave the company yet. Hang out for another month.” And in four weeks, all those vulnerabilities magically went away. Right? And had we not had the metrics and not had the relationship, not had the awareness, that would have just kept going. I’m sure someone would have ended up quitting there from frustration because people walk with their feet. So I think it is a really important combination in monitoring your program and making sure it’s working.

[26:36]  Well, and don’t underestimate the impact of tech debt as it’s kind of like its own class of vulnerabilities, right? If you’re building code that’s not modular, if you’re building it on languages that are in favor today and not in favor tomorrow, if you are dependent on, you know, tightly coupled to frameworks, right? So that you can’t now evolve, you’ve built in, you’re guaranteed to have findings. But I actually also wanted to sort of pull everybody else in, because when we talk about education, I’m going to drag us back a little bit to education. When we talk about education, invariably what we end up doing is we give people a secure coding course which teaches them all about “don’t do buffer overflow. Here’s how to avoid SQL injection.” And with all the modern tools that are out there, and I’m not saying you don’t need to know how to do this as a developer, but the good tools that are out there that you’ve baked into your CI/CD pipeline, they’re going to find those things for you, and you’re going to learn by those tools teaching you as you are developing and going through your commit process. The piece where we still are kind of broken is back on that design side. How am I bringing attacker / bad actor thinking into “how do I sign up a user? How do I deal with file uploads?” There’s a pile of stuff and that’s the hard stuff, that’s the stuff that is really challenging that you have to be there at the beginning in order to remediate because then it bakes itself in and it’s really expensive to remove. I can see Pieter’s getting really excited. How have you guys dealt with that?

[28:20]  I’ll just say like I authored and teach a course called Secure Coding for Coders, right? And people say, “Okay, so you teach buffer overflow and everything.” And yes, and eventually we do get down into the weeds there, but I spend the first three to four weeks of that course essentially teaching developers how a hacker thinks, right? And people question, by the second class they’re like, “are we going to get into the coding part?” I’m like, we are in the coding part, and people don’t understand that the majority of coding actually happens on a whiteboard, right? And that’s also the majority of what hackers do, they whiteboard out their strategy and they look for data in the recon and then they attack. And so by teaching people how hackers think and giving a window into that, you develop a healthy paranoia, right? And even if they don’t know how to do it, they at least remember, “wait, I remember something about this. This is what we could do with stolen credentials. I don’t want my credentials to get stolen. Let me go talk to Heather to make sure I don’t end up doing something where credentials get stolen.” Right? And so you create this kind of mindset shift, where if you just tell them how to address correctly for buffer overflow, it’s in one ear and out the other. There’s no mental impact. And that’s part of the deception of a lot of the secure coding role-based training that we do, it’s not really effecting a mental shift in how they think about the world. And not having that awareness and training leads to security tech debt, and security tech debt is one of the biggest obstacles to getting a security program on the apps side to move forward because they say “this is just too much, I can’t do this,” right? And you have to get past that barrier that’s been created because that awareness wasn’t there when they started, so they created their own security tech debt.

[30:17]  Or imagine a hypothetical situation where the tech debt is discovered way late in the product life cycle. And it turns out you’re dependent on Java 2, right? And uplifting is actually going to require you to stop all development for six months in order to fix it, right? That’s a really hard conversation to have and it’s really one where security, no matter how hard you try security is the bad cop because security is the one that’s saying “look at all these critical vulnerabilities and this now out-of-date code that is brittle, not modular, not maintainable”, and now we’ve got a huge issue that we’ve got to figure out how to go and resolve and now we’re in a really ugly situation where security is absolutely the bad cop.

[31:10]  Yeah. And then that also loops it all the way back. That’s where if you don’t have good leadership that’s on board with security, you’re not going to be able to solve that problem, right? They’re going to just accept the risk and move forward.

[31:27]  Yeah. And CISOs have long understood the challenge of positioning security as an enabler of the business. But what about the head of engineering? If you’re a software company and you’re having to make those hard decisions that could delay a software release, you have to really be able to persuade the C-suite who are looking at it from a business lens of what are the repercussions or what is the risk here, and there need to be dollar signs behind that risk, not just, I mean reputation damage is extremely important, but how much did it cost the company when something went wrong?

[32:12]  I also think that going back to what Doug said and combining with what Joye is saying, I often find that when you’re in that scenario where security is forced into being the bad cop, it’s good to rally allies. And one of the ways I do that is take those critical vulnerabilities, go hire a red team, go spend 50K on a red team, and have the red team actually go pull out “here’s the pile of data I stole.” Because to Doug’s point earlier, it’s no longer this theoretical, “but it hasn’t happened to us yet” risk. It hasn’t happened to you yet because you either don’t know and no one’s told you or no one has bothered. But look at what happened as soon as I told someone to bother, right? It’s very easy for people to accept a theoretical risk. It’s a lot harder for someone to look at that pile of data and go, “Yeah, I’m okay with that.”

[33:09]  The way I explain it, and I’m laughing because the way I explain it is that my wife will ask me something, I’ll tell her something, she won’t believe me until her friend tells her the exact same thing. But that’s how it works. No matter how much knowledge and background I have answering a question my wife has, she won’t act on it until her friend says, “Hey, you should do this. I saw this and you should do this.” And then she’ll do it. It’s the same thing in the business. They hear you, you’re part of the family, you’re telling them this is an issue, you’ve got to address it, but sometimes they need to hear it from that third party before they act.

[33:46]  Yeah. Well, Doug’s right. And software quality and security is much more than a technical problem, right? It’s a leadership, relationships, politics problem that needs to be solved by leadership and everyone in the chain.

[34:06]  Diplomacy. Diplomacy, right? I had a general manager saying, “You’re very diplomatic.” Well, yeah, I have to be, right? We all have to be diplomatic as CISOs, right?

[34:18]  Well, and you bring up a good point. Sometimes you do have to be the bad cop and say, look, security has to matter. One of the things I ran into when I ran my program, I had an application that was old, and we all have old applications within our tech stack. And sometimes you just have to move it off to its own island because it’s just not secure enough to stay within. And sometimes that balance, what you’re talking about Joye and Doug, if you’re not careful, the focus is “we have to have income coming in, we have to be able to continue our business,” but there may be times where you just have to cut the line and say we have to rewrite and we have to go down different paths. And from a liability standpoint, the CISO always gets the finger pointed: “It’s all you guys that are forcing us to do this. We’re all happy and things are working great.”

[35:17]  So, if you don’t have some people that are unhappy with you, you’re probably not doing a good job as a CISO. Right? If everybody’s happy with you, you’re probably not doing what you should be doing.

[35:29]  So true. Um, I’m going to switch us to topic two. The biggest pitfalls in application security and how to avoid them. The focus of this question is common mistakes CISOs make in application security, wasted efforts, practical ways to avoid them. So with that being said, Pieter, I’m going to ask you this question. What is the number one appsec mistake that CISOs make and how can it be prevented?

[35:53]  Focusing on tools and not on process. And I think we’ve all been kind of quietly echoing that through this conversation, right? You can bring in the greatest tool in the world. If no one uses it, no one pays attention to it, they don’t know how to use it, it doesn’t do anything for you. The process is the process, development and the tools that we’ve used to develop. And I think we’re all a little bit on the older side here. I work with developers who have no idea what it’s like to not have an IDE. And I’m like, do you have no idea what privilege that is, right? And now I work with developers who are like “oh man, I’ve only ever really been vibe coding, that’s what I started doing.” And that’s where this is going, right? So it is going to continuously evolve. The processes do change over time, but the process is core to success or failure, the tools come and go. And CISOs, especially new-to-the-role CISOs, tend to over-rotate on “if I just get this tool in there that I know works then it will solve all of the problems.” And the problem usually has very little to do with the tool. It has to do with the fact that there has been no process set up around the tools, and that is really core. If you have a process, people will support processes generally, people don’t rally around tools, right? And you need that partnership and that support. So you’re not going to go to your CTO and go “yeah just go log into tool X, it will give you everything you need.” That’s not creating a partnership. There needs to be a process that they’re engaged in.

[37:47]  Yeah, Pieter’s right. It has to be people and process and technology. And I will say, as the field CISO, when I talk with our customers or peer CISOs who are in companies all over the world, 80% of my conversation is process-based. We don’t really talk about tools. We talk about the recovery and the fact that the recovery cannot be done in the absence of forensics because you will get whacked by the threat actor if they’re still in your system while you’re trying to do the rebuild, right? So you’ve got to extract the threat actor from the network and then be able to put together the timeline of when they actually breached so that you can then have a higher confidence that what you’re rebuilding is in a trusted state. That’s process. Tools are obviously involved but also people, who’s doing the rebuild? In our case that’s the backup admin. Who’s doing the forensics? That’s security. So we live in an interesting world in which we have to talk with security and IT and they’re oftentimes two separate teams, sometimes hostile toward each other. So really, going back to Pieter, the process is really, really important.

[39:16]  So look, a great tool will not fix a broken process. And so there’s a question from the audience: what do we think about autonomous AI agents in the development environment? I think, Pieter said vibe coding. Let’s be really clear, those are tools, right? If I have a broken process, bringing AI in to help me code is not going to make things better. In fact, it might make things a whole lot worse because I don’t have the process in place to make sure that what I’m doing is robust, is maintainable, is all those things.

[39:52]  Oh, you really want to jump in. I want to amplify that. And I’m going to use the word amplify like five times in this statement so everyone remembers it. So to amplify what Heather’s saying, AI is the great amplifier. That’s what people don’t seem to understand. I am in an AI-first company. We are at the bleeding edge. I’ve had vibe coding going on for like nine months now already. If you’re bad at it, you’re going to get way worse at it, right? The vibe coding is not going to change how you code. If you’re bad at appsec and you bring in AI appsec tools because you don’t have a process already, you’re going to amplify how much you don’t have a process and how much of a mess you make, right? There are absolutely places where AI can fill gaps if you have absolutely nothing. But if you’re already doing the thing, if you do it well, AI will let you do it way better. If you do it poorly, AI will make it so much worse. And so I just want everyone to remember: amplify. That’s what you’re getting with AI.

[41:02]  And that goes back to training and awareness. If you’re not trained well on how to use AI, it amplifies, and you come out with, all of a sudden you have this security and other tech debt you’ve got to solve in the future. So you’re not helping yourself by doing that.

[41:14]  Yep. Well, and when you’re doing vibe coding, security really becomes more and more important because, on my talk, “the dark side of AI”, a simple application that should be 3 to 5,000 lines of code ends up being 80,000. And when you have 80,000 lines of code, think about what is your threat model? What is your exposure? Look at how many times, if you have to fix something, you’re going to have to go to all these locations to repetitively fix the same thing over and over. And that’s just because AI, to your point, amplified it, just blew it out of proportion. And so security, especially in a vibe coding environment, is absolutely vital for success. If you don’t have it, you’re going to just explode your security risk dramatically.

[42:11]  I love this process flow. I wish I had gotten to it sooner because I’d love to stay here for the rest. Um, I have to move to topic three because we are at 12:47 and we have 13 minutes left and I want to make sure that we hit all the topics. So topic number three: security versus speed, striking the right balance without bottlenecks. The focus of this question is really achieving security without slowing down software development, talking about vibe coding here, or others, but especially the amplification. So here’s the question: how can CISOs make security seamless and invisible rather than disruptive to development? Pieter, you got any thoughts on this?

[42:58]  I mean, don’t. Don’t do that. We have this want as CISOs, because we have a job where we are put into positions where we have to be bad cops, we have to call in favors, we have to deal with high friction situations, to try to minimize friction everywhere we can. And I think that’s a good thing, but I think we go about it in ways where we’re not actually teaching people to fish, right? And so what we’re doing is we start giving people fish and we feed them fish and we feed them fish. And what I always tell people is I’m also maybe not going to teach you how to fish how I fish, but I will give you a really good boat and really good radar and teach you how to cast a line. I’m going too far into this fishing metaphor. But the idea is you want to make sure that it is visible to them. It’s not necessarily disruptive, but it is visible and they are part of security, right? If you’re trying to take it away from them and do it over here and make it quote-unquote seamless, then they don’t become aware, they don’t become educated, they’re not partnering with you, and all the things we’ve talked about for the past 40, 50 minutes start creeping in and whatever you’re building is going to fall down really, really fast. You’re going to fail to scale at it.

[44:25]  Look, friction is a good thing, right? When you are driving your car through a neighborhood that has a lot of children where people are prone to speeding, what do they do? They put speed bumps in. Speed bumps are friction. Speed bumps are reminders to slow down and be safe. And that’s part of what we’re trying to do, right? We used to use the word safety a lot in the security community. We sort of went away from it, right? That comes back from our roots in many ways informed by secure engineering and the role of manufacturing starting with all of the physical pieces, right? And we’ve moved away from including the word safety in our vocabulary. And I kind of think it’s time we start bringing it back because when we talk about safety, the word friction isn’t quite such a bad word.

[45:21]  Yeah. And I think it’s about relationship management. That’s very easy to say and very hard to do sometimes, especially when your organization is adversarial sometimes to what everybody else is doing or trying to do. So you as an individual cannot be adversarial. I used to work in a very large organization and my role was an independent auditor. So when a large program would go sideways in terms of cost or schedule, it was up to me to develop cost-informed options to get back to solvency. And a lot of times that would be cutting funding. So how did I get good data from the program management office when they knew I was going to be cutting their funding? It’s all in the relationship and how you frame what you’re trying to do, that we’re on the same team, we’re working towards the same objectives, so give me good data. And I rarely had to get into “now we’re going to do this easy or we’re going to do this hard” kind of conversation. But if you can always try and have the more gentle way of looking towards common goals and managing that relationship effectively, you’ll be much better in the long run.

[46:47]  Yeah. And that’s beautiful. I had a CEO, he’s very good at making things very succinct, and he’s like “keep us safe.” I had a CTO that said “keep the wheels on the bus.” These are very short statements that people understand and cause them to act, right? Just being very succinct in that way and working very closely and building relationships is so helpful in the security world and just makes a huge difference.

[47:11]  I would just add to that: don’t be transactional. There’s a tendency for security folks to be transactional and come to people for the first time and ask them to do something. Come to them for the first time and say, “I’m here to help. I’m here to keep you safe. What can I do? Tell me your problems. I’ll see if I can help.” Right? It creates a completely different relationship because then we’re partners in keeping the wheels on the bus. Right? I’m not just the guy pointing and saying, “The wheels are falling off. Go fix it.” No one wants that. Everybody that comes into my organization in the first 30 days, I give them 10 or 20 people and say go introduce yourselves, ask them how you can help, find out something personal about them. Don’t go to them and ask them to do something, go introduce yourself, and it pays dividends.

[48:01]  So we are cut from the same cloth. The thing that I did, and this is a real beautiful conversation because to me communication’s everything; the more you know what’s going on, the better informed you are, one of the things I always told my guys: call the software architects, say hello, see how things are going. That way when they get that phone call the first time you call, “hey what’s wrong,” it becomes a better relationship, so then they will answer when something really does go south, and they are more apt to be at the ready to help you and be more honest with you, because that communication is absolutely key. And in a lot of companies it’s just missing, that human dynamic. A lot of us have people underneath us; when you’re the CISO you’ve got the security team, the apps guys, and just that simple phone call, or go take a stroll. That’s one of the things that I would also do: two to three times a week for just a half an hour I would stroll through the development area and just say hello, and hearing what they’re working on, they would reach out to me and say, “Hey, we’re going to start doing a mobile app. What’s the proper way to secure it? If they set the phone down and they want to lock it, what’s the best way to unlock the app?” Once you start getting that communication, now all of a sudden you’ve got that relationship building towards a stronger end. But you have to empower your team members as well, because a lot of times, it’s surprising to me, they’ll want to do something and they’ll come to me and say, “can I go reach out to this person?” I’m like, you don’t ever have to come ask me that. I don’t care who it is. If it’s a CEO and you need to talk to the CEO, go talk to them. You’re empowered to do that. But it’s surprising to me how often that doesn’t, people are reluctant to do that because they feel like they need permission. So you’ve got to build that environment where they have permission to go do that, and the relationship really kicks off there. When they say, “oh I can do this, I don’t have to ask permission,” it changes the dynamic really quickly.

[50:09]  Yeah. I find it very interesting that we’re in an application security webinar and we spent a lot of time talking about relationship management.

[50:22]  It goes hand in hand. It really truly does. All right. I want to give the audience just at least a minute or two to ask a couple of questions. I know we’re basically at time, but I really want to give you guys at least a chance to ask a question or two and see where this goes. So, if you’re on chat, please reach out and ask. Ah, got one. We are struggling with developer buy-in for security. What’s the best way to get dev teams on board? Anyone want to take this one?

[51:11]  Same thing. When I’ve gone into organizations that are really reluctant on the engineering side to do something, I don’t want to say I trick them, but what I do is, they come in with a very simple problem, right? So, storing credentials separate from code, right? It’s a simple problem. And get them to agree to fix that, and then I use that as the building block to add more and more to it until a year out or two years out all of a sudden they’re fully involved in security and they don’t know how they got there. So my strategy has always been: don’t go for a big bang, because you’re not going to achieve that, right? Go pick the little things, pick the quick wins. Start doing that because then you can start building on that. You can say, “well, you helped me here solve this security problem; this is very similar because it solves this problem, can you fix that for me too? And here’s a process that maybe we can implement around that.” And so it slowly builds. You can’t do it overnight, right? You have to build it that way, a brick at a time. And if you have a really reluctant team, I’ve had really reluctant DevOps teams that didn’t want to patch, and we came and said “well, patch this one thing.” And then they’re like, “okay, great, that worked, but I can make it better.” Okay, well let’s make it better and let’s expand it to this. And then like I said, a year or two out, all of a sudden they have this really strong patching program and they’re running it all by themselves because they’ve taken ownership.

[52:37]  I take a slightly different tactic, which is I come in and I say, “Hey, what are three things you absolutely hate?” And usually they hate something related to tech debt. And I key in on that and I go, “Do you want to change that?” And they go, “Oh my god, yes, more than anything.” And I go, “Great. I have this giant hammer called security that’s insecure. I think we need to change that.” Right? And right away we go from being adversarial to like, “oh my god, he can fight the battles for me.” And if I’m going to piss people off anyway to get something done, I might as well make some allies at the same time, right? So I find that’s very helpful.

[53:11]  Going in and listening and understanding why is really important to getting people on board, because half the time all you need to do is listen and then people are on board. You don’t even necessarily have to offer a strategy, although I love Pieter’s approach and I’ve done similar. It’s the listening that gets you that first major milestone, and everything else is easier after that.

[53:46]  Yeah. Wow. All right. We have two minutes. I want to do our final closing and say a couple things. You know, we’ve covered a lot of ground today. This has been an amazing conversation and I want to thank all of you guys for coming, because I wish we could book this as a recurring session, I love this group and the conversations have been amazing. You know, the big takeaway: appsec doesn’t have to be unmanageable. It doesn’t have to be a blocker. We talked about processes, communication. I really loved where we went. We can embed security into our processes, reduce some real risk, not just compliance or numbers or check boxes, but actually do something about it. But guys, if you have questions after, we’re going to end going live here in a minute, but if you have questions, feel free to reach out to us on LinkedIn if that’s okay with you guys. You can reach out to me, you can send me an email, you could reach out to OX Security. We would love to take your questions and help answer them. With that being said, Pieter, Joye, Heather, Doug, thank you guys so much for coming. I really enjoyed today. This has been a blessing and an amazing time. Thank you. Stay safe out there.