The right way to use open source in defense

The Pentagon’s recent decision to terminate Microsoft’s use of China-based engineers to support its cloud systems should shock no one. ProPublica’s investigation simply confirmed what many of us have known for years: foreign engineers had indirect access to some of our most sensitive networks, and the Department of Defense let it happen. Open source software (OSS) powers most of the world’s technology and is an incredible engine for innovation, but it cannot be deployed blindly without vetting and accountability.

This isn’t just about Microsoft, it’s a symptom of a much deeper problem. The U.S. defense community has built a culture of dependency on software ecosystems filled with unvetted foreign contributors. When the very systems that protect our warfighters rely on code touched by engineers in adversarial nations, we are putting national security in jeopardy.

Back in 2020, I raised these concerns directly with Microsoft’s DOD leadership. I was ignored. And now, years later, here we are. Unless we face the hard truth, this will not be the last time we discover adversaries inside our critical infrastructure.

Why OSS needs guardrails

Let me be clear: I am not against open source. In fact, I am a huge proponent of it. OSS is the backbone of modern software and innovation and every major tech company, including my own, relies on it. The issue is how the government uses it.

When open source becomes the backbone of mission-critical defense AI systems without vetting, governance, or understanding of contributor provenance, it stops being an asset and starts being a liability.

Take projects like vLLM, built to run large language models faster, or OpenWebUI, which makes them easier to use. These tools are popular — they speed up AI deployment and lower barriers to experimentation, but they have zero cybersecurity best practices and are also maintained by global communities that include contributors from adversarial nations. Without serious vetting, there is no way to know whether the code is secure or compromised. Yet, despite having dozens of critical vulnerabilities, NIPRGPT was authorized within the Department of Defense despite using those insecure OSS dependencies.

OSS is powerful. But without security, accountability, and support, it’s a ticking time bomb.

The cost of getting it wrong

We are already seeing the problem unfold. Defense programs eager to prove out AI concepts are leaning heavily on open-source foundations. That speed comes at a cost when no one is asking the basic questions: Who wrote this code? What is its cybersecurity state? Who maintains it? What is its bill of materials? What happens when it breaks?

These are not side projects anymore. They are becoming part of the DOD’s AI strategy. And every time we embed OSS without governance, we deepen a dependency on developers we do not know and cannot hold accountable. The U.S. would never install unvetted foreign parts in a fighter jet. Why are we so casual about embedding unvetted foreign code in our most sensitive digital systems?

Artificial intelligence is not just another technology. It is the defining capability of 21st-century warfare and our adversaries know this, which is why they are investing heavily and pushing their contributions into open-source ecosystems the DOD is eager to adopt. If we continue building critical systems on fragile, foreign-influenced code, we are not innovating. We are handing our adversaries the advantage they want.

How COTS gets OSS right

The answer is not banning OSS — that would cripple innovation. The answer is using OSS responsibly. In defense, that means relying on commercial off-the-shelf (COTS) solutions that take the best of open source and layer it with the rigor of enterprise security.

COTS brings what OSS alone cannot. Vendors have strong incentives to harden and test their products because their businesses and reputations depend on it. When vulnerabilities appear, there is clear accountability. Someone owns the problem, and someone is responsible for fixing it. COTS also delivers resilience. Contracts, service-level agreements, and dedicated support teams ensure that mission-critical systems are never left dependent on volunteers scattered across the globe.

COTS is not anti-OSS. It’s OSS done right, backed by security, oversight, and reliability at the level national security demands.

Steps the DOD must take now

The Department of Defense doesn’t need another study. It needs to act. Immediately:

• Audit open-source dependencies. No one can secure what they can’t see. The DOD has to know exactly where OSS is embedded across its systems and what risks those dependencies create.
• Set real vetting standards. Every open-source component should be checked for who is contributing the code, the code security status, and whether there’s foreign involvement that could compromise national security.
• Prioritize COTS for mission-critical systems. COTS solutions can harness OSS, but they also bring the accountability, testing, and hardened security that defense requires.
• Balance speed with sovereignty. Before OSS touches systems that safeguard our national defense, it must be secured. Anything less is negligence.

The stakes are not theoretical. The future of warfare will be decided by AI, and if we keep ignoring the risks, we will lose before the fight even begins.