After years of offshoring manufacturing, there’s been a renewed interest in bringing manufacturing back to the United States. That interest has largely focused on the physical supply chain, not the software supply chain, and that’s a concern for the reliability and security of the software systems government agencies rely on.
The software supply chain is often a more immediate and less visible vulnerability than the physical supply chain, where components can be physically inspected and validated. Without placing the same importance on where software is developed as we are on where physical parts are being produced, we’re not truly living up to the goals of this “America first” initiative and are exposing our critical infrastructure to unnecessary risks.
The software supply chain is already a target
The risks of not having a solid strategy to ensure software sovereignty are significant, including the loss of operational control or the introduction of backdoored systems in critical infrastructure. For military vessels, that could mean a heightened risk of a denial-of-service attack at a critical moment or of adversary persistence within fleet systems.
Since 2021, the China-linked Volt Typhoon group has gained access to networks associated with critical U.S. infrastructure across communications, energy, transportation and water and wastewater systems. These operations are believed to be pre-positioning to create disruption during future conflict scenarios.
Similarly, just before Russia’s invasion of Ukraine, Russian attackers targeted Viasat, the satellite communications system used by Ukraine, disrupting military communications and connectivity for thousands of users.
In both cases, the attack surface wasn’t the physical asset, but the software and systems that connect and control it.
What is software sovereignty?
Given the software supply chain’s impact on critical U.S. infrastructure, the country ought to define software sovereignty requirements. Software sovereignty consists of four core pillars:
- Location: Code is written on U.S.-controlled infrastructure.
- Control: Code runs on servers owned and operated by the government and its contractors.
- Toolchain integrity: Compilers, dependencies and build systems are U.S.-sourced and auditable.
- Isolation: There is no dependency on external software-as-a-service (SaaS) or cloud services that a foreign adversary could access through legal processes, cyberattacks or vendor relationships.
Without this in place, a contractor engineer can push code to a Navy combat system from a laptop syncing to 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 get 250 new American-built ships in the water over the next decade.
While the SHIPS Act puts restrictions on where the ships can be built, by who and using what parts, it doesn’t lay out any requirements for where the software running those ships is developed.
A modern destroyer is a software platform that happens to float. From combat management systems in Navy destroyers, to autonomy software in unmanned surface vessels, to AI-assisted maintenance platforms that are deployed across the fleet, software is central to how these ships operate.
Yet the development of that software can take place on commercial cloud and development infrastructure that may operate outside 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.
Clear policy precedent exists
Extending sovereignty standards for software would not be an entirely new direction for U.S. policy regarding cybersecurity for government programs.
In 2021, the White House issued an executive order on “Improving the Nation’s Cybersecurity,” establishing standards for secure software development across federal agencies and vendors. It strengthened software supply chain security through requirements for secure development practices, information sharing and the adoption of multi-factor authentication and encryption.
Other frameworks reinforce this approach. The Defense Department’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 deployed systems. They do not define or enforce where software development environments must reside or who controls them.
If this administration wants to push for “America first” for manufacturing, it should also push for it in software development practices. Defense systems, critical infrastructure, and industrial operations are only as secure as the systems that operate them. Without addressing where and how those systems are developed, the U.S. 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 amended it, removing the requirement for software attestation and the requirement for agencies to conduct digital identity work. The changes shift the responsibility for cybersecurity onto vendors rather than it being enforced at the federal level.
While the Trump administration might be pulling back regulations that improve cybersecurity, there doesn’t need to be a trade-off between speed, innovation and safety. Sovereign development environments can still support artificial intelligence-assisted development and modern engineering workflows. In many cases, we’ve seen governance at the infrastructure layer improving consistency and scalability.
The transition is already underway
Today, most federal programs still develop on a patchwork of local laptops, virtual desktop interfaces (VDI) and isolated virtual machines (VMs). These setups meet baseline security but fragment workflows, slow onboarding and make consistent control nearly impossible to enforce.
The shift underway is toward self-hosted, centrally managed cloud development environments that run inside agency infrastructure, across unclassified, classified and air-gapped networks. The same workspace standard, audit trail and toolchain travels with the developer instead of the laptop.
By only allowing developers to work in development environments that are centrally managed, agencies are able to more easily enforce security policies, monitor activity and maintain compliance with federal cybersecurity standards.
In addition to being safer, these environments also enable greater flexibility for developers because they can work across 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, emerging technologies and changing security landscapes.
Stronger software sovereignty requirements would not invent something new. They would codify what the most forward-leaning agencies are already doing. Without them, the U.S. is building infrastructure an adversary can already reach.
Amanda Phelps is a strategic advisor of allied defense and intelligence at Coder.
Copyright
© 2026 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.
