The Software Behind the Mission

Why resilience depends on adapting software while sustaining essential services

Roughly six months after Anthropic introduced Claude Mythos Preview through Project Glasswing, I find myself returning to a question beyond what AI can discover. Can institutions safely change the software their missions depend on? The announcement brought attention to powerful new capabilities, but the institutional response now deserves equal consideration.

Identifying a weakness, producing a correction, and protecting an essential service are related achievements. They are not the same achievement. Between them sit decisions about ownership, trust, testing, deployment, and continuity. I believe the next chapter of resilience depends on turning technical progress into changes institutions can make with confidence.

The developments across government and industry this year offer a useful way to examine how that capacity is being built. They also reveal a central challenge for institutions whose responsibilities depend on software, expertise, and maintenance they do not fully control.

What this year’s response reveals

What stands out to me is the attention being given to the work between discovery and operational protection. The announcements differ, but each provides a way to examine who will do that work, how it will be supported, and whether institutions can use the result. Together, they offer a more useful story than a sequence of increasingly capable tools.

The March Cyber Strategy for America emphasized federal modernization, critical infrastructure protection, secure supply chains, and cooperation with industry and academia. The June executive order on advanced AI directed the formation of a clearinghouse to coordinate vulnerability discovery, validation, remediation, and patch distribution. These developments placed institutional coordination alongside technical capability as part of the national response.

CISA’s revised remediation directive connected urgency more explicitly to operational context. Its prioritization considers public exposure, known exploitation, the potential for automated exploitation, and technical impact. It also requires covered agencies to establish responsibilities, validation procedures, and reporting. Those requirements apply to covered Federal Civilian Executive Branch systems, not every enterprise or national security system, but they provide a concrete example of connecting risk assessment to accountable action.

Alongside those policy developments, industry initiatives are organizing capabilities around the software itself. Project Glasswing applies frontier AI to defensive security work. Akrites provides shared incident response and disclosure coordination for critical open source software, while OSERA focuses on shared remediation, backpatching, and standards that support enterprise adoption of fixes. Lightwell extends an enterprise open source maintenance model across a broader software footprint.

GOLD EAGLE addresses another part of the problem by augmenting the existing vulnerability coordination environment, including support for validation and deduplication of reports. These are distinct efforts, not parts of a single national program. Their significance, in my reading, is the investment they represent in the capacity surrounding software. Discovery needs coordination, corrections need maintenance and validation, and institutions need a practical way to consume the result.

The next test is whether those investments make action more dependable.

The distance between a fix and a protected service

JPMorganChase’s recent executive briefing makes an important distinction between deciding to address a vulnerability and completing the work required to protect an environment. Establishing exposure, identifying owners, coordinating suppliers, testing changes, and deploying them remain separate operational responsibilities. That distinction deserves attention because it is where technical progress meets institutional reality.

A correction can be available while an organization is still determining where it applies. A change can be approved while testing remains incomplete. A supplier can deliver an update while the consuming institution still needs to establish whether it can introduce that update safely. The availability of a fix matters, but leadership also needs to understand the organization’s ability to use it.

OSERA’s October announcement offers an example of progress on part of that journey. It reported a remediation and attestation standard and patched releases covering more than 50 projects in the Spring and Java ecosystems. Those are meaningful reported outputs, although they do not establish that every affected institution has deployed the resulting updates. A strong remediation process connects these stages, providing a path from a relevant finding to a trusted correction, through validation, and into the environment where the mission runs.

This is not a reason to discount upstream progress. It is a reason to understand the work required to realize its value. The outcome that matters to the institution is a change in its exposure, achieved without sacrificing the function the software supports.

Why critical infrastructure needs more than a patch

For essential services, remediation is itself an operational change. The urgency of a vulnerability does not remove the need to understand the consequences of altering the affected system. In operational technology environments, patching must account for safety, availability, and the behavior of the physical process. Joint guidance published by CISA emphasizes coordination with operational staff and the use of isolation and compensating controls when timely patching is not feasible.

