AI code security risk: The need for a smarter layer between detection and remediation | Daily Reports Online
AI has dramatically increased the speed and volume of software development. In a recent Google survey, 90% of developers reported using AI tools to assist them in their work, with 71% using it to write code.
One company told the New York Times that after adopting Cursor, an AI-native code-writing product, they went from producing 25,000 lines of code a month to 250,000, creating an enormous backlog of lines that needed to be reviewed by their team.
CEO and co-founder of Appknox.
While these tools have accelerated software delivery, they’ve introduced more risk. One study finds that 45% of AI-generated code contains security vulnerabilities, and AI-generated pull requests contain 1.7x more issues on average than those written by humans.
Detection isn’t the challenge. Modern security tooling can identify the problems, generating more findings and vulnerabilities than ever before. The problem for most security and engineering teams is what happens next.
With the sheer volume of AI-generated code flowing in, security teams can’t keep pace. They’re struggling to discern which issues pose a genuine risk. Because static severity levels treat every flagged issue equally, triaging gets complicated.
Siloed and disconnected security tools slow remediation, forcing development teams to context-switch just to assess an issue. And the more vulnerability reports to sift through, the higher the likelihood that real risks will slip through the cracks.
What’s needed is a smarter layer between detection and development—one that validates findings, identifies what’s truly exploitable and delivers fixes developers can act on within their flow of work.
Detection is happening. But what comes next?
With static analysis, dynamic testing and automated scanning, modern security tools are proficient at flagging vulnerabilities. The more complex problem is what follows: How do security teams determine which vulnerabilities pose a risk, and how do they get fixes to developers before those issues reach production?
Most teams default to severity scores to manage the backlog, but those scores were designed for a different era of software development. They rank vulnerabilities against a standardized rubric instead of the specific architecture, data flows or exposure profile of a given application.
A vulnerability rated “critical” in one context may be completely unreachable in another. When every alert demands urgent attention, nothing does. Engineers stop acting on scores and start acting on instinct, which is where real risks get missed.
AI-powered development merely compounds the challenge. More findings, more noise and far greater difficulty separating what matters from what doesn’t. And as development accelerates, the window to catch and fix those issues before they reach production keeps shrinking.
The smarter layer: Triaging, working in context and taking action
Cutting through that noise requires tooling that provides a smarter layer between detection and development, helping teams validate issues, triage them and take action before a problem escalates.
This starts with a few key shifts:
If teams are going to accurately detect and fix vulnerabilities, they need to shift from static to runtime analysis. Here’s why:
The speed of remediation depends on how quickly it can reach developers, delivered in plain language and applied in the environments they’re already working in.
Forcing developers to move out of the AI-native environments they’re working in, like Cursor or Claude Code, to check a separate security dashboard creates unnecessary friction and slows them down. At scale, that friction becomes delay, and delay is where vulnerabilities survive.
Developers need security tooling that integrates directly into their workflow and behaves more like engineering tools than an entirely separate system — scanning for detection, validating exploitability and delivering a fix in context.
Where AI fits into a smart security layer
Closing the growing gap between the number of vulnerabilities found by detection tools and how development teams respond to them requires several changes. If security tooling is going to keep pace with AI-assisted development, it needs to be part of the solution.
Integrated into the development workflow, AI can help teams validate problems, triage risks by severity and exploitability and deliver guidance so developers can make fixes in real time. Here’s how.
Integrate security tooling into development workflows. Developers need guidance on how to remediate issues in the moment, within the tools they use every day. By investing in security tools that integrate with AI code environments, teams can reduce workflow friction, eliminate context switching and speed up the steps to get to a fix.
Move away from static severity scoring. Static codes eventually get drowned out. A “critical” scoring won’t catch anyone’s eye, especially if the vulnerability being flagged requires the developer to move to an entirely separate application to assess it (and then back to make the fix).
Instead, teams that make the shift to exploitability-based prioritization ensure their development teams can sift through the noise and address the vulnerabilities that pose real-world risk first.
Validate earlier. It’s much more costly to work backward once code has reached production. By catching issues, validating them and fixing them earlier in the development process, teams get back time and resources and reduce overall risk for their organization.
Organizations shouldn’t have to choose between speed and security when adopting AI-enabled development. They instead need security tools that help them cut through the noise, keep pace with this new speed of production and close the gap between flagged vulnerabilities and what comes next.
We’ve featured the best laptop for programming.
This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here:
