The Secure Developer

The Crucial Role Of Consolidated Platforms In DevSecOps With John Delmare

Episode Summary

Explore the role of consolidated platforms in software development with our guest, John Delmare, Global Application and Cloud Security Lead of Accenture. This episode dives into the growing complexity in the developer space and how these platforms streamline processes and foster collaboration among distributed teams. We discuss balancing application and cloud security, the financial and time-saving benefits of integrated platforms, and the role of best-of-breed technology in an evolving tooling landscape. Tune in for a preview of future secure development practices and practical advice on navigating this dynamic space.

Episode Notes

Episode Summary

Explore the role of consolidated platforms in software development with our guest, John Delmare, Global Application and Cloud Security Lead of Accenture. This episode dives into the growing complexity in the developer space and how these platforms streamline processes and foster collaboration among distributed teams. We discuss balancing application and cloud security, the financial and time-saving benefits of integrated platforms, and the role of best-of-breed technology in an evolving tooling landscape. Tune in for a preview of future secure development practices and practical advice on navigating this dynamic space.

Show Notes

In this engaging episode of The Secure Developer, host Simon Maple chats with John Delmare, Managing Director of Accenture and Global Application and Cloud Security Lead, about the movement towards platform consolidation in the field of DevSecOps.

They dive into an in-depth exploration of the potential advantages and barriers that emerge from the reduction of tool sprawl. Using his extensive experience and insights, Delmare sheds light on how this development can enhance efficiency for developers and, at the same time, benefit companies by making processes more streamlined, cost-efficient, and effective.

Not losing sight of the role of best-of-breed tools, the conversation takes a turn into how such tools fare in the current scenario, whether they still hold relevance, or if the consolidation trend is set to overshadow them. More intriguingly, Delmare and Maple delve into the potential implications of emerging technologies like General Artificial Intelligence (GenAI) on the strategies for security tooling.

Further enriching the conversation, they emphasize the critical need for a common ground between security and development teams. Platform consolidation comes into play here by offering shared data views and aligning the teams towards unified goals, making the perfect case for seamless DevSecOps practices.

This episode is packed with insights that would cater to developers, security professionals, and decision-makers in the IT industry, offering them a clearer view of the current trends and allowing them to make strategically sound decisions. Tune in to be part of this insightful conversation.

Links

Follow Us

Episode Transcription

John Delmare: “In general, I'd say it turns out better. I mean, it's far from universal, right? There are always going to be people that are going to be pissed off that you took something away from them that they really liked or replaced it with something different. But when you look at it from an enterprise-scale perspective, I'd say that, typically, it's an increase in quality of life versus detraction from it. I think that that speaks to the maturation of the industry as a whole because, again, I think rewinding 5 to 10 years, the tooling in this space was nation, right? It was, most of these companies were really good at one thing. You might be really good at SAST. You might be really good at DAST. It might even – within that beat, we’re great at these sets of languages and not great at these other sets of languages.”

[INTRO]

[00:00:45] ANNOUNCER: You are listening to The Secure Developer, where we speak to leaders and experts about DevSecOps, dev and sec collaboration, cloud security, and much more. The podcast is part of the DevSecCon community found on devseccon.com, where you can find incredible dev and security resources, and discuss them with other smart and kind community members. 

This podcast is sponsored by Snyk. Snyk’s developer security platform helps developers build secure applications without slowing down, fixing vulnerabilities in code, open source containers, and infrastructure as code. To learn more, visit snyk.io/tsd. 

[INTERVIEW]

[00:01:32] Simon Maple: Hello and welcome to another episode of The Secure Developer. My name's Simon Maple, and I will be your host for this episode. Joining me today is John Delmare, Managing Director of Accenture and also the global application and cloud security lead. Welcome, John. How are you?

[00:01:50] John Delmare:  Thank you. I'm well. Thanks. Excited to be here. 

