As a technology advocate, I’ve spent the last 12 years delivering solutions to address some of the most pressing challenges for the Department of Defense and Federal Civilian organizations.  Over the last 3 years, I’ve been critically focused on helping the Army and Navy combat evolving threats from adversaries in our technology supply chains. This blog discusses cybersecurity risks to our supply chain and how Software Bills of Materials (SBOMs) should be leveraged to mitigate persistent and hidden vulnerabilities in our Defense and National Security Systems software.  This blog post is part 1 of a series examining SBOMs for National Security.   

The Software Supply Chain Problem 

In 2024, the Department of Defense (DoD) requested $58.4 billion to cover its information technology (IT) and cyberspace activities (IT/CA).  The multi-billion-dollar figure may promote questionable feelings amongst American taxpayers; however, we may not know the full extent to which our Defense and National Security depend on this technology budget. Even more, most of this IT budget is used to sustain enterprise software systems which provide critical business functions in the areas of logistics, finance, contracting, health care, and human capital in addition to critical weapons platforms, global telecommunications, command and control (C2), and national security systems.  In recent years, the exponential rate of software adoption aligned to future DoD strategic plans, coupled with a 1300% increase in software supply chain threats, has created pause amongst DoD leadership; many realizing the need to look backward and understand what exactly is in the software running our largest and most critical Defense weapons platforms and enterprise IT systems.    

Ironically, the same adversaries the DoD encounters globally also produce software components underpinning the defense systems intended to defeat them.  There have been several examples of adversaries covertly inserting themselves into software even though the ‘standard’ vetting and government regulatory checks were completed.  In 2022, Pushwoosh was discovered as a Russian-rooted technology company embedded in nearly 8,000 smartphone applications across Apple and Google online stores.  The embedded Pushwoosh code, which collects user data including precise geolocation, was discovered in applications being used by the US Army, Centers for Disease Control and Prevention (CDC), The National Rifle Association (NRA), Union of European Football Associations (UEFA) and Britain’s Labour Party, to name a few. 

It Only Takes One: Vulnerabilities at Scale  

Globally exploiting a single software vulnerability has proven to be another attack vector of our adversaries.  Some examples of scalable exploitations include the Voice over IP vendor hack, 3CX, and the attacks on Progress Software’s MOVEit managed file transfer application.  The MOVEit attacks were carried out by the Clop cybercriminal group, affecting 62 million people worldwide.  In addition to 3rd party code, open-source software presents its own set of threats in the software supply chain, particularly for obsolete components still being used by the DoD. 

One more recent example was action taken by the DoD to ban the use of DJI drones due to the American Security Drone Act, which was passed as part of the National Defense Authorization Act of 2023. The Fortress analysis of the DJI Mini 2 drone SBOMs uncovered the drone’s ability to record audio, track phone status, and download files without notifying the user while maintaining connectivity to Chinese data-sharing servers and internet protocols (IPs).  While DJI refutes the ban and its alleged ties to Chinese state-controlled entities, I would propose DJI clarify its business activities with China Chengtong Holdings Group and Shanghai Venture Capital Guidance Fund.  In reality, the DoD cannot ban every technology with ties to China, but the power of SBOMs will allow agencies to partition and minimize risks in software, regardless of who contributed the code. 

Unfortunately, the growing number of vulnerabilities are not being discovered by government software resellers or the original equipment manufacturers (OEMs) before they’re exploited. So, what is the government supposed to do? The answer begins with discovering the power of Software Bills of Materials (SBOMs) and ends with putting SBOMs to work for a scaled proactive software supply chain defense.  

SBOMs: The Critical Piece of our National Cybersecurity  

Many government agencies are beginning to realize the value of using SBOMs within their cybersecurity programs.  In August this year, the Assistant Secretary of the Army (Acquisition, Logistics, and Technology) released a new policy requiring commercial off-the-shelf vendors to produce and include SBOMs with any new contracting actions; “This policy applies to current and future programs planning to, or currently, executing on the Software Acquisition Pathway, Urgent Capability Acquisition, Middle Tier of Acquisition, Major Capability Acquisition, and Defense Business Systems.”   

Several preceding policies inspired this new Army SBOM policy:   

  • Army Directive 2023-16  (Supply Chain Risk Management for Weapon Systems) states that the original equipment manufacturers implement Supply Chain Risk Management (SCRM) during development and production, and the Government has a shared responsibility to manage that risk. Software is a component of SCRM risk, and SCRM is to be conducted on systems throughout their lifecycle.  
  • Army Directive 2024-02  (Enabling Modern Software Development and Acquisition Practices) emphasizes the Army’s reliance on software, the importance of understanding the risks systems can introduce to a network, and how to mitigate those risks to the greatest extent possible.  

The new Army SBOM policy requires Program Executive Offices (PEO) and Program Managers (PM) to:  

  • Incorporate contract language requiring vendors to generate and deliver SBOMs for all covered computer software and SBOMs for COTS software 
  • Securely store and manage SBOMs in a PEO or PM-defined location 
  • Monitor SBOMs throughout their portfolio and utilize them for vulnerability, incident management, and supply chain risk management in accordance with the SBOM Management and Implementation Guide 

By February 2025, Army PEOs/PMs shall:  

  • Be required to codify their processes for the collection, storage, management, and continuous monitoring of SBOMs in accordance with the ASA(ALT) SBOM Management and Implementation Guide   
  • Codify their risk and incident management processes and procedures for risks and vulnerabilities uncovered through continuous monitoring of SBOMs in accordance with the ASA(ALT) SBOM Management and Implementation Guide 
  • Collect and analyze SBOMs from covered computer software per ASA(ALT) SBOM Management and Implementation Guide 
  • Perform SBOM collection, storage, management, and continuous monitoring of SBOMs in accordance with their codified processes 

While the policies around SCRM and SBOMs encourage us to improve our security posture, the Army has yet to provide any guidance on how Army programs will budget for analyzing the SBOMs submitted or monitoring their components for vulnerabilities.  To highlight a few benefits the Army should expect to gain from leveraging SBOMs, read my next blog post, “Part 2: SBOM Use Cases for Critical Military Programs and National Security Systems,” which explains several use cases across multiple U.S. Army programs and platforms. 

Silent Threat-1