DOD has reported that countries hostile to the United States are focusing  resources on developing information warfare strategies. DOD  information system security requirements focus on operational software  threats, rather than potential threats posed by software developers. While  recent DOD initiatives could increase DOD’s focus on software security,  efforts to date have not translated into greater knowledge for program  managers about foreign software development activities. DOD Acquisition Policy Allows Discretion in Managing Foreign Software Suppliers

DOD acquisition policy allows program managers discretion in managing  foreign suppliers used for software development. These procedures are intended to mitigate  system vulnerabilities from operational threats, such as external hacking  and unauthorized access to information systems. However, they do not  apply to internal threats that could affect the integrity of the software,  such as the insertion of malicious code during software development. Program Officials Generally Did Not Manage Risks from Foreign-Developed Software

While DOD initiatives have begun to recognize potential risks from foreign  software suppliers, this is not always the case within the weapon programs  where software is developed or acquired. Program officials for most of the  systems we reviewed did not make foreign involvement in software  development a specific element of their risk identification and mitigation  efforts. As a result, program officials’ knowledge of the foreign-developed  software included in their weapon systems varied. In addition, risk  mitigation efforts emphasized program level risks, such as meeting  program cost and schedule goals, instead of software security risks. Further, program managers often delegated risk mitigation and source  selection to their prime contractors who tended to be concerned with  software functionality and quality assurance, rather than specifically  addressing software development risks associated with foreign suppliers. For 11 of the 16 systems,  program managers have not identified foreign supplier involvement in  software development as a significant risk to the security of their weapon  systems. As the amount of software on weapon systems increases,  it becomes more difficult and costly to test every line of code. Further,  DOD cannot afford to monitor all worldwide software development  facilities or provide clearances for all potential software developers,  especially for COTS software. Unless  this is done early in the software acquisition process, it cannot be included  as part of software source selection and risk mitigation decisions and  could result in increased cost and less effective security measures if risks  have to be addressed later in the acquisition process. Appendix I: Scope and Methodology

To determine how the Department of Defense (DOD) measures the extent  of foreign involvement in software development in weapon systems and  how risks associated with using foreign suppliers for software  development are measured and mitigated, we reviewed relevant DOD  guidance, policies, regulations, and procedures.
Why GAO Did This Study

The Department of Defense (DOD) is increasingly reliant on software and information systems for its weapon capabilities, and DOD prime contractors are subcontracting more of their software development. The increased reliance on software and a greater number of suppliers results in more opportunities to exploit vulnerabilities in defense software. In addition, DOD has reported that countries hostile to the United States are focusing resources on information warfare strategies. Therefore, software security, including the need for protection of software code from malicious activity, is an area of concern for many DOD programs. GAO was asked to examine DOD's efforts to (1) identify software development suppliers and (2) manage risks related to foreign involvement in software development on weapon systems.

What GAO Found

DOD acquisition and software security policies do not fully address the risk of using foreign suppliers to develop weapon system software. The current acquisition guidance allows program officials discretion in managing foreign involvement in software development, without requiring them to identify and mitigate such risks. Moreover, other policies intended to mitigate information system vulnerabilities focus mostly on operational software security threats, such as external hacking and unauthorized access to information systems, but not on insider threats, such as the insertion of malicious code by software developers. Recent DOD initiatives may provide greater focus on these risks, but to date have not been adopted as practice within DOD. While DOD has begun to recognize potential risks from foreign software content, this is not always the case within the weapon programs where software is developed or acquired. Program officials for the systems in this review did not make foreign involvement in software development a specific element of their risk identification and mitigation efforts. As a result, program officials' knowledge of the foreign developed software included in their weapon systems varied. In addition, risk mitigation efforts emphasized program level risks, such as meeting program cost and schedule goals, instead of software security risks. Further, program officials often delegated risk mitigation and source selection to contractors who are primarily concerned with software functionality and quality assurance, rather than specifically addressing software security for development risks associated with foreign suppliers. Unless program officials provide specific guidance, contractors may favor business considerations over potential software development security risks associated with using foreign suppliers. As the amount of software on weapon systems increases, it becomes more difficult and costly to test every line of code. Further, DOD cannot afford to monitor all worldwide software development facilities or provide clearances for all potential software developers. Therefore, the program manager must know more about who is developing software and where early in the software acquisition process, so that it can be included as part of software source selection and risk mitigation decisions.