When Anthropic announced in April 2026 a limited preview of its Claude Mythos model capable of finding and exploiting vulnerabilities at scale, government and industry immediately focused on what it could mean for cybersecurity. Mythos Preview can reportedly find and author vulnerability exploits in hours that would have previously taken weeks. The White House even viewed the capability as significant enough to re-examine aspects of its current approach to artificial intelligence oversight.
But the growing focus on AI-driven vulnerability detection risks obscuring another category of threat hidden deeper within modern software ecosystems and their supply chains. Risks facing national security systems arise not only from software code vulnerabilities, but from governance structures and strategic dependencies embedded within the larger software ecosystems. This gap creates a strategic blind spot: modern defense technologies may rely on software ecosystems whose control, influence, or development pathways lie outside the visibility of traditional supply chain risk frameworks.
As the next generation of defense and weapons programs come online infused with AI capabilities, defense officials should scrutinize software supply chains supporting mission-critical defense systems with the same mindset as they do physical supply chains. Software ecosystems built upon open-source dependencies should be evaluated for geopolitical risk and subjected to risk-tiered governance reviews within the defense acquisition process. This more expansive strategic software assurance review would evaluate strategic risk stemming from things like maintainer authority, dependency governance, repository control, and indicators of foreign ownership, control, or influence. Critical defense technology software supply chains should be treated as strategic infrastructure.
Fortunately, adopting a more strategic view to shielding software supply chains from risk does not require new legislation or regulation. There are already regulatory regimes in place; the necessary step towards realizing the full spirit of those regimes is improving due diligence in reviewing critical defense software supply chains. These reviews should be scoped and only performed on the most critical systems, taking advantage of existing expert personnel in the acquisition program offices, supported by the contractors’ security, compliance, and product teams.
Strategic Risk in Software Supply Chains and the Limits of Disclosure
The 2020 SolarWinds compromise demonstrated how software supply chain attacks can result in more severe national security consequences than traditional cybersecurity incidents. By compromising a trusted software update mechanism, attackers gained simultaneous access to numerous government and private-sector systems. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) ultimately attributed the activity to the Russian Foreign Intelligence Service. The incident was one of the most widespread and sophisticated hacking campaigns ever conducted against the federal government.
The SolarWinds attack involved foreign adversaries covertly compromising a trusted software ecosystem. But future risks may not involve covert compromises at all. Adversarial influence or control may emerge through seemingly legitimate participation, governance authority, or long-term stewardship within critical software projects, as demonstrated by the XZ Utils compromise, where a malicious backdoor was inserted into software present in most Linux distributions. Defense acquisition officials should therefore examine software ecosystems through a strategic lens that exposes governance, dependency structures, and influence.
Identifying and disclosing software supply chain risk is critical to mitigation efforts, yet current disclosure and compliance frameworks may only be capturing part of the risk. Discussions of geopolitical supply chain risk have traditionally centered on physical technologies such as semiconductors, telecommunications infrastructure, and critical manufacturing dependencies, while software ecosystems often remain comparatively invisible within broader strategic risk discussions. Open-source software ecosystems remain a persistent challenge within broader supply chain and geopolitical risk discussions.
Companies frequently disclose risks such as export controls affecting technology products, political instability in regions where suppliers operate, or trade tensions that could have direct applications to industries in the defense, telecommunications, or the semiconductors space. For example, U.S. semiconductor export controls targeting advanced AI chips and semiconductor manufacturing equipment have been discussed as a source of supply chain disruption and geopolitical risk for technology firms dependent on global semiconductor markets.
Corporate disclosures for publicly traded companies do increasingly acknowledge risks arising from reliance on software components. However, such disclosures typically focus on the potential for adversary exploitation of technically vulnerable software or systems rather than governance dynamics. For instance, they do not typically discuss whether key open-source maintainers operate under the legal jurisdiction of a foreign government, whether a critical software dependency is disproportionately controlled by contributors in an adversarial nation, or whether a vendor’s ownership structure exposes supply chain decision to foreign state influence. For example, Palantir Technologies disclosed that vulnerabilities in open-source dependencies may expose its systems to cybersecurity risk. However, such disclosures that acknowledge security vulnerabilities frame them primarily as cybersecurity risks and typically overlook geopolitical risk emanating from complex software ecosystems. Major defense-adjacent artificial intelligence firms are not ignoring software risk, but existing disclosure and software assurance frameworks may not be designed to surface governance-related risks. Given the purpose of filing requirements, one could argue that large, cleared defense contractors, especially those that support critical defense systems, should also be identifying and disclosing strategic risks associated with open-source software ecosystems.
Spotting Geopolitical Risk in Software Supply Chains
Modern defense and dual-use technologies increasingly depend on layered software ecosystems assembled from globally distributed open-source components. Consider an autonomous drone system used for surveillance or targeting operations. Visual data captured by onboard sensors or cameras may first pass through open-source computer vision libraries such as OpenCV before being analyzed by machine-learning frameworks. Those frameworks, in turn, rely on hundreds of upstream software dependencies maintained by globally distributed authors and contributors.
As one of the most popular and widely deployed computer vision libraries in the world, OpenCV is used in the production systems of major companies and embedded in autonomous robotics systems, vehicles, and drones. This type of computer vision software is increasingly employed on the battlefield in Ukraine for target recognition and drone guidance. A governance shift or compromise affecting even one trusted upstream component can therefore propagate through an entire ecosystem of downstream technologies. As a result, software used in critical systems may ultimately depend on layers of code developed, maintained, or governed far outside the visibility of the organizations deploying them.
In 2025, a software supply chain vulnerability was discovered in the widely used Go programming library easyjson that drew scrutiny due to its association with engineers from the Russian technology company VK. The package was hosted on GitHub by a MailRu account, which is owned by VK, and the VK CEO was sanctioned in 2022 by the U.S. Treasury following the Russian invasion of Ukraine, due to being or having been a leader or official of the Government of Russia, amongst other reasons. Build-pipeline visibility and automated governance analysis could plausibly have surfaced the library for deeper review based on ecosystem reach and contributor affiliation references. Although no malicious functionality was identified, the case showed how software provenance and governance relationships may create strategic concerns that are not visible through traditional technical analysis.
Both these pieces of software are published and maintained on repository websites like GitHub where contributors can collaborate and track software versions. Industry and government will sometimes borrow these base project versions, tailor the software for their specific needs, and introduce it for use in internal projects, essentially dragging an entire software dependency structure with it.
Should foundational packages such as OpenCV support mission-critical autonomous or missile-defense systems, such as Golden Dome, this could create systemic downstream risk. Assessing strategic risk and compliance associated with this code would not require entirely new rooms of experts; instead, it is possible to leverage existing teams with a clear understanding of where to look to find possible risk indicators or signals. This is why reviewing the code repository and the build pipelines showing all the bits and pieces needed for OpenCV to function would be essential, with one of the benefits being the exposure of transient dependencies.
We Have Authority, We Just Need to Apply It to Software
Defense acquisition policy in the United States has increasingly recognized supply chain risk through legislative and regulatory frameworks such as the National Defense Authorization Act (see Title VIII, Subtitle H—Other Matters) and Defense Federal Acquisition Regulation Supplement (see Section 252.239-7018 Supply Chain Risk). The latter’s supply chain provisions allow the Pentagon to restrict the use of technologies that may present national security risks. The fact of possible foreign ownership, control, or influence is relevant for determining national security risk under current regulatory regimes, according to section 889 and 1260H logic under the National Defense Authorization Act.
Existing procurement restrictions targeting Huawei and ZTE and other Chinese corporations under section 889 demonstrate that the United States government already views foreign control over critical technology infrastructure as a national security concern. That same logic ought to be applied under the NDAA when evaluating software acquisitions writ large, with explicit consideration of the potential national security risks raised by foreign ownership, control, or influence in potential software acquisitions. It is also worth noting that recent Trump administration actions involving outbound investment restrictions, expanded Committee on Foreign Investment in the United States scrutiny, and supply chain security initiatives demonstrate an increasing willingness to evaluate foreign associations, strategic dependencies, and adversarial influence within critical technology supply chains. An understanding of who was involved in a particular code’s lifecycle requires extending supply chain analysis beyond traditional vendor relationships, to include governance and provenance signals. Reviewers ought to take this closely into account when conducting the strategic software review that I recommend below, relying on the NDAA national security risk-related provisions that already exist.
The Limits of Software Bill of Materials
Organizations and governments, to include the United States and the European Union, have increasingly mandated the use of software bill of materials as a means for ensuring the most surface-level enumeration of components and provide some level of improved accountability in software environments. This adoption greatly accelerated following the SolarWinds compromise, signaling a recognition across industry actors of the need for such measures. The accelerated adoption also reflects the fact that there are no statutory requirements in the United States for inclusion of contributor provenance, governance changes, or foreign influence within projects. Furthermore, a recent U.S. executive order and memorandum take the software bill of materials requirement from mandatory to optional, with the administration opting for a less burdensome risk-based approach. Therefore, while a software bill of materials is a good starting point for analysis, it cannot be the end.
This creates a structural weakness in which governance-related supply chain risks may remain unnoticed by compliance frameworks until after a compromise is discovered, as illustrated by the XZ backdoor. A backdoor (a covert method used to bypass legitimate access to a system) had been intentionally planted in XZ Utils, an open-source data compression utility available for years in Linux installations. Furthermore, the backdoor in XZ Utils was not detected by automated security tools; the compromise was only discovered in 2024 when a human investigator noticed unusual and suspicious computer system behavior, such as the consuming of an abnormally high amount of CPU resources. Examining the source code for insecure coding patterns and vulnerability would not have yielded results from static application security testing. The backdoor introduced into XZ Utils was inserted by a contributor who had gradually obtained maintainer privileges over a three-year period. This was a supply chain attack that weaponized governance. The malicious logic existed within a legitimate component that would appear normal in a code repository’s software bill of materials. The XZ incident demonstrated how governance dynamics within open-source projects can create systemic risk.
Improving Visibility Without Losing Focus
Modern defense systems depend on globally-developed software ecosystems, making complete government control over software supply chains neither operationally feasible nor strategically advantageous. Resource constraints and the pace of software innovation therefore require a realistic approach to the time and effort needed to conduct strategic software assurance reviews. Reviews should ideally improve visibility into strategic dependencies without imposing unworkable acquisition burdens. Software acquisition must continue to outpace adversaries and not interfere with the need to rapidly tackle the strategic challenges. The purpose of strategic software assurance reviews is not to discourage open-source adoption or fragment globally-developed software ecosystems, but to improve visibility into governance structures and dependencies that may create elevated risk in mission-critical systems.
In this context, defense acquisition officials should conduct high-level strategic software reviews for only critical technologies—particularly systems involving AI, autonomous platforms, and sensitive national security infrastructure. Existing cybersecurity and bill of materials-based transparency frameworks remain valuable for vulnerability management and component visibility, but they provide limited insight. Reviews should be tiered where the government program offices identify their “crown jewels” for protection and determine the criticality of a system for defense and the essential software components within that system for a higher standard of review. For this scoped effort, defense contractors and technology providers should similarly expand software supply chain reviews beyond traditional vulnerability scanning and software bill of materials compliance.
The necessary regulations and policies are already in place to implement better due diligence. Existing frameworks already require certain contractors to assess cybersecurity and supply chain risk through Defense Federal Acquisition Regulation Supplement, Software Acquisition Pathways, and other combined contractor security obligations. Risk-tiering the reviews by focusing first on the most sensitive programs would best provide for the needed due diligence while avoiding overburdening the system with unrealistic review standards across the board.
What a Strategic Software Review Should Look Like
In practice, a strategic software supply chain review should assess risk across the broader parts of the software ecosystem. Such a review would include the software components inside a system, the places where software is developed and managed, and the systems used to build and deliver software. Practitioners must make use of the inventories of software ingredients from the bill of materials, the information from within source code repositories where the code is maintained, and the software build pipelines—automated processes that test, compile, and distribute software updates.
This modest adjustment in how the ecosystem is reviewed by practitioners will help assess risk far beyond what can be accomplished with current software composition analysis (finding vulnerable components) and static application security testing (finding insecure code). Analyzing these three components would capture not only the direct, but also the transient dependencies of a given software project. Furthermore, each of these components contains unique signaling information and artifacts not contained in the other.
Software build pipelines provide visibility into both direct and transitive dependencies, which assists in the operational feasibility of governance-focused review. The challenge is determining which dependencies warrant deeper inspection. This step is where leveraging both new agentic techniques for open-source intelligence analysis, sanctions listings, corporate registries, and government advisories become useful solutions. By teaming with counterintelligence offices, U.S. acquisition officials and cleared industry officials can review signals gleaned from the three review components to enrich their findings.
Who Conducts It
These scoped reviews should be conducted by the government program office, supported by the relevant contractor’s security, compliance, and product teams. This structure ensures coherence across relevant cybersecurity, legal, and technical offices. These teams should work collaboratively with component-level government counterintelligence offices, such as those within the Department of Defense like the Air Force Office of Special Investigations, if certain systems are designated top-tier and subject to more thorough review. Foundational expertise already exists within contractor cybersecurity, compliance, and software engineering teams responsible for things like the Cybersecurity Maturity Model Program, National Institute of Standards and Technology compliance, and software assurance activities. At times, a more collaborative bridge will need to be built for counterintelligence support. And this support is well within current mandates of U.S. military criminal investigative organizations.
Although this article focuses on U.S. defense acquisition, any governance-focused software assurance framework will inevitably intersect with allied software assurance regimes, including emerging European requirements for software provenance and disclosure. Alignment rather than fragmentation should therefore guide implementation.
Conclusion
AI systems such as Mythos may transform how governments identify software vulnerabilities, but vulnerabilities are only part of the strategic picture. The lessons of XZ, SolarWinds, and easyjson suggest that some of the most consequential risks may not emerge from vulnerable code, but from the software ecosystem through which code is governed, trusted, and delivered. The harder strategic question for defense leaders is thus not simply whether software is secure, but whether the ecosystems producing that software are trusted. Modern military capability increasingly depends on software assembled from globally distributed dependencies, maintainers, and repositories far outside traditional supply chain scrutiny. The United States has already learned to evaluate geopolitical risk in semiconductors, telecommunications infrastructure, and critical manufacturing.
Until policymakers begin evaluating software ecosystems not merely as collections of code, but as strategic infrastructure shaped by governance, influence, and control, geopolitical risk in software supply chains will remain hidden in plain sight.
