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

Chart: “Cyber Risk Goes Parabolic.” Number of CVEs by severity (Critical, High), 2022 to 2026. Source: a16z.

According to the 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.

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.

Chart: “Zero-Days-To-Exploit, Almost 90% Of The Time.” Zero-day rate by year, 2018 to 2026. Source: a16z.

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.

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.

Slide: “Security is bought in pieces. Breaches happen in chains.” Each vendor sees its own slice.

Shift-Left Controls Rate Findings in Isolation

Shift-left 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 authorization check on an API write. A code scanner rates it on its own merits. Put it next to an exposed staging host and a secret shipped in a JavaScript bundle, and it becomes a path to write access on the identity system.

Severity lives in the chain. A finding without reachability is an educated guess.

Point-in-Time Pentesting Leaves the Rest of the Year Uncovered

Service-led pentesting and PTaaS 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

Every approach on the market tests some piece of the breach path. They differ in where testing starts, how deep it goes, and how often it runs.

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. 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

• Cloud and infrastructure-as-code configurations

• 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.

Slide: “We see the company from the inside and the outside.” CodeAnt External and CodeAnt Internal feeding 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?”

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.

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?

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.

Slide: “Every attack makes CodeAnt smarter.” Model, attack, prove, fix and reset, learn loop. ~15B security events processed monthly.

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:

1. Conditions: when does this become exploitable?

2. Sequence: how does it reach a critical asset?

3. 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 leaked secret and the missing authorization check in place. The next exposed host reopens the same path.

Slide: Attack and validate, verified attack-path record, customer protection, privacy-safe abstraction, proprietary attack-path corpus.

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 Found

The assessment traced proven paths from exposed hosts, through three root causes, to four categories of company data.

The report distinguishes proven attack paths from paths that were considered but not proven. Only proven paths drive priority.

Slide: “CodeAnt shows how companies will get breached, before attackers do.” Exposed surface, company boundary, root cause, company data. Redact all hostnames before publishing.

Why Siloed Tools Would Miss It

Each root cause, found alone, looks like a routine ticket. A secrets scanner flags the bundle. An API scanner flags missing authentication. An attack surface tool lists the staging host.

None of those tools shows that the three findings together reach write access on the identity system. That chain 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.

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.

[Image placeholder] Slide: “Every verified exploit makes CodeAnt stronger for every customer.” Private graph stays with Customer A, shared patterns verified only.

9. Evidence From the Loop

The loop runs on real customer infrastructure every day. Its output is measurable.

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.

Adoption Sequence

Teams get to proven paths fastest by connecting signals in this order:

1. Establish the external baseline: map domains, subdomains, IPs, open ports, exposed services, and leaked credentials.

2. Connect internal context: add repositories, dependencies, binaries, cloud configurations, and identity.

3. Prove and prioritize: run attacks, separate proven paths from considered ones, and rank by reachability to critical data.

4. Remediate at root cause: close proven paths, re-test them, and keep them in the model as recurrence guards.

5. 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.

Find the breach path before the attacker does.

This white paper is a living document. As attack techniques and AI capabilities evolve, so will the model it describes.

Published by CodeAnt AI | September 2026

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