TL;DR: AI-assisted code review is no longer experimental. 75% of organizations are using or planning it. Software supply chain tracking is moving from SBOMs to PBOMs for more granular visibility. Tool sprawl is getting replaced by consolidated platforms. And if Claude finding 500+ zero-days in production code doesn't make you rethink your AppSec strategy, nothing will.
Anthropic quietly dropped a bombshell this month: Claude Opus 4.6 was pointed at real-world codebases and found over 500 high-severity zero-day vulnerabilities. Not theoretical bugs. Not edge cases in toy examples. Production-grade, been-in-the-codebase-for-years vulnerabilities that fuzzers missed and manual reviewers walked right past. You can read the full Anthropic zero-day research yourself.
That one finding tells you almost everything you need to know about where application security is heading in 2026. The tools are getting genuinely good. The question now isn't whether AI can review code, it's whether your team is set up to work with it effectively.
AI Code Review: What It Does Well (and Where It Still Falls Down)
According to OX Security's 2026 AppSec trends report, 75% of organizations are already using or actively planning to use AI and ML tools for code review. That's not hype anymore. That's adoption at scale.
Here's what AI code review is actually good at right now: pattern recognition. SQL injection, buffer overflows, hardcoded credentials, insecure deserialization. These are the kinds of bugs that follow predictable structures. AI catches them fast, flags them in context, and can often suggest a fix before you even open a ticket. AI Code Security Assistants (ACSAs) now integrate directly into IDEs and pull request workflows, which means developers see the feedback in the same place they're writing the code.
That last part matters more than people realize. The biggest reason DevSecOps adoption stalls isn't tool quality, it's friction. If your security tooling interrupts the developer workflow, developers route around it. ACSAs that surface findings inline, without requiring a context switch, are actually getting used. Veracode and Gartner both flag this: developer experience is the single biggest factor in whether AppSec tools stick.
Where AI still struggles: business logic flaws. If a function does exactly what the code says but the business requirement was wrong, an AI tool scanning syntax and patterns won't catch it. An AI doesn't know that your payment system should never allow negative amounts, or that your access control model has an implicit assumption that breaks when users have multiple roles. That requires context that lives outside the code itself.
My take: use AI to handle the pattern-matching class of bugs. That's a solved problem now. Reserve your senior security engineers' time for architecture reviews, threat modeling, and the logic-layer stuff that requires actual business context. That's the only way to make manual review scale.
For more on why AI security strategy needs to be deliberate, not just reactive, see my earlier post on why your business needs an AI security strategy.
From SBOMs to PBOMs: The Supply Chain Gets More Granular
If you've been following software supply chain security, you know that SBOMs (Software Bills of Materials) became a compliance requirement after the 2021 executive order on cybersecurity. The idea is simple: know what's in your software, the way a food label tells you what's in your cereal. OWASP's SBOM project and NIST's supply chain guidance have been the primary reference points here, and CISA has been pushing SBOM adoption across critical infrastructure sectors.
SBOMs are good. But they have a blind spot: they tell you what components are in your software, not how those components got there or what happened to them along the way. That gap is exactly what attackers exploited in SolarWinds and similar supply chain attacks. They didn't compromise the final software artifact. They compromised the build pipeline.
Enter PBOMs, or Pipeline Bills of Materials. A PBOM tracks not just the components, but every tool, action, environment, and artifact in your CI/CD pipeline that touched the code before it shipped. Think of it as the difference between listing ingredients and documenting the entire manufacturing process, including who handled it, what machines were used, and what the temperature was during packaging.
This is more granular, more complex, and a lot more useful when you're investigating a breach or trying to satisfy a regulator asking how your build process works. The shift to PBOMs reflects an industry that's moved past "we have an SBOM" as a checkbox and toward actually understanding what it means to have a secure software supply chain.
If you're not already producing SBOMs, start there. But if your team is already SBOM-mature, start thinking about pipeline visibility. Where does your build process have gaps? What tools run in your CI/CD that you don't control? That's your attack surface.
Platform Consolidation: Killing the Tool Sprawl Problem
Here's a real problem I've seen in organizations of all sizes: they have a SAST tool, a DAST tool, a dependency scanner, a container scanner, a secret scanner, a cloud posture tool, and maybe three more things someone's VP of Security bought at RSA two years ago. None of them talk to each other. Each one generates its own findings. And nobody knows which findings actually matter.
Gartner's data is stark here: 43% of organizations are still at the lowest maturity level for AppSec. That's almost half of all organizations still in the early stages of a program that's been a best practice for over a decade. Part of why is exactly this tool sprawl problem. Teams get overwhelmed and prioritize nothing.
The 2026 trend is consolidation. Vendors are building unified platforms that combine Application Security Testing (AST), software supply chain security, and Application Security Posture Management (ASPM) under one roof. ASPM specifically is worth understanding: it's the layer that correlates findings across all your tools and helps you identify the 10-25% of vulnerabilities that are actually reachable, exploitable, and worth fixing. The rest can wait.
This doesn't mean you should rip out everything and buy one vendor's platform. That's usually a bad idea for different reasons. But it does mean you should be asking: which of my tools actually integrate, which findings am I acting on, and which are just noise? If you can't answer that, your AppSec program has a prioritization problem regardless of how many tools you're running.
The Cybersecurity Dive's 2026 trends coverage points to platform consolidation as one of the defining moves this year, and I think they're right. Security teams that are still buying point tools in 2026 are going to spend more time managing dashboards than managing risk.
Shadow AI and the New Blind Spots
There's one trend I want to call out that doesn't get enough attention: shadow AI agents. As AI coding tools become standard (GitHub Copilot, Cursor, Codeium, and a dozen others), developers are using them to write and commit code that wasn't reviewed with the same scrutiny as human-written code. Sometimes it's committing AI-generated code without fully understanding what it does. Sometimes it's entire features scaffolded by an AI agent running semi-autonomously.
I wrote about this dynamic in the context of agentic workflows in my post on AI agents coming for your workflow, but the security angle is one most teams haven't fully worked through yet. If you want the foundational context, AI Agents Explained covers how these systems actually work.
The problem isn't that AI writes bad code. Sometimes it writes excellent code. The problem is that your existing security review process probably wasn't designed with "an AI wrote 40% of this PR" as a normal input. That's a gap worth closing before your next pen test closes it for you.
And if you're using LLM-based tools in your development process, don't skip my post on LLM prompt injection for developers. It covers an attack class that's still underappreciated in most AppSec programs.
What This Actually Means for Your Team
Regulatory pressure is only going up. The EU AI Act, SEC cybersecurity disclosure rules, and the Secure by Design push from CISA are all moving in the same direction: prove that you know what's in your software and how it was built. That's not going away.
So here's what I'd actually do if I were building or rebuilding an AppSec program right now:
First: Deploy an ACSA in your developer workflow if you haven't. It doesn't have to be a big procurement. GitHub Advanced Security, Snyk, or Semgrep all have reasonable entry points. Get AI in the loop at the PR stage.
Second: Get your SBOM generation automated and integrated into your CI/CD pipeline. If you're not generating SBOMs automatically on every build, you're doing it manually (or not at all), and neither of those scales.
Third: Audit your tool stack for what's actually generating actionable findings vs. what's just generating noise. If a tool's findings aren't being triaged and fixed, it's not contributing to security. It's contributing to alert fatigue.
Fourth: Have an explicit conversation with your team about AI-generated code in your review process. What's your policy? What do reviewers look for differently when half the PR was written by Copilot?
The Claude zero-day story is going to get repeated in different forms by different AI systems over the next 12 months. Attackers will use the same techniques, pointing AI at your code looking for the same patterns. The teams that win aren't the ones who panic. They're the ones who already have AI working for them in the review process before someone uses it against them.
If you want to talk through what this looks like for your specific environment, reach out directly or take a look at what we do at Empowerment AI. This is exactly the kind of problem I work on with clients.