Your EOL Open Source Is a Japan Active Cyber Defense Problem. Here’s How to Fix It.

If your organization operates critical infrastructure in Japan, or supplies the systems those operators depend on, the rules changed on 1 October 2026. Japan’s Active Cyber Defense law (Act No. 42 of 2025), enacted on 16 May 2025, brought its core provisions into force that day: mandatory incident reporting, government information sharing and a public–private council. By 31 March 2027, operators must notify the government of the product names and versions running on their most critical systems, and the law’s communications-data powers take full effect by 22 November 2027.

Most of the conversation around the law focuses on its headline powers: government analysis of communications data and the authority to neutralize attacker servers. Those matter. But there is one obligation that should be top of mind for every CISO and engineering leader running critical systems on open source: the law puts your software versions in front of the government. End-of-life (EOL) software stops being an internal risk register item and becomes something regulators can see.

The law does not care that your upstream framework reached end of life. It cares whether a vulnerable system that Japan depends on can be fixed. If the component has no upstream maintainer, that answer gets very hard.

What the Law Actually Says About End-of-Life Software

The obligations apply to roughly 250 designated critical infrastructure operators across 15 sectors, including electricity, gas, water, telecommunications, finance, aviation, rail and logistics. They focus on “specified critical computers”: systems such as internet-facing firewalls and VPNs, authentication servers, and systems that control access to critical facilities. A system can be in scope even if a vendor, group company or cloud provider owns it, as long as the operator relies on it.

Three interlocking obligations create the EOL problem:

Incident Reporting (in force 1 October 2026)

Operators must report incidents, and events that could cause them, on specified critical computers to their sector minister and the Prime Minister. Initial reports are due promptly — draft ordinances suggest as soon as possible for DDoS and within about three to five days for ransomware and other attacks — with a detailed report within 30 days. If an attacker exploits a known vulnerability in an EOL component, the reporting duty starts regardless of whether a patch exists.

Asset Notification (first deadline 31 March 2027)

Operators must notify the product names and versions of their specified critical computers — by the end of March 2027 for existing systems, and within about four months of introducing new ones. The government plans to match that version data against vulnerability intelligence, including unpublished vulnerabilities, and alert operators directly. An EOL version in your notification is a flag the government can see.

Vendor Duties (Article 42 and the Basic Act on Cybersecurity)

Companion amendments give IT suppliers an effort duty to design for their customers’ security and share supporting information. Under Article 42, ministers can share vulnerability information with vendors, request reports on their products and ask them to take measures to prevent damage — including overseas vendors that supply into Japan.

These obligations operate together. An EOL dependency creates a cascading failure: the version appears in your asset notification, the government matches it to a known vulnerability and alerts you, no upstream patch exists, and if it is exploited, your reporting clock starts with no fix to point to.

EOL Software Is Not Just a Technical Problem

Japan’s law is built on visibility and supervision. Operators’ critical systems are now known to the government down to the version level, and ministers can ask operators to address vulnerabilities — including zero-days — on the most critical systems. For operators, an unpatched EOL component becomes a matter of regulatory scrutiny, service continuity and public trust. For vendors, it becomes a question customers and ministries will ask directly, and one that shapes who wins the next contract.

Critically, the obligations are ongoing. Every new critical system must be notified within months of introduction, and every alert needs a response. If your critical systems today contain AngularJS (EOL since December 2021), Angular 18 or earlier, Spring Security 5.x, Node.js 18 or Vue 2, you already have components that no upstream maintainer will patch.

Two Real-World Examples of Unpatched EOL CVEs

CVE-2026-22732: Spring Security — CVSS 9.1 (Critical)

This critical vulnerability causes HTTP security response headers to silently not be written when responses are committed before Spring Security’s filter chain can write them. Headers such as Cache-Control, X-Frame-Options, Strict-Transport-Security and Content-Security-Policy are simply absent. It affects Spring Security versions back to 5.7.x, and for EOL versions there is no upstream patch. If an authentication portal or operations system relies on legacy Spring Security, you have:

• A critical vulnerability on a specified critical computer with no upstream fix
• A version in your asset notification that the government can match to this CVE
• A likely government alert with no patch to apply
• An incident reporting obligation — prompt initial report, detailed report within 30 days — if the flaw is exploited

CVE-2026-27970: Angular — XSS via i18n ICU Messages (CVSS 7.6, High)