[00:01:52] Simon Maple: Excellent. Well, we're looking forward to a great conversation. I mean, in this podcast where we very often talk to a number of people who have had experiences as their role in the security team for a particular company. But just as we were talking offline, it's great to be able to talk to someone who's had so much experience from so many different companies and different points of view, which I guess you've had for many years at Accenture, right?

[00:02:15] John Delmare:  I have. Yes. Now, I've been with Accenture for almost 18 – It'll be 18 years in April. Only about half of it within security actually. The first half I joined into our technology consulting practice out of our Seattle office 17 and a half years ago. I spent the first part of my career there working with a lot of product development organizations and then a lot of – when Agile came on, I see a lot of Agile transformations and DevOps transformations and things of that nature. 

Then midway through, I found religion and I stumbled across a cloud security project at the time where we were doing a lot of DevSecOps work. I found that I had a passion for it. When they asked me to transfer into security, I looked at them like, “Are you sure? Because I'm pretty sure the only thing I know about security is how to get around the security team.” They said, “That works great, actually. You can help us out with that piece of it.” 

For the last eight or so years, it's been all about application security and DevSecOps. A couple years ago, I took on our AppSec practice. More recently, I’m largely in response to what we're seeing in the market and the way companies are evolving. We've combined our cloud and application security practices to more effectively address some of the problems that our clients are dealing with in that respect. It's been a heck of a journey. It's a lot of fun being able to solve these problems for our clients and all these different companies in terms of how they're modernizing their digital estates. 

[00:03:29] Simon Maple: Yes, amazing. So they basically said, “John, we can't get you to speak to our security team. So the only way we can think of managing it is to actually put you in the security team.” You're forced to speak to them. 

[00:03:40] John Delmare:  That's pretty much it. If you can't beat them, join them, right? 

[00:03:43] Simon Maple: Absolutely. It's interesting actually that you cover cloud security and application security now. Talk us through a little bit about how you see those two teams. Either are they consolidating? Are they staying apart? How do you see the dynamic of those two different groups? 

[00:03:56] John Delmare:  This is a very recent change for us, but it made a lot of sense from two different perspectives. So the first one was we looked at our teams that were doing this kind of work doing cloud security and application security. While there are some aspects of it that are very unique to each one of the worlds, like in the cloud world a lot of the OS-specific stuff, a lot of the CSP-specific things. On the AppSec side, there's SAST and DAST and things that are very specific to the application world. 

But then like if you think about it as a Venn diagram in the middle, there was a whole slew of common skill sets around DevSecOps, granted it might be deploying infrastructure as code or application code. But kind of core DevSecOps skills were so similar and API security in terms of not only how to build and deploy them but how to monitor them at the runtime, container security, server list, the list goes on. There was such a high level of overlap in the skills and the type of work that people are doing. It made sense. 

Then from a market-facing perspective, that's what we see playing out in the industry as well. The era of mass lift and shift is maybe not over, but I think it's winding down. Increasingly, these large companies are more pivoting to more complicated problems around complex modernisation and how do you actually refactor and rearchitect some of these applications to be cloud native and run in the cloud more effectively.

As they're pivoting in that world, it just made more sense to pivot our team’s response to that, and we're seeing also our clients are oftentimes merging their teams as well. So more and more, I'm working with these companies where you talk to the AppSec lead who's also the cloud security lead because, from their perspective, it makes sense. So not only like where the cloud journeys are going but where our clients and these companies, how their security teams are orchestrated and how our own skill sets kind of merge together. 

We're like, “This is kind of a no-brainer.” So we fuse those teams together, and we're working on rolling that out because we think that's going to be the best way to help solve some of these problems out there. 

[00:05:49] Simon Maple: Yes, very interesting. I'd love to kind of like expand that discussion a tiny bit and talk a little bit about market conditions. I suspect over the last couple of years, obviously, not ideal and a lot of companies have needed to react to those. Obviously, essentially, you're in constant contact with so many different organizations and companies. How have those that you have worked with fared through these times, in particular around security budgets and the activities that their programs are working with? How have you felt like those have been impacted?

