Australia's approach to operational resilience and critical infrastructure protection has moved decisively from aspiration to enforcement. On 1 July 2025, the Australian Prudential Regulation Authority's Prudential Standard CPS 230 Operational Risk Management came into force — replacing three predecessor standards and introducing the most comprehensive operational resilience obligations that APRA-regulated entities have ever faced. Simultaneously, the Security of Critical Infrastructure (SOCI) Act, as substantially expanded by reforms in 2021 and 2022, imposes an entirely separate but equally demanding set of cybersecurity, risk management, and incident reporting obligations on responsible entities across eleven sectors of the Australian economy.

For technology leaders at organisations subject to either or both frameworks — and many organisations in financial services are subject to both — the combined regulatory picture creates overlapping obligations in risk identification, vulnerability management, supply chain governance, and incident response. End-of-life open source software sits at the intersection of all of them.

EOL open source rarely appears on a compliance checklist. It is not flagged when a framework is deployed. It does not send alerts when its upstream maintainer releases a final version. But when a CVE is disclosed against an EOL component, the absence of a vendor patch simultaneously triggers a cascade of unresolvable compliance gaps under CPS 230 and the SOCI Act — gaps that HeroDevs Never-Ending Support (NES) is specifically designed to close.

‍

Australia's Dual Regulatory Framework: CPS 230 and the SOCI Act

Understanding the compliance exposure that EOL open source creates requires first understanding how the two frameworks interact, and where their requirements converge on the same underlying technology risks.

‍

APRA CPS 230: A New Standard for Operational Risk in Financial Services

CPS 230 is APRA's cross-industry prudential standard for operational risk management, replacing the three standards it supersedes: CPS 231 (Outsourcing), CPS 232 (Business Continuity Management), and CPG 233 (Operational Risk Management). It applies to all APRA-regulated entities — authorised deposit-taking institutions, general and life insurers, private health insurers, and superannuation RSE licensees — and reflects APRA's recognition that operational risk in the financial sector has become inseparably intertwined with technology risk, third-party dependency, and cyber exposure.

CPS 230 is built around three interconnected pillars: operational risk management, business continuity planning, and service provider management. The standard requires entities to identify their critical operations, establish disruption tolerance thresholds, and demonstrate how they will maintain those operations through severe disruptions. It requires boards and senior management to take explicit accountability for the operational risk framework. And it requires comprehensive governance of material service providers — including a register of material service providers that ADIs, superannuation trustees, and insurers were required to submit to APRA by 1 October 2025.

‍

The SOCI Act: Protecting Critical Infrastructure Across Eleven Sectors

The SOCI Act, as expanded by the 2021 and 2022 amendments, creates a distinct but complementary framework for protecting Australia's critical infrastructure assets from cyber and physical threats. It applies across eleven sectors — encompassing energy, communications, financial services, healthcare, water, transport, data storage and processing, higher education and research, the defence industry supply chain, food and grocery, and space technology — through a combination of Positive Security Obligations and Enhanced Cyber Security Obligations.

The core compliance mechanism for most responsible entities is the Critical Infrastructure Risk Management Program (CIRMP), which requires an all-hazards approach covering four vectors: physical security and natural hazards; personnel hazards; supply chain hazards; and cyber and information security hazards. CIRMPs must be reviewed and updated regularly, and responsible entities must submit an annual report to the Cyber and Infrastructure Security Centre (CISC) attesting to their program's adequacy. For entities declared as Systems of National Significance, additional Enhanced Cyber Security Obligations apply — including mandatory vulnerability assessments with required remediation plans.

Critically, the SOCI Act's grace periods have ended. Cyber incident reporting, CIRMP obligations, and cyber and information security framework requirements are all mandatory with no basis for extension.

Many organisations operating in financial services are subject to both CPS 230 and the SOCI Act simultaneously — facing compounding obligations in risk identification, vulnerability management, and supply chain governance that EOL open source fails to satisfy under either framework.

‍

How EOL Open Source Creates Specific Exposure Under CPS 230

Operational Risk Identification: The Inventory Problem

CPS 230's foundational requirement is that APRA-regulated entities identify, assess, and manage their operational risks with effective internal controls, monitoring, and remediation. The Prudential Practice Guide CPG 230 reinforces this by setting out APRA's supervisory expectations on technology risk, including the management of software lifecycle risks.

End-of-life open source components present a structural problem for this requirement. They are frequently undocumented in software inventories, they predate formal risk registers, and their transition from supported to EOL status rarely triggers a risk assessment review. An entity that cannot identify its EOL open source dependencies cannot assess them, cannot demonstrate effective internal controls over them, and cannot remediate vulnerabilities in them. The operational risk identification framework that CPS 230 mandates is functionally incomplete wherever an unidentified EOL component exists.

Critical Operations Resilience: No Patch, No Recovery Path

For each critical operation, CPS 230 requires entities to establish disruption tolerance thresholds — the maximum period and extent of disruption they can sustain — and to maintain business continuity plans that demonstrate how they will remain within those thresholds during severe disruptions.

