AI coding assistants have transformed how quickly software can be built, but they have also intensified a long-running tension between development speed and security assurance. “There’s an awkward reality coming to light in the cybersecurity world: developers are being told to ship faster at the exact moment security teams need more scrutiny over what gets shipped,” says Katie Paxton-Fear, Staff Security Advocate at Semgrep. “Most developers want to build securely, but they’re also under real pressure to get code out the door.”
“AI has poured gasoline on that tension,” she continues. “A developer can now generate a feature, integration, or entire block of application logic before a traditional security review would have even started. The model may produce perfectly functional code. It may also choose an insecure function, misunderstand a trust boundary, or introduce a vulnerability the developer doesn’t know to look for.”
Kelvin Lim, Head of Security Engineering (APAC) at Black Duck, acknowledges the scale of the change but argues the core objectives remain the same. “AI is changing how software is developed. Teams are producing more code, at greater speed, and security programs need to keep pace. However, the fundamentals have not changed. Organizations still need to understand what is in their software, identify the risks, and have confidence that those risks are being managed.”
His colleague Dom Glavach, CISO at Black Duck, puts the stakes plainly. “In the AI era, securing our world is making innovation fast, accountability clear, and trust measurable,” he says. “AI has made software development faster, and speed without independent verification can scale risk just as quickly.”
Not an either-or decision
As AI-powered security testing tools mature, some organizations are asking whether they can replace established approaches altogether. Lim rejects that framing. “When it comes to the intersection of application security and AI, I do not see deterministic and AI-driven testing as an either-or decision. Both have an important role,” he says. “Deterministic testing gives organizations consistent, repeatable results. This is critical for tracking remediation, enforcing policies, and meeting audit and compliance requirements. AI-driven testing brings a different strength. It can reason across code and business logic, helping teams identify complex vulnerabilities that established rules may not detect.”
Glavach takes a similar view. “Organizations should use AI to expand security reasoning and identify complex issues, while relying on repeatable testing to confirm results and provide evidence that risk has been materially reduced,” he says. “The most defensible approach combines AI-driven and deterministic testing so that each method challenges the assumptions of the other. AI contributes contextual reasoning, adaptability, and the ability to explore complex paths. Deterministic methods such as static analysis, software composition analysis, and runtime testing provide consistent coverage, reproducible results, and measurable assurance.”
In practice, Lim says, the question is where each approach fits in the software development lifecycle. “The practical approach is to apply each method where it delivers the most value. Deterministic testing should remain part of the development lifecycle, especially at build and release gates where consistency and auditability matter. AI-driven analysis can add another layer of review for complex code changes, business logic, chained vulnerabilities, and code written with AI coding assistants.” Crucially, he adds, “Any findings still need to be validated, prioritized, and governed through the organization’s existing application security processes.”
The shared blind spot
Glavach highlights a specific risk that emerges as AI takes on more of the development pipeline. “This matters most when AI creates and reviews the same software. The two systems can share the same blind spot,” he warns. “Independent testing methods provide the perspective diversity necessary to close these gaps.”
Paxton-Fear agrees that simply asking a model to behave securely is not a control. “‘Write this securely’ isn’t enough context for an LLM. Security has to move closer to creation,” she says. “Code should be checked while it’s being written. AI-generated changes should get the same scrutiny as human-written ones.”
Just as important, she argues, is the quality of what developers are shown. “Findings also need enough context to explain whether a weakness is genuinely exploitable instead of burying developers in another pile of warnings. The goal is to help developers move quickly without making security another obstacle to getting good code out the door.”
Embrace AI, keep the controls
For Lim, the message this Cybersecurity Awareness Month is one of balance. “AI is here to stay, and we should embrace the value it brings. But we should not remove proven controls simply because a new technology is available,” he says. “The real opportunity is to combine AI-driven insight with deterministic assurance. This will help organizations identify more risks, support developers in fixing issues earlier, and deliver software faster without compromising security or trust.”
Paxton-Fear concludes that, far from sidelining developers, AI is making their role in security more central. “AI isn’t removing developers from the security process. It’s making good developer guardrails more important. If software creation is going to accelerate, secure development can’t remain the part everyone waits on at the end.”
