AI-assisted software development is no longer a novelty. It's rapidly becoming the default method for writing code, says Snyk Field CTO Clinton Herget, a six-year veteran of the application-security provider."AI is behind some form of all software development that is happening today," Herget says in a recent wide-ranging webcast. "If you think your developers are not using any kind of AI to build their software, it's just that they're not telling you about it."Unfortunately, code-completion copilots, LLM-written documentation, and fully agentic coding environments have sped up software development so much that traditional AppSec, and even mature DevSecOps practices, can no longer handle them, he adds."We're in a fundamentally different world in terms of how software is being built," Herget says. "We have to secure it very differently than we would have in the past."New methods of securing application development are needed, Herget says.We've gone through this before, he adds. Fifteen years ago, agile methods, automated CI/CD, and cloud infrastructure transformed how software was built and forced traditional application security to evolve into DevSecOps, with shift-left practices and tooling embedded in developer workflows.Today, Herget says, AI acceleration and AI-native development are driving a similar disruption, but with the added complexity of non-deterministic systems, new attack surfaces, and a rising volume of machine-generated code that can swamp existing controls."How do we shift even further left than the human developers into the AI tools that they're using?" he wonders.The issue isn't simply that AI writes insecure code, he says. It's that LLMs train on human-written code that itself contains insecure patterns, and that LLMs then scale those flawed patterns at machine speed.At the same time, the people building software are changing. Instead of the old two-party model of security personnel and developers, Herget sees a three-part ecosystem emerging."We no longer can rely on there being a relatively small community of people who have the ability to build software — in other words, developers," he says."Now essentially everyone in our organizations can become an app creator or a software builder," he adds. "What that means is we have to think in a completely different way about how we do security enablement and training and education."Security teams must shift from being reactive gatekeepers to becoming policy creators who define risk tolerance and guardrails. Platform or "foundational" engineers can then implement those guardrails in pipelines, developer environments, and agent-to-agent frameworks.A third group — app creators or "software builders" — may not write code at all, instead relying on "vibe coding," natural-language prompts and agentic systems to produce functional applications quickly.This role-shift matters because developer experience remains the central constraint, even in an AI age. Herget highlights three factors that drive productive engineering: protecting flow state, reducing cognitive load, and shortening feedback loops.Traditional AppSec often fails on all three because it lets developers be interrupted by poorly timed remediation requests, forces extra research to understand findings, and allows for long back-and-forth cycles to confirm what needs fixing.AI, Herget argues, can help reverse that dynamic if it’s applied to provide context, not just speed.That leads to his core thesis: AI-accelerated DevSecOps must become an "autonomous platform" that uses AI for issue visibility, prioritization, and policy orchestration while recognizing that AI is not trustworthy."You can't rely on an LLM to secure itself, because you're not injecting additional context and understanding into that loop," Herget says.But if organizations try to preserve old assurance models by putting a human in the loop for everything, they'll lose the velocity benefits of AI and inherit the worst outcomes: more insecure output plus more human cleanup."We can't simply say we want AI acceleration," he adds, "but [insist] we want a human to be verifying everything, because then you get the worst of both worlds."The goal is not to let AI "secure itself," but to inject context and verifiable understanding into pipelines using the right techniques. Sometimes this will include "symbolic" AI approaches that apply structured rules to code rather than relying solely on semantic pattern prediction.Herget offers Snyk's own static analysis as an illustration: rather than using an LLM to "read" code, the Snyk Code AI-powered SAST tool parses programs into abstract syntax trees and layers vulnerability intelligence on top to improve accuracy and reduce noise.The broader shift, he says, is from binary pass/fail stopgates to "yellow lights" that can auto-fix, deprioritize, or route issues intelligently without breaking developer flow.To operationalize AI trust, Clinton proposes three interconnected but independent AI "engines" that should work as a continuous loop, each of which performs different tasks.First, a fact engine gathers what's knowable, such as SBOMs, dependencies, and AI components. Then a flow engine models how data and behavior move through the system to infer risk and remediation options.Finally, a threat engine tests assumptions dynamically through techniques like DAST, fuzzing, red teaming, and pen testing, then feeds results back as new facts."You don't simply have to waste time running every siloed scanning engine against every line of code," Herget says. "We can intelligently decide which code or which repositories need the right kinds of scanners run against them to collect the right kinds of context."Done properly, this loop enables context-aware remediation, smarter scan coverage, reachability and breakability analysis, and better correlation between static and dynamic findings."What AI can allow us to do within DevSecOps is to correlate findings between different kinds of tools," Herget says, "particularly between our static and dynamic analysis results."Ultimately, AI acceleration will introduce headwinds such as harder threat modeling, new "AI tech debt," and governance gaps, Herget says. But it will also unlock faster triage, better prioritization, more actionable guidance, and even automatic remediation.The winners, he says, will be organizations that treat context as the new control plane for AppSec at AI speed.
Application security, DevSecOps, AI/ML

The next evolution of application security: AI-accelerated DevSecOps

Created with SocialSight AI

Related Events
Get daily email updates
SC Media's daily must-read of the most current and pressing daily news
You can skip this ad in 5 seconds