An EOL open source component embedded in a critical system creates a resilience gap that no business continuity plan can fully bridge. The disruption scenario is not hypothetical: a CVE is disclosed against the EOL framework, a threat actor exploits it, and the critical system is compromised. Unlike a supported framework where a patch can be deployed before or after an incident to close the vulnerability, an EOL component has no such remediation pathway. The disruption scenario is predictable, the attack vector is public, and the recovery plan cannot include patching the root cause.

Material Service Provider Management: The Register Gap

CPS 230's service provider management obligations require entities to maintain a comprehensive policy covering all material service providers, enter formal agreements that include security and operational requirements, and monitor those arrangements on an ongoing basis. The material service provider register — submitted to APRA by October 2025 — must accurately reflect all material third-party relationships that support critical operations.

Open source software used in critical systems is a material third-party dependency, but EOL open source has no service provider to register, no agreement to enter, and no vendor to monitor. The upstream maintainer relationship has been terminated. An entity that relies on EOL open source for critical operations has a material dependency that cannot be governed under the CPS 230 service provider management framework because the provider no longer functions as one. This is not a documentation gap — it is a structural governance gap that the standard's requirements cannot accommodate without an active vendor relationship.

Board Accountability: Risk Postures Boards Cannot Defend

CPS 230 explicitly places boards and senior management in the accountability chain for operational risk. Directors must ensure that operational resilience is embedded in governance frameworks and decision-making processes. APRA supervisory engagements increasingly probe technology risk at board level — and assessors will ask whether boards have been informed of, and have approved risk treatments for, material unmitigated technology risks.

A board that has approved an operational risk framework containing unidentified or unmitigated EOL open source exposure has approved a governance framework with a material gap. When that gap surfaces during a supervisory engagement or an incident notification, the question will not be whether the board knew about it — it will be why the risk management framework did not surface it for board consideration.

‍

CPS 230 Obligation Mapping: EOL Exposure vs. NES Resolution

‍

How EOL Open Source Creates Specific Exposure Under the SOCI Act

The CIRMP Cyber Hazard Vector: Unresolvable Known Vulnerabilities

The CIRMP's cyber and information security hazard vector requires responsible entities to identify cybersecurity vulnerabilities in their systems, assess their potential impact, and implement measures to minimise or eliminate those risks where reasonably practicable. Annual reporting to CISC must attest to the adequacy of these measures.

EOL open source components with catalogued CVEs are precisely the kind of cybersecurity hazard the CIRMP cyber vector is designed to capture — and precisely the kind of hazard it cannot resolve. The vulnerability is known, it is documented in public CVE databases, and it has likely been flagged by the entity's own vulnerability scanning tools. But the measure required to minimise it — a security patch — does not exist. The CIRMP framework assumes that identified hazards have available mitigations; EOL open source hazards do not, absent an active security maintenance relationship.

The CIRMP Supply Chain Hazard Vector: The Departed Supplier

The CIRMP's supply chain hazard vector requires responsible entities to identify significant IT and OT supplier dependencies, assess the cybersecurity risks those dependencies create, and address those risks through their risk management program. Contracts with third parties should embed cybersecurity requirements, and suppliers should be evaluated on their cybersecurity proficiency.

End-of-life open source represents a supply chain hazard event — the functional equivalent of a key supplier exiting the market. The maintainer that produced the framework has ceased security operations. There is no cybersecurity proficiency to evaluate, no contract to embed requirements in, and no supplier to notify of vulnerabilities. An entity whose CIRMP supply chain hazard assessment does not account for EOL open source dependencies has a material blind spot in its supply chain risk management program that CISC reviewers may identify in the annual report.

ECSO Vulnerability Assessments: Remediation Plans That Cannot Be Written

For entities declared as Systems of National Significance, the Enhanced Cyber Security Obligations require mandatory vulnerability assessments — conducted or reviewed by the Australian Cyber Security Centre (ACSC) — with required remediation plans as an output. These assessments are not aspirational; they are compliance documents that ACSC and CISC will examine.

A vulnerability assessment of a system running EOL open source will produce findings for each known CVE against those components. The assessment output requires a remediation plan for each finding. But a remediation plan for an EOL CVE cannot commit to a vendor patch timeline when no vendor exists to deliver one. The plan can only offer compensating controls, isolation measures, or a migration commitment — none of which satisfies the standard interpretation of vulnerability remediation in an assessment context.

Annual CIRMP Reporting: The Attestation Problem

Responsible entities must submit an annual CIRMP report to CISC attesting to their risk management program's adequacy and compliance. This attestation covers all four hazard vectors, including cyber and information security and supply chain. For entities with material EOL open source dependencies in critical infrastructure systems, the attestation creates a binary problem: the CIRMP either does not disclose the EOL exposure (creating a material omission), or it discloses it and acknowledges an unresolved hazard (inviting regulatory scrutiny).