[00:06:18] John Delmare:  It largely follows overall IT spend in my experience. It's caveat that by certain industry-specific things, so highly regulated industries with very iron clad compliance since they have to go to like budgets stay a little bit more stable from a security perspective for those. But especially for cloud and application security, by the nature of the fact of how federated out accountability is for AppSec and cloud security to the actual IT and delivery teams, I typically see those budgets kind of rise and fall in line with what the IT and the digital orgs are getting. 

The pandemic was boom times. Obviously, there's a ton of money thrown at the problem there. Since then, though, we've seen a huge push to get more efficient. Teams are being challenged to do more with less. That's across the board within IT but also in security, although we like to think that we're very unique, we're not immune to those influences. So there's been a ton of pressure of, okay, we've given you a bunch of money over the past couple of years. 

Now, it's time to grow up in a way and mature our processes and mature how we approach things to get more done. It's not a never-ending budget that we get, right? So thinking through how security teams can evolve, how they deploy their people, how they deploy their technology, how they operationalise that, these are all factors that we're having to start to think a lot harder about lately, at least from what we're seeing. 

[00:07:33] Simon Maple: Yes. I mean, absolutely. I guess if we're looking at a lot of the tooling and processes that we needed to change as a result of this, what would you say are kind of like some of the primary considerations, I guess, for companies when they need to think about what tooling needs to be used or what programs they want to run? What are typically the things that they think about when they want to plan these?

[00:07:54] Simon Maple: That's a good question. I mean, it costs, first and foremost, right, because of those budget pressures everyone's under now. A lot of times, we like to think that it's more about other factors around like efficiency and best of breed this, that, and the other thing. But a lot of times, it comes down to how are you quantifying and managing your costs around it. That's a big piece of it. 

The second piece of it is capability mapping and making sure that the things that you want to secure that you have technology properly aligned to all those aspects. A lot of times, you start out with the mindset of trying to reduce cost and consolidating reduced tooling. But you'll uncover that you actually have gaps that might require more investment in those spaces. So it's more like a redeployment of investment to be more efficient, rather than overall reduction sometimes. Not all the time, obviously. 

But in terms of how considerations around it, I think a lot of times we see it's kind of on a maturity curve, right? So whereas at the beginning, rewind 5 or 10 years when AppSec programs were starting to get off the ground, you were seeing companies kind of throw tools at it a little bit like, “Hey, let's just get something out there. Let's get something operationalised. Let's give a scanning tool that, okay, great. They like that tool, great. Go use that. They like that tool, great. Go use that.” The idea was just to get coverage. 

As programs and the teams have evolved, you can start to take a step back and be like, “All right, is that really the right way to address this problem?” It follows, in my experience, the rise and fall or maybe not rise and fall but the pendulum swinging of the broader IT tooling ecosystem. So like this is not specific to security, right? The same thing happened in DevOps world, where when DevOps started to get real big, it was like, “Hey, pick the right tool for the job.” Everybody gets to pick the right – whatever they want to use. 

Then over time, there was a realization across these companies that, yes, that might be great for a team or that team or a small collection of teams. When you look at this from an enterprise-scale perspective, the licensing was starting to get unmanageable. The infrastructure cost was starting to get unmanageable. The consistency of quality and results across these teams was a little bit too all over the place. So you start to see that pendulum swinging back towards more of – I mean, the buzzword today is a platform engineering approach, right, which is essentially a consolidation of lot of those things into a single platform. 

I've seen the same thing in the security landscape as well, is that at first it was like, “Hey, pick whatever you want.” Now it's, “All right, let's try to be a little bit smarter about this and standardise on some tools because it can be so much more helpful to not only controlling costs but to accelerating scale and adoption as well.” Because all of a sudden, now there's fewer tools you have to train people on. There's fewer things to learn about. There's fewer things to manage. There's fewer frameworks and technical standards. 

It streamlines the whole process to be able to get that more consistent scale, which is what most of our clients are really after. We want to be able to consistently answer the question, is my digital estate secure? So anything you can do from a tooling and technology perspective to get there is super helpful. 

