In the last 90 days, every major frontier AI lab has launched a cybersecurity platform. Anthropic unveiled Project Glasswing and the Claude Mythos model, demonstrating autonomous vulnerability discovery in closed-source software. Google shipped a Gemini CLI security extension. And this week, OpenAI launched Daybreak, a multi-tiered platform built on GPT-5.5 and Codex Security, with partners including Cisco, CrowdStrike, Palo Alto Networks, and Cloudflare already integrating its capabilities.
This isn’t a single vendor doing something interesting. It’s a structural shift in who builds security tooling and how fast it evolves. For security leaders, the question is no longer whether AI will reshape application security. It’s whether your program is keeping pace with what’s already here.
The AI lab capability stakes are rising on both sides
The same AI capability that makes security analysis faster for defenders also makes it faster for adversaries. That’s not a theoretical concern. It’s already creating real operational pressure.
Earlier this year, HackerOne paused its bug bounty program after AI-assisted vulnerability research led to a surge in reports that open-source maintainers couldn’t process fast enough. The term the industry has landed on is “triage fatigue”: too many findings, too few people to evaluate them, too little time to fix them. AI didn’t create the vulnerability backlog, but it is making the backlog impossible to ignore.
At the same time, AI-assisted development tools are producing more code, faster, than any team could write manually. More applications, more code, faster cycles. The result is a larger attack surface entering production every day, discovered by more capable adversaries, sooner.
What the AI lab headlines are getting wrong
Most coverage frames these platforms as the beginning of the end for traditional security testing. The economics tell a different story.
Anthropic’s own published Glasswing results showed that scanning a single large codebase end-to-end cost approximately $20,000 for one review. For targeted bug discovery in specific components, the cost was roughly $50 per finding. Those numbers help explain where AI scanning excels: targeted, high-value analysis of complex code. They do not support replacing traditional application security testing across an enterprise portfolio where hundreds of applications ship code daily.
Even Daybreak’s own partners are saying the quiet part out loud. As Cisco’s chief security and trust officer, Anthony Grieco told CyberScoop, the real value “lies not in the model alone but in the enterprise framework built around it.” That’s the point. AI is a powerful component. It is not, by itself, an AppSec program.
The credible architecture—and the emerging consensus among analysts, enterprise security architects, and now the AI labs’ own partners—is hybrid. Deterministic, rules-based scanning for broad, fast, repeatable coverage across the portfolio. AI layered on top where it adds genuine leverage: triaging the backlog of false positives, generating remediation guidance, covering new languages quickly, and detecting vulnerability classes that require contextual reasoning rather than pattern matching.
But whether AI replaces traditional scanning is only one dimension of a larger shift. AI is also changing what applications look like, what vulnerabilities they contain, and how developers build them. Security leaders evaluating their programs today need to account for all of these dimensions, not just the tools-versus-tools question the headlines are focused on.
Three questions every security leader should be asking now
- Is your AppSec program covering AI-specific risks? The applications your teams are building today include large language models, AI agents, and model context protocol (MCP) servers. These introduce new vulnerability classes (prompt injection, excessive agency, data poisoning, supply chain risks in AI models) that traditional SAST wasn’t designed to detect. If your vendor can’t demonstrate coverage of the OWASP Top 10 for LLM Applications, you have a gap.
- Does security work where your developers actually work? AI-assisted development changed where code gets written. Developers work in IDEs, AI agents operate inside repositories, and code generation happens continuously. Security tools that only run at the end of the pipeline miss the window. Security needs to be present in the IDE, in CI/CD, and alongside AI coding agents. Not bolted on afterward.
- How long has your vendor been investing, and what’s in production? Every AppSec vendor will claim an AI strategy this year. The differentiator is what’s shipping, not what’s planned. Ask what’s in production today. Ask when development started. Ask how triage and remediation actually work at enterprise scale. Roadmaps are easy. Shipping is hard.
Where Fortify stands on AI tooling
OpenText Fortify started building generative AI into SAST, DAST, and SCA in 2023. Before Glasswing. Before Daybreak. Before AI-powered security became a headline. A significant portion of the portfolio is AI-powered in production today.
OpenText Fortify Remediation Aviator is available across on-premises, private cloud, and Fortify on Demand. It uses frontier models to audit SAST findings, separate true positives from false positives, explain each finding in plain language, and provide remediation guidance with ready-to-apply code fixes. In its first eight weeks of internal use at OpenText, Aviator audited more than 300,000 findings across 1,500 applications and reduced mean time to triage by 70%. In a market defined by triage fatigue, that’s the difference between a backlog that grows and one that shrinks.
Fortify’s SAST engine covers all ten categories of the OWASP Top 10 for LLM Applications 2025, from prompt injection to data poisoning, across the major AI frameworks and libraries. The Fortify MCP server and Fortify Agent Skills let AI coding agents work with real AppSec context, so security travels with the developer regardless of the tools they use. A next-generation VS Code extension, purpose-built for AI-powered development workflows, shipped in the 26.2 release.
And for organizations that can’t use AI tooling—due to compliance, air-gap requirements, or internal policy—Fortify’s traditional SAST, DAST, and SCA continue getting stronger. AI features are optional add-ons, not gates on the core product. That flexibility matters. Not every organization is ready to adopt AI at the same pace, and a vendor that forces the choice isn’t serving the full market.
The bottom line
AI didn’t make application security obsolete. It made the gap between strong programs and weak ones wider and more visible. The organizations that stay ahead will treat AppSec as a program that evolves with the threat landscape, not as a checkbox that gets revisited once a year.
Go deeper: For the full technical breakdown of Fortify’s AI investment and hybrid architecture, read AI Didn’t Break Application Security. It Exposes the Next Evolution on the Fortify community.
See it in action: Learn how the next-generation Fortify VS Code extension keeps security in lock step with AI-assisted development: Keeping Application Security in Lock Step with AI Assisted Development.
