Executive Summary
AI changed software development in two directions at once. Engineering teams now ship more code than their reviewers can read, and adversaries now run AI agents that scan, exploit, and move through systems at machine speed.
The data reflects both shifts. Vulnerabilities increased 10x from 2025 to 2026, and 86.7% of exploited CVEs in 2026 were exploited on or before the day they were disclosed.
Defense still runs at human speed. Most companies buy separate tools for code, cloud, network, and attack surface management, then add a pentest once a year. None of those tools shares a model of how the company can actually be breached.
This paper describes a different operating model. CodeAnt AI builds one living threat model of a company from the inside and the outside. It continuously attacks that model, proves which paths reach critical data, fixes them at the root cause, and learns from every attempt.
The paper covers:
How the threat landscape changed in 2026, with the underlying data
Why siloed security tools and point-in-time pentests miss breach chains
How a living threat model correlates internal and external signals into one graph
The five-stage loop that attacks, proves, fixes, and learns continuously
A proven breach path from a real assessment
How verified exploit intelligence compounds across customers without sharing private data
The metrics and adoption sequence for running preventive security inside the SDLC
1. The Security Landscape Changed in 2026
For most of the last decade, security programs assumed human attackers working at human pace. That assumption stopped holding in 2026.
AI Multiplied the Code, and the Attack Surface With It
AI coding agents let a single developer produce several times more code than before. Reviewer bandwidth stayed flat, so the gap between code written and code carefully reviewed widens every quarter.
Every new service, dependency, container image, and cloud resource adds to what an adversary can reach. The attack surface now grows with every merge.
Adversaries Now Operate at Machine Speed
Attackers use AI agents to scan, test, exploit, and move laterally. They don't need to understand a company the way a human operator once did.
They also don't work one target at a time. An agent can run thousands of attacks across thousands of companies simultaneously.
Attacks are happening at machine speed. Defense is still running at human speed.
Vulnerability Volume Went Parabolic
According to a16z analysis of CVE data, vulnerabilities increased 10x from 2025 to 2026. The shape of the curve matters as much as the multiple.
From 2022 through 2025, high-severity CVEs stayed mostly between 100 and 500 per period, peaking near 530 in 2024. In 2026 the series crosses 2,200.
Critical-severity CVEs rarely exceeded 100 per period before 2026. In 2026 they climbed past 600.
Share of exploited CVEs exploited before or on the day of disclosure. Chart data from a16z.
The Disclosure-to-Exploit Window Collapsed
The second chart is the more dangerous one. It tracks the share of exploited CVEs where exploitation happened before or on the day of public disclosure.
Year | Zero-day rate (% of exploited CVEs) |
|---|---|
2018 | 18.7% |
2019 | 22.4% |
2020 | 22.8% |
2021 | 31.1% |
2022 | 33.8% |
2023 | 42.2% |
2024 | 47.9% |
2025 | 53.6% |
2026 | 86.7% |
The rate crossed 50% in 2025 and jumped 33 points in a single year. A remediation process that starts at disclosure now starts after exploitation in nearly nine out of ten cases.
Zero-day rate by year, 2018 to 2026. Chart data from a16z.
The Defender's Asymmetry
An adversary doesn't need to understand the 10,000 cloud, network, code, and infrastructure configurations inside a company. They need one path in:
One exposed service
One leaked credential
One misconfigured database
One vulnerable dependency
One endpoint nobody protected
Once inside, they identify running services, locate databases, map access paths, extract data, and leave.
The defender's job runs the other way. Protect every endpoint, secure every deployment, monitor every cloud configuration, track every identity and permission, detect every leaked secret, and respond to every infrastructure change.
All of it has to happen continuously. A company has to win every day. An attacker has to win once.
2. Why Today's Security Stack Can't Keep Up
The problem is rarely a shortage of tools. Most security teams already own plenty of them.
Security Is Bought in Pieces, and Breaches Happen in Chains
A typical company spreads coverage across at least five vendors. Each one owns a slice:
Code security
Cloud security
Network security
Attack surface management
Secrets detection
Threat detection and SIEM
Compliance
An annual penetration test
These tools don't learn from one another. Each produces findings against its own slice, rated by its own severity model.
The result is fragmented visibility. A company can run every one of these tools and still not know the single path an adversary would use to reach its customer data.
Each vendor sees its own slice of the environment.
Shift-Left Controls Rate Findings in Isolation
Shift-left security controls remain necessary. Linting in the IDE, secret detection in pre-commit hooks, AI code review on pull requests, and scanning in the build pipeline all stop defects early, where they're cheapest to fix.
Each of those controls answers one question well. Is this change safe on its own?
What they can't answer is whether a weakness in one layer becomes a route through the next. That question decides whether a finding leads to a breach.
Consider a missing authentication check on an API read. A code scanner rates it on its own merits. Put it on an internet-reachable production host, and it becomes a direct path to a workforce directory with passwords.
Section 6 walks through exactly that path from a real assessment. Severity lives in the chain, and a finding without reachability is an educated guess.
Point-in-Time Pentesting Leaves the Rest of the Year Uncovered
Service-led pentesting and PTaaS (penetration testing as a service) still account for roughly 75% of the market. The work is scoped, manual, and delivered as a report after the engagement closes.
A company that changes on every commit can't be assessed once a year. The report describes a system that stopped existing a few hundred deploys ago.
Traditional pentests also leave no complete record of what was tested. The customer gets conclusions without the trail behind them.
How Current Testing Approaches Compare
A full breach path runs in three phases. Attackers land externally, expand internally, and then reach enterprise cloud and identity. Each testing approach covers a different part of that path.
Approach | External attack surface | Apps and APIs | Code-guided attacks | Shipped binaries | Cloud and identity | What the attack proves |
|---|---|---|---|---|---|---|
AI pentesting | Not covered | Continuous | Autonomous, on demand | Not covered | Not covered | App exploits |
AI pentesting and AppSec platforms | Continuous | Continuous | Continuous | Not covered | Posture only | App exploits |
Enterprise attack testing | Continuous | Continuous | Not covered | Not covered | Continuous | Network and identity paths |
Pentest services and PTaaS | One-time, manual | One-time, manual | One-time, manual | One-time, manual | One-time, manual | Scoped attack paths |
Living threat model (CodeAnt AI) | Continuous | Continuous | Continuous | Continuous | Continuous | Code-to-data path, verified |
Each approach tests a piece. A living threat model is built to prove the entire breach path, continuously.
3. See the Company From the Inside and the Outside
Most tools see one side or the other. The paths that matter run between them.
CodeAnt AI combines both views into one continuously evolving threat model. We see your company from the inside and the outside.
CodeAnt External Maps What an Attacker Can Reach
CodeAnt External looks at the company the way an adversary would, from the internet inward, through continuous attack surface management. It maps:
Domains and subdomains
IP addresses and open ports
Reachable services, live endpoints, and APIs
Misconfigured databases, weak hosts, and exposed infrastructure
Third-party and vendor risk
Leaked employee credentials across the dark web, the public internet, and Telegram channels
Live attack and external threat intelligence
The goal is to identify every path an external adversary could use, before one of them is used.
CodeAnt Internal Maps How the Company Is Built
CodeAnt Internal understands what runs inside the company and how it fits together. It maps:
Code, pull requests, and commit history
Third-party code dependencies and shipped binaries
Secrets and credentials
VMs and containers
Runtime behavior, identity, and access configuration
Internal context turns an external exposure into a specific root cause. It also shows which internal weaknesses an outsider can actually touch.
External and internal context feed one living threat model.
One Graph Instead of Separate Inventories
Siloed tools keep separate inventories of repositories, packages, containers, and cloud resources. CodeAnt AI connects them as one graph, so a weakness in one node becomes a route through the next.
A vulnerable npm package, scanned alone, is one line in an SCA report. In the graph, it's a dependency pulled into a backend service, shipped in a container, running on EKS behind a load balancer that exposes a public subdomain.
That connection changes the question a security team asks. "How severe is this?" becomes "Can this be reached?"
Repositories, packages, containers, and cloud resources mapped as one graph.
4. How the Living Threat Model Works
The threat model runs on paired signals. Each internal signal has an external counterpart that determines whether it matters.
Paired Internal and External Signals
The model ingests five internal and five external signal classes and correlates them before scoring anything.
CodeAnt Internal | CodeAnt External |
|---|---|
Code, PRs, and commit history | Domains, IPs, and subdomains |
Dependencies and binaries | Open ports and services |
Secrets and credentials | Live endpoints and APIs |
Cloud and IaC configurations | Network and traffic context |
Runtime, identity, and access | External threat intelligence |
A secret in a repository matters more when a live endpoint uses it. An open port matters more when the service behind it runs a vulnerable binary.
Four Jobs the Model Performs
Every input feeds four continuous functions:
Correlates internal and external context: joins what the company ships with what attackers can see.
Continuously rebuilds with every change: updates on commits, infrastructure changes, identity changes, and exposure changes.
Builds end-to-end exploit paths: chains individual weaknesses into complete routes from entry point to impact.
Measures reachability to crown-jewel data: tests whether a path reaches customer data, production systems, or secrets.
Every finding the model produces answers one question. Can this reach critical data?
Every attack path is measured against one question. Can this be reached?
5. The Continuous Attack-and-Defend Loop
CodeAnt continuously attacks, continuously defends, and builds a self-learning threat model. The loop is closed on purpose, and it processes roughly 15 billion security events every month.
The Five Stages
Each stage produces an output that the next stage consumes.
Stage | What happens | Output |
|---|---|---|
01 Model | The graph is built from internal and external signals and rebuilt on every change | Current threat model |
02 Attack | Agents attempt attack paths against the reachable surface | Successful attempts, failed attempts, and controls encountered |
03 Prove | Paths validated end to end are marked proven, and unvalidated paths stay labeled as considered | Verified attack-path record |
04 Fix and reset | The root cause is remediated and the same path is re-tested | Closed path with a recurrence guard |
05 Learn | The verified pattern is abstracted and fed back into the model | Stronger model for this customer and for similar customers |
The loop processes roughly 15 billion security events every month.
What an Attack Produces
Every attack run records three things:
Successful attempts: the steps that worked.
Failed attempts: the steps that didn't, and where they stopped.
Controls encountered: the defenses that blocked or slowed the attack.
Failed attempts carry as much signal as successful ones. They show which controls actually hold under a real attack, which a configuration audit alone can't confirm.
The Verified Attack-Path Record
A successful attack becomes a structured record with three parts:
Conditions: when does this become exploitable?
Sequence: how does it reach a critical asset?
Proven remediation: what change permanently closes it?
The record is what separates a proven path from a theoretical one. It carries enough detail for an engineer to reproduce the path, and enough precision to verify the fix.
Customer Protection
The record drives remediation in three steps:
Fixed at root cause: the change targets the condition that made the path possible in the first place.
Re-test the path: the same sequence runs again to confirm it's closed.
Prevent recurrence: the closed path stays in the model, so a later commit that reopens it gets caught.
Patching only the exposed host leaves the underlying missing control in place. The next host that exposes the same API reopens the same path.
How one verified attack becomes customer protection and shared intelligence.
6. Anatomy of a Proven Breach Path
This example comes from a real CodeAnt AI assessment. Hostnames and customer details are removed.
What the Assessment Mapped
The assessment mapped every reachable host, every root cause, and every data store those root causes could touch. It then separated what was proven from what was only considered.
Layer | What was mapped |
|---|---|
Exposed surface | Four application hosts (production API, data center app, portal, and staging API), plus 12 peripheral hosts |
Root causes | Client-side secrets in JavaScript bundles, no authentication on API reads, and no authorization on API writes |
Data in scope | Customer PII (3,000+ records), workforce directory and passwords, identity system write access, and asset, vendor, and OT data |
One proven attack path, with every other route marked as considered but not proven.
The Proven Path
One path was proven end to end in this assessment:
Entry point: the production API host, reachable from the internet.
Root cause: no authentication on API reads.
Data reached: the workforce directory, including passwords.
Every other route toward customer PII, identity system write access, and asset, vendor, and OT data stayed labeled as considered, not proven.
That distinction keeps the report honest. Proven paths drive immediate remediation, and considered paths tell the team where the model will test next.
Why Siloed Tools Would Miss It
Each part of the proven path, found alone, looks like a routine ticket. An attack surface tool lists the production API host as reachable. An API scanner flags missing authentication as one finding among many.
Neither tool shows that this host and this missing control together hand an outsider a workforce directory with passwords. That connection is the breach, and it only appears when the hosts, the code, and the data sit in the same graph.
7. Pentest Auditability
Traditional pentests deliver a report after the work ends. The customer can't see every action taken during the assessment, so the findings have to be taken on trust.
CodeAnt AI records the full testing trail, including:
Every call made
Every command executed
Timestamps
Response codes
Failure rates
Latency
What was tested
What happened at each point in the attack path
Teams can inspect, visualize, download, and share the trail.
This matters for three groups. Engineers can reproduce a path before fixing it. Auditors get evidence of what was tested and when. Security leaders can verify that autonomous agents stayed in scope.
8. Compounding Intelligence With Private Boundaries
Every verified exploit makes CodeAnt stronger for every customer. The boundary that makes this safe is strict.
What Stays Private and What Is Shared
Internal learnings stay private to each customer. Only verified, externally reachable exploit patterns are shared.
Context | Examples | Handling |
|---|---|---|
Private internal context | Code and repositories, cloud and IaC, identity and access, runtime and infrastructure, CI/CD | Never leaves the customer. Improves only that customer's threat model. |
External exposure | Public IPs and domains, exposed services, internet attack surface, threat intelligence | Verified exploits can be abstracted and reused across customers. |
Internal learnings stay private. Verified external exploits transfer.
Privacy-Safe Abstraction
Before any verified pattern leaves a customer's model, it passes through three steps:
Remove customer data: all identifying data and content is stripped.
Preserve the graph pattern: the shape of the path (which kinds of nodes connect, in what order) is kept.
Keep the attack conditions: the conditions that made the path exploitable are retained.
What remains describes how a class of breach works without describing whose system it was found in.
The Proprietary Attack-Path Corpus
Abstracted patterns feed a corpus of four record types:
Verified attack paths
Failed attempts
Blocking controls
Proven fixes
The corpus is applied back to every customer's model. A control that blocked an attack in one environment informs how the same path is scored in another.
Re-Scoring Similar Customers
When a verified external pattern matches another customer's exposure, that customer is re-scored automatically. If Customer A's assessment proves a new path, Customers B, C, and D with matching exposure are re-scored without waiting for their own next assessment.
Every new customer adds external exploit intelligence. The model gets harder to catch up with the longer it runs.
9. Evidence From the Loop
The loop runs on real infrastructure every day. Its output is measurable.
Metric | Result |
|---|---|
Security events processed | ~15 billion per month |
CVEs discovered | 150+ |
Highest-severity finding | CVSS 10.0 in pac4j, undetected for six years |
Downloads protected | 2B+ per month, from one upstream finding |
Findings from CodeAnt AI's continuous testing and security research.
CVE-2026-29000 in pac4j-jwt
pac4j-jwt is a widely used Java authentication library. The CodeAnt AI security research team found that an attacker could authenticate as any user, including administrators, using only the server's public key. The flaw is tracked as CVE-2026-29000 with a CVSS score of 10.0.
No single component was broken. The JWT specification allows unsigned tokens, the underlying library behaved correctly, and pac4j's null check was correct in isolation. Authentication disappeared only where those pieces met.
That is the same failure class a living threat model is built to find. Every component passes review, and the composition is the vulnerability.
After private disclosure, pac4j's maintainer released patches within two days, and CodeAnt AI contacted hundreds of downstream maintainers whose packages were affected.
10. Running Preventive Security Inside the SDLC
Preventive security doesn't replace the SDLC controls teams already run. It connects them to the question those controls can't answer alone.
Where the Threat Model Plugs In
The model rebuilds on the same events that already drive engineering work:
Commits and pull requests: code changes update the internal graph and can open or close paths.
Infrastructure changes: cloud, IaC, and identity changes re-score reachability.
Exposure changes: new subdomains, open ports, and leaked credentials update the external view.
Code review keeps catching defects at the cheapest point. The threat model tells the team which of the remaining weaknesses an adversary can actually use.
Metrics That Measure Prevention
Finding counts reward noise. These measures track whether breach risk is actually going down.
Metric | What it tells you |
|---|---|
Proven paths open to critical data | Current, verified breach exposure |
Time to close a proven path | Remediation speed on the risks that matter |
Recurrence rate of closed paths | Whether fixes address root causes |
Share of findings with verified reachability | How much of the backlog is proven versus theoretical |
External exposure drift | How fast the attack surface changes between assessments |
Adoption Sequence
Teams get to proven paths fastest by connecting signals in this order:
Establish the external baseline: map domains, subdomains, IPs, open ports, exposed services, and leaked credentials.
Connect internal context: add repositories, dependencies, binaries, cloud configurations, and identity.
Prove and prioritize: run attacks, separate proven paths from considered ones, and rank by reachability to critical data.
Remediate at root cause: close proven paths, re-test them, and keep them in the model as recurrence guards.
Run continuously: rebuild on every commit and infrastructure change, and track the prevention metrics above.
11. Conclusion
AI made software faster to build and faster to attack. The first change created more attack surface. The second removed the time defenders used to have between disclosure and exploitation.
A security stack bought in pieces can't keep pace with breaches that happen in chains. It rates findings in isolation, tests on a calendar, and never learns across the environment.
Preventive security needs one model that learns continuously from what is exposed externally, what is changing internally, how attackers behave, and which paths lead to real impact.
CodeAnt AI understands how a company works, finds the unchecked spot, identifies the root cause, and shows the path to a potential data leak. It proves that path, closes it, and makes every other customer's model stronger in the process.
See Your Breach Paths Before an Attacker Does
Get a pentest report that shows proven paths to your critical data, with the full audit trail behind every finding.
Get Pentest Report | Book a Demo