[00:10:51] Simon Maple: It’s interesting the way kind of like you mentioned it a couple of times there was in the early stages, I think you said certain developers will go out, and they'll pick whatever tool they want. Very often, it's because it's the best tool for the job. Sometimes, it's not necessarily a great tool, but it's the one that a developer has experience with or the first one that they picked up or whatever. So they pick something up. 

Is this typically something that tends to happen? Is this a common outcome where, typically, people will have to consolidate because they just have a sprawl of tools? Or is this something which you feel companies out the box can sometimes come out and say, “Look, we need this solution. I want to roll out a good platform solution for all of our developers,” and that this is the option? Do you feel people are in one bucket or the other? Or is it mostly one?

[00:11:38] John Delmare:  Well, I'll give a little bit more of a nuanced answer to that because there's two kind of dimensions to this movement. So one of them is just a straight what I think was a de-duplication, where, oh, my gosh, we have six different SAS tools deployed throughout the enterprise. That makes no sense. We need to standardise or reduce the number of those. That's largely kind of what we talked about at this point like cost consolidation and like ease of scaling, things like that. 

Then there's the other dimension of, “Okay, we've de-duped everything, and we have our standardised tools. Out of those, what makes sense to consolidate into a single platform?” Because that's where we see a lot of the tooling industry going right now, right? Is that either through organic growth or acquisition, all these are consolidating into platforms. You get benefits with that around single panes of glass and ease of management and streamlining the procurement licensing process. 

So it's a slightly different set of drivers, but I typically see it as kind of a one-two punch. At first, they look at capability mapping and de-duplication. Then secondarily, it's, all right, now out of that, what makes sense to purchase as sort of a single platform? Are vendors and companies that they can cover big patches of this because it just makes more sense to do it that way? It's interesting, though. 

[00:12:49] Simon Maple: It’s interesting as well that I think from listening to your answers, a lot of the benefits or the advantages of those consolidations. It tends to help the business a little bit more. I think when we’re talking about whether it's costs, whether it's fewer vendors that they would have to deal with, whether it's procurement, that teams that can get more benefit because they're using more platforms maybe over more years with greater number of licenses. That's all great. 

But one thing that we haven't talked about here is the end user, right? It's like the developer. How is the developer impacted potentially if you take away their beautiful one tool because not enough people were using it, and they've been given something else, which they don't particularly want to use but almost being forced to use? How do you see organizations consolidate onto a single platform? Does your mileage vary, depending on the vendor? Or does it at the end of the day turn out better overall for that developer as well?

[00:13:43] John Delmare:  In general, I'd say it turns out better. I mean, it's far from universal, right? There's always going to be people that are going to be pissed off that you took something away from them that they really liked or replaced it with something different. But when you look at it from an enterprise-scale perspective, I'd say that, typically, it's an increase in quality of life versus detraction from it. 

I think that that speaks to the maturation of the industry as a whole because, again, like because – I think rewinding 5 to 10 years, the tooling in this space was nation, right? It was most of these companies were really good at one thing. You might be really good at SAST. You might be really good at DAST. It might even – within that beat, we're great at these sets of languages and not great at these other sets of languages. 

A lot of times in those early days, the developers were picking things that work well for what they needed to do for their particular language technologies that they were working with, right? Now that we're at a place where so many of these tooling companies have broader capabilities where they're pretty great at most of the languages and because they're taking this platform approach, they can do all these things. It's a one-stop shop. 

Once you kind of introduce the development teams to that concept that, “Hey, it does it just as good, if not better, as what you're using before, but you also get these other benefits around it,” it’s not that hard to win hearts and minds around it, especially if you can make the case that, “Hey, we're going to redeploy some of the savings to these other areas that are going to make your life better, right?”

