"AI didn’t invent new classes of risk. It poured fuel onto existing ones."
Dr Andrew Bolster sets out new security approaches that respond to the accelerating pace of AI-enabled software development.
AI is no longer an experiment inside the software development lifecycle. It’s already embedded in everyday engineering work. Developers now routinely use AI-powered tools to generate code, refactor logic, suggest optimisations, and even review pull requests. This adoption has happened quickly, and often ahead of internal policy maturity, creating understandable unease among security and governance teams.
That tension is frequently framed as a problem of “shadow AI” or policy non-compliance. But from an application security perspective, that framing misses the point. The real issue isn’t who or what wrote the code. The real issue is whether the organisation can accurately understand and manage risk at the pace at which software is now being produced.
Ultimately, deployed code behaves the same regardless of its origin. Vulnerabilities don’t check authorship. License obligations don’t change based on whether a human wrote a function or an AI suggested it. Once code ships, it contributes to application risk in the same way: meaning security outcomes depend on visibility, context, and decision-making, not process purity.
Acceleration Without a New Threat Model
AI didn’t invent new classes of application risk. What it did was pour fuel onto existing ones.
Development velocity has increased dramatically over the past few years. Codebases are larger, release cycles are shorter, and change surfaces are constantly shifting. Application security programs, however, were largely designed for a slower, more predictable pace of delivery. Many still depend on manual review, periodic scans, and downstream feedback that arrives long after code is written.
This growing mismatch between development throughput and security capacity is the real pressure point. When teams deploy daily, or multiple times per day, while security review scales linearly, something has to give. The result is usually deferred remediation, exception handling, or widening vulnerability backlogs.
AI didn’t create that bottleneck. It exposed it.
When Feedback Arrives Too Late
As development outpaces review, feedback loops stretch and eventually collapse. Developers receive security findings weeks after the relevant context has faded. Security teams see alert volumes rise while their ability to triage declines meaningfully.
Over time, this degrades trust on both sides. Developers see security as a source of noise or delay. Security teams struggle to separate urgent issues from low-impact findings. Backlogs grow, remediation slows, and organisations convince themselves they’re “managing risk” simply because scans are running.
This leads to a dangerous paradox: high confidence paired with low discrimination. Teams believe they have AI risk under control, yet acknowledge that most alerts don’t meaningfully influence decisions. The issue isn’t a lack of tools, it’s a lack of usable context at the moment decisions are made.
Why Models Alone Aren’t Enough
Modern LLMs are extremely capable at recognising general patterns. They can generate syntactically valid code, identify common vulnerability classes, and suggest remediation ideas based on what they’ve seen before. That makes them valuable accelerators, but also fundamentally incomplete as security decision-makers.
There are entire categories of information AI systems do not naturally possess, including: your organisation’s specific threat model, historical decisions about which risks were accepted or rejected, architectural trade-offs made for business reasons, evolving priorities that shape acceptable risk, and the real-time status of incidents, delivery pressure, and remediation ownership. Trying to “teach” all of this through fine-tuning or static training quickly breaks down. Business context changes faster than models can be retrained. The problem isn’t intelligence, it’s relevance.
Securing AI-accelerated development doesn’t require smarter models. It requires better context, delivered at precisely the right time.
Without Context, Security Scaling Breaks
The organisations that are succeeding with AI-driven security aren’t those chasing the most advanced models. They’re the ones that deliberately govern and operationalise context. In practice, that context tends to fall into three categories:
Facts: These are objective, verifiable inputs: vulnerability data, security advisories, SBOMs, component versions, license identifiers, and severity metrics. This is foundational intelligence; necessary, but not sufficient on its own.
History: This is where context becomes powerful. Historical knowledge captures how findings were triaged in the past, which risks were accepted, which were remediated, and why. It reflects lived organisational experience rather than abstract policy. Lose this, and teams are forced to relearn the same lessons repeatedly.
Opinions: Expert judgement (codified and scaled) is what turns raw findings into priorities. It reflects how experienced security professionals weigh impact, exploitability, and business relevance in real scenarios. This layer transforms data into decisions.
Individually, these elements have limitations. Together, they enable security systems to reason more like experienced practitioners, and to do so at scale.
Reframing the Role of AI Agents
Within this contextual framework, AI agents can be highly effective. Rather than acting as autonomous security authorities, they become interfaces to institutional knowledge. They can review AI-generated code against known license constraints. They can surface remediation suggestions aligned with prior decisions. They can explain not just what a finding is, but why it matters in the current environment.
Most importantly, this approach supports developers where they work: inside editors, pull requests, and pipelines; and do so without turning security into a blame exercise. The goal isn’t to police authorship. It’s to improve decisions at the moment they’re made.
Building Momentum Where It Matters Most
Regulatory expectations are rising while reporting windows are shrinking. Budgets are tighter, not looser. In this environment, success won’t come from running more scans or generating more alerts faster. It will come from delivering the right security context directly into development workflows before pipelines overload and teams disengage.
AI hasn’t made application security harder. It has made inefficiencies impossible to ignore.
The future of application security won’t be defined by fear of AI-generated code. It will be defined by how effectively organisations contextualise risk, scale judgment, and support faster decisions at the speed modern software demands.
Dr. Andrew Bolster, Sr, is R&D Manager at Black Duck
