Claude Is Rewriting COBOL

On February 23, 2026, a single announcement moved markets. Anthropic revealed that Claude Code can automate the most resource-intensive phases of COBOL modernization: mapping dependencies, documenting undocumented business logic, translating legacy code into modernized one. IBM's stock dropped 13% the same day — its worst single-day fall since 2000. A $17 billion consultancy ecosystem built around legacy code maintenance suddenly looked vulnerable to disruption.

The market's message was unambiguous: AI-driven code modernization has moved from theoretical to operational. But in the rush to rewrite decades-old codebases, a critical conversation is not getting enough attention.

What happens to application security when they modernize?

 

The Modernization Illusion

Here is what most modernization narratives leave out. When Claude Code translates a COBOL program into Java, it preserves the business logic — the calculations, the workflows, the decision trees that took decades to refine. That's the value proposition, and it's real.

But the business logic is not where vulnerabilities actually live. Vulnerabilities live in the language, the architecture, the dependencies, and the infrastructure. And every one of those changes completely during modernization.

 

Language migration

COBOL and C have their own vulnerability patterns. C is prone to buffer overflows, format string bugs, and memory corruption. COBOL carries risks of SQL injection through unparameterized EXEC SQL blocks, buffer overflows in fixed-length PIC field operations, and command injection via system call interfaces. The migrated code is functionally equivalent. It is not security-equivalent. A codebase that had zero injection vulnerabilities in COBOL may have dozens in Java — not because the AI made a mistake, but because the target language enables vulnerability classes the source language didn't have.

And here's a wrinkle many teams miss: during migration, they often have legacy executables where original source code was lost years ago. To get a security baseline before modernization, they need the ability to scan compiled binaries directly — decompile, deobfuscate, and analyze. Most AST tools can't do this.

 

Architecture transformation

Monoliths become microservices. What was a single program on a mainframe becomes dozens of independent services communicating over APIs. Each API endpoint is a new entry point for attackers. Event buses, circuit breakers, async processing — all add architectural complexity. The attack surface doesn't just change; it expands geometrically.

 

New dependencies

A COBOL application on a mainframe typically has zero open-source dependencies. After migration to Java, that same application pulls in Maven or Gradle packages — potentially hundreds of libraries. According to the Linux Foundation, open-source components make up 70-90% of modern applications. In 81% of enterprise codebases, high or critical-risk vulnerabilities already exist in open-source components.

The challenge compounds with transitive dependencies — libraries pulled in by your libraries. A vulnerability in a package three levels deep in the dependency tree is just as exploitable as one in the code. Effective SCA needs reachability analysis to trace whether a vulnerable function is actually invoked in the application — otherwise we’re drowning in theoretical CVEs while the real risks hide in the noise.

 

Infrastructure shift

On-premise mainframes give way to cloud, containers, or serverless. New deployment models mean new configuration risks, new IAM boundaries, new exposure points. A misconfigured S3 bucket has nothing to do with the original COBOL — but it's a direct consequence of modernization.

 

Each Layer Needs a Specific Type of Security Testing

The relationship between modernization steps and security testing requirements is direct:

Language migration → SAST

The migrated code must be scanned for vulnerability classes specific to the target language — SQL injection via unvalidated EXEC SQL calls, buffer overflow in fixed-length PIC field operations, and command injection through system call interfaces. AI translation produces functionally equivalent output, not secure output. The scanner needs to cover both legacy and modern languages — ideally from a single platform, to compare vulnerability profiles before and after migration without switching tools.

 

New dependencies → SCA

When a codebase goes from zero open-source to hundreds of packages, software composition analysis becomes essential. 96% of modern codebases contain open-source components. SCA identifies known vulnerabilities, flags license issues, monitors for new CVEs, and generates the SBOM (Software Bill of Materials) that regulators increasingly require.

 

New APIs → DAST

Decomposed microservices expose APIs that must be tested dynamically — authentication flaws, broken access control, injection via API parameters. These vulnerabilities only manifest at runtime.

 

The new stack → compliance reporting

Regulators don't grant exceptions because code used to be COBOL. The modernized system needs its own CWE/SANS, OWASP, and PCI DSS evidence — continuous, not one-time.

 

Where Security Fits in the Modernization Timeline

Anthropic's own Code Modernization Playbook outlines a phased approach: weeks 1-2 for discovery, weeks 3-4 for proof of concept, weeks 5-8 for first migration, month 3+ for scaling. 

 

Security testing belongs at every phase:

Discovery (weeks 1-2)

Baseline the existing codebase in its current language. If it's COBOL, C, Delphi, or Perl — make sure your scanner actually supports them. Many don't. Some cover 43 languages including legacy stacks.

 

Proof of concept (weeks 3-4)

Scan the migrated PoC. Compare vulnerability profiles old vs. new. Are new classes appearing? This is where SCA enters the picture for the first time — the legacy code had no dependencies, the new code has hundreds.

 

First migration (weeks 5-8)

Integrate AST into the CI/CD pipeline of the new system. Automated scans on every build. Quality gates that prevent critical findings from reaching production.

 

Scale (month 3+)

As more systems modernize, patterns from earlier migrations inform what to watch for. Compliance reports accumulate, building the evidence trail auditors expect.

 

Transformation workaround

AI-driven code modernization is definitely a breakthrough — it compresses years of work into weeks. But every layer of that transformation creates an attack surface that didn't exist before. The organizations that treat security as a parallel workstream from day one are the ones that avoid discovering, too late, that their modern Java application has more open vulnerabilities than their legacy COBOL ever did.