[00:15:08] Simon Maple: I hear that quite a lot actually when people start realizing, “Oh, yes, I was using this tool. But now, I get these three other tools for free, and I don't actually have to do anything, and I can see when they run or when these notify me of whatever outcomes are of those tools.” That's typically a big game because, actually, they would have probably been a greater pain by using three other tools for that to maybe stand out by themselves. They don't get that support of perhaps a platform team or an overall central team providing that to them. 

Let's turn that around, though. When we think about the best-of-breed, do you still see – despite all the consolidation that's happening, is there still a place for best-of-breed within our tooling choices? 

[00:15:45] John Delmare:  There's always going to be a place. Particularly for emerging technology areas, new or growing languages that come onto the scene or frameworks that come up, or it could be new technology as a whole that we have to figure out a way to secure like, for example, when containers came on a scene. How do you properly secure a container image and scan that? So a whole suite of investment was directed to startups around that problem. 

I think that if you want to take a real risk-based approach of making sure you're securing all the new stuff that comes up, that's kind of the sweet spot in my mind for the best-of-breed kind of tools. Or if you have like a very specific, very strategic initiative for your company, where you have to stand up x technology, whether it be a digital marketplace, whether it be – whatever it is and making sure that you take your best developers, which they oftentimes do for these super important things and take the best tooling for the job and put it in place for it. Sure, that makes sense. 

By and large for the broader enterprise, I think it just makes sense. Again, you can't take a consolidation for the sake of consolidation approach. You have to do it where it makes sense. That's why I usually like to start with that capability mapping and making sure that, number one, you have everything covered and de-duplicated to some extent. Then you look at within that what platforms can cover big patches of it where it makes sense. It's not like, hey, we're just going to pick a platform and force it down everybody's throat. It has to have a business case and a reason behind it. 

Then the other side of that, too, that we haven't really touched on yet is you mentioned some of the business benefits, too. It's amazing to me when we do a lot of these tool rationalization efforts. How many companies really don't understand how much they're spending on technology across the company? Not only do they understand it, but they don't have a real way to discover it. It's literally going through PDFs in their procurement system to pull out licensing. There's like no centralised tracking for it. 

That’s another benefit and great justification for initiatives like this is not only are we going to save money and probably get better security out of it because we're going to uncover gaps and increase developer experience, all these things. But we're going to find some drivers to improve the procurement process as a whole, too, because you're going to get this data for the first time. Once you get the data for the first time, identify the sources, you can better industrialise that tracking going forward as well. 

[00:18:07] Simon Maple: Yes. No, absolutely. Is there an argument also for the makeup of a company? Maybe it's the size of the organization, the size of the security team maybe or whether it's budgetary restrictions or not. Are there certain types of companies that you see favor one versus the other? Maybe even the difference between like a startup, say, and a – well, not a startup. A midsize company and an enterprise company, for example. 

[00:18:31] John Delmare:  Small, midsize, and even like the smaller and the large enterprises have a much higher appetite for buying – have to sort of a platform-first approach. It's more of like a, “Hey, we need the 90% solution at a cost-effective price that can get us the best bang for the buck.” So we see a lot of consumption of that in that space. 

Much larger enterprises, it kind of depends on where they're at in their budgetary cycles. Because they have such more industrialised plumbing and machinery around everything, they can take this piece of tech over there and this piece over there, and tie it together via their frameworks and their data architecture, and get some of the benefits you'd otherwise get from a single platform type of company. We see a lot more variation, I think, in a large one, just because of that. 

[00:19:19] Simon Maple: Clear benefits probably I would say either side in terms of whether you want a specific platform tool, consolidating to a tool, or best-of-breed tool. If we think about it from an absolute results side now in terms of, okay, what's my team actually done with this platform versus a set of, a collection of tools, what have you seen in the responses of organizations that have moved to a platform over time? Are they able to actually get better results do you feel with a platform versus a set of tools or vice versa? 