Neither outcome is comfortable. The first risks a finding of inadequate program disclosure; the second invites questions about why a known, remediable risk has not been addressed. The only defensible position is one where the EOL hazard is disclosed and a credible mitigation — active security maintenance through a provider like HeroDevs — is documented as the treatment.

‍

SOCI / CIRMP Obligation Mapping: EOL Exposure vs. NES Resolution

‍

How HeroDevs Never-Ending Support Addresses the Compliance Gap

HeroDevs was built to solve the specific structural problem that both CPS 230 and the SOCI Act now enforce against: providing active, documented security maintenance for open source frameworks after their upstream maintainers have discontinued support. Through its Never-Ending Support (NES) product line, HeroDevs provides backported security patches, CVE remediation, compliance documentation, and a formal vendor relationship for a broad portfolio of EOL open source frameworks — without requiring organisations to immediately migrate to a newer major version.

NES addresses the compliance gaps created by EOL open source at the level of each specific obligation, under both frameworks:

Operational Risk Register (CPS 230): NES provides security advisories, CVE tracking, and patch release documentation that give risk teams concrete, auditable evidence to incorporate into the operational risk register. EOL components under NES are identifiable, assessable, and actively treated — satisfying the risk management lifecycle that CPS 230 requires.

Critical Operations Resilience (CPS 230): By delivering backported patches for known CVEs in EOL frameworks, NES removes publicly disclosed attack vectors from critical system environments before they can be exploited. This directly supports the disruption tolerance thresholds that CPS 230 critical operations obligations require.

Material Service Provider Register (CPS 230): The HeroDevs NES subscription is a contractual, documentable service arrangement. Organisations can register HeroDevs as a material service provider for their covered open source components, enter a formal agreement with defined security maintenance obligations, and monitor NES performance through advisory and patch delivery cadence — satisfying the CPS 230 service provider governance requirements that unmaintained open source cannot meet.

CIRMP Cyber Hazard Remediation (SOCI): NES produces and delivers patches for CVEs disclosed against covered EOL frameworks, enabling CIRMP owners to document completed remediation actions for each identified cybersecurity hazard. An EOL open source CVE that would otherwise sit as an unresolvable CIRMP finding becomes a treated, closed risk with an audit trail.

CIRMP Supply Chain Hazard Mitigation (SOCI): NES restores an active supply chain relationship for EOL frameworks. Responsible entities can identify HeroDevs as the active security maintenance provider for covered components, assess NES against their cybersecurity criteria, embed supply chain security requirements in the NES agreement, and monitor supplier security performance — satisfying the supply chain hazard vector obligations that maintainer cessation otherwise defeats.

ECSO Remediation Plans (SOCI, SoNS): For SoNS operators, NES enables the production of concrete, deliverable vulnerability remediation plans. Each identified EOL CVE can be mapped to a committed NES patch release, with a defined delivery timeline — replacing the open-ended migration commitments or compensating control workarounds that vulnerability assessments otherwise require.

‍

NES Coverage Across the Australian Enterprise Open Source Stack

HeroDevs NES covers a broad and growing portfolio of the open source frameworks most commonly deployed across APRA-regulated entities and SOCI-covered critical infrastructure operators in Australia, including Angular, AngularJS, Vue 2, React, Node.js, Spring Boot, Django, Elasticsearch, and many others. For each covered framework, HeroDevs delivers drop-in compatible packages that integrate with existing codebases without requiring architectural changes.

NES customers receive structured security advisories in the format needed for risk registers and CIRMP documentation, patch release notes suitable for board-level technology risk reporting, and compliance artifacts supporting both CPS 230 service provider governance requirements and SOCI annual CIRMP attestation. For APRA supervisory engagements and CISC annual reviews, these materials provide the documented evidence chain that regulators and their assessors will look for.

‍

No More Runway: Both Regimes Are Fully Operational

CPS 230 has been in force since 1 July 2025. The material service provider register was due at APRA by 1 October 2025. The transitional arrangement for pre-existing service provider contracts expires at the earlier of the next renewal or 1 July 2026 — meaning the service provider management obligations of CPS 230 will apply to all contracts by mid-2026 at the latest.

The SOCI Act's grace periods have ended. CIRMP obligations, cyber incident reporting requirements, and the cyber and information security framework requirements are all mandatory. Annual CIRMP reports are being submitted and reviewed. For entities declared as Systems of National Significance, ECSO vulnerability assessments are not a future obligation — they are current ones.

The window for organisations to identify and address EOL open source exposure is not a future planning item — it is an open compliance gap. Every day that a critical system runs an EOL open source component with a known CVE is a day that the organisation is operating outside the risk management standards that both CPS 230 and the SOCI Act require.

HeroDevs NES can be deployed against existing codebases without a migration, a re-architecture, or an extended implementation project. For organisations that identify EOL open source exposure in their CPS 230 operational risk frameworks or SOCI CIRMPs, NES provides the fastest path to a documented, defensible, and regulatory-grade security posture — one that satisfies the spirit and the letter of both frameworks.

‍

‍