AI is changing software development. AppSec leadership must change too 

If there was any doubt remaining over the importance of AI to contemporary software development, Google’s 2025 DORA Report largely put it to rest. Its headline finding that AI adoption among software development professionals had "surged" to 90% illustrates just how quickly these tools have become embedded in everyday engineering workflows, with developers now spending a median of two hours each day working with AI. As the report goes on to explain, “The key takeaway is clear: AI is a transformative tool for developers.” 

 

This has significant security implications. But while much of the discussion has focused on the risks AI introduces into software, far less attention has been paid to what it means for the people responsible for securing it. 

 

Until relatively recently, this wasn’t so much of an issue. Generally speaking, application security kept pace with software development and release cycles, and because these took longer, security teams had defined opportunities to review applications before production. 

 

Today, however, AI-assisted development has compressed those timeframes by increasing both software output and the pace at which changes reach production. And let’s be clear, this isn’t just about generating more code; AI has also lowered the barrier to software development, enabling people without deep programming expertise to build software from natural language prompts through a process known as ‘vibe coding’.

 

A 2025 post on X by Andrej Karpathy, a founding member of OpenAI, which has now been viewed more than seven million times, sums it up nicely: "There’s a new kind of coding I call ’vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

 

Bad vibes? 

From an AppSec perspective, however, the downsides are increasingly evident. Every new application that draws on vibe coding potentially expands an organisation’s attack surface. It stands to reason that as software output increases, so does the volume of code that must be secured, especially as the speed of development and the speed of security assurance are becoming increasingly disconnected. 

 

As AI shifts how development work happens day to day, prioritising speed, intuition and experimentation over formal review, there are significant security implications. According to a HackerOne survey of 303 senior security leaders at global enterprises, 94% of organisations expanded their AI/ML footprint in the past year, but only two-thirds formally test more than 60% of their AI systems. Development is scaling while security coverage lags behind.

 

AI-generated code may appear technically correct yet contain insecure design choices, weak authentication logic, exposed secrets or vulnerable dependencies, among other issues. As a result, application security needs to extend well beyond vulnerability scanning to cover secure development practices, governance for AI-generated code, open-source dependency risk, cloud-native applications and the integration of security into CI/CD pipelines. 

 

An ownership shift

As development becomes continuous, application security has to become continuous too. Today, the scope of AppSec has expanded beyond vulnerability management to include AI governance, software supply chain risk, developer enablement and cloud-native security. 

 

Ultimate accountability often still rests with the (very busy) CISO whenever an application is compromised. However, no single executive can effectively absorb all of that alongside broader security responsibilities. The challenge is managing an application security function whose scope has expanded significantly in a very short period of time. 

 

For organisations that have already recognised these challenges, application security has become a specialist discipline in its own right. As its scope has expanded, many are recognising that it requires dedicated leadership, elevating the Head of AppSec from a technical management position to a strategic leadership role.

 

From technical to strategic leader

But what does this look like in practice? Firstly, a ‘Head of AppSec’ should not be viewed as another layer of management; the role exists to provide dedicated leadership for an increasingly complex security discipline. Rather than acting as the final approver before software is released, the Head of AppSec helps embed security throughout the software development lifecycle. 

 

The role should collaborate with engineering leadership to ensure security requirements are embedded in everyday development rather than applied at the end of the process. The Head of AppSec should also be there to help developers work more securely by providing guidance that fits naturally into existing engineering workflows. All of this should sit within a governance framework that ensures AI-generated code is subject to consistent security oversight.

 

By taking ownership of day-to-day application security, the Head of AppSec enables the CISO to focus on broader security leadership. The role provides a single point of accountability for application security, ensuring that decisions about software risk are made consistently rather than being distributed across multiple teams. In practice, this means owning vulnerability prioritisation, establishing governance for AI-assisted development, measuring remediation performance and ensuring security tooling produces meaningful outcomes rather than simply more alerts. 

 

An effective Head of AppSec turns noise into signal. A vulnerability is no longer simply another finding in a report; it becomes a business risk with an owner, a priority and a clear path to remediation. Developers receive guidance that is practical, actionable and aligned with the way they already build software, helping security become an enabler of delivery rather than a blocker to it. The role also helps translate technical findings into business risk, creating the space to prioritise issues based on their potential impact rather than the volume of vulnerabilities identified. 

 

A balancing act

AI-assisted development is not a temporary shift. As organisations continue to accelerate software delivery, they must also evolve how application security is led and governed. Rather than attempting to oversee every component directly, security leaders need operating models that enable effective oversight at scale.

 

Get the balance right, and organisations can aim for a win-win of a development culture that embraces vibe coding but does so without introducing additional and quite possibly completely avoidable new risks. Get it wrong, however, and we can expect more headlines about AI-generated software exposing organisations to risks that should have been identified long before applications reached production. 

 

---

 

Sid Nanda is a Staff Product Manager at HackerOne, where he leads the context integrations strategy for HackerOne’s agentic continuous threat exposure management (CTEM) solution

 

Main image courtesy of iStockPhoto.com and BlackJack3D