AI now acts as an accelerant, but with a double-edged sword.
On the one hand, it substantially widens the code’s attack surface by making the introduction and propagation of vulnerabilities at scale much easier. On the other hand, it radically reshapes development cycles by streamlining code generation, testing, and deployment at an unprecedented pace.
This acceleration changes the rules. Software security can no longer operate according to a post hoc remediation logic, detached from the real production rhythm, but must integrate directly into development workflows and become a continuous mechanism capable of guiding the code throughout the application lifecycle.
In 2026, disruption is impossible to ignore. AI has entrenched itself at the heart of development tools and workflows, dramatically speeding up code production… but also the exposure to vulnerabilities.
Meanwhile, attackers are leveraging exactly the same capabilities to detect and industrialize the exploitation of flaws at an unprecedented rate. In 2018, an average of 840 days elapsed between vulnerability disclosure and its exploitation. By 2026, that window had fallen to 1.6 days, and researchers even project a minute by 2028!
The risk has also scaled. Vulnerabilities once considered peripheral can now be transformed almost instantaneously into IA-generated operational attack chains.
Claude Mythos of Anthropic illustrates this rupture in spectacular fashion. Independent tests indicate the model can identify known vulnerabilities and generate functional exploits within ten to fifteen minutes, at a cost of less than a dollar.
Its success rate could reach 72.4% in exploiting known flaws, compared to 14.4% for Opus 4.6 and 4.4% for Sonnet 4.6. A model originally designed for reasoning and safety is now among the most effective offensive tools ever evaluated.
AI-adapted security: the end of CVSS as the sole arbiter
An unpatched flaw is no longer just a backlog item: it now represents a potentially exploitable attack surface ready for use.
Historically, vulnerability management relied on a relatively stable prioritization logic, distinguishing critical flaws from less severe ones. This model worked in a context where exploiting a vulnerability was costly, slow, and dependent on advanced skills.
This equation is now undermined by the capabilities of generative AI models, able to analyze code, identify attack vectors, and accelerate the search for exploitation scenarios. In this context, CVSS, anchored in exploitation complexity, required privileges, and impact, no longer suffices to reflect actual risk.
The central concern becomes exploitability in production—that is, reachability within active code, the true exposure level, and the automation potential of the attack. A vulnerability-management approach based solely on human teams is limited here, and organizations are progressively moving toward agentic remediation approaches capable of prioritizing and automatically patching certain flaws.
The governance of security thus shifts from a static severity-based model to a dynamic model centered on operational exploitability, combining an attackability score, automated fixes at the pull-request level, and the continuous integration of AppSec into the development lifecycle.
A security that’s “agile” in kind
In an AI-powered development environment, security can no longer intervene only at the end of the chain. It must be embedded at every stage of the application lifecycle and evolve at the same pace as development workflows.
The “shift left” becomes an operational necessity. But the scope of what must be secured now goes beyond the produced code. AI-enhanced IDEs, automatically generated pull requests, CI/CD pipelines guided by agents, and third-party AI components each introduce new exposure surfaces.
Servers used by agents to access external tools, autonomous agents capable of opening PRs or triggering deployments with minimal human oversight, and fictional dependencies generated by some models create risks largely invisible to traditional scanners designed to analyze only the source code.
In this context, an AI Bill of Materials (AI-BOM), capable of mapping all AI components present within development workflows, becomes as essential as an SBOM for conventional software dependencies. This visibility is crucial for governance, traceability, and compliance with frameworks such as the National Institute of Standards and Technology’s AI RMF, the European Union AI Act, ISO 42001, or the OWASP LLM Top 10.
Application security must now be managed as an industrial, continuous capability, focused not on the sheer volume of alerts but on the real exploitability of vulnerabilities.
This requires reducing noise through contextualized analysis, prioritizing risks by their exploitability potential, automating fixes at the pull-request level, and ensuring ongoing oversight of development and delivery pipelines. Because an AI cannot effectively self-audit the code it produces.