The answer is not to accept exposure indefinitely. It is to prepare better choices. An operator with tested alternatives, clear decision authority, and a credible recovery path has different options from a team encountering those questions for the first time during an urgent response. Preparation can make the difference between a difficult but manageable change and a decision constrained by the absence of alternatives.

The operating context matters. A financial application, a hospital system, and an industrial controller do not share one maintenance model. Their requirements for testing, availability, and change approval need to be understood rather than compressed into a general instruction to move faster. A credible resilience discussion must account for those differences while keeping the obligation to reduce risk intact.

For national security, this creates two connected responsibilities. We need to reduce the opportunity for compromise while preserving essential functions as systems are corrected, isolated, replaced, or recovered. Preparedness should make those responsibilities easier to reconcile through testing arrangements, maintenance planning, clear authority, and alternatives that can be used in practice.

The goal is not speed in isolation. It is the ability to make a justified change without creating an unacceptable operational consequence.

Accountability in a shared ecosystem

Preparing those choices requires clarity about what an institution controls and what it relies on others to deliver. An institution can own a mission without owning every component that supports it. Dependence does not remove accountability, but it changes what an accountable institution must prepare for.

Leaders do not need to reproduce every upstream capability internally. They do need to understand which capabilities their mission depends on, what commitments support those dependencies, and what options remain if the expected response fails.

That requires a more practical view of relationships. A supplier relationship should establish how the organization obtains support when software needs to change. A maintenance arrangement should clarify what remains supported and what happens when that support ends. A partnership should make a necessary action possible, with responsibilities that remain clear when circumstances become difficult.

This connects with an interest I have carried from earlier roles into my work today. Institutions often meet their most consequential responsibilities through relationships that extend beyond their direct authority. The quality of those relationships becomes visible when something needs to happen. In software security, someone must investigate the issue, produce and maintain a correction, validate the result, and bring it into the relevant environment.

Institutions should also examine what they help sustain. Akrites was established to provide coordinated response and disclosure support for critical open source software, working with upstream maintainers. Its announced commitments include helping extend remediation support to critical infrastructure. That direction recognizes the need to accompany additional findings with the capacity to investigate and act on them.

Contribution can include engineering effort, maintenance support, responsible disclosure, validation expertise, or resources that help shared work continue. That support should reflect what maintainers need and have the capacity to take on, rather than creating additional demands without the resources to address them. Creating additional work without usable support is not the same as strengthening the ecosystem. The opportunity is to sustain capabilities that serve multiple institutions without expecting every consumer to recreate them independently.

The next frontier is the capacity to change

The capability I would prioritize next is the ability to update, replace, isolate, or recover a software dependency while preserving the essential function it supports. That work begins before an emergency. Institutions can examine whether required dependencies have credible maintenance paths, whether supported alternatives exist, and whether changes can be tested without unreasonable delay.

They can also question which components remain in the environment without serving a necessary purpose. The objective is not fewer components at any cost. It is software that is easier to understand, maintain, and change responsibly. Reducing unnecessary exposure and strengthening maintenance capacity should support the same operational goal, giving institutions better options when circumstances change.

Institutions do not need complete control of the software ecosystem or the ability to maintain every dependency independently. They need a clearer understanding of their dependencies, credible support around them, and practical options when those dependencies must change.

Those options also need to reach organizations with different levels of capacity. The June executive order explicitly recognizes access to defensive capabilities for organizations such as rural hospitals, community banks, and local utilities. That is an important part of the national resilience discussion. Shared capabilities fulfill their purpose when the institutions that need them can use them, not merely when those capabilities exist.

Build choices before they are urgently needed

Progress should be measured by whether institutions have better choices when a software dependency becomes unsafe. Can they obtain a trusted correction? Move to a supported alternative? Isolate the affected function? Recover while preserving the service people depend on?

Building those choices requires sustained technical work and relationships with clear responsibilities. It gives government, industry, academia, and the open source community a practical purpose around which to contribute. Behind that work are people responsible for services and missions that cannot simply pause while software gets fixed. Progress needs to reach them as something they can use with confidence.

I believe the next chapter of resilience will be built in the ability to change the software behind the mission while preserving the essential functions people depend on.