App Modernization Is a Security Control

Recently I sat down with a CISO at a large government organization. I am leaving out which one, and I am paraphrasing rather than quoting. Their view was that if you want to reduce attack surface, cut down known vulnerabilities and thin out what shows up in your SBOMs, modernizing the applications is the quickest way to do all three.

I had always filed modernization under cost and agility. They filed it under security. That is a strong claim from one practitioner, so I went to see whether the published evidence backs it. Mostly it does. A few parts need caveats, and I have put those in too.

The patching race is already lost for some vulnerabilities

Verizon's 2025 Data Breach Investigations Report found that exploiting a vulnerability was the initial access vector in 20% of breaches, up 34% on the previous report. Edge devices and VPNs made up 22% of those exploitation targets, up from 3%. Organizations only fully fixed about 54% of those edge vulnerabilities during the year, and the median time to do it was 32 days.

Google's Mandiant tracked how long attackers take. In its 2023 time-to-exploit analysis the average was 5 days, down from 63 days in 2018 and 2019. Its M-Trends 2026 report estimates the mean at -7 days, meaning exploitation routinely happens before a patch exists, and says exploits were the most common initial infection vector for the sixth year running, at 32% of intrusions.

• 20%

  of breaches began with an exploited vulnerability (Verizon DBIR 2025)

• 32 days

  median to fix edge-device flaws, with only ~54% fully fixed

• ~70%

  of critical security debt is third-party code (Veracode)

• 13%

  of 2025 Log4j downloads still had Log4Shell (Sonatype)

A negative time-to-exploit does not mean patching is pointless. It means the zero-day share of the problem cannot be patched at all, and the rest is a race you win by having less exposed in the first place.

Where the exposure actually lives

Veracode's 2025 research found that half of organizations carry critical security debt, meaning flaws left open for more than a year, and that about 70% of it comes from third-party code and the software supply chain. Its public sector snapshot is a little worse: 78% of public sector organizations carry some security debt, 55% carry critical debt, and third-party libraries contribute over 70% of the critical part.

Then there is Log4j. Sonatype's December 2025 analysis found that roughly 13% of Log4j downloads from Maven Central in 2025, about 40 million, still contained Log4Shell. It also found that about 95% of vulnerable components downloaded already had a safer version available.

The fix existed and people did not take it. The reports do not say why, so what follows is my inference rather than a finding. For a lot of applications, taking the fix means upgrading a framework the application was never built to upgrade, and nobody can say how long that will take or what will break.

What an SBOM can and cannot do

An SBOM is an ingredients list. Its real value shows up the day the next Log4Shell lands, when "are we exposed, and where?" becomes a query instead of a three-week scramble. If you do not have them yet, start generating them.

Two limits matter here. First, an SBOM measures the problem and does not shrink it. The SBOM for an application stuck on an unsupported framework is an accurate list of things you cannot easily fix. Second, a listed component with a known CVE may not be reachable in your deployment. That is the gap CISA's VEX minimum requirements address, with statuses of not affected, affected, fixed and under investigation.

So here is how I read the CISO's point: modernization is the thing that changes what is on the list.

Four ways modernizing moves the number

This part is my reasoning, not a published result, so weigh it that way.

Supported means patchable. CISA's stated reason for ordering federal agencies to replace end-of-support edge devices in BOD 26-02 is that vendors stop shipping CVE patches and security updates for them. That directive covers edge devices on U.S. federal civilian networks, not application runtimes. The logic carries over, though: a component with no vendor patch stream is a vulnerability you have agreed to keep.

Upgrades stop being projects. An application with a modern build and a real test suite turns a dependency bump into a pull request. That is the difference between a patch queue you can triage on a schedule and one nobody wants to own.

The platform takes over a layer of patching. On App Service or Container Apps, Azure owns the update and patch burden for the platform underneath your code, as covered in our containerization and modernization guide. Your code and its dependencies stay yours. The operating system and runtime hosting layers stop being a VM you forgot about.

The SBOM becomes a build output. Once an application has a pipeline, the inventory is produced on every build instead of reconstructed by hand after an incident. Credentials move the same way. Stored secrets give way to managed identity, and secret scanning catches what is left before anything ships.