This cross-site scripting vulnerability affects Angular’s internationalization pipeline — highly relevant for systems serving Japanese and English interfaces. When ICU messages contain HTML that is not properly sanitized, an attacker who compromises translation files can inject JavaScript that runs in a user’s browser. Angular versions up to 18.2.14 are affected, and the Angular team does not backport security fixes to EOL versions. If an operator portal or management console uses an EOL Angular version, you have:

• A known XSS vulnerability in a system operators and staff rely on, with no upstream patch
• A risk of credential theft from the very users who administer critical systems
• A version-level exposure visible through asset notification
• For vendors, an Article 42 request you cannot fully answer

The HeroDevs Vulnerability Directory tracks hundreds of CVEs across EOL frameworks still widely deployed in enterprise products, including Spring Boot, Node.js, .NET, AngularJS, Angular and many more.

So What Do You Actually Do About It?

The long-term answer is migration to a supported version. But anyone who has led a major framework migration knows the reality: these projects take months or years, need extensive regression testing and compete with other priorities. In critical infrastructure, where availability and safety come first, rushing a migration on a core system is a risk in its own right.

The 31 March 2027 asset notification deadline is not waiting for your migration to finish, and incident reporting is already live. This is where HeroDevs Never-Ending Support (NES) comes in.

NES provides commercial long-term support for open source software that has reached end of life. HeroDevs engineers maintain the EOL codebases, backport security fixes, and publish patched releases as drop-in compatible packages through standard registries (npm, Maven, NuGet and more). No architectural changes required.

How NES Changes the Active Cyber Defense Picture

The law’s duties attach to operators because they run the critical systems, and increasingly to vendors because they supply them. NES changes the practical reality of meeting those duties.

When HeroDevs provides NES for an EOL component, that component has an active vendor providing security patches, a CVE response process and fixes published on a documented timeline. HeroDevs NES gives operators a fix to apply when the government’s vulnerability alert arrives.

• Asset notification: Your notified versions are supported, patched builds with an active vendor — not unsupported EOL releases waiting to be flagged.
• Responding to alerts: When the government matches a vulnerability to your systems, HeroDevs triages, patches and ships the fix, so you can act on the alert instead of explaining why you can’t.
• Incident reporting: If exploitation does occur, you have a corrective measure in progress to cite in your initial and 30-day reports — not an open gap.
• Vendor duties: Suppliers can commit to patching the open source inside their products, meeting customer expectations and Article 42 requests.
• Migration runway: NES bridges the gap between “we know we need to migrate” and “the migration is done,” so critical systems can be modernized carefully, without leaving them exposed.

Common Questions About Japan’s Active Cyber Defense Law

Does Japan’s Active Cyber Defense law apply to foreign vendors?

Yes, in part. The reporting and notification duties fall on designated operators in Japan, but Article 42 reaches vendors that supply products into Japan, including those based overseas. In practice, operators will also push requirements down to suppliers through contracts.

Our system is hosted by a cloud provider. Is it still in scope?

It can be. A system can count as a specified critical computer even if a vendor, group company or cloud provider owns it, as long as the operator relies on it for the critical service.

My EOL dependency is deep in the stack. Does it still matter?

Yes. The government plans to match notified versions against vulnerability data, and vendors may be asked which of their products contain a vulnerable component. A deep library with an unpatched CVE is still part of the system you notified.

We are planning a migration. Can we wait?

Incident reporting is already in force, and the first asset notification deadline is 31 March 2027. A migration plan is an intention, not a patch. Until the EOL component is gone, it is the version you will notify and the one an alert will point to.

What happens if we receive a vulnerability alert?

For the most critical systems, operators can be asked to address the vulnerability. With an EOL component and no upstream patch, your options are a rushed migration, compensating controls that may not satisfy regulators, or a supported, patched version from a provider like HeroDevs.

The Bottom Line

Japan’s Active Cyber Defense law is live. Incident reporting began on 1 October 2026, the first asset notifications are due by 31 March 2027, and full implementation follows by November 2027. The law puts the versions of your critical systems in front of the government, making EOL software a regulatory exposure, not just a technical one.

If your critical systems contain EOL open source dependencies — and nearly all enterprise stacks do — the question is not whether this is a risk. It is. The question is what you do about it before your asset notification is filed.

HeroDevs Never-Ending Support is one of the most cost-effective ways to close that gap: it restores active vendor support for EOL components, keeps them patched against new vulnerabilities, and gives operators and vendors a credible answer when the government asks.

Start by understanding what is in your stack. The HeroDevs End of Life Dataset is a free resource that tracks 12 million+ package versions and identifies which EOL frameworks have known, unpatched CVEs — and what NES support is available for them.

‍