[00:19:51] John Delmare:  I feel the biggest benefit there is around the visibility because it's so often so hard to tie together the different tools into a single view, where it's like, all right, we have our SAST results from over here, our DAST results from over there, our SCA results from over here. Tying them all together into like a single view of risk for an application, which is at the end of the day what most of these executives are after. They just want to know, “Is my application or my cloud estate secure?” They don't really care about the fact that they have x-rated defect closure on SAST and SCA. It's like, “No, is my stuff secure and how do I know that?” 

I feel like that's a great benefit that some of these consolidated platforms bring is the visibility to that where they tie all the results from the different products together into a single thing. Much more so than on the developer experience, although I do think there are benefits because, again, the devs only have to learn a single tool or a single platform which is great. But I feel like the benefits of that visibility and the analytics piece outshines a little bit. 

[00:20:49] Simon Maple: I like that. That approach is almost like if everything was equal in terms of usability and experience and things like that, I think best-of-breeds would be perfect to get those kind of results in the same platform. But such a thing doesn't exist necessarily. But, no, no, very interesting. 

Looking forward, how would you foresee, I guess, whether it's the market slowly improving over time now in 2024 and beyond? How do you foresee how security tooling strategies will continue, I guess, particularly with things like new technologies in and around AI, which as you mentioned, there are going to be very specific new tools that are created as a result for these kind of new technologies? Do you see consolidation still being an important thing in a year or two or as budgets maybe open up slightly more and, hopefully, soon in the near future? Do you see people more kind of like going back to a sprawl approach?

[00:21:47] John Delmare:  I think this trend has legs right now. We've seen this big wave of it happening within the cloud and AppSec sides respectively. I think kind of the next one is a continuation of that with those two worlds coming together, which we're already seeing a lot of vendors doing. Snyk’s one of them. How do we get better visibility into the applications in the cloud and not thinking about them separately, kind of going back to what we're talking about at the beginning? 

In my opinion, I think that's going to continue. We're going to see a lot more of that. Trying to do more with less is a trend that ain't going away anytime soon either. So there's going to be a continued appetite for consolidating technology landscapes, I think. The GenAI piece that you brought up, that's the wild card, right? I think everyone's kind of sitting back right now as like, “All right, which areas of this is GenAI going to make totally obsolete, whether it be on the discovery scanning side or on the remediation side or both of them, workflow and management? How's this going to impact how security requirements and threat models are generated, and how's that then tie into the testing life cycle and remediation?” 

It's a really exciting time that I don't think anybody has like the beat on yet. But it has the potential to radically upend this whole thing, so yes. Well, I think the consolidation will continue marching on. I think everyone's kind of waiting to see what this GenAI wild car is going to turn out to. I'm really excited to see how that shapes up. I know there's a lot of startup investment going towards. I know a lot of the big players are taking this really, really seriously and have already incorporated it to a large extent. So it's an exciting time to be in the space, I think. 

[00:23:15] Simon Maple: Yes. That sounds great. That sounds amazing. Let's slightly twist onto, I guess, when a vendor like Snyk, for example, or others, when they do provide, deliver a platform of capabilities, whether it's SAST and SCA and many more, what would you say are the core characteristics of a platform that make it consumable successfully versus just one vendor with many products? 

There's a lot of companies, for example, as when they do, products actually stay fairly unique in terms of they're not consolidated. They're actually more of a number of different tools, each with their own look and feel and so forth. That will, obviously, tick a lot of the boxes in terms of fewer vendors, those kinds of things. But the usability in things are, obviously, as distinct products. What would you say are kind of like some of the most important things, if you was to look at a platform that you would see as, “Yes, these are my top three most important aspects that I can see adoption, more seamless adoption by my organization?”

[00:24:18] John Delmare:  That's a great question. I think the first one is the degree to which they can integrate views of risk. Like I said before, great, you have it all in a platform. It's all tied together. If you have to click on different views to see SCA versus SAST versus DAST versus containers, whatever, you're not getting any of the value of a platform. So it's the degree that you can merge that risk reporting in a way that you can see at a glance what your risk landscape looks like. Also, just as importantly, what you need to do to improve it. I think that's like a huge important thing. 

