Ask a frontier AI model to review a codebase and something genuinely impressive happens. It reasons across application logic, traces authorisation flows several steps deep, spots vulnerability chains a pattern-matcher would miss and proposes a fix that accounts for context. For anyone who has watched static analysis tools choke on business logic for the past decade, it looks like the breakthrough the industry has been waiting for.
It’s real. It’s also one part of the problem and mistaking it for the whole problem is how security programs quietly take on risk they don’t know they’re carrying.
Finding a flaw once and proving a program is sound are different jobs
Detection and assurance sound like the same activity from a distance. They aren’t. An AI model can inspect a repository, surface a defect, explain the impact, and draft a remediation, all genuinely useful for the developer sitting in front of that one repository at that one moment.
A security leader’s job starts after that moment. They need to know which applications were assessed and by what method, whether findings were fixed, mitigated, or formally accepted, and whether they can prove any of it to an auditor, a regulator, a customer, or a board. It’s a different discipline from finding a bug, with its own requirements. Two of them expose exactly where AI reasoning, used alone, runs into trouble.
- Determinism: Governance depends on a simple property: the same code, assessed twice, produces the same result. AI reasoning doesn’t offer that by design. It’s probabilistic, and consecutive runs over identical code can surface different findings, because the model is reasoning through the problem independently each time rather than applying a fixed rule set. That variability is exactly what makes AI good at catching novel, context-dependent flaws. It’s also exactly what makes it a poor foundation for a system of record. Audit trails and regulatory attestations need a baseline that holds still; a baseline that shifts between scans undermines the case a security team is trying to build.
- Cost at frequency: Real assurance means testing continuously at every commit, every pull request, every merge, in CI, across an entire portfolio, where periodic sampling of high-value repos used to be the norm. AI-based scanning tends to run at a meaningfully higher cost than deterministic static analysis, and that gap compounds every time another gate gets added to the pipeline. As the primary detection layer at that frequency, the economics start to strain against the model that made frequent testing possible in the first place.
All of this is solvable with enough engineering. A team can build the prompts, agents, integrations, policy logic, evidence repositories, and reporting to run AI-driven testing reliably at scale. But at that point, the organisation isn’t running a workflow anymore but building and operating its own application security platform, at the cost and complexity a platform exists to remove.
A quieter risk: the same reasoning that writes the code is asked to check it
As AI generates a growing share of production code, a subtler problem emerges when the same class of model is also relied on as the primary check on that code. The reasoning that introduced a flaw can be the same reasoning that overlooks it on review, not because the model is careless, but because the blind spot is architectural, not incidental. Breaking that loop requires a check that doesn’t share the model’s assumptions: something independent and deterministic, not just a second opinion from a similar system.
That points to a mistake worth naming directly: reaching for more AI models as the fix. Model diversity has some value; different models do catch different things. But models drawing on similar training data, similar architectural assumptions, and comparably limited runtime visibility tend to fail in similar ways. Pointing a second AI reader at the same context often repeats the analysis rather than deepening it.
Defence in depth was never about stacking more of the same tool
Real defence in depth comes from combining methods that fail differently, so that what one approach misses, another is positioned to catch:
- Static analysis for fast, deterministic, repeatable detection
- AI reasoning for business logic and multistep vulnerability chains
- Software composition analysis for open source, license, and supply chain risk
- Dynamic analysis for vulnerabilities that only surface at execution
- Interactive analysis and fuzzing for runtime and protocol coverage
- Centralised policy and reporting to hold it together at enterprise scale
The goal isn’t to find the single best method and scale it. It’s resilience through independence, a programme where no one method, model, or source of evidence is asked to carry the whole weight of assurance on its own.
AI has earned its place in the modern security stack. It reasons about code in ways static tools can’t match. Reasoning and assurance answer different questions, and an enterprise security programme has to answer both. The organisations getting this right aren’t choosing between AI and deterministic assurance. They’re using each for what it’s actually good at and building governance that can withstand the scrutiny of a board, an auditor, and a customer.
Dom Glavach
Dom Glavach is CISO at Black Duck. With more than 20 years of cybersecurity leadership experience spanning high-growth SaaS organisations, regulated industries, and national defence environments, Dom most recently served as Chief Information Security Officer and Chief Security Strategist at CyberSN.