Where I would push back

"Quickest" is relative, and a few things can beat modernization on speed:

• Retire it. The fastest attack-surface reduction is an application that no longer exists. Any portfolio review should ask first whether the app needs to be there.
• Isolate it. Network segmentation and virtual patching buy time within the same week for an application you cannot touch yet.
• Bump one dependency. If a fix exists for a version you can still run, you do not need a modernization project.

Two other caveats. Containerizing is not modernizing: a JDK 8 monolith in a container is still a JDK 8 monolith, which we spelled out in the containerization post. And a modernized application has its own new dependencies and its own cloud configuration to get wrong, so you are trading a known, aging risk for a smaller and more manageable one, not for zero.

AI tooling changes the cost side of this. Microsoft's documentation for GitHub Copilot modernization lists the IDE upgrade experience for Java, .NET and C++ as generally available and the CLI modernization agent for assessment and planning as public preview, with CVE scanning after upgrades and every change reviewable by a human. Those statuses are as of October 2026 and may have moved by the time you read this. For scale, the Government of Alberta reported a roughly 20x speed-up on specific projects, which we covered with the caveat it needs in our conversation with the Deputy Minister. That figure is self-reported, not a benchmark. Run a pilot on one real application before you plan a portfolio around anyone's number.

How I would sequence it

You can do the first two steps without us.

1. Inventory every application. Record the runtime and framework versions, the vendor support end date, whether it faces the internet, and who owns it.
2. Cross-check against known exploitation. Compare the components against CISA's Known Exploited Vulnerabilities catalog. Anything on it that is reachable from outside moves to the top.
3. Sort each application into one of four buckets: retire, replace with a supported product, upgrade or re-platform, or contain and leave.
4. Start with internet-facing applications on end-of-support stacks. That is where the Verizon and Mandiant numbers above bite hardest.
5. Measure three numbers. Track the count of end-of-support components, the median age of dependencies, and the days it takes to ship a patched build. If all three are not falling, you are moving applications around and not modernizing them.

Where we fit

Containerization and app modernization is one of the five pillars of our agentic DevOps work. In practice that means choosing the right target (App Service, Container Apps or AKS), running the Java and .NET upgrades with GitHub Copilot modernization, scanning code and secrets before anything ships, and landing the result in a governed Azure landing zone instead of a one-off exception. The pattern is written up for an energy-sector setting in our legacy modernization use case.

If you have the list from step 1 and want a second opinion on the order, book a discovery call or join our Discord community. If your next question is whether the foundation is ready for agents, the Agentic AI Readiness Scorecard is free and has no email gate.

Frequently Asked Questions

Does application modernization reduce attack surface?

Usually, yes, when the modernization changes what is running: a supported runtime and framework, upgraded dependencies, a managed platform that patches the layer beneath the app, and managed identity instead of stored credentials. Moving an unchanged application into a container does none of that. The honest test is whether the end-of-support component count and the age of your dependencies went down.

Is modernizing an application faster than patching it?

It depends on the app. If a fix exists for a version you can still run, patching is faster. Modernization wins when the application sits on an end-of-support runtime or framework where no patch will ever arrive, or when every upgrade is a multi-month project. Retiring an app nobody needs, or isolating it, can beat both on speed.

Does having an SBOM reduce vulnerabilities?

No. An SBOM is an inventory of components. It tells you where you are exposed when a new vulnerability lands, which is valuable, but it does not fix anything, and it does not say whether a vulnerable component is reachable in your deployment. VEX statements are the companion format for that. Modernization is what changes the contents of the list.

Can AI tooling modernize a legacy Java or .NET application safely?

It can do much of the upgrade work, including framework upgrades, build fixes and CVE scanning after the upgrade, with a developer reviewing each change. As of October 2026, GitHub Copilot modernization's IDE upgrade experience is generally available for Java, .NET and C++, and its CLI modernization agent is in public preview. Published speed-ups are self-reported and vary by application, so scope a pilot instead of trusting a headline number.