What if your biggest security risk isn’t the vulnerability you know about but the 1% you missed?
In this episode of Breach Ready Dialogues, Agnidipta Sarkar speaks with cybersecurity veteran Ross Young about lessons learned from real-world breaches, including the 2019 Capital One incident.
They get into the security gaps teams often miss: misconfigurations, incomplete tool transitions, exposed systems, weak architecture, and the challenge of securing fast-moving cloud and AI environments.
The conversation also covers microsegmentation, Zero Trust, vulnerability management, and why security teams need to focus more on exposure and root causes, not just vulnerability counts.
A practical conversation for CISOs, security leaders, architects, and anyone working to make their organization more breach ready.
Agnidipta Sarkar: Hi. Good morning, good afternoon, and good evening, no matter where you are. And we are back at the Breach Ready Dialogues. I have Ross Young with me. Ross is the CEO of Peer Capabilities and the co-host of the CISO Tradecraft Podcast. And as is usual, we are going to talk about stuff that’s not really written down in books, but primarily things that we have experienced.
Agnidipta Sarkar: Ross brings a whole lot of experience to the table today. So if you’re wondering how we’re going to go ahead, the whole idea is if you listen to this podcast, you’ll probably realize that breaches will happen. It’s a question of how you emerge on the other side. And at the end of the day, all your cybersecurity investments that you’re doing, they should come together to help you make sure that you are ready for the next breach, and when that happens, you are able to keep your critical digital systems mostly unaffected by the breach.
Agnidipta Sarkar: Having said that, let me go back to Ross. Ross, why don’t you formally introduce yourself and- Hi, everyone … yeah, sorry, a little bit about your background in breaches.
Ross Young: Yeah. Hi, everyone. My name is Ross Young. It’s a pleasure to meet everybody. My name is Ross Young. I’ve been in cyber for about 20 years.
Ross Young: I’ve spent over 10 and a half years at CIA. I’ve worked at NSA, I’ve worked at big banks, at the Federal Reserve Board, Capital One, and I’ve even been the CISO at Caterpillar Financial for four years. So I’ve had a chance to work in a lot of fun, different places, and I was even a part of Capital One when they had the major breach in 2019.
Ross Young: So happy to talk more.
Agnidipta Sarkar: Yeah. Thank you. Why don’t you tell us a little bit about stuff that most CISOs don’t know about? Considering your experience in all these companies that you mentioned, especially Capital One, and then you had experience with intelligence agencies as well. Tell us about stuff that people don’t know about breaches.
Agnidipta Sarkar: They assume a lot. We– especially for those CISOs who are, thank God, not yet in a breach
Ross Young: Yeah. I think the biggest thing that happens is you’re probably never going to be able to predict where your breach is going to happen. There’s things where you’re like, “Oh, we’re gonna get popped because we’re not patching fast enough.” And surprisingly, it may come in from a very different way that you may have not ins- inspected at all.
Ross Young: And I’ll just give you the example when I was at Capital One, one of the things that had come in is we had this former AWS employee who really knew all the ins and outs of AWS. And so that individual was able to actually identify this service called EC2 Metadata Service, and what that allowed them to do was actually obtain some very sensitive credentials via a server-side request forgery attack.
Ross Young: And it was something like, I don’t think anybody really understood this type of AWS attack. It was very new, very much required a lot of insider knowledge to conduct these type of an attack. And when we saw this, I think the biggest thing was just all the little things that started happening that we never could have anticipated So, so back at the time, Capital One, we were all-in on A- AWS, and what that meant is we would often look for things to use from a security point of view.
Ross Young: So think of GuardDuty as your data loss prevention tool. And the little things that you started to learn a- across the way was, hey, when AWS actually stands up a brand-new region, and in the region at this time was Bahrain, they don’t actually put in every AWS capability at the exact same time. And so while you may have GuardDuty in AWS East and AWS West, in a brand-new region, it certainly wasn’t gonna be launched.
Ross Young: And so that was something that we found in a very surprisingly way, was that when the bad actor waited till the time till a brand-new AWS region was launched, they exfilled the data in a way that our DLP didn’t exist with that knowledge of how to use the EC2 metadata service in order to steal data.
Ross Young: And so little things like that where they get to start chaining all of these things together that you c- you would not have been able to predict and would’ve known where your defenses started falling a little bit short, I think is a really big aha moment that companies have. And what I like to tell people is a lot of times you think your tools, your WAF, your other tools are working as they should be, only to figure out they’re not installed, they’re not configured in the way that maybe developers or other people would’ve promised you that they are, and then that becomes the oversight that actually implements the attack.
Agnidipta Sarkar: Wow. Wow. That’s an eye-opener. In fact not many people think about, every new service as something, every new change as something to worry about to ensure that the cybersecurity controls are in place. Which I believe– A- again I keep saying that the biggest enemy of cybersecurity is actually change management.
Agnidipta Sarkar: Not that the tools didn’t work, but because we didn’t do the change the way it should be done, with the diligence that is needed. Because usually, a request for change comes at the last moment on the CISO’s desk. “Hey, guess what? We decided to do this change. You are here to tell us tell us if this is going to be secure or not.
Agnidipta Sarkar: And you have one day to get back to us.” That’s something that you usually get into a pressure, and all these things come together in the end when there is a breach. But as you said, I think the great takeaway is that not only change, but also configuration is something that- Cybersecurity leaders need to have a complete handle on, of every other system that can…
Agnidipta Sarkar: That has access to critical data. But, Yeah, go ahead. Were you saying something?
Ross Young: Yeah and it’s these things that happen that you don’t realize are big items until later. And I’ll just give you the example. Every organization has a tool that they will replace at some point in time, right? And you can just think of, oh, we didn’t like this data loss prevention tool, and then we go to a new one, or we didn’t like this SIM, and we go to a new one.
Ross Young: There’s always a tool that you’re getting rid of and going to a different one. And the problem that ultimately happens is you start off really strong and say, “Okay, we’re gonna get to let’s call it 80% of the tool transition will happen on this date.” And then maybe you get to, 95% a couple months later.
Ross Young: And then what you find is that last 5% or that last 1% is really hard. For some reason, the new technology doesn’t work on all the systems the way the old technology used to. And so what happens is ultimately you’re like, “Ah, we, we did good enough. We’re gonna close this initiative out because we got five new priorities for next year.”
Ross Young: And that little crack that you forget about happens over and over, and as you start having this nine comp- noncompliance on 1% of these things, this is where it goes wrong. And when we s- saw this in, in, in Capital One, this is w- some of the lessons learned where they went through and say, “How could we do a little bit better?”
Ross Young: So originally we had used a web application firewall called ModSecurity, and it was a pretty good WAF at the time, and eventually we ended up replacing it with a newer WAF, and that was a Barracuda WAF. But for some reason, we didn’t get through that last 1% of all the systems. And not only that, but somebody had actually misconfigured that WAF.
Ross Young: Instead of it being able to, block things one of the problem was they misconfigured it. And so when you have a proxy, you can configure it as a forward proxy or reverse proxy. The problem is both can actually be legitimate, configurations depending on what you’re trying to do. But if you put your WAF in the wrong type of proxy mode, that’s what enables a server-side request forgery attack.
Ross Young: And so there was no tool that was gonna say it was misconfigured because both configurations are valid depending on what you’re trying to achieve, but in this case, it was misconfigured. And so these are the little lessons learned of, hey, if you’re only relying on a tool to scan all of the vulnerabilities, sometimes it’s gonna miss those application logic attacks where you’ve misconfigured it.
Ross Young: But because both ways could be a valid misconfiguration, y- you may not catch those things. And what were the other things where you think that, hey, we did 100% transition between tools, but you actually left that 1% not finished, and you just moved on to the next initiative. And if the bad guys are scanning all of your IP addresses and finding those 1% of things because they know more about your attack surface than you do, that’s something that can come back to kinda catch you.
Ross Young: So I thought that was such a big aha moment for me and Capital One just really got so much smarter when they learned from these lessons of, “Oh, we should have done this.” And certainly I think there was also some pieces that they had learned from AWS. One of the other big things that I don’t think people talk enough about is the bad actor was actually able to use the command line integration, the CLI calls, in order to do the EC2 metadata call.
Ross Young: And EC2 is ultimately a server. And I always struggle to say why is it that a command line, which is being used by a human, would be able to impersonate a server and act as a server. Clearly that does not sound like a least privileged type CLI service from AWS. So little things you’re gonna learn as you start to go in and challenge how we do zero trust and how we actually, limit the scope of certain things just come up and you’re like, “Man, hindsight’s 20/20.
Ross Young: I wish we would’ve known these things before they happened.”
Agnidipta Sarkar: Oh, absolutely. In fact, one of, one of my experiences in a breach was the fact– and I’m talking about after the breach happened or rather during the breach. The strain on the people who are trying to put systems back online, reduce the attack, or reduce the effect of the attack, is the thing that you wonder, how is it that the bad guys know more about the attack surface than the defenders?
Agnidipta Sarkar: Be– And I’m saying this because the bad guys and they’re s- they’re actually in your company. I’m just eliminating the insider abuse because insiders of course know about the enterprise. But again, most insiders know little. They don’t know as much as the security guys know about the enterprise or the IT guys know about the enterprise.
Agnidipta Sarkar: So why is it that the attackers know more than us? Ideally, if I am the CISO or I am part of the security organization, ideally I’m saying, I should define what the attack surface could be and put defenses on that path. A bit like those warning things that you put, in, in the jungle when they have when they go camping, they put those thin wires.
Agnidipta Sarkar: So it- it’s called a tripwire, right? So the moment a tripwire- … is crossed, you get an alert, and then all that you do then is address that. I think that’s where the future should be. And you talked also about the CLI and why should a human be a- able to ac- have access. But what you’re pointing to now is something far bigger because this, we are in, I would call it the age of mythos.
Agnidipta Sarkar: I’m not even calling it the age of AI. If such a capability is still around in certain systems, it’s a gap that we haven’t thought about, and the machine could exploit that far faster, far deeper than a human can
Ross Young: Yeah, there’s a lot of things here, and I put a, let’s call it a Monday morning quarterback hat on, like you’d see on ESPN and just take the example of the EC2 metadata service.
Ross Young: After the breach, AWS actually released version two, which had a way to actually, mitigate some of these security issues. But what they did is they still actually left version one around. And so think about that. Everybody else who still ran version one they could still have the same exploit used against them.
Ross Young: And this is something that I think AWS can do a better job on. Clearly they know what the misconfigurations of AWS are. There’s tools like Wiz, there’s tools like AWS security tools that tell you, “Hey, you’ve got to turn encryption on here. You need to turn sharing off here. You need to minimize IAM roles here,” all of these things.
Ross Young: But at the end of the day, they take this stance where they step back and say this is the shared responsibility model. This is what we’re responsible for, and this is what you’re responsible for.” But I would actually challenge them and say, “Look, if you actually know that these configurations are bad, why is it you allow any customer to even have those as an option to choose a bad option?”
Ross Young: There’s really no good reason for these. We need to actually remove any way a customer could cause self-harm by having a misconfiguration. But nobody ever really holds AWS accountable for the, for just even allowing bad configurations that they know, and they’ll go in and they’ll say so many customers are using this version, and we don’t want to change it.”
Ross Young: I’m sorry, you deprecate services all the time, but why aren’t you deprecating bad configurations? I’d love to see some more accountability held to AWS and other, large scale cloud providers for giving those weaknesses in those configurations that they know clearly shouldn’t exist.
Agnidipta Sarkar: I think what you just said makes complete sense.
Agnidipta Sarkar: In fact, one of the things that you, what you just told me is something that we can work on, the standards we’re working on, like cloud the CCM models, right? The Cloud Security Alliance stuff that we’re doing. I think we should put that as a primary condition that if there is a known configuration gap in any cloud service provider, then the responsibility or the accountability of that, of removing that rests on the cloud service provider
Ross Young: Yeah, absolutely.
Ross Young: You can look at Cloud Security Alliance. They have some really good benchmarks for operating systems for cloud environments. You can find the one for AWS or GCP or Azure. And then you have to go and, secure your organization against those. But I still would go back and say, why is that even an option?
Ross Young: And you could just think of the default- Absolutely … credentials and configurations on a unhardened Windows laptop. Like same thing. Those things should be hardened from the get-go. But we really don’t h- say, this is negligence from the supplier in giving these bad settings.
Agnidipta Sarkar: Oh, that is so true. In fact, you brought on hardening. One of the things that I usually tell people… so my methodology of looking at how you become breach-ready is by doing two main things: the ability to anticipate an attack, and I don’t mean to an absolute reality, but to the extent that’s practically feasible.
Agnidipta Sarkar: Because there’s a whole lot of information that CISA has thrown up on their website about attackers and their attack methods. There is also MITRE that lists how attackers go around attacking. So if you knew that some combination could work, your anticipation program should be done by trying to model how an attack could happen on a particular enterprise given how they’re configured.
Agnidipta Sarkar: And then comes the hardening part. If you know– If you are able to use, let’s say, some AI capability or whatever, or a human capability to determine, let’s say, an exposed server can be exploited by, let’s say, Ransomhub, and you know from the CISA website of the Ransomhub profile is that they go from the initial access directly into s- lateral movement, then the next thing that you would want to do is to create a model, a cyber defense model that allows you to, stop that lateral movement in the event there is an exploit.
Agnidipta Sarkar: Now, you don’t know whether that server is exploited or not, but at the same time you go and get your whole enterprise hardened, reduce the attack paths, and then make sure that the lateral movement cannot happen for unauthorized people. Of course, you need it when you need to, let’s say, do a service call, then probably you need RDP open.
Agnidipta Sarkar: But until that time, you don’t need anything, isn’t it?
Ross Young: Yeah. Years ago, I, I open sourced this framework I call the OWASP Threat and Safeguard Matrix. And basically, it has the NIST functions of identify, protect, detect, respond, recover as these kind of vertical columns, and on the horizontal side, you put what are the material threats to harm our company?
Ross Young: And I think a lot of these really don’t change, right? They’re gonna attack humans, probably via phishing or thumb drive attacks. They’re going to attack our, let’s call it our servers, right? How do they do some type of malicious supply chain attack, or they’re looking for known vulnerabilities or fuzzing our websites with some type of DAST scanner.
Ross Young: You start to see over and over the common things of how they’re gonna attack our servers, our desktops in different ways. And what you wanna do is overlay a series of safeguards across these things. Take for example the web application that’s sitting on the internet today, and you’re really worried that the next version of Claude Code is going to find vulnerabilities in your system, right?
Ross Young: The first thing I would need to know is, do I actually have a good asset inventory of all the applications that are on the internet for my app- my organization? Because it’s really hard to patch what you don’t even know you have. And then after you actually have that inventory, maybe you can scan all the IP addresses, you know all the DNS entries, things like that, and you build out that cyber threat exposure management, you need to protect those systems, right?
Ross Young: You’re gonna say if a zero day happens, how would I actually stop that?” Maybe I’m gonna put it behind a WAF, where even if I didn’t patch that web application, I have something that can virtually patch, a SQL injection or prompt injection attack. And, I might even use a second layer as- Or microsegmentation Yeah.
Ross Young: Yeah. If it’s something that’s very vulnerable think of like a hospital. They have an MRI machine that might be running Windows XP from a vendor that went out of service 10 years ago. You’re not really going to patch that at all. You just have to put it into some type of segment of your network that nobody can get to, that the harm is really reduced from the likelihood of those attacks, right?
Agnidipta Sarkar: And that’s where I think microsegmentation plays a big role because you can today create zones and then microsegments within those zones and you can practically Obscure the connectivity from any other user, like create islands of excellence within the enterprise which are not exposed to the internet in any ways.
Agnidipta Sarkar: If you have an MRI machine which is on an XP, like you correctly said, you’re not going to patch it ever because that machine, if you have to replace that machine, the cost of that replacement is so high that… Plus forget the cost, the operational aspect also, because the MRI machine is usually set up inside a building.
Agnidipta Sarkar: It’s not that it’s portable.
Ross Young: And there’s always something like that happens. If you just believe you can be perfect at cyber you just haven’t had enough real world experience, right? So w- and I’ll give you another example. When I was in one of my other employers, we had an HVAC system.
Ross Young: That HVAC system, it’s just not gonna get patched in the same way that a normal Windows endpoint or server is. It’s gonna be old, it’s gonna have vulnerabilities, and the manufacturer’s just not gonna care because they’re gonna build, some newer generation of HVAC system and just not largely support old systems.
Ross Young: And so using that micro-segmentation is exactly how we had to secure that system, and we had to put it on some type of risk acknowledgement to say, “We’re not gonna patch this machine because no patch exists,” right? But I am going to do mitigating control measures of, isolating it with some type of segment type approach.
Agnidipta Sarkar: Yes. And I think that is where it makes so much of a difference. Because now you– if I simply go by what you’re saying, if I am at a hospital and if I am planning to become breach ready, I would have to think about all these things. I would have to think about how do I manage configurations?
Agnidipta Sarkar: How do I move my systems from being exposed to the inet- internet to put them behind some microsegments? And I need to do that pervasively across IT, OT, or the cloud. It doesn’t matter where you found the vulnerability, where you found the zero day, whether it would be on an EC2 instance or it is, as you said correctly on a microwave– on a X-ray machine, wherever, or a HVAC.
Agnidipta Sarkar: It really doesn’t matter. You need to have a capability that you can build so that you can do all that mitigating controls just by pressing a button. We need to be, cognizant of the fact that we are spending a lot of money in cybersecurity tools which look fancy, which are… like you talked about phishing, for example.
Agnidipta Sarkar: We’ve been using some phishing tools for some time, anti- anti-phishing tools, and then they do these exercises where they send you this email with an Amazon card and all that. Yes, you need that. You need people to learn more. But that’s not really a foundational control. That’s what you build after you’ve built all the other foundational controls so that you’re able to do what you just mentioned.
Agnidipta Sarkar: Make sure that you have… You understand what your assets are. The biggest problem that you have today is we don’t know where our assets are. We don’t know whether there’s a shadow IT or a shadow AI or a shadow SaaS operating, where suddenly something has been exposed to the internet and we don’t know about it.
Agnidipta Sarkar: And that’s the big challenge. If there’s a configuration open, change management not done properly, the biggest enemy that we have when we have breaches is actually us. We are not united the way we should be and we don’t let tools talk to each other. That’s the other part
Ross Young: Yeah, I think there’s a lot of problems that we have, and what I would say is we solve symptoms instead of the root cause.
Ross Young: And I’ll just take the example of a vulnerability management program. If you were to go to most more vulnerability management programs, what you would see is some type of tracking on the number of vulnerabilities and probably the average age of the vulnerabilities. The problem is, every time you get a new vulnerability scanner, you’re probably gonna have a different number of vulnerabilities that you’re finding and how old those vulnerabilities are.
Agnidipta Sarkar: Exactly. And so
Ross Young: I think what you’re doing is you’re treating a symptom. Yes, you wanna get rid of vulnerability, but I don’t think that’s the right metric to go off of. And so I’ll give you a different example of how do we actually measure the technical debt of our applications? And so take a more sophisticated approach that says, I wanna do something called a taint analysis, and what does that mean?
Ross Young: For each application, I wanna know how many different APIs or resources are actually exposed. And on those resources, I have these things called sources and sinks. Sources are like on the, let’s call it 50 different APIs that are publicly exposed to customers, how many inputs from humans or web inputs do we have that take some type of input?
Ross Young: And then the sinks are what is it they actually write to? Is it a database? Is it a file system? All of those things. And so if we actually know that level of knowledge about our system, we can come back and say, out of the 50 inputs that are on the system, how many of those do we sanitize? Because if we could actually sanitize using parameterized queries, we could stop whole classes of attacks, right?
Ross Young: So imagine if you could say, we have 100% sanitized the 50 inputs on this website, so we don’t have to worry about SQL injection or prompt injection. So even if Claude Code gets the next version, which is 10 times better at fixing and finding vulnerabilities, doesn’t really matter because we’ve already blocked that whole class of vulnerabilities.
Ross Young: So that’s what I wanna see us really focusing on. How do we go back to the root cause, which is we don’t actually sanitize our inputs, and use that as a measurement for vulnerability management on our various apps instead of just how many vulns are on the apps today.
Agnidipta Sarkar: Phenomenal. I think what you just said made my day.
Agnidipta Sarkar: Look at it this way. And you hit the nail on the head because I am seeing all this talk about Mythos being the next big thing and et cetera, et cetera. And it has found so many vulnerabilities in Firefox and this and that Yes, they did. But the question, the moment I ask how many of them are ones that you would solve, the answer is not all, because you’re not going to solve all those vulnerabilities.
Agnidipta Sarkar: It’s– There’s also a factor about, like you said, what’s the exposure of your system that you want to solve? How do you prioritize? You do not prioritize it on the vulnerability, you need to prioritize on the exposure. And I think, as you said correctly, if there was a mechanism by which, you know you could figure out, you could parameterize, you could figure out how you are– you’re going to look at sources and sinks, that makes a huge difference if you can then connect it to the micro-segmentation platform through through an integration, so that the moment you alert that, the micro-segmentation platform comes up with defenses for it.
Agnidipta Sarkar: That would make it so much simpler and not so complex because then your vulnerability program is going to be far easier to operate. It doesn’t matter if AI is going to throw 10,000 vulnerabilities at you.
Ross Young: Yeah. Yeah, there’s just so many keys here, and I’ll just take the example of things like Kubernetes.
Ross Young: One of the things I thought that was really another interesting point from a micro-segmentation is usually I have a server, and I have to expose certain ports and certain services on those things, right? So I might go in and say, “Oh, it needs to have four forty-three, exposed and port fifty-three, so I can have DNS and other things happening on that system.”
Ross Young: And you might even say, “Oh I’m exposing, fifty different API calls.” But what you might actually figure out is not everybody needs access to all fifty API calls. Only certain systems need access to these two API calls, and these other five are different IP addresses. And so you can start to go and segment some of these things.
Ross Young: And also not all of them at the same
Agnidipta Sarkar: time.
Ross Young: Yeah. Yeah. And so just knowing what needs to be exposed and who needs to be exposed, and working at a smarter level than the old what I would call the IP-based firewalls, where you’re just doing it at the layer three instead of the layer seven smarter ones that are out there.
Ross Young: Super, super important to know and understand some of those things because that can also really limit your scope.
Agnidipta Sarkar: Yeah. What you just talked about is that we need to think about how can we build zero trust as an approach, not only a product called zero trust, because there is no product. The whole idea of NIST 800-207 was that the world is able to adopt a mechanism that, Truly is following the principles of zero trust and not really thinking, a- as you just said the traditional method.
Agnidipta Sarkar: We need to get into that mode. I think we’ve talked a lot. I could go on with you. We’ve been… i’m having fun, but- and I’ll just
Ross Young: share one more with you. I know I mentioned how to do the input validation. Yeah. Another really important one is authorization on all of your calls. Just think of there’s this concept known as IDOR, and if you haven’t h- heard of IDOR basically it’s an attack where people can basically change a couple of parameters.
Ross Young: So imagine if you’re in your URL, you say, “If user equals 321,” that’s the user ID being passed. And if somebody can just simply change it to a different number and now they’re in a different user account, that would be really bad, especially if they could do it to figure out what the admin number is, right?
Ross Young: So how do we actually make sure we’re doing that? That’s just another simple way where I think you can start to measure these root causes. And so are you doing authentication? Are you doing input sanitization? Are you doing encryption and using those as core premises of how do you validate an application from a security point of view instead of just how many vulnerabilities are there if I run it with this security tool?
Ross Young: Which I think is not a good way when we’re always going to find more vulns with smarter LLMs and algorithms. We need to go back to eliminating root causes of deficiencies in our organization.
Agnidipta Sarkar: Oh you’re so right, and I think what you also pointed to is a malaise that I see across the world.
Agnidipta Sarkar: We no longer do design. We just go, find the tool that we need, and we buy it, and we put it. We don’t spend time thinking about root causes, thinking about the whole architecture thing. And the worst part that I have– I heard recently was that a company downsizing laid off a whole bunch of architects, security architects.
Agnidipta Sarkar: People don’t understand that security architects may be a pain normally because they are the ones who come up and say, “No, you can’t do this,” because they’ve thought this through. And so they’re laid off and when they’re laid off, you’ve just eliminated that basic layer that does design, that does those foundational things that you just talked about.
Ross Young: Yeah, at the end of the day, if you go to any large company and you say how many CISOs or architects or compliance officers do you have to the number of developers?” You’re gonna find a ratio at least 100 developers to every architect if not higher- There you are … or CISOs, right? And so I think the point here is it’s really hard for that one architect to understand all of the code changes that are happening daily.
Ross Young: And if it was bad five years ago, now when code is three times faster or 10 times faster because you just gave all your developers AI coding capabilities with Gemini or Claude, and your architects are like we still need you to come to next week’s architecture review board so we can manually process these things,” you just have to understand you’re killing developer velocity.
Ross Young: Yeah. So there has to be a shift where you’re saying, how do we give an architect AI capabilities, agentic capabilities, and say, “We’re going to build a virtual arch– agentic architect who can do automatic architecture reviews on every code change-” Absolutely. “… who can actually look through these things.”
Ross Young: That’s actually what I’m building at my company today at Clear Capabilities. So if anybody’s interested, ping me on that. But I think this is where we’re gonna have to go because security, data privacy, compliance should not be bottlenecks to developer velocity. Instead, we need to build agentic capabilities there so they can scale, and they can have speed that they just don’t have.
Agnidipta Sarkar: Thank you so much, Ross. I think we talked a lot, and I’m pretty much sure if you’re willing, we can come back and do a part two of this, because there are so many things that I just realized we haven’t talked through. And so I’m going to thank you once again and then catch up with you outside. So to everybody else, I think this was a treasure trove of inputs and practical suggestions that CISOs can use.