The second piece of that is the degree to which most times it is either scanning-based or monitoring-based, right? So either the findings or the alerts, how are they piped into the rest of the ecosystem? In my opinion, a platform that tries to be self-contained, especially the development community, trying to get the development community swivel chair over to their platform to take actions or review things is not going to be very successful. You have to have it integrated into the rest of the development life cycle and have those results push and discoverable into the workflow management tools that they're already using. It doesn't make sense to try to create new workflows that people have to pivot over to, so the views of risk, the integration into the development tools where people actually take action on fixing and remediating things. 

Then thirdly is more sort of a philosophical thing, I suppose. But I see certain companies focus very, very specifically on developers. I see some of them focus very, very specifically on like the risk team. I think that both of them sometimes lose the forest for the trees. It's like, yes, you have to have a developer focus and, yes, you have to have a risk focus. But you can't focus exclusively on either one of them. There have to be dimensions to solving the enterprise problem because that's what this is. It's an enterprise problem that you have to give visibility on, but you also have to pipe things into the development hands, and make sure that their experience is good and conducive to actually taking action and reducing your risk. 

Having that holistic mindset, I feel like, is really, really important that sometimes it gets lost in the shuffle of being am I optically focused on developers, or am I am optically focused on like the risk and compliance team. 

[00:26:20] Simon Maple: Yes. No, I think that's a really good summary. One extra piece that, as you were mentioning it, I thought you were going to go there actually when you were talking about almost like the dev side and the security side. One thing in addition that we often see as well is almost this need for developers and security to not necessarily have discussions on their own land as it were. 

So not to have dev and security talking about a view from security and likewise, not have them both talk about a pure risk view on the security side, but to have some kind of like common ground in the middle, where there's one dashboard or one view of data to be able to say, look, this is what we're both going to be talking about and looking at such that we can almost like track our same goal on this dashboard, whereby it makes sense to both of us, rather than in one backyard or the other. I think, yes, there's some really top advice there. Appreciate sharing that. 

[00:27:11] John Delmare:  I totally agree with that addition. This is one of those areas in security is that it's more highly federalised than any of the – I mean, it's not like the security team can go flip a firewall switch to solve a code problem. You have to take accountability for actually doing the work, and those teams have to work together. Having a silent thing where you're just pitching things over the wall, I mean, I think we all know. We've seen it over the past decade. It doesn't work. So having tooling that facilitates those teams coming together has got to be the goal. 

[00:27:37] Simon Maple: Yes. Wonderful. John, we could talk for another 30, 40 minutes. I'm sure. We should cover, of course, the final question which we're always asking. If there's one part of your job that you could give away to AI, what would it be and why?

[00:27:52] John Delmare:  I think anybody who knows me will just start laughing. I am a administrative operational nightmare. So anything that I can offload in my world around administrative tasks or operational, like give that to GenAI and solve that for me. I'll take that in a heartbeat. 

[00:28:07] Simon Maple: You'll be surprised how many times this gets given as an answer. I know there are tens and hundreds of startups trying to fix this problem, but there should probably be thousands. 

[00:28:16] John Delmare:  Come fast enough. 

[00:28:17] Simon Maple: Yes, absolutely. Wonderful. Well, John, thank you very, very much for your time. This has been a really great discussion. Really, really pleased to have you on The Secure Developer. 

[00:28:25] John Delmare:  Yes. Thanks for having me. This is fun. 

[00:28:27] Simon Maple: Thank you and thanks for everyone who tuned in. We'll speak again soon. 

[END OF INTERVIEW]

[00:28:34] ANNOUNCER: Thank you for listening to The Secure Developer. You will find other episodes and full transcripts on devseccon.com. We hope you enjoyed the episode, and don't forget to leave us a review on Apple iTunes or Spotify, and share the episode with others who may enjoy it and gain value from it. If you would like to recommend a guest or topic or share some feedback, you can find us on Twitter @devseccon and Linkedin at The Secure Developer. See you in the next episode. 

[END]