After years of moving manufacturing overseas, there is renewed interest in bringing manufacturing back to the United States. Much of this interest has focused on the physical supply chain rather than the software supply chain, and that is a concern about the reliability and security of the software systems that government agencies rely on.
The software supply chain often represents a more immediate and less visible vulnerability than the physical supply chain, where components can be physically inspected and validated. If we do not give the same importance to where software is developed as to where physical parts are manufactured, we are not truly meeting the goals of this America First initiative and are exposing our critical infrastructure to unnecessary risk.
Table of Contents
The software supply chain is already a target
The lack of a solid strategy to ensure software sovereignty poses significant risks, including loss of operational control or the introduction of backdoor systems into critical infrastructure. For military ships, this could mean an increased risk of a denial of service attack at a critical moment or the adversary’s persistence within fleet systems.
Since 2021, the China-linked Volt Typhoon group has gained access to networks connected to critical US infrastructure in communications, energy, transportation, and water and wastewater systems. These operations are believed to represent pre-positioning to create disruption in future conflict scenarios.
]]>
Likewise, shortly before Russia’s invasion of Ukraine, Russian attackers attacked Viasat, the satellite communications system used by Ukraine, disrupting military communications and connectivity for thousands of users.
In both cases, the attack surface was not the physical asset, but the software and systems that connect and control it.
What is software sovereignty?
Given the impact of the software supply chain on critical U.S. infrastructure, the country should define software sovereignty requirements. Software sovereignty consists of four basic pillars:
- Location: The code is written on US-controlled infrastructure.
- Control: The code runs on servers owned and operated by the government and its contractors.
- Toolchain integrity: Compilers, dependencies and build systems come from the USA and are verifiable.
- Insulation: There is no reliance on external Software-as-a-Service (SaaS) or cloud services that a foreign adversary could access through legal processes, cyberattacks or supplier relationships.
Without this capability, a contractor engineer can transmit code to a Marine combat system from a laptop and synchronize it with a commercial cloud build server in a foreign region, with no enforceable sovereign boundary in between.
A closer look at software sovereignty in practice
Congress last year introduced the Shipbuilding and Harbor Infrastructure for Prosperity and Security (SHIPS) for America Act of 2025, an effort to put 250 new American-built ships on the water over the next decade.
While the Ships Act sets restrictions on where ships can be built, by whom and using what parts, it does not set requirements for where the software that runs these ships is developed.
A modern destroyer is a software platform that floats randomly. From combat management systems in Navy destroyers to autonomy software in unmanned surface vessels to AI-powered maintenance platforms deployed across the fleet, software is central to the operations of these ships.
]]>
However, development of this software may occur on commercial cloud and development infrastructures that operate outside of direct government control or rely on globally distributed, multi-tenant systems without enforceable sovereignty guarantees.
The legislation defines sovereignty in terms that the maritime industry understands – shipyards, labor and materials – but not in terms that apply to software development.
There are clear political precedents
Expanding software sovereignty standards would not be an entirely new direction for U.S. policy regarding the cybersecurity of government programs.
In 2021, the White House issued an executive order to “Improve the Nation’s Cybersecurity,” establishing standards for secure software development among federal agencies and vendors. It strengthened the security of the software supply chain through requirements for secure development practices, information sharing and the introduction of multi-factor authentication and encryption.
Other frameworks reinforce this approach. The Department of Defense’s Cybersecurity Maturity Model Certification (CMMC) sets security standards for defense contractors, while FedRAMP defines security criteria for cloud service providers serving the government.
However, existing federal security frameworks secure data and systems in place. They do not define or enforce where software development environments must reside or who controls them.
If this administration wants to advance “America first” manufacturing, it should advance the same in software development practices. Defense systems, critical infrastructure and industrial operations are only as secure as the systems they operate. Without addressing where and how these systems are developed, the US risks leaving a critical vulnerability unaddressed.
The Trump administration has also begun rolling back cybersecurity requirements. Former President Joe Biden, in his final days in office, built on his original cybersecurity executive order with a new executive order that added new requirements. Last summer, President Donald Trump changed it, removing the software certification requirement and the requirement for agencies to conduct digital identity work. The changes shift responsibility for cybersecurity to providers rather than being enforced at the federal level.
While the Trump administration may roll back regulations to improve cybersecurity, there doesn’t have to be a trade-off between speed, innovation and security. Sovereign development environments can continue to support artificial intelligence-assisted development and modern engineering workflows. In many cases, we have found that governance at the infrastructure layer improves consistency and scalability.
]]>
The transition is already underway
Today, most federal programs are still developed on a patchwork of local laptops, virtual desktop interfaces (VDI), and isolated virtual machines (VMs). These setups meet basic security, but fragment workflows, slow down onboarding, and make enforcing consistent control nearly impossible.
The trend is toward self-hosted, centrally managed cloud development environments that run within government infrastructure across unclassified, classified, and air-gapped networks. The same workspace standard, audit trail and toolchain are carried with the developer and not with the laptop.
By only allowing developers to work in centrally managed development environments, agencies can more easily enforce security policies, monitor activity, and ensure compliance with federal cybersecurity standards.
Not only are these environments more secure, but they also allow developers greater flexibility, allowing them to work on any infrastructure, operating system, or development stack, rather than being forced into a specific setup. This allows them to respond more quickly to new requirements, new technologies and changing security landscapes.
Stronger requirements for software sovereignty would not invent anything new. They would codify what the most progressive agencies are already doing. Without it, the US is building an infrastructure that an adversary can already reach.
Amanda Phelps is a strategic advisor for allied defense and intelligence at Coder.
https://federalnewsnetwork.com/commentary/2026/07/the-case-for-an-america-first-software-supply-chain/
