Key Takeaways
- Renewed U.S. efforts to reshore manufacturing focus almost exclusively on the physical supply chain, leaving the software supply chain inadequately addressed.
- The software supply chain is a stealthy, high‑impact vulnerability; adversaries such as China’s Volt Typhoon and Russia’s Viasat attacks demonstrate how compromising software can cripple critical infrastructure.
- Software sovereignty—ensuring code is written, built, and run on U.S.-controlled infrastructure with auditable toolchains and no foreign‑dependent SaaS—offers a concrete framework to close this gap.
- Current legislation like the SHIPS Act of 2025 sets strict rules for shipbuilding but contains no comparable mandates for the software that powers those vessels.
- Existing federal cybersecurity policies (EO 2021, CMMC, FedRAMP) improve security of data and deployed systems but do not govern where or how software is developed.
- Recent rollbacks of cybersecurity requirements under the Trump administration shift responsibility to vendors, potentially weakening oversight.
- Forward‑looking agencies are already adopting self‑hosted, centrally managed cloud development environments that provide consistent security, auditability, and flexibility; codifying these practices as software‑sovereignty standards would extend best practices government‑wide.
Introduction: Renewed Interest in Domestic Manufacturing Overlooks Software
After years of offshoring production, policymakers and industry leaders have revived a “America first” push to bring manufacturing back to the United States. The focus of this resurgence has been squarely on the physical supply chain—factories, labor, raw materials, and component sourcing—while the software that runs those systems receives far less attention. This imbalance creates a critical blind spot: even if every bolt and plate is made domestically, the code that controls combat systems, navigation, and logistics may still be developed, built, or executed on foreign‑controlled infrastructure, exposing national security assets to unnecessary risk.
Why the Software Supply Chain Is a Pressing Threat
Unlike physical parts, software cannot be inspected with a caliper or X‑ray; its integrity depends on trust in the development environment, build tools, and deployment pipelines. When those elements reside outside U.S. sovereign control, adversaries can inject backdoors, compromise dependencies, or hijack build servers without ever touching a piece of hardware. The software supply chain therefore represents an immediate, less visible, but potentially far more damaging vector for attacks on critical infrastructure.
Real‑World Illustrations: Volt Typhoon and Viasat Attacks
Since 2021, the China‑linked Volt Typhoon group has infiltrated networks tied to U.S. communications, energy, transportation, and water‑wastewater systems. Their activity is believed to be pre‑positioning for disruptive effects during a future conflict, targeting the software that orchestrates those services rather than the physical assets themselves. Similarly, just before Russia’s invasion of Ukraine, attackers compromised Viasat, the satellite communications provider used by Ukrainian forces, degrading military connectivity for thousands of users. In both cases, the point of entry was software and the systems that manage it, underscoring how a breach in the software supply chain can translate directly into operational paralysis.
Defining Software Sovereignty: Four Core Pillars
To mitigate these risks, the United States should adopt a clear software sovereignty framework built on four pillars:
- Location – Source code must be written on infrastructure under U.S. jurisdiction.
- Control – The compiled binaries should run only on servers owned and operated by the government or its authorized contractors.
- Toolchain Integrity – Compilers, libraries, build scripts, and continuous‑integration/continuous‑deployment (CI/CD) pipelines must be sourced from U.S. providers and be fully auditable.
- Isolation – Development and deployment environments must not rely on external SaaS or cloud services that a foreign government could access via legal process, cyber‑intrusion, or vendor relationships.
When any of these pillars is missing, a contractor engineer could, for example, push an update to a Navy combat system from a laptop that syncs to a commercial cloud build server hosted overseas, with no enforceable sovereign barrier separating the code from potential foreign interference.
Legislative Gaps: The SHIPS Act Ignores Software
Congress’s Shipbuilding and Harbor Infrastructure for Prosperity and Security (SHIPS) Act of 2025 aims to deliver 250 new American‑built ships over the next decade, imposing strict rules on where hulls are assembled, who builds them, and what materials are used. Yet the act contains no analogous requirements for the software that governs those vessels. Modern destroyers are essentially software platforms that happen to float; their combat management systems, autonomy algorithms for unmanned surface vessels, and AI‑driven maintenance tools are all code‑driven. Without sovereignty standards for this software, the SHIPS Act secures the hull while leaving the brain of the ship vulnerable to external manipulation.
Existing Federal Policies Offer Guidance but Fall Short
The U.S. government already possesses several cybersecurity frameworks that touch on software security. Executive Order 14028 (2021) mandated secure development practices, provenance tracking, and multi‑factor authentication for federal agencies and contractors. The Defense Department’s Cybersecurity Maturity Model Certification (CMMC) imposes security benchmarks on defense industrial base partners, while FedRAMP sets baseline standards for cloud service providers handling government data. These initiatives strengthen the protection of data and deployed systems but do not dictate where the software itself must be created, built, or validated. Consequently, they leave a critical gap: the ability to enforce that development environments remain under U.S. control.
Policy Shifts Under the Trump Administration
In a further complication, the Trump administration has begun rolling back certain cybersecurity safeguards instituted by its predecessor. Amendments to the 2021 executive order removed requirements for software attestation and for agencies to conduct digital identity work, shifting more responsibility onto vendors rather than maintaining federal oversight. While proponents argue that reducing regulatory burden can spur speed and innovation, the change risks weakening the very controls needed to guarantee software sovereignty, especially when vendors may opt for cheaper, globally distributed development pipelines that lack enforceable U.S. safeguards.
The Emerging Shift: Self‑Hosted, Centrally Managed Development Environments
Despite the policy uncertainty, many forward‑looking federal agencies are already moving toward a model that aligns with software‑sovereignty principles. Rather than relying on a patchwork of personal laptops, virtual desktop interfaces (VDIs), and isolated virtual machines (VMs)—which fragment workflows and hinder consistent enforcement—agencies are adopting self‑hosted, centrally managed cloud development environments. These platforms run inside agency‑controlled networks, spanning unclassified, classified, and air‑gapped zones, and provide a uniform workspace, immutable audit trails, and vetted toolchains that travel with the developer regardless of the endpoint device.
Such environments deliver multiple benefits: they simplify the enforcement of security policies, enable real‑time monitoring of activity, and ensure compliance with federal standards like CMMC and FedRAMP. At the same time, they grant developers greater flexibility to work across any operating system, infrastructure, or development stack, allowing rapid adaptation to new requirements, emerging technologies, or evolving threat landscapes. In effect, they codify best practices that the most advanced agencies have already proven effective.
Conclusion: Aligning Software Policy with the “America First” Goal
If the United States truly wishes to realize an “America first” strategy for critical infrastructure, it must extend that principle to the software that animates those assets. Software sovereignty offers a concrete, actionable framework—grounded in location, control, toolchain integrity, and isolation—to close the supply‑chain gap that currently leaves defense systems, energy grids, transportation networks, and other vital services exposed. By building on existing cybersecurity guidance, closing the legislative omissions seen in acts like SHIPS, and resisting rollbacks that dilute federal oversight, the nation can secure not only the steel and silicon of its platforms but also the code that makes them operate. The transition toward centrally managed, sovereign development environments is already underway; formalizing these practices as national policy will ensure that the software powering America’s future is as trustworthy and resilient as the hardware it controls.
Amanda Phelps is a strategic advisor of allied defense and intelligence at Coder.
Copyright © 2026 Federal News Network. All rights reserved.