Autonomous Preventive Security for AI-Speed Software Development

Amartya | CodeAnt AI Code Review Platform
Amartya Jha

CEO, CodeAnt AI

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

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

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.

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%

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

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.

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.

Approach

Where testing starts

Internal depth

Cadence

What it proves

Pentest services and PTaaS

Scoped targets

Limited to engagement scope

One-time, manual

Scoped attack paths

AI pentesting for applications

Apps and APIs

None

Autonomous, on demand

Application exploits

AppSec platforms with AI pentesting

Apps, APIs, and code

Cloud posture only

Continuous

Application exploits

Enterprise network testing

Internal network

Network and identity

Continuous

Network and identity paths

Living threat model (CodeAnt AI)

External attack surface, apps, and APIs

Code, shipped binaries, cloud, and identity

Continuous

Verified code-to-data path

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.

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?"

Slide: "So we map it as one graph." Repositories to subdomain dependency 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?

Slide: "We map every attack path that can reach critical data." Internal and external inputs into the living threat model, output to 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.

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

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

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.

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.

Layer

Finding

Exposed surface

Four application hosts on a managed cloud app service (production API, data center app, portal, and staging API), plus 12 peripheral hosts

Root cause 1

Client-side secrets in JavaScript bundles

Root cause 2

No authentication on API reads

Root cause 3

No authorization on API writes

Data reached

Customer PII (3,000+ records)

Data reached

Workforce directory and passwords

Data reached

Identity system write access

Data reached

Asset, vendor, and OT 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.

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.

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.

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.

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

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:

  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

Start Your 14-Day Free Trial

AI code reviews, security and quality trusted by modern engineering teams.

Ship clean & secure code faster

Get Pentest Report

NO CC REQUIRED

Ship clean & secure code faster

Get Pentest Report

NO CC REQUIRED