Report of the 

Defense Science Board Task Force 

on 

Mission Impact of Foreign Influence 

on DoD Software 

September 2007 

Office of the Under Secretary of Defense 

For Acquisition, Technology, and Logistics 

Washington, D.C. 20301-3140
This report is a product of the Defense Science Board (DSB). 

The DSB is a Federal Advisory Committee established to provide independent advice to 

the Secretary of Defense. Statements, opinions, conclusions, and recommendations in this 

report do not necessarily represent the official position of the Department of Defense. 

This DSB Task Force on Mission Impact of Foreign Influence on DoD Software 

completed its information gathering in November 2006. 

This report is UNCLASSIFIED and is RELEASABLE to the public.




DEDICATION 

Theoren P. (Trey) Smith, III 

1954 – 2007 

During the course of this Defense Science Board Task Force our colleague, 

Trey Smith, passed away from a long illness. Although Trey was not able to 

see this final report, his leadership and thoughts pervade it. 

Trey Smith was Chief Technology Officer (CTO) of Science 

Applications International Corporation (SAIC). Before joining 

SAIC in 2002, Trey served in many executive roles at Cable & 

Wireless (C&W), Road Runner, Compaq Computer

Corporation, and IBM. Prior to joining IBM, he conducted 

research at AT&T Bell Laboratories. 

Trey was a graduate of Brown University where he earned a 

Ph.D. in physics. He received a bachelor's in physics from the 

U.S. Naval Academy and served in the U.S. Navy as a nuclear 

engineer and division officer. 

Trey is survived by his wife Kathy, his daughters Kristen, Julia 

and Kimberly, and his son, Theoren. 

 

Mission Impact of Foreign Influence on DoD Software_______________________________i
ii_______________________________________________________DSB Task Force on 
____________________________________________________________Table of Contents

TABLE OF CONTENTS 

Executive Summary............................................................................................................ v 

Introduction......................................................................................................................... 1 

Findings............................................................................................................................... 9 

Structure of the Software Industry.............................................................................. 9 

Talent Base in Software............................................................................................ 10 

Computer Science Education in the U.S. and Abroad.............................................. 11 

The Growing Complexity of Cyberspace ................................................................. 13 

Software in the Department of Defense.................................................................... 16 

The Threat to DoD Software..................................................................................... 21 

The State of Software Assurance in the DoD Today................................................ 30 

Existing DoD Information Assurance Policies to Address Software Vulnerability. 35 

Ongoing Efforts in Software Assurance ................................................................... 36 

Supplier Trustworthiness Considerations................................................................. 39 

Other National Security Acquisition Models............................................................ 40 

Detecting Vulnerabilities.......................................................................................... 40 

Best Practices for Code Development ...................................................................... 45 

Security Response Processes.................................................................................... 47 

Software Assurance in Computer Science Education............................................... 48 

Conclusion ................................................................................................................ 49 

Recommendations............................................................................................................. 51 

DoD Procurement of COTS and Off-Shore Software .............................................. 51 

Increase U.S. Insight into Capabilities and Intentions of Adversaries ..................... 51 

System Engineering and Architecture for Assurance ............................................... 53 

Improve the Quality of DoD Software...................................................................... 55 

Improve Tools and Technologies for Assurance ...................................................... 56 

More Knowledgeable Acquisition of DoD Software................................................ 59 

A Research and Development Program on Assurance is Needed ............................ 65 

The National Agenda for Software Assurance ......................................................... 67 

Appendix........................................................................................................................... 69 

Terms of Reference.................................................................................................. 71 

Task Force Membership .......................................................................................... 73 

Descriptions of Example Software-Intensive Programs in DoD ............................. 75 

Task Force Findings and Recommendations........................................................... 82 

Briefings Presented to the Task Force ..................................................................... 85 

References................................................................................................................ 87 

Abbreviations & Acronyms..................................................................................... 89 

Mission Impact of Foreign Influence on DoD Software______________________________iii
Table of Contents_______________________________________________________________ 

List of Figures 

1. Market Share Changes........................................................................................ 2 

2. Risk vs. Consequence ......................................................................................... 6 

3. Comparison of Degrees Awarded..................................................................... 12 

4. Moore's law as demonstrated by Intel microprocessors. .................................. 13 

5. Software size (MSLOC) increases over time.................................................... 14 

6. Total Web Sites Across All Domains............................................................... 15 

7. IAVM Taskings Issued ..................................................................................... 31 

iv_______________________________________________________DSB Task Force on 
__________________________________________________________Executive Summary

EXECUTIVE SUMMARY

Software has become the central ingredient of the information age, increasing 

productivity, facilitating the storage and transfer of information, and enabling

functionality in almost every realm of human endeavor. However, as it improves 

the Department of Defense’s (DoD) capability, it increases DoDs dependency. 

Each year the Department of Defense depends more on software for its 

administration and for the planning and execution of its missions. This growing 

dependency is a source of weakness exacerbated by the mounting size, complexity 

and interconnectedness of its software programs. It is only a matter of time before 

an adversary exploits this weakness at a critical moment in history. 

The software industry has become increasingly and irrevocably global. Much of 

the code is now written outside the United States (U.S.), some in countries that may 

have interests inimical to those of the United States. The combination of DoDs

profound and growing dependence upon software and the expanding opportunity 

for adversaries to introduce malicious code into this software has led to a growing 

risk to the Nation’s defense. 

A previous report of the Defense Science Board, “High Performance Microchip 

Supply”, discussed a parallel evolution of the microchip industry and its potential 

impact on U.S. defense capabilities. The parallel is not exact because the 

microchip fabrication business requires increasingly large capital formation – a 

considerable barrier to entry by a lesser nation-state. Software development and 

production, by contrast, has a low investment threshold. It requires only talented 

people, who increasingly are found outside the United States. 

The task force on microchip supply identified two areas of risk in the off-shoring of 

fabrication facilities – that the U.S. could be denied access to the supply of chips 

and that there could be malicious modifications in these chips. Because software is

so easily reproduced, the former risk is small. The latter risk of “malware,” 

however, is serious. It is this risk that is discussed at length in this report. 

Software that the Defense Department acquires has been loosely categorized as: 

• Commodity products – referred to as “commercial-off-the-shelf” (COTS) 

software; 

• General software developed by or for the U.S. Government – referred to as 

“Government-off-the-shelf” (GOTS) software; and 

• Custom software – generally created for unique defense applications. 

The U.S. Government is obviously attracted by the first, COTS. It is produced for

and sold in a highly competitive marketplace, and its development costs are 

amortized across a large base of consumers. Its functionality continually expands

in response to competitive market demands. It is, in a word, a bargain, but it is also

Mission Impact of Foreign Influence on DoD Software_____________________________v 
Executive Summary_____________________________________________________________ 

most likely to be produced offshore, and so presents the greater threat of malicious

modification. 

There are two distinct kinds of vulnerabilities in software. The first is the common 

“bug”, an unintentional defect or weakness in the code that opens the door to 

opportunistic exploitation. The Department of Defense shares these vulnerabilities 

with all users. However, certain users are “high value targets”, such as the 

financial sector and the Department of Defense. These high-value targets attract 

the “high-end” attackers. Moreover, the DoD also may be presumed to attract the 

most skilled and best financed attackers—a nation-state adversary or its proxy. 

These high-end attackers will not be content to exploit opportunistic vulnerabilities, 

which might be fixed and therefore unavailable at a critical juncture. Furthermore, 

they may seek to implant vulnerability for later exploitation. It is bad enough that 

this can be done remotely in the inter-networked world, but worse when the

malefactors are in DoDs supply chain and are loyal to and working for an adversary 

nation-state—especially a nation-state that is producing the software that the U.S. 

Government needs. The problem is serious, indeed. Such exploitable 

vulnerabilities may lie undetected until it is too late. 

Unlike previous critical defense technologies which gave the U.S. an edge in the 

past, such as stealth, the strategic defense initiative, or nuclear weaponry, the U.S. 

is protected neither by technological secrets nor a high barrier of economic cost. 

Moreover, the consequences to U.S. defense capabilities could be even more severe 

than realized. Because of the high degree of interconnectedness of defense 

systems, penetration of one application could compromise many others. 

In a perfect world there would be some automated means for detecting malicious 

code. Unfortunately, no such capability exists, and the trend is moving inexorably

further from it as software becomes ever more complex and adversaries more 

skilled. Even if malicious code were discovered in advance, attributing it to a 

specific actor and/or knowing the intent of the actor may be problematic. 

Malicious code can resemble ordinary coding mistakes and malicious intent may be

plausibly denied. The inability to hold an individual accountable weakens 

deterrence mechanisms, such as the threat of criminal charges, or even separation

of the individual or entity from the supply chain. 

Task Force Conclusion

The Department of Defense faces a difficult quandary in its software purchases in

applying intelligent risk management, trading off the attractive economics of COTS 

and of custom code written off-shore against the risks of encountering malware that 

could seriously jeopardize future defense missions. The current systems designs, 

assurance methodologies, acquisition procedures, and knowledge of adversarial 

capabilities and intentions are inadequate to the magnitude of the threat. 

vi_______________________________________________________DSB Task Force on 
__________________________________________________________Executive Summary

Task Force Findings 

The Industry Situation 

The software industry has become increasingly global as suppliers seek lower cost

employees, access to a larger talent base, cultures conducive to highly-structured

processes, and round-the-clock operation. The issue of foreign influence is only 

one of degree, because many companies develop code in multiple geographic 

locations and may embed code from other vendors, code from open source

developers, or even code of unknown provenance. 

While the United States still has preeminence in computer science, Asia is rapidly

gaining. The United States retains a pool of talented computer scientists and 

engineers, but the natural tendency of the industry is to seek the lowest cost supply 

of talent. In recent years that has been primarily in India, while China and Russia 

are on the rise. 

DoDs Dependence on Software 

In the Department of Defense, the transformational effects of information 

technology (IT), joined with a culture of information sharing, called Net-Centricity, 

constitute a powerful force multiplier. DoD has become increasingly dependent for 

mission-critical functionality upon highly interconnected, globally sourced, 

information technology of dramatically varying quality, reliability and 

trustworthiness. 

Software Vulnerabilities 

The majority of software used in the Department of Defense is commercial-off-theshelf product. Although the DoD takes advantage of the functionality and 

inexpensive pricing enabled by the huge market, this code has many weaknesses 

that are exploitable by even moderately capable hackers, who have been the 

beneficiaries of a culture that has produced an evolution of widely-disseminated 

and powerful tools for system intrusion. 

The DoD does not fully know when or where intruders may have already gained 

access to existing computing and communications systems. The Moonlight Maze 

activities, which are classified and thus not detailed here, and numerous other data 

points demonstrate that the U.S. Government, and specifically the DoD computing 

systems, is a constant target of foreign exploitation. 

The Threat of the Nation-State Adversary 

In dealing with a nation-state adversary, the level of threat rises far above that 

posed by hackers. It can be assumed that the technological capability to craft 

actionable malicious code mirrors that of the United States own best computer 

Mission Impact of Foreign Influence on DoD Software_____________________________vii 
Executive Summary_____________________________________________________________ 

scientists. Means and opportunity are present throughout the supply chain and life 

cycle of software development. While code developed in the United States is not 

immune from risk, the opportunity for an adversary is greatly enhanced by 

globalization. 

A sophisticated adversary would have three possible aims in the exploitation of

existing or planted software vulnerabilities – denial of service, stealing of 

information, and malicious modification of information. The outcome of any of 

these would also be accompanied by a loss of confidence in DoDs essential 

systems. 

Awareness of the Software Assurance Threat and Risk 

DoDs defensive posture remains inadequately informed of the sophisticated 

capabilities of nation-state adversaries to exploit globally sourced, ubiquitously 

interconnected, COTS hardware (HW) and software (SW) within DoD Critical 

Systems. Similarly, decision-makers are inadequately informed regarding the 

potential consequences of system subversion, and the value of mitigating that risk. 

The Intelligence Community (IC) does not adequately collect and disseminate 

intelligence regarding the intents and capabilities of nation-state adversaries to 

attack and subvert DoD systems and networks through supply chain exploitations, 

or through other sophisticated techniques. 

DoD does not consistently or adequately analyze and incorporate into its 

acquisition decisions what supply chain threat information is available. 

Status of Software Assurance in the DoD 

Software deployed across the DoD continues to contain numerous vulnerabilities 

and weak information security design characteristics. The DoD and its industry 

partners spend considerable resources on patch management, while gaining only 

limited improvement in defensive posture. 

The evidence gathered during this study was insufficient to quantify the extent to 

which awareness and protection against the system assurance problem has 

permeated DoD systems and networks. The panel did however identify 

considerable variation in the extent to which the systems assurance problem is 

impacting next-generation DoD systems. That impact ranges from extensive with 

the introduction of inter-networked COTS and open source IT into of the Army’s

Future Combat System (FCS) program, to only slight in the United States Air Force 

(USAF) F-22 program. 

The DoD defensive efforts, implemented largely through decentralized execution, 

are difficult to synchronize to achieve a coordinated enterprise effect. DoD has not 

effectively allocated assurance resources to address the systems assurance problem, 

viii_______________________________________________________DSB Task Force on 
__________________________________________________________Executive Summary

nor has it designed its systems and networks to mitigate this problem in the face of 

the capabilities of nation-state adversaries. 

The primary process relied upon by the DoD for evaluation of the assurance of 

commercial products today is the Common Criteria (CC) evaluation process. The 

task force believes that Common Criteria is presently inadequate to raise

sufficiently the trustworthiness of software products for the DoD. This is 

particularly true at Evaluation Assurance Level-4 (EAL4) and below, where 

penetration testing is not performed. Nonetheless, Common Criteria evaluation is

an international program, well established, and not easy to change. 

Ongoing Efforts in Software Assurance 

Software assurance is receiving attention at a number of federal agencies and

laboratories, including the DoD, National Security Agency (NSA), National 

Institute of Standards and Technology (NIST), and Department of Homeland 

Security (DHS). Within the DoD a Software Assurance Tiger Team has been 

studying the problem and has developed a comprehensive strategy for managing 

risk through system engineering, source selection, design, production, and test. 

The key element of risk management in this strategy is the prioritization of

criticality among system components and subcomponents, with special procedures 

and attention placed on the system components determined to be most critical to

mission success. 

Supplier Trustworthiness Considerations 

It is not currently DoD policy to require any program, even those deemed critical 

by dint of a Mission Assurance Category I status, to conduct a counterintelligence 

review of its major suppliers, unless classified information is involved. Supplier 

trustworthiness enters into existing DoD acquisition processes primarily for 

protection of classified information and for research technology protection. From a

systems assurance perspective, supplier trustworthiness should consider adversarial 

control and influence of the business or engineering processes of the supplier, as 

well as the ability of the business and engineering processes to prevent outside 

penetration. 

Finding Malicious Code 

The problem of detecting vulnerabilities is deeply complex, and there is no silver

bullet on the horizon. Once malicious code has been implanted by a capable 

adversary, it is unlikely to be detected by subsequent testing. A number of 

software tools have been developed commercially to test code for vulnerabilities,

and these tools have been improving rapidly in recent years. Current tools find 

about one-third of the bugs prior to deployment that are ever found subsequently, 

and the rate of false positives is about equal to that of true positives. However, it is 

the opinion of the task force that unless a major breakthrough occurs, it is unlikely 

Mission Impact of Foreign Influence on DoD Software_____________________________ix 
Executive Summary_____________________________________________________________ 

that any tool in the foreseeable future will find more than half the suspect code. 

Moreover, it can be assumed that the adversary has the same tools; therefore, it is

likely the malicious code would be constructed to pass undetected by these tools. 

The task force believes that the academic curriculum in computer science does not 

stress adequately practices for quality and security, and that many programmers do 

not have a defensive mindset. While many vendors methodically check and test 

code, they are looking for unintentional defects, rather than malicious alterations. 

Government Access to Source Code 

It is tempting to consider having the U.S. Government take the source code of a 

commercial product and run its own vulnerability assessment tools against it. 

However, there are a number of legal, ethical, and economic barriers that make this

an unattractive proposition, particularly from the point of view of the vendor. 

License agreements forbid reverse engineering of source code, vendors worry about 

the loss of intellectual property, and perhaps most importantly, they worry about 

the cost of supporting the actions and findings of a team of outsiders not familiar

with the design and implementation of such hugely complex programs. Some of 

these worries are lessened when the testing is done by an independent laboratory. 

Conclusion 

All of the considerations just listed seem to point to an intractable problem. The 

Nation’s defense is dependent upon software that is growing exponentially in size 

and complexity, and an increasing percentage of this software is being written offshore in easy reach of potential adversaries. That software presents a tempting 

target for a nation-state adversary. Malicious code could be introduced 

inexpensively, would be almost impossible to detect, and could be used later to get 

access to defense systems in order to deny service, steal information, or to modify 

critical data. Even if the malware were to be discovered, attribution and intent 

would be difficult to prove, so the risk for the attacker would be small. 

Against this backdrop of potential disaster, practical experience and belief paint a 

picture of aggravating and continuous software problems, but not ones that are 

lethal. However, there are some systems on which, to varying degrees, life depends 

(e.g., power, health). In this sense, DoD systems are among the most critical

because their national security mission is often measured in fatalities, and failures

that would be innocuous in another context can be lethal and lead to mission 

failure. 

If the attacker cannot be deterred and its malware cannot be found, what is to be 

done to provide assurance that DoD software will perform in mission-critical

situations? Although there never will be an absolute guarantee, software assurance 

is really not about absolute guarantees but rather intelligent risk management. The

risk of vulnerable software can be managed through a suite of processes and 

x_______________________________________________________DSB Task Force on 
__________________________________________________________Executive Summary

mitigation strategies detailed in the Task Force recommendations, and this risk can

be weighed against the attractive economics and enhanced capabilities of massproduced, international software. 

Task Force Recommendations 

Acquisition of COTS and Foreign Software 

DoD should continue to procure from, encourage and leverage the largest possible 

global competitive marketplace consistent with national security. 

The DoD must intelligently manage economics and risk. For many applications the 

inexpensive functionality and ubiquitous compatibility of COTS software make it

the right choice. In acquiring custom software the increased risk inherent in

software written offshore may sometimes be worth the considerable cost savings. 

The task force recommends that critical system components be developed only by 

cleared U.S. citizens. 

Increase U.S. Insight into Capabilities and Intentions of 

Adversaries 

The intelligence community should be tasked to collect and disseminate 

intelligence regarding the intents and capabilities of adversaries, particularly 

nation-state adversaries, to attack and subvert DoD systems and networks through 

supply chain exploitations, or through other sophisticated techniques. 

DoD should increase knowledge and awareness among its cyber-defense and 

acquisition communities of the capabilities and intent of nation-state adversaries. 

Offensive Strategies Can Compliment Defensive Strategies 

The U.S. Government should link cyber defensive and offensive operations to its 

broader national deterrence strategies, communications and operations, treating 

adversarial cyber operations that damage U.S. information systems and networks as 

events warranting a balanced, full-spectrum response. 

System Engineering and Architecture for Assurance 

DoD should allocate assurance resources among acquisition programs at the 

architecture level based upon mission impact of system failure. The task force 

endorses the strategy and methods to accomplish this as developed by the DoD 

Software Assurance Tiger Team and validated by the Committee on National 

Security Systems (CNSS) Global IT Working Group. 

Mission Impact of Foreign Influence on DoD Software_____________________________xi 
Executive Summary_____________________________________________________________ 

DoD cannot cost effectively achieve a uniformly high degree of assurance for all 

the functionality it uses across many and varied mission activities. Allocating

criticality of function levies a requirement for assurance of that function, and also 

of those functions that defend it. Systems identified as critical must then allocate 

criticality at the sub-system and assembly level. 

To properly allocate scarce assurance resources, DoD must allocate criticality at the

system-of-systems and enterprise architecture level. This analysis should occur 

early within the life-cycle, and should render a prioritization decision no later than 

Acquisition Milestone A, to allow programs of record to appropriately respond to 

their criticality. 

Improve the Quality of DoD Software 

The DoD can effectively raise the “signal-to-noise ratio” against software attacks

by raising the overall quality of the software it acquires. If there were fewer 

unintentional bugs in software, the visibility of deliberate malware would be 

increased. While general improvements in information assurance (IA) will not, per

se, prevent a determined attacker from corrupting the software supply chain, there 

are several compelling benefits in improving the overall assurance/securityworthiness of COTS. 

A sophisticated adversary would have to work harder to introduce an exploitable 

vulnerability instead, as is currently the case, of relying upon the plausible 

deniability of a common programming error to avoid attribution of malicious 

intent. Furthermore, a sophisticated adversary would have less confidence that its 

malware would remain undetected, invisible in a world containing far fewer 

distracting vulnerabilities. That uncertainty could be a deterrent in itself. 

Improve Tools and Technology for Assurance 

Improve Trusted Computing Group (TCG) Technologies

The Trusted Computing Group initiatives, centered on the Trusted Platform 

Module (TPM), provide a means for containing intrusions into separated 

information domains. Each chipset that implements the Trusted Platform Module 

embeds a unique identifier. Cryptologic verification of this identity is required 

when access to system assets is requested. TPM may help ensure that only 

approved and signed code is run, thus reducing the risk of unapproved code being 

installed. 

NSA and others have identified a number of improvements and complementary 

practices that would strengthen TCG-compliant systems, including privacypreserving attestation, virtualization, and architectures that provide richer software 

assurance measurement and monitoring capabilities. 

xii_______________________________________________________DSB Task Force on 
__________________________________________________________Executive Summary

Improve Effectiveness of Common Criteria

Currently, the official DoD-wide evaluation/validation scheme is the National 

Information Assurance Partnership (NIAP) based upon the Common Criteria. The 

reality today is that it would be far easier and more effective to improve Common

Criteria than to invent a new scheme specific to the DoD or to DHS. 

A number of ways to strengthen Common Criteria are discussed in the

Recommendations section of this report. Among these suggestions are crediting

vendors for the effective use of better development processes, including the use of

automated vulnerability reduction tools and automated tools for vulnerability 

analysis—during evaluations at levels four (EAL4) and below. Validation schemes 

should also reduce artificial artifact creation and rely upon artifacts that are 

generated by the development process. 

Improve Usefulness of Assurance Metrics

There is a natural tension between the U.S. Government’s need to know the 

security-worthiness of what they procure and a vendor’s need to avoid disclosing 

particular vulnerabilities. One way to satisfy both needs would be to develop a 

weighted index of the security-worthiness of software. A weighted score could be 

generated via testing based on some combination of the utility of the tools itself, the 

amount of code coverage of the tool, and the test results against a particular 

product. The entire development process should also be evaluated. 

More Knowledgeable Acquisition of DoD Software 

DoD should implement a scalable supplier assurance process to assure that critical

suppliers are trustworthy. No product evaluation regime in effect today provides 

insight into a vendor’s real development processes and their effectiveness at 

producing secure and trustworthy software – so the software assurance challenge 

for DoD is to define an evaluation regime that is capable of reviewing vendors’

actual development processes and rendering a judgment about their ability to 

produce assured software. 

The DoD acquisition process should require that products possess assurance 

matching the criticality of the function delivered. Furthermore, the DoD should 

require that all components should be supplied by suppliers of commensurate 

trustworthiness, and in particular, that all custom code written for systems deemed 

critical be developed by cleared U.S. citizens. 

The collective buying power of the U.S. Government is such that it can force 

change on its suppliers to a degree no other market sector can reasonably do. The 

DoD, working in collaboration with the Office of Management and Budget (OMB), 

DHS, and other Federal agencies, can help to change the market dynamic through 

both positive and negative incentives so that they get better quality software, and to 

make better risk-based and “total cost”-based acquisitions. 

Mission Impact of Foreign Influence on DoD Software_____________________________xiii
Executive Summary_____________________________________________________________ 

Research and Development in Software Assurance 

DoD should establish and fund a comprehensive Science and Technology Strategy 

and programs to advance the state-of-the-art in vulnerability detection and 

mitigation within software and hardware. The goals of the classified and

unclassified research and development (R&D) investments in assurance should be 

to develop the technology to effectively take accidental vulnerabilities out of 

systems development and to improve Trusted Computing Group technologies in 

order to bound most risks of intentionally planted software. This program should 

monitor what markets are delivering, identify gaps between what the market is 

delivering and what DoD needs, and fill this gap. 

xiv_______________________________________________________DSB Task Force on 
____________________________________________________________________Introduction 

INTRODUCTION 

The 1990s saw a change from closed economies to free market mechanisms and a

desire of more than half the world’s population -- in India, China and the former

Soviet Union – to compete economically. This has had a dramatic impact on the 

distribution of world income and caused dramatic changes to mature economies. It 

is clear that China, India, Russia and Brazil are no longer simply participating in 

low-end manufacturing, but are full-fledged economic participants in the global 

market place, with burgeoning internationally-competitive and internationallyemployable populations. This transformation of the global marketplace is linked to

the expansion of information technology into nearly every facet of life. Although 

reliance on IT is both beneficial and irreversible, it also creates significant

opportunities for threat actors, in particular the nation-state adversary to control 

fundamental systems, networks, and critical infrastructure. 

To place the issues of globalization in context, it is useful to consider both the 

current U.S. role in software development and world trends in this area. As of

2006, the United States held a clear leadership role in software development, as it

did in hardware production not long ago. In 2003 the United States represented 65 

percent of world-wide employment in the IT services sector, according to a 

McKinsey Global Institute study. Despite fears following the dot-com bust and 

rumors of massive outsourcing and off-shoring of software jobs, current U.S. 

employment in the various software disciplines is actually above the highs of the 

dot-com era. What then is the concern about globalization? 

Much of the infrastructure required for globalization of software employment was 

created in the 1990s and earlier. This includes the astounding growth and spread of 

the Internet as a communications and distribution medium; the building and overbuilding of broadband fiber world-wide, virtually eliminating carrying costs as a

factor; the wide-spread adoption of wireless, allowing societies to leap-frog 

infrastructure limitations; the broad adoption of a few standard applications such as 

Oracle and Systems, Applications and Products (SAP), allowing start-ups overseas 

to focus on fewer skills when offering support; significant improvements in higher 

education in technical skills, particularly in India and China; and the creation of an

overseas job market for U.S.-trained foreign nationals, allowing them to return 

home to relevant jobs. 

Thus, while the United States remains a dominant player in global software 

development, trends clearly point to erosion, reducing the United States to mere 

competitiveness. These trends may be irreversible. Software is and will 

increasingly be developed world-wide, chasing both lower costs and an expanding 

talent pool. Further, some of the strongest future players in this market space are 

adversaries of the United States. In some cases, the adversarial basis may be purely 

economic, while in others the United States must account for the possibility of 

confronting adversaries either directly or indirectly in military conflict. A 

Mission Impact of Foreign Influence on DoD Software_____________________________1 
Introduction____________________________________________________________________ 

generation ago, U.S. adversaries feared the risk of using hardware and software

developed in the U.S., as it might be used as a weapon against them. Similarly, the 

United States must now confront -- and plan for -- the reality that adversaries may 

well be supplying the key hardware and software on which the U.S. bases its 

military and economic superiority. 

Characterizing the extent of globalization and the challenge that it presents to the 

United States is complicated by the number of issues presented. The key point 

from the standpoint of this study is that U.S. multinationals are seeking -- and

China, India and Russia are providing -- software services, up to and including 

design services. The extent to which the United States is off-shoring 

manufacturing operations to the detriment of U.S. labor market interests is not 

addressed in this report. These countries are entering into the market to produce 

software products, and they are supporting U.S. corporations in delivering 

products. 

Figure 1, from the “Innovation Consortium,” showing the erosion of U.S. market

share, typifies the market situation. The next tier of data concerns the underlying 

capabilities that are supporting these market changes. There is much debate 

regarding the details of the data, but the clear trending of all indices (patents issued,

R&D, PhDs granted, etc.) is that U.S. predominance in IT technology is rapidly 

eroding to mere competitiveness. The discussion below regarding the engineering 

graduate data is instructive. However, it is difficult to interpret competitiveness 

statistics for countries totaling five to six times the population of the United States. 

Figure 1. Market Share Changes 

2_______________________________________________________DSB Task Force on 
____________________________________________________________________Introduction 

Any description of the state and trends in globalization of software must

acknowledge the paucity of valid data on the subject, which makes any analysis 

tentative. Several factors contribute to the lack of valid data. Neither government 

nor industry has captured data for any period of time in this new arena. The data 

that exists has been captured inconsistently using differing parameters and 

definitions, and much of the data is captured with an agenda in mind, damaging its 

use for objective study. Most importantly, the whole issue of software 

globalization, in general, is so new that only a few years of data are available in any 

case. Thus, while there are clear trends discernable, it will be important to 

revalidate and refine these trends and the conclusions they drive before making 

radical changes in policy or practice. Data over the next few years promises to be

more fruitful and exact. This contrasts markedly with the data available on

hardware off-shoring, which is both easier to accumulate and has been available for 

some years now. 

This Task Force considered the potential impacts of the action of numerous threat 

actors (hacker, criminal, terrorist, nation-states, and sophisticated nation-state 

adversaries, etc.) upon different elements of society (intellectual property, critical 

infrastructure, national security systems). However, it was the consensus of the

group that ultimately the most difficult risk to address is nation-state adversary 

creation and exploitation of vulnerabilities that interfere with the DoD projection of

military force. Further, DoD senior management remains inadequately informed 

about the reality of such a prospect, and even critical programs do not account for 

this risk. 

The Impact of Globalization on Microelectronics 

In 2003, the Under Secretary of Defense for Acquisition, Technology, and

Logistics (USD(AT&L)) tasked the chairman of the Defense Science Board to 

stand up a task force to investigate the implications of the movement of

semiconductor manufacturing and design capability offshore. The two principal 

concerns with this offshore migration were the DoDs inability to assure supplies of

critical parts during times of crisis and the inability of DoD to assure design 

function based upon adversarial access to design and fabrication processes. 

The recommendations of that task force were focused on ameliorating the threats

posed by offshoring microelectronic fabrication, design, packaging, and testing. 

The initial focus of the study centered on issues and approaches for increasing 

confidence in U.S. access to critical semiconductor technology. However, as the 

study progressed, increased concern over the assurance of functionality of the 

technology itself rapidly emerged. This is best summarized by a quote from the 

report’s introduction: 

Mission Impact of Foreign Influence on DoD Software_____________________________3 
Introduction____________________________________________________________________ 

“From a U.S. National Security view, the potential effects 

of this restructuring are so perverse and far reaching and 

have such opportunities for mischief that, had the United 

States not significantly contributed to this migration, it 

would have been considered a major triumph of an 

adversary nation’s strategy to undermine U. S. military 

capabilities.” 

Based upon the extent and potential impact that loss of the integrity/assurance of 

U.S. high performance microchip supply could have, the study additionally 

recommended chartering a comparable study for software. As stated in the study: 

“A strategy for achieving the above hardware counter-tamper objectives without a

comparable strategy for software is of limited utility.” Consequently, the task force 

recommended chartering a similar DSB study to investigate national security issues 

associated with rapid migration of software production, testing and maintenance 

overseas. This resulted in the formation of the Defense Science Board Task Force 

on Mission Impact of Foreign Influence on DoD Software. 

Interrelationships between Software and Hardware Risks 

The offense gets to pick the time, the place and the means to attack a target. The 

defense must be strong enough to withstand the strength of the attacker at the 

defender’s weakest point. This is as true in information operations as it is in 

conventional warfare. The principal reason behind the microchip report’s 

recommendation for the standup of this software study is embodied within this 

axiom of warfare. 

From a defensive perspective, microelectronics and its associated software cannot 

be separated. While the offense may be able to attack either and meet operational 

objectives, the defense must be prepared for the offense to attack at the seam of 

software and hardware. If this offensive approach is done well and the defense 

examines the software and hardware only as independent elements, the offense is

likely to go unnoticed until too late.

The microchip report provides the gamut of issues that affects both DoDs assured

supply and the assurance of the components. The principal issues center on the 

fabrication facilities moving offshore due to extreme cost benefits and host country 

incentives. Once this market is centered in the U.S. opponents’ back yards, other 

elements of the microelectronics process (e.g., design, test, and packaging) will 

follow. This provides significant access opportunities for the adversary and few, if 

any, new access alternatives for the U.S. 

As conveyed in the present study, the issues surrounding the offshoring of software

are diverse. Software design, development, testing, distribution, and maintenance 

can all be done more inexpensively offshore. As explained in Thomas Friedman’s 

book, The World is Flat, global high bandwidth connectivity has allowed and 

4_______________________________________________________DSB Task Force on 
____________________________________________________________________Introduction 

encouraged third-world countries to compete effectively in the software arena 

where the cost of entry is low. 

While some of the reasons driving microelectronics and software offshore are 

different, the impact on DoDs mission-critical systems, from incorporating foreigndeveloped parts, is the same. The U.S. is significantly enhancing the adversary’s 

ability to access this technology in many of the life-cycle phases. This access 

provides opportunity to clandestinely modify the components that could negatively 

impact the functionality of mission-critical applications. 

Risk: Threat, Vulnerability, and Consequence 

The DoD now relies upon networked, highly-interconnected systems for many 

mission-critical capabilities, and this reliance is projected to increase. The software 

in these systems is the key ingredient that provides much of the increased capability 

delivered to the warfighter, just as it represents the key factor in increased

productivity and new capabilities for industry today. For the DoD, this advanced 

technology is a force multiplier. Yet the reliability of that force multiplier is

increasingly unknown due to the risks posed by a rapidly expanding supply chain 

that includes some of the Nation’s most technologically sophisticated adversaries. 

DoDs most highly sensitive systems are composed of defense-unique and highlyassured subsystems and components. However, other critical weapons systems, 

communication systems and support systems incorporate COTS or open source 

software (OSS). This software is likely to contain defects, as well as both 

accidentally and deliberately introduced vulnerabilities. Additionally, 

misconfiguration and/or poor maintenance of complex heterogeneous systems may 

also leave an organization vulnerable. All of these things are key components of

system risk. 

After vulnerabilities, threat is the second key component of system risk. 

Adversaries are well aware of the dramatic advantage that networked technology 

(Net-Centricity) brings to the U.S. military. They will assuredly seek to counter 

this advantage. To constitute a true threat, adversaries must have the intent,

capability, and opportunity to attack DoD IT systems. If threat agents are able to 

identify and attack system vulnerabilities effectively, system failure will occur with

the consequence that mission-critical capabilities may be compromised. 

Global software development presents an opportunity for threat agents to attack the 

confidentiality, integrity, and availability of operating systems (OS), middleware,

and applications that are essential to the operation of the U.S. Government and the 

DoD. The most direct threat is overt foreign corruption of software: insertion by 

the developer of malware, back doors and other intentional flaws that can be later 

exploited. A second threat is foreign adversaries’ corruption of the commercial 

supply chain. Commercial development processes make no guarantees about the 

purity (or lack of corruption) of the supply chain, nor could they reasonably do so. 

The overall opaqueness of the software development supply chain and the

Mission Impact of Foreign Influence on DoD Software_____________________________5 
Introduction____________________________________________________________________ 

complexity of software itself make corruption hard to detect. Furthermore, most

companies are not actively looking for malicious introduction of suspect code, 

although there may be some collateral benefit from the fact that they do consider 

the provenance of code to ensure no infringement of intellectual property rights. 

Figure 2 displays the relationship among threats, vulnerabilities, risks and 

consequences. Risk, in this case, is defined as the probability of system failure.

Threat and vulnerability contribute to this risk. The consequence of system failure 

must be assessed based on mission impact and the criticality of the mission. 

Figure 2. Risk vs. Consequence 

Assessing systems according to the framework in Figure 1 encourages 

prioritization of resources toward IT systems where risk is high and the 

consequence of system failure is severe. Since risk and consequence are 

independent factors, decision makers can consider whether resources are most 

effectively employed in reducing risk (e.g., by insisting on government-supplied 

software in a weapon control system) or in mitigating the consequence through a 

redundant system (e.g., by fielding a medium range, armed Unmanned Aerial 

Vehicle (UAV) system in addition to an artillery system). 

This framework illustrates that DoD can raise the level of IT system assurance by 

countering threats, by reducing vulnerabilities, reducing opportunities for 

vulnerabilities to be introduced (e.g., using cleared people) or mitigating the impact 

of vulnerabilities through redundancy, isolation and other techniques. For example, 

the threat component of risk can be countered by reducing the opportunities of 

threat agents to insert malicious code at points in the supply chain. System

vulnerability can be reduced by detecting and correcting defects and malicious 

6_______________________________________________________DSB Task Force on 
____________________________________________________________________Introduction 

code. Vulnerable COTS or open system software modules can be defended by 

placing them within robust, well-defended architectures. 

As this report points out elsewhere, cost and capability advantages will increasingly

drive the DoD to incorporate into its systems COTS software and IT hardware

components produced on foreign soil. The provenance of commercial IT may 

provide adversaries an easier opportunity to compromise DoD systems. Other links 

in a supply chain that includes production, installation and upgrades may provide 

additional opportunities for foreign influence. Such opportunities must be 

appropriately recognized and countered. Similarly, other elements of threat must 

be identified and countered. In addition to recognizing and reducing the 

opportunity element of threat, DoD and the Intelligence Community can neutralize 

adversaries through judicious countermeasures. Discovering and then eliminating 

or defending vulnerabilities addresses a major component of risk. At the same time

these actions serve to increase the capabilities an adversary must possess to mount

an effective attack. 

The DoD and the broader national security community have recognized this

problem and have identified some possible solutions. The DoD Software 

Assurance Tiger Team has developed a strategy and concept of operations 

(CONOPS), described later in this report, to manage these risks. The Committee 

on National Security Systems (CNSS) established a Global IT Working Group, 

which independently validated the work of the Tiger Team and other studies 

regarding the risks of globalization. The working group then developed a strategy 

applicable to the broader Federal community. 

Mission Impact of Foreign Influence on DoD Software_____________________________7 
Introduction____________________________________________________________________ 

8_______________________________________________________DSB Task Force on 
_____________________________________________________________________Findings 

FINDINGS 

Structure of the Software Industry 

FINDING: The software industry, as well as the software talent base, is becoming 

increasingly global, and this trend appears to be irreversible. 

The software industry comprises a diverse collection of organizations that cannot 

be simply categorized. There are large and often well-known software providers 

with widely distributed development facilities and smaller software providers 

whose development facilities may be completely located in one geographical area.

There are system integrators who serve a critical function in integrating hardware

and software and may write custom software as part of that process. Other 

companies (like financial institutions and military weapons providers) are not 

traditionally thought of as software houses, but in fact create large quantities of

software as a routine part of their business. The abundance of software is reflective 

of its transformative value, while the diversity in the industry is reflective of the 

low barriers to entry. Indeed, even individuals with limited formal education in 

computer science can create commercial or not-for-profit software companies and

cheaply distribute software around the globe. 

The Task Force focused on the larger software companies, system integrators, and

military providers who, as part of their normal course of business, provide the DoD

with significant amounts of software. In many cases, these companies have foreign 

nationals working in the United States as well as geographically distributed

software development processes. Moreover, these companies are increasingly offshoring software development. 

Market realities are such that few companies develop, ship, and support their 

software using only U.S. citizens located in the U.S. or, for that matter, only 

foreign developers located overseas. “Foreign influence over software” may thus be 

a matter of degree. The market reality is that many commercial software companies 

develop products in multiple geographic locales. Even a U.S.-based company of 

any size can and likely does have a worldwide presence if not worldwide 

development. In fact, venture capital firms routinely pressure software start-up 

firms to use overseas talent. Many companies may also embed code from other

vendors (open source or code licensed from a third party) which itself may be of 

unknown or unproven provenance. 

There are clear benefits to global development for the software industry that both 

directly and indirectly benefit DoD: 

• First, offshoring gives companies access to a larger pool of talent (so that 

they can continue to produce world-class software). Presumably, having a 

healthy domestically-owned or domestically-controlled software industry, 

Mission Impact of Foreign Influence on DoD Software_____________________________9 
Findings______________________________________________________________________

even if development is done globally, is preferable to having no domestic 

industry at all. 

• Second, developing software overseas potentially results in much lower 

development costs, so companies can potentially supply more functionality 

- including functionality of interest to DoD – without raising prices. For 

example, given that DoD tends to have massive systems, the ability to build

more scalable and reliable systems by investing the cost savings generated 

by offshore development is a tangible benefit to DoD. 

• Third, there may be advantages to offshoring that provide a tangible benefit 

in terms of quality or security-worthiness. Better talent produces better

quality software. Moreover, there is anecdotal evidence from the Year 2000 

(Y2K) experience that developers in some countries may as a group be 

more willing to follow a structured development process (such as the

Capability Maturity Model (CMM)), instead of arguing that development 

processes emphasizing security also “stifle creativity.” Ultimately, securityworthiness is at least partly about quality, and quality is in part a result of

talented people following strong development processes and paying 

attention to secure coding practice. 

Talent Base in Software 

The globalization of the software industry is driven not just by cost. Although offshoring can reduce costs, because pay scales in other countries may be lower than

those in the United States, it is likely that this pay gap will diminish over the long 

term. This is because one result of globalization is to increase opportunity and 

improve the standard of living in more countries, thus causing pay scales to 

increase in other economies as demand for quality workers increases. Indeed, over 

the last few years, the gap in pay for software developers has grown smaller, even 

if still substantial. Thus in the longer term it is not just about cost but access to 

talent, an issue ironically exacerbated in part by the government’s own policies that 

limit the number of Visas issued to foreign IT workers. 

An adequate supply of software talent is the key enabler for developing a sound 

technology base in software research and development. In order to evaluate the 

adequacy of the U.S. software industry’s ability to meet DoDs needs for custom 

software, the Office of the Under Secretary of Defense for Acquisition, Technology 

and Logistics (OUSD(AT&L)) sponsored a Software Industrial Base Study (SIBS). 

The two-phase study was launched to assess the demand for software within DoD 

and the industrial base’s ability to satisfy that demand. 

Phase I of the study, completed in October 2006, found that the overall pool of 

software programmers appears to be adequate. However, there is a larger demand 

for the upper echelons of the software developer and management cadres, 

exacerbated by the fact that people trained in these specialty areas generally cannot 

easily transfer their skills across domains of expertise. In order to develop the 

10________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

specialized software that is most critical to the DoD mission, knowledge of the 

application domain is harder to obtain and more valuable to DoD than knowledge 

of a particular programming language or even knowledge of software engineering 

itself.

Software engineers who have expertise in defense-oriented applications are likely 

to be in greater demand in the DoD sector than in the commercial marketplace.

Likewise, employers in the DoD sector are highly motivated to retain experienced 

software engineers because of the expense of training new ones in the relevant 

applications, as well as the cost and delay of obtaining a security clearance for a 

person entering from the commercial market. Phase I of the SIBS specifically

highlights a key choke point in the pool of top-tier program management/software 

architect talent. Industry is trying to grow this cadre with training and career 

development strategies for high-potential employees, highlighting the critical need

to coordinate government human resources strategies with industry. Phase II of the 

study is underway. 

Computer Science Education in the U.S. and Abroad 

The United States remains one of the world’s most competitive arenas for computer

science education, and the heart of the current U.S. workforce (ages 45-64) is still 

the best educated workforce compared to other countries. The United States is 

producing a significant number of engineers, computer scientists and information 

technology specialists, and remains competitive – though no longer dominant -- in

global markets. The challenge for the United States over the next decade will be to 

retain its role as a global pacesetter in the education of engineering and scientific 

talent and thereby to sustain its legacy as a preeminent technological innovator. 

Programs in software engineering and other efforts to train thousands of new 

programmers with the needed analysis, design, development, and project 

management skills are not widely offered in the university and post-graduate 

education systems and, additionally, demand for these courses is dropping. Indeed, 

industry uniformly notes that educational institutions are not producing enough job 

candidates and those that they are producing lack the necessary grounding in

security to develop products that address today’s threats. 

Varying, inconsistent reporting of problematic engineering graduation data has 

been used to fuel fears that the United States is losing its technological edge. In 

addition to the lack of nuanced analysis around the type of graduates and quality of 

degrees being awarded, these articles also tend not to ground the numbers of 

engineers in the larger demographics of each country. While the growth of 

offshoring activities in the IT sector, particularly in India and China, is real and 

increasing, the United States is not in the desperate state that is routinely portrayed. 

Many of the studies on rates of graduating engineering students world-wide 

consider only the raw number of graduates, without factoring in either the accuracy

of what is counted or the quality of the education. Such studies also evaluate only 

total numbers of graduates from each country, without considering per-capita 

Mission Impact of Foreign Influence on DoD Software_____________________________11 
Findings______________________________________________________________________

graduating rates per country. A recent report developed by graduate students of 

Duke University’s Master of Engineering Management Program does attempt to 

consider the varying education standards of India and China compared to the 

United States, and does examine the data in the context of each country’s total 

population. 

The Duke study has determined that the massive numbers of Indian and Chinese 

engineering graduates reported in various studies include not only four-year 

degrees, but also three-year training programs and diploma holders, as shown by 

Figure 3 below. This is particularly significant for the outsourcing debate, as the 

competition off-shore for talent focuses on only the best educated and experienced 

individuals among four-year graduates, and those holding advanced degrees. 

Figure 3. Comparison of Degrees Awarded. Number of Bachelor and Sub-Baccalaureate Degrees in

Engineering, Computer Science, and IT Awarded per Million Citizens in 2004. 

The Duke Study notes that per capita the United States produces 750 technology 

specialists for every million citizens, compared with 500 in China and 200 in India. 

A comparison of like-to-like data suggests that the United States produces a 

significant number of engineers, computer scientists and information technology 

specialists, and remains competitive in global markets. The great majority of

engineers involved in outsourced professions hold a minimum of a four-year 

degree. Given the higher degree requirements for outsourced professionals, one 

could argue that approximately half of China’s and India’s annual engineering and 

IT graduates are capable of competing in the global outsourcing environment. 

12________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

However, a recent McKinsey global labor market study argues that this estimate is

far too generous. McKinsey concluded that only 10 percent of Chinese engineers 

and 25 percent of Indian engineers can compete in the global outsourcing market, 

after factoring in language skills, educational quality, cultural fit, job accessibility, 

as well as the attractiveness of domestic non-outsourced jobs. 

The Growing Complexity of Cyberspace 

There is an increasing complexity in micro-electronics, software, and computer 

networks as shown by the following data. 

Micro-Electronics

Micro-electronic devices have been exponentially increasing in complexity over 

time. Intel co-founder Gordon Moore noted this in 1965 and stated what became

known as Moore’s law -- that the number of transistors on a chip about doubles in a 

short fixed time period. His original formulation predicted a time period of one

year for the years 1965-19751

, and later stated the period of two years2 (though 18 

months has been widely quoted). Simply looking at one microprocessor line – 

Intel’s – shows that this prediction of exponential growth in micro-electronics’ 

number of transistors per chip has held true all the way through today (Figure 4 

below).3

Figure 4. Moore's law as demonstrated by Intel microprocessors. 

 

1 Moore 1965 2 Intel 2007 3 Intel 2007

Mission Impact of Foreign Influence on DoD Software_____________________________13 
Findings______________________________________________________________________

Exponential growth in the number of components has been shown in many other

microelectronic products such as Random-Access Memory (RAM) chips (with 

corresponding sizes4

), and it is widely expected that this trend will continue for 

some time to come.

The rules of physics cannot be violated, so no exponential growth can occur 

forever. Even Moore has stated that doubling every two years “can’t continue 

forever.”5

 Regardless, microelectronic components are expected to continue to 

grow in complexity for many years to come. 

Software

Software tends to grow significantly in size over time, illustrated in Figure 5. 

Software source lines of code (SLOC) values publicly available for products such 

as Microsoft Windows and Red Hat Linux give strong evidence that this trend is 

continuing.6

 This increasing size brings with it increasing complexity. 

0

10

20

30

40

50

60

1990 1992 1994 1996 1998 2000 2002 2004 2006 2008

Windows non-NT

Windows NT

Red Hat Linux

Figure 5. Software size (MSLOC) increases over time. 

 

4 Dix 2004

5 Dubash 2005 6 Schneider 2000, McGraw, Associated Press 2007, Wheeler 2000, Wheeler 2001 

14________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

Networks

The number of interconnected computers has grown rapidly as well. 

Netcraft has tracked the total number of web sites on the (public) world wide web 

since 1995. Originally it only tracked the number of unique names with a website. 

As the number of “inactive” sites grew (e.g., sites which existed but did not yet 

post content), it began separately tracking the number of active sites. Figure 6

shows a steady growth in the number of publicly-accessible web sites from 1995 

on.7

Figure 6. Total Web Sites Across All Domains August 1995 - February 2007. 

Other studies have attempted to determine the number of hosts on the Internet 

(whether or not they are web servers), including Lottor’s Request for Comments 

(RFC) 1296, Zakon’s8

, and the Internet Systems Consortium (ISC). These studies 

confirm that the number of computers interconnected through the Internet has been

rapidly rising for decades. Computers and systems in DoD, and throughout the

U.S. Government and U.S. critical infrastructure, have been swept along in this 

trend, creating avenues of attack across DoD systems and networks. 

 

7 Netcraft 2007 8 Zakon 2006

Mission Impact of Foreign Influence on DoD Software_____________________________15 
Findings______________________________________________________________________

Software in the Department of Defense 

FINDING: DoD has become increasingly dependent for mission-critical 

functionality upon highly interconnected, globally-sourced, information technology 

of dramatically varying quality, reliability and trustworthiness. 

Over the past several decades, global competition in the information technology 

industry has dramatically reduced the cost of hardware and software IT products. 

At the same time, advances in networking and communications technologies have 

made connectivity through commercial protocols ubiquitous. In the DoD, the 

transformational effects of such technologies have created a Net-Centric 

environment, where information and functionality are shared and interconnected to 

a high degree. While Net-Centricity is a powerful force multiplier, the increasing

dependency upon this capability creates and amplifies the risk of vulnerability to 

unintentional or maliciously-induced system malfunction. 

Size and Scope of DoD Software

To bring context to this discussion, it is useful to consider the sheer size and scope 

of DoDs dependence on software, and the increasing pace of that dependence. 

Software has been growing in the dimensions of size, complexity, and 

interconnectedness, each of which exacerbates the difficulties of assurance. This 

and the following sections of this report discuss these trends. 

The amount of software contained within DoD systems has been growing 

exponentially.9

 It is estimated that the DoD cleared industrial base, including 

approximately 70,000 programmers, software engineers and computer engineers, 

meets the annual demand for software written for DoD. There is no definitive

source of data on the amount of code required annually by DoD. However, the 

Center for Strategic and International Studies (CSIS) study did develop an estimate

of 60 million software lines of code (SLOC) (new and maintenance code) required 

annually by the national security community in 2006. 

The amount of software included within DoD systems is considerably larger than

this estimate when COTS software integrated into DoD systems and networks is 

included. The COTS content of DoD Systems and networks varies considerably. 

Command and Control (C2) and Mission Support systems are probably 

predominantly COTS. The Future Combat System (FCS) represents a significant

intermediate point: Of the total estimated 63.8 million SLOC for FCS, 12.3 million 

will be written for the program, 14.6 million SLOC will be reused and 36.9 million

SLOC will be COTS. On the F22 Program, which leverages high assurance COTS

developed under the multi-independent levels of security program (MILS) for 

certain mission-critical elements of the platform, software is predominantly custom, 

totaling approximately 4 million SLOC. 

 

9 CSIS, 2006

16________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

DoDs increased risk comes not only from the continuing shift to software 

developed overseas, but from the sheer volume and dependence DoD has on all 

types of software to meet mission requirements. Some measurements relating to

software are the size and scope of DoD IT activities, as indicated by the following

FY2006 data points (from the Department of Defense Chief Information Officer 

(DoD CIO). 

• The DoD FY06 IT Budget is $30 billion. 

• DoD has some 5 million Computers. 

• DoD has issued approximately $10 million Common Access Cards (CAC). 

• DoD Operates in some 600,000 facilities in 6,000 locations in 146 

Countries. 

• DoD has three global Intranets (NIPR, SIPR, and Joint Worldwide 

Intelligence Communication System (JWICS)). 

Foreign Dependencies in DoD Software

Although there are no firm figures, it appears that custom DoD software is 

developed predominantly by U.S. citizens, many of whom hold clearances. The 

impact of globalization on the pedigree of source code within DoD systems is 

driven by the globalization of the supply chain for COTS, called “packaged 

software,” to distinguish such software from software services and from embedded 

software within commercial hardware components. There does not appear to be 

direct information regarding the percentage of this software that is globally 

sourced. Recent studies indicate that global sourcing (from high wage to low wage 

countries) of SW Engineering talent within the SW Product sector can be expected 

to increase from 7 percent (41,000 full time equivalents FTE)) to 18 percent 

(116,000 FTE) over the period 2003 to 2008.10 Thus, ignoring direct imports of 

foreign origin COTS, COTS purchased from U.S. companies can be expected to

become increasingly foreign sourced. At a minimum, the lines of code would 

approach the percentage of global sourced labor (18% in 2008). Because, by 

function, R&D is among the most easily globally sourced, this figure can be 

expected to increase over time barring supply shortages. Moreover, this number 

does not include COTS products developed by foreign manufacturers and sold to 

DoD or incorporated into DoD systems and networks by the DoD industrial base. 

Varieties of Software used in the DoD

Software is developed within many different business models. Broadly, software 

may be divided into Custom, GOTS, and COTS. In fact, the issue is more complex 

than this, and in each of these cases there are closely related types (e.g., freeware 

and open source software), and in each case software developed within one 

business model may be incorporated into another. For example, many COTS 

developers and DoD custom code developers may also embed open source or code 

from other developers, which itself may be of unknown or unproven provenance. 

Because custom software can be well characterized and controlled, most security

 

10 McKinsey, 2006

Mission Impact of Foreign Influence on DoD Software_____________________________17 
Findings______________________________________________________________________

and reliability risks for the DoD are frequently associated with open source and 

COTS software. However, this is not always the case, as, for example, when 

rapidly prototyped custom software finds its way into the operational setting and 

soon becomes indispensable. At this point in time almost all IT environments are 

composed of “mixed code.” 

Custom Software 

Custom software is specifically designed for an individual customer. While it may 

later be cleared or released for broader use, in general an individual customer

procures custom software for a specific purpose, intends to be the sole user of this 

software, and takes concrete steps to protect the proprietary nature of the software 

and its derivatives. Examples might include quantitative algorithms for evaluating 

hedge funds for a financial institution or avionics software for an advanced aircraft 

manufacturer. 

GOTS refers to custom software developed for the government for one purpose that 

is later reused “off the shelf” by contractors and other government agencies and 

integrated into new government systems and applications. GOTS software may be 

developed by the technical staff of a government agency or by an external entity 

with funding, oversight and specification from the agency, or by a combination of 

both. The DoD has established and employs a large and stable industrial base for 

both custom and GOTS software. Where specified or required, contractors and

vendors develop or support 100% of their software in the United States using only 

U.S. citizens who are vetted, and shipping code that has been reviewed and tested 

to meet specific security, reliability and operational requirements. 

Commercial-Off-The-Shelf (COTS) Software 

COTS software is used "as-is." COTS products are designed to be easily installed 

and configured to interoperate with existing system components. Almost all

software bought by the average computer user and much of the software used by 

the U.S. Government and the DoD is COTS. Examples include operating systems, 

database management systems, email servers, application servers, and office 

product suites. Because it is mass-produced, one of the major advantages of COTS 

software is the relatively low cost of acquiring, maintaining and achieving 

technology refresh. Given these low costs and the competitive forces at work, 

COTS software producers may or may not know, manage or track the provenance 

of their software, except to the extent needed to ensure that the necessary license

are obtained for embedded components. In addition, they generally do not make

source code available, so supplier identity and software content is often blurred by

the reuse of legacy code, subcontracting, outsourcing, and use of Open Source 

Software (OSS). 

Open Source 

In general, open source refers to software whose source code is freely available for 

use, modification and redistribution by the public, often without royalties. It is 

18________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

usually developed through public (open) collaboration with the result that there 

may be little or no knowledge of the motivations or loyalties of many of its

developers. Examples of OSS include the Linux kernel, the Apache web server and 

the Mozilla Firefox web browser. 

Most major systems integrators use OSS in their systems. In addition, several open 

source organizations have emerged (e.g. The Open Source Initiative) that provide 

certification and several companies deliver open source solutions as their core 

business. Freeware and shareware preceded open source and were available for 

use, modification or distribution at no cost for an unlimited or limited time, 

respectively. As with some open source now, freeware and shareware, and

derivatives, could also be distributed at no cost. The result has been that freeware 

and shareware are embedded within countless software programs, modules and 

systems. 

Managed Services 

Another area of increased opportunity and risk for DoD is the rapid increase in the 

use of managed services. The switch to this kind of support is projected to increase 

rapidly nation-wide over the next decade, and DoD will not remain immune from 

the trend. The greater risk inherent in managed services stems from the need to 

give unparalleled access to the service provider of services as part of the 

contractual arrangement. DoD has begun to address this concern in policy, 

requiring that DoD elements considering a contract for managed network services 

get a counterintelligence assessment of the proposed provider in order to identify 

risks from contracting with companies controlled by countries or organizations of 

concern. 

The Growing Complexity and Interconnectedness of DoD Software

Software complexity is growing rapidly and offers increasing challenges to those 

who must understand it, so it comes as no surprise that software occasionally

behaves in unexpected, sometimes undesirable, ways. Sometimes the seeds of this

behavior are indigenous to a specific software module but sometimes the cause of

the anomalous behavior is “environmental”—i.e., it stems from some other 

software co-habiting the immediate process space, or the larger application space,

or on other machines in the network space. 

In addition to what are traditionally considered applications, there are numerous

support processes or daemon processes running in the background. This leads to 

“unconscious” interdependencies that may cross process boundaries. The most

common example of such interdependency is the buffer overflow, in which a 

program fails to check input sufficiently with the result that program code 

embedded in the input gains control of the process. If there is a critical function to 

perform, it must be ensured that it does what, and only what, was intended. 

However, these interdependencies allow what may be a less critical function to

disrupt the operation of a more critical function, unless great pains are taken to 

keep them separated. 

Mission Impact of Foreign Influence on DoD Software_____________________________19 
Findings______________________________________________________________________

A buffer overflow may not occur in a critical application, but in a co-resident 

application. More importantly, the operating system may not safeguard against 

other processes that are intended—by their designer, but perhaps not by the user—

to interact. Like most security functions, they work reasonably well to keep the

honest people from doing something wrong. Was that buffer overflow in a 

neighboring program mere inadvertence, or malice aforethought? 

DoD decision-makers are intentionally trading off confidence in the assurance of 

the critical application for the cost, performance, and availability benefits of COTS. 

In these systems, the functionality in excess of that required to meet the 

requirements of the critical application is staggering. This excess functionality 

creates unnecessary risk, pushes the envelope of DoDs evaluation ability, provides 

ample access opportunities for opponents, and creates domain isolation "by-pass" 

paths. Users making decisions to include excess functionality do so with an

understanding of the benefits without a corresponding understanding of the

associated risks. 

Note that economics and technology exacerbate these problems of interdependency

and interconnectedness. General purpose platforms running a multitude of 

applications seem like a “best buy,” and programmer productivity rises 

dramatically by re-use of legacy code -- where provenance is neither known or of 

concern to the developer. 

The very complexity of this problem ensures no simple solution, but this cannot 

serve as an excuse to ignore it. Attending carefully only to a critical application is

no grounds for confidence on the overall performance of the system. The entire 

environment must be of concern. 

Examples of Software Development in the DoD

The Aegis System introduced in 1980 required fewer than 2 million lines of code. 

The F-22 aircraft introduced in 2005 requires perhaps double that, while the F-35 

aircraft scheduled for introduction around 2010 will have an estimated 12 to 14 

million lines, and the Future Combat System planned for around 2015 will require 

an estimated 16 to 18 million lines of custom code, and some 60 million lines of

COTS, GOTS and open source. Correspondingly, in the F-4 introduced in 1960, 

software controlled some 8 percent of functionality by software, while software 

will control 80 percent of the F-22. 

The Task Force received briefings from three warfighting programs: FBCB2-Blue 

Force Tracking, F-22, and FCS. All three programs are viewed as important to the 

DoD war fighting mission. These three programs are described in Appendix C. 

Broadly speaking, the Task Force found that the three programs varied widely 

regarding the extent of their incorporation of COTS, their reliance upon general 

purpose Internet protocols (IP), and in their attention to risks posed by their supply 

chains. FCS and F-22 had processes to consider supply chain risks within the 

20________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

lifecycle. That said, none of the programs have in place a process to analyze the 

supply chain for the kinds of risk posed by a nation-state adversary. 

The Threat to DoD Software 

Prior to the development and broad adoption of the Internet, adversaries were in 

many cases forced to gain close access to their IT targets. This generally meant

that in order to be operationally effective, the opponent needed to have the 

resources and accesses typically associated with a nation-state intelligence service.

These activities were typically limited in scope, not easily scalable, and not a core 

operational technique. Additionally, during this period, the motivation for applying 

operational resources within this area was limited, as the value of the intelligence 

residing inside these systems was usually not high grade ore (with some notable

exceptions). With the introduction of the Internet, this rapidly changed. Not only 

did this bring into the game the hacker level adversary, it also significantly 

increased the utility and scalability of targeting IT. The volume of the gold and the 

grade of the ore simultaneously increased. 

Net-Centricity offers the DoD immense opportunity to increase effectiveness of

force projection, but also is an attractive target for those attacking the 

confidentiality, integrity, and availability of DoD data and systems. Future warfare

environments will involve information sharing by coalition forces via the Secret 

Internet Protocol Router Network (SIPRNET) as well as the Non-classified Internet 

Protocol Router Network (NIPRNET), thereby expanding greatly the number of 

persons with access and the potential for mischief. 

A combination of factors has produced a high-risk condition: system designers 

placing insufficient emphasis on security; an increase in the number and 

sophistication of attackers; the growing abundance and value of information on the

Internet; and a significant increase in utilization and dependence on the technology. 

Hacking techniques are widely disseminated and automated, while “defensible 

coding” is not. And, as the adage goes, developers must find all bugs, hackers need 

find only one. Thus, the advantage rests with the attackers. The defense has not 

begun to respond from an institutional perspective. From a defensive perspective, 

the preponderance of thought is that the challenge/threat is modest and DoDs 

defenses are adequate. After all, there has never really been a “smoking gun” that 

has caused concern or could not be explained away. This perspective undermines a 

core component of U.S. national security. 

The DoD does not fully know when or where intruders may have already gained 

access to existing computing and communications systems. The Moonlight Maze 

activities, which are classified and thus not detailed here, and numerous other data 

points demonstrate that the U.S. Government, specifically the DoD computing

systems, is a constant target of foreign exploitation. Further, the Eligible Receiver 

series of exercises have demonstrated an ability to penetrate and exploit selected 

DoD systems. And recently, the Commerce Department revealed that attacks by

Mission Impact of Foreign Influence on DoD Software_____________________________21 
Findings______________________________________________________________________

Chinese hackers forced one of its bureaus to cut off Internet access and discard

virus-infected computers. 

FINDING: Adversaries’ use of low-level cyber attack techniques to exploit weak 

information assurance controls and vulnerable software has led to successful attacks 

upon sensitive but unclassified (SBU) systems and networks of DoD and the defense 

and commercial industrial base. This has occurred notwithstanding extensive DoD 

efforts in security and information assurance. 

Attacks on computer systems are designed to breach (1) confidentiality, (2) 

integrity, or (3) availability. 

Malevolent modification of the system or its components is the most challenging to 

detect and protect. It is a domain that likely interests the United States most 

sophisticated potential adversaries far more than most other Internet aggressors, 

and also a domain in which the most sophisticated potential adversaries may have a 

decade of experience from tampering other systems (fielded and in development).

Net-Centric systems surely will attract sophisticated adversaries who can subvert 

the supply chain to replace or alter software or hardware, recruiting well-placed 

insiders and exploiting single-string dependencies. Even if the provenance of each 

part of an IT component can be determined, with precision, the complexity of the 

technology makes the challenge of discovering malicious constructs within those 

component(s) remarkably difficult. In fact, a classified experiment conducted in 

the mid-1980s demonstrated the overwhelming challenges of discovering 

subversion structures within microprocessor/software based systems of the time. 

Knowing how much to trust the software to do what, and only what, it is supposed 

to do is far from a science. Worse, having once lost confidence in a system, it is 

unlikely that such confidence will be readily restored. Military contests are, in fact,

contests of will, and if an adversary can cause the U.S. Military to doubt its own

capabilities, the United States determination will be lessened and their coercive

powers enhanced. A military legend is instructive: A combatant commander is said 

to have remarked that he would not go into battle unless his blood supply was 

assured and, in this context, he meant not only assured physically, but that the

information about the blood supply was equally assured—i.e., trustworthy. The

reality is that DoD does control its blood supply, but its control of the information 

system surrounding the blood supply could be placed in doubt. 

There are those with a deep understanding of the range of offensive options that can 

be arrayed to target IT and the corresponding impact of the associated security 

compromise. Unfortunately, for those in the information assurance camp, the 

problem seems overwhelming and while they quickly accept the magnitude of the 

problem and turn to seeking solutions and strategy, little effective progress has 

been made on the defensive side. Consequently, there is a large and growing gap 

between what a sophisticated offense can achieve and what a good defense can 

protect. By way of example, the offense has been hard at work for at least twenty

22________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

years (e.g., “The Cuckoo’s Egg”), but security efforts did not massively increase 

until 9/11. 

Recent computer/network intrusions into DoD systems have resulted in increased

national interest in this problem. Numerous studies have been conducted and more

are in progress, partly to ascertain the impact of such attacks. Congressional 

interest is growing. The Weapons of Mass Destruction (WMD) commission 

recommended starting a new Presidential commission focused on this national 

security challenge. Ironically, had it not been for an adversary’s use of simple and 

detectable offensive approaches, the DoD may not have had the current level of 

attention on this most important problem.

Opportunistic and Targeted Vulnerabilities 

Although the DoD needs to plan for a wide range of threats, attacks on DoD IT 

systems fall into three groups: opportunistic -- launch of a general attack on the 

Internet which, by extension, impacts DoD operations; specific targeting of DoD 

systems by someone without sponsorship or political motive; and specific targeting 

conducted by a dedicated (and potentially well-funded) adversary. The differences 

are important, especially when there is widespread reliance on commercial 

software. 

Opportunistic attacks involve actors who are not specifically targeting the DoD, but 

whose actions could nonetheless affect military operations. Worms (which may 

cause denial of service attacks) and spam (which can significantly impact costs and

productivity) represent this type of threat. Significantly, improvements in 

commercial software development practices – along with proper management of IT 

systems by implementing appropriate risk management and defense-in-depth 

strategies -- can eliminate this threat or greatly reduce its impact. 

Targeted attacks may come from different sources and be prompted by different 

motives. Throughout the 1990s, for example, hackers would often attack 

government systems because they made interesting targets and provided bragging 

rights. In some of those cases, the actor neither had a broader political motive nor 

state sponsorship. In these cases, better security – although perhaps providing 

more of a “challenge” -- may serve to drive the attackers elsewhere (much like a 

good home security system, the goal is not to defeat a concerted effort but to make 

the target less attractive). More importantly, better security may include better

auditing and evidence collection, thus ultimately resulting in the prosecution of the

hacker and the creation of a meaningful deterrent effect. 

The deterrent value of computer security is relatively small today, in large part 

because the number of hackers actually identified and prosecuted successfully is 

small, and criminal penalties are sometimes too lenient to provide real deterrence.

In some countries--both friend and foe--laws prevent or significantly reduce 

prosecutions. But commercial needs are driving better authentication on the 

network, governments are increasingly collaborating on cyber-crime investigations 

(note the recent U.S. ratification of the Council of Europe Cyber-Crime

Mission Impact of Foreign Influence on DoD Software_____________________________23 
Findings______________________________________________________________________

Convention, the first major cyber-crime treaty) and government-industry 

partnerships around Internet safety and cyber-crime prevention and response are 

growing. Thus, there is hope that greater deterrence can be created through better 

investigative practices and international coordination. 

In contrast to targeted attacks by non-sponsored individuals, sponsored attacks raise 

a different set of problems. Assuming an adversary is sufficiently motivated to

devote meaningful resources to a structured effort, better DoD IT security will not 

serve as an adequate protection. Additionally, there is no meaningful penal 

response, since a sponsoring country will not aid the victim country in investigating

and prosecuting the actors. Simply put, organized attackers using tradecraft can 

probe in perpetuity, looking for zero-day bugs (i.e., bugs unknown even to the 

product vendor), unpatched vulnerabilities, or misconfigurations of systems. No 

COTS development process will deliver a product capable of withstanding a 

dedicated nation-state attack -- attackers can reverse engineer patches faster than 

system administrators can test them and apply them, and configuration of complex 

heterogeneous systems remains difficult, even as vendors increasingly automate the

configuration process for their own products. Moreover, vendors do not prohibit

users from clicking on attachments, although more protective mechanisms (e.g., 

sandboxing) are now being deployed. State sponsored or organized transnational 

efforts can result in protracted attacks where information is slowly compromised. 

Relative Risks in COTS and Custom Software

COTS software development environments can be more easily penetrated than

custom development environments because: 

• COTS software contains other packages (not developed in-house) that are 

not tracked or otherwise flagged as “not invented here.” Consider the case 

in which a developer downloads an encryption routine off the Internet that 

may not be implemented well or that has been deliberately corrupted, and 

nobody knows that this package was downloaded from someplace else. 

Software not known to be there in the first place will not be factored into a

risk assessment. Obviously, this problem varies considerably from vendor 

to vendor, with significantly less risk coming from vendors with robust 

security development processes. 

• The software is known to contain “not invented here” code, but it is of 

unknown provenance and unknown security-worthiness. For example, 

consider a case in which object code is shipped with a commercial product 

and the vendor does not have source. Some code may have been there so 

long nobody remembers where it came from. Without source, it may be

difficult to vet security-worthiness. 

Thus, while COTS development environments are more porous to attack than those 

of DoD custom development environments, subversion or tampering with 

components destined for the latter are more likely to achieve adversarial objectives. 

24________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

In short, attacks on COTS are easier, but attacks on custom products are more

likely to meet the requirements of the adversary. 

The risk of damage from maliciously introduced vulnerabilities increases with the 

ease of adversarial access to the development environment. U.S. businesses and

foreign businesses with development based in the United States are not immune to 

adversary manipulation by U.S. citizens or “outsiders” infiltrated into a domestic

operation. That said, an adversary with “home court advantage” finds it safer and 

cheaper to manipulate the production and distribution of software products in its 

own control. 

Reliability engineers have long recognized that frequent modification of software 

through patching can reduce reliability by introducing new flaws, even while some

patching brings upgrades to fix reliability issues. The less obvious but more

serious concern is the use of patches to deliberately introduce new exploitable 

vulnerabilities or to sustain old ones. As with any supply chain, the entirety of the

supply chain is only as secure as its weakest link and ongoing maintenance is, 

unhappily, a fact of life. Seldom is the entire supply chain under a single auspice, 

so the continuing maintenance permits new actors to enter in a variety of guises. 

The Nation-State Adversary

System administrators and information assurance officers are often pre-occupied

with everyday “hacker and patch/update” activities. Many see these as the only

threats, overlooking the far greater risks posed by the approaches/techniques of the 

high-end threat posed by sophisticated adversaries. 

Even if a target is either not connected or has no known exploitable vulnerability, 

the adversary must find a way to get close to the target or to introduce vulnerability

through a life-cycle operation. It is this vector that separates the hacker from the 

sophisticated adversary. It is this vector that provides abundant operational 

opportunity for the sophisticated adversary who can take advantage of the global IT

market from an access perspective. 

It is the consensus of the Task Force that sophisticated nation-state adversaries will 

examine the possibilities of exploiting supply chain weaknesses in DoD acquisition

of critical systems. These adversaries will then seek to exploit such weaknesses to

degrade or deny capability of critical systems if they determine it is their best 

option to ensure damage while remaining hidden. These adversaries will attack to

their best advantage, and their advantage improves significantly when software 

development moves under their control through the globalization of software

development. The Task Force sees exploitation of software and hardware

development or production as a key area for such adversaries. Bottom line:

globalization of software development, where some of the United States

adversaries are writing the code the DoD will depend upon in war, creates a rich

opportunity to damage or destroy elements of the war fighter’s capability. 

Mission Impact of Foreign Influence on DoD Software_____________________________25 
Findings______________________________________________________________________

FINDING: The enormous functionality and complexity of IT makes it easy to 

exploit and hard to defend, resulting in a target that can be expected to be exploited 

by sophisticated nation-state adversaries. 

Scope and Character of the Threat from a Nation-State Adversary

Unlike the terrorist, the nation-state adversary seeks to create subversions that 

persist even years into the future, while remaining hidden, as a key objective of a 

nation-state adversary is to put in place reliable offensive capabilities well in

advance of need. The ability to subvert a system through supply chain exploit, 

while remaining hidden, is greatly enhanced by deep knowledge of the context 

within which the tainted subsystem will operate (e.g., system design, intended use) 

or what components it will include. 

The nature of espionage is changing in the age of globalization, but in many cases, 

U.S. characterizations of an intelligence organization are mired in the past. This 

becomes a problem for those who are a target of such an organization and still have 

defenses in place to deal with the old threat. During the Cold War, clandestine 

technical operations were primarily used to support human recruitment, but today 

these technical activities are becoming more of the main act. In fact, human 

operations are increasingly being used to support technical operations. For one 

embracing the old paradigm, this is somewhat counter-intuitive. 

This transition is largely due to rapidly growing utilization of technology to create, 

store, manipulate, and communicate secrets. Secrets are no longer the exclusive 

domain of safes and the minds of targets. Additionally, based upon DoDs

overwhelming dependence on technology, the target is not always the secret but 

increasingly the target is the integrity and availability of the technology itself to

support its intended mission. As mission-critical systems become progressively 

more reliant upon technology, a denial of service attack becomes extremely 

attractive. At the core of most of this advanced technology is software. 

FINDING: Nation-state adversaries are able to employ a full spectrum of offensive 

intelligence trade-craft, including attacks that subvert the supply chain, to damage 

or defeat mission-critical systems. The risk from such supply chain exploits can 

only increase as larger portions of the supply chain become more accessible to the 

adversary through global sourcing. 

A common, but incorrect, perception is that the only way for a sophisticated

adversary to attack a network-accessible target is with cyber tools. While having a 

negative impact on the confidentiality, integrity, or availability of the cyber target

is the operational objective, the adversary has a rich array of tools at its disposal: 

surreptitious entry, spies, signals intelligence (SIGINT), clandestine technical 

collection, cyber, foreign partners and the use of cover companies. This array of

tools allows the sophisticated adversary to conduct a targeting assessment to 

determine how it can meet its operational requirements while minimizing costs and 

risks. 

26________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

Once this assessment is completed and a high-level plan developed, the full 

spectrum of modern day espionage is engaged: operational access options are 

examined; partners are approached; special technology is developed; and where 

appropriate, legal/policy constraints are examined. This opponent gets to pick the 

time, the place, and the combination of methods conducted within a veil of secrecy

to achieve their objectives. The synergistic and mutually supportive nature of these

tools/approaches can yield powerful offensive results. This offensive paradigm is 

often ignored, dismissed as not real, or deemed too difficult to handle. For 

mission-critical applications, this may well lead to mission failure. 

As the importance of life-cycle access to a sophisticated adversary’s success 

becomes more evident to the DoD, a reasonable conclusion to draw would be to

significantly limit these access opportunities to the adversary by mandating all 

software and hardware be designed, developed, tested, distributed, and maintained 

only by trusted agents. Unfortunately, even if these agents were U.S. companies, 

the door for access opportunities would be far from closed to the adversary. By 

design, a sophisticated foreign intelligence service has the ability to operate 

clandestinely within the United States backyard. 

There are other factors that compound the magnitude of the defensive challenge.

First, it is well understood that the COTS strategy for DoD is an important part of 

its business model for mission success. A corollary to this strategy is that

provenance of the piece parts of the software is increasingly foreign. As discussed 

above, each of the foreign pieces provides an access opportunity for the adversary. 

Second, even if one knew with precision the provenance of each part, the 

complexity of the technology makes the challenge of discovering malicious

constructs within the component(s) remarkably difficult. 

Third, the technical and operational ease of altering software coupled with the

scalability and inexpensive character of the approach make it a very desirable 

offensive strategy. 

A summary that characterizes the gap between the location of a sophisticated 

offensive operation and the United States best defensive, implemented strategy is 

found in The Digital Dimension: 

The defensive challenges are daunting! Today there is no 

clear approach to effectively offsetting the advantages of 

the offensive adversary. What are the intrinsic 

characteristics and environmental factors of the defensive 

situation that have resulted in a growing gap between 

offense and defense? They include technology complexity; 

impracticality of comprehensive evaluation; design, 

production, and maintenance functions performed globally; 

imbalance of focus and competing aspects among 

confidentiality, integrity, and availability; insufficient 

Mission Impact of Foreign Influence on DoD Software_____________________________27 
Findings______________________________________________________________________

insight into the offensive investments, approaches, and 

organization of opponents; lack of coordination and 

cooperation between offensive and defensive elements; no 

national-level ownership; and the absence of a national 

research - investment strategy.11

The Risk in Low-Level Attacks

FINDING: Nation-state adversaries’ penetration of sensitive-but-unclassified 

systems and networks could allow them to steal system information or tamper with 

system artifacts, enabling them to target existing and future DoD Systems. 

The software that is being developed for military purposes, as well as the software 

that can be predictably expected to be used by DoD or other high value targets, is 

stored as data within networks of commercial industry and the DoD industrial base.

When the networks of these organizations are penetrated, such software can be 

stolen. This is a significant problem for intellectual property protection and

acquisition program protection. However, frequently confidentiality attacks are not 

as pernicious as integrity and availability attacks. Software and other elements 

(e.g., Application-Specific Integrated Circuit (ASIC) designs) can be tampered with 

(back doors, logic bombs), or other defects inserted. This can expose DoD systems

yet to be fielded to operational risk. 

Knowledge of the Nation-State Adversary Threat

FINDING: DoDs defensive strategies and techniques remain inadequately informed 

of the sophisticated capabilities of nation-state adversaries to exploit globally 

sourced, ubiquitously interconnected, COTS HW/SW within DoD Critical Systems, 

and the potential consequences of system subversion. 

Currently, there are no effective means for incorporating critical information 

regarding major cyber attack/subversion into DoD mission planning. Military

exercises do not include consideration of system failure due to cyber attack or other 

covert means of subversion as an element of the exercise. There is no strategic 

consideration of command and control failure within mission planning as has been 

required historically for critical command and control (e.g., within nuclear 

command and control). Yet the high levels of interconnectedness among IT 

applications in C2 and sensitive-but-unclassified networks yield ever increasing

opportunities for large-scale failure. These failings are a natural consequence of 

the historical disconnect between those who attack systems and those tasked with 

defending them. 

As described above, there is a tendency to take a narrow view of the nation-state 

adversary threat, believing that it is limited to cyber operations only. This arises 

from a number of factors that prevent those acquiring, defending and operating 

 

11 Sims 2005

28________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

systems and networks from getting full information regarding the scope of the 

threat. 

1. Real knowledge of what the adversary is capable of is tightly held within 

the offensive operational community for fear that disclosing such 

information will hinder the ability to use those capabilities. 

 

2. There is no clear understanding within the offensive operational community 

of the defensive actor’s need to know such information, and the risk to 

national security if the defense does not understand the adversaries’ 

capabilities.

3. The amount of offensive information to be disclosed and the number of 

defensive players with a need to know requires that highly compartmented 

information be so “watered down” during declassification, that it may be 

too vague to be actionable. 

FINDING: The Intelligence Community (IC) does not deliver timely, actionable 

intelligence regarding the intents and capabilities of nation-state adversaries to 

attack and subvert DoD systems and networks through supply chain exploitations, 

or through other sophisticated techniques. 

In 2002, the Intelligence Community Acquisition Risk Center (ICARC) led an 

effort to review and improve collection requirements for supply chain threat in both 

the signals intelligence (SIGINT) and human intelligence (HUMINT) arenas. It 

appeared to have little or no impact or follow through. There is little evidence that 

such proposed changes were adopted, and even less evidence that these 

requirements, if adopted, would have pushed far enough up the resources chain to 

have impact. What is needed is a thorough revamping of the collection 

requirements to capture the capabilities and clarify the intent of nation-state

adversaries to exploit the supply chain. Also required is some education for the 

collectors and taskers to ensure that there is an understanding of the criticality of 

such information. For instance, information is needed on the movement of 

intelligence officers from and to commercial companies, as well as ties that the

intelligence services develop with commercial entities, whether through infiltration, 

investment or partnering. 

Without a better understanding of the capabilities and intents of nation-state 

adversaries, DoD and the U.S. Government run the risk of investing heavily in 

areas of protection of IT software and hardware when in fact there is no plan or

capability to exploit it. Alternatively, without a clear understanding of the threat,

program managers are likely to refuse to expend funds on protecting their systems

from an unproven threat, thereby enabling a sophisticated adversary to do 

maximum damage at little risk or cost. 

Mission Impact of Foreign Influence on DoD Software_____________________________29 
Findings______________________________________________________________________

FINDING: The risk of undetected subversion of custom software is considerably 

greater than the corresponding risk for COTS. 

Adversaries’ Model of Risk Management

This report details and will later recommend a greater utilization of risk 

management techniques. While it is understood that there will never be a perfect 

defense, it is not well understood how to perform effective defensive risk 

management in today’s IT environment. At a minimum, one must characterize

systems, keep these characterizations current, know the impact of 

system/component compromise, understand the intentions, motivations, and 

capabilities of all adversaries, discover system vulnerabilities and threats,

apply/develop techniques to close the vulnerabilities, and exercise incident 

response plans in preparation for an event. 

Often overlooked is the importance of the defense’s understanding of the risk 

management factors and decision factors of the opponent. A defensive posture is 

enhanced by addressing these factors. The offense must ask: 

• What is the utility/intelligence gain of conducting the operation? 

• What is the cost (dollars, people, opportunity, etc.) of conducting the 

operation? 

• What is the likelihood of the opponent’s defense detecting my operation? 

• What is the probability of the opponent attributing this operation to our

organization/country? 

• What are the consequences of the operation being discovered and attributed 

to us?

• What are alternate operational approaches to meeting our requirements? 

By more deeply understanding the adversary’s answers to these questions and the 

weight that they attach to each factor, the U.S. will be better positioned to optimally

apply both active and passive defensive resources. As long as the impact of

defensive compromise remains high, these assessments, investments, operations, 

and strategies must be developed and acted upon. This must not be a static 

exercise. It must be continuous and relentless. 

The State of Software Assurance in the DoD Today 

In the security context, software assurance is best defined as the level of confidence 

that software is free of vulnerabilities either intentionally or unintentionally 

designed or inserted during the software development and/or the entire software

lifecycle. The true goal of software assurance is to prevent the exploitation of

software, thus increasing its dependability and defensibility.

30________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

Vulnerabilities in DoD Code

FINDING: Software deployed across DoD continues to contain numerous 

vulnerabilities and weak information security design characteristics. DoD and its 

industry partners spend considerable resources on patch management, while 

gaining only limited improvement in defensive posture. 

The DoD Information Assurance Vulnerability (IAV) Management (IAVM) 

process was created to prepare and rapidly disseminate mitigating actions for 

potentially critical software vulnerabilities to DoD Components. IAVM notices 

have three criticality levels: 

• IAV Alert (IAVA) – most critical – a vulnerability posing an immediate and

potentially severe threat to DoD systems. 

• IAV Bulletin (IAVB) – less critical than IAVA, but pose a threat to DoD 

systems. 

• IAV Technical Advisory (IAVT) – less critical than IAVB. 

Figure 7, on the next page, shows that the total number of vulnerabilities resulting 

in IAVM notices has increased each year, as has the number of the most critical 

IAVAs and IAVBs. The number of IAVTs decreased in 2006, but since the total 

number of notices increased, reported vulnerabilities tended to be more critical in 

2005 and 2006: 

0

20

40

60

80

100

120

140

199819992000200120022003200420052006

Number of Notices

IAVA:

most

critical

IAVB

IAVT

Total

Notices

Figure 7. IAVM Taskings Issued 

These IAVM figures only include the most critical vulnerabilities and do not count

multiple vulnerabilities addressed within a single alert; the true number of publiclyknown software vulnerabilities is far greater. Over 17,000 vulnerabilities have 

been publicly published on the Internet from 1998 through mid-2006; over 6,000 of 

them could cause root-level compromise, yet only 423 IAVM notices have been 

published in that period. Thus IAVM notices do not include 93 percent of the 

Mission Impact of Foreign Influence on DoD Software_____________________________31 
Findings______________________________________________________________________

publicly-known root-level compromise vulnerabilities, and do not include 98 

percent of the publicly-known vulnerabilities. 

There are simply more vulnerabilities than DoD can handle: Issuing an IAVM for 

each release of a new remote root compromise vulnerability would render the 

IAVM program ineffective and cost DoD precious resources. Alerts provide 

priority of effort in vulnerability mitigation to limit burden and resources

imposed.12 In addition, for mission-critical or complex software, programs are 

unlikely to be patched quickly regardless of the severity of the issue, precisely

because the systems are so critical or complex. Such conditions mandate 

significant testing before patch deployment. Other reports have also found that the 

number of software vulnerabilities reported annually is rapidly increasing.13

Common Criteria

FINDING: The primary processes relied upon by DoD for evaluation of the 

assurance of commercial products, Federal Information Processing Standards 

(FIPS) and NIAP Common Criteria Evaluation Process, do not address software 

vulnerabilities except for higher assurance levels (if at all). Moreover, these 

processes do not scale to the volume of software critical to the DoD mission. 

In 1997, NSA and NIST established the National Information Assurance 

Partnership (NIAP) with the goal to increase the level of trust consumers have in 

their information systems and networks through the use of cost-effective security 

testing, evaluation, and validation programs. Using the Common Criteria as its 

standard14 for evaluating information assurance products, the NIAP Common 

Criteria Evaluation and Validation Scheme was established in 2000. The Common 

Criteria enables the validation of security functionality, and improves confidence 

that the product is free of vulnerabilities through an increasing set of evaluation 

assurance levels (EAL1 through EAL7). At levels above EAL4, nation-specific 

methodologies are required; however, at EAL4 and below, the 

evaluations/validations are recognized by countries through the Common Criteria 

Recognition Arrangement. NIAPs prime mission is to evaluate/validate information 

assurance products, not specifically software, but a substantial amount of software

is evaluated at varying functionality and assurance levels through NIAP and the 

Common Criteria Recognition Agreement for use within the DoD. 

Common Criteria (CC) evaluates the extent to which a product’s security features 

comply with a formal description of those features. The description may be either a 

(government) user-provided “Protection Profile” or a developer-provided “Security 

Target.” Evaluations against a Protection Profile assess the extent to which a

product complies with user requirements – evaluations against a Security Target 

merely evaluate the extent to which the product does what its developers say it 

does. 

 

12 Lawrence 2006 13 ISS 2007, Messmer 2007,. Lemos 2006 14 ISO 15408

32________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

Because most product vulnerabilities arise at the implementation (code) level, and 

because evaluations at EAL4 and below focus only on the product’s design

documentation, Common Criteria evaluations at EAL4 and below have no real 

bearing on confidence that a product is reasonably free from vulnerabilities. 

The NIAP was formally assessed through a Government Accountability Office 

(GAO) study and informally through a variety of draft DoD documents. One 

advantage of using the Common Criteria is that it replaced multiple, country 

specific evaluation criteria that forced the vendors to evaluate the same product, at 

great expense, in multiple venues. With the addition of the Common Criteria 

Recognition Arrangement, vendors received definite cost benefits, recognition for 

their evaluated information assurance products within a more global market place, 

and the amount of labs evaluating products expanded while adding competition for 

their evaluation services. On a case-by-case basis, other advantages have included 

improvements in product developmental practices, and some reduction in 

vulnerabilities especially during the design of security features. Criticisms of 

Common Criteria-based schemes are that they are expensive, require artifacts that 

are not produced until well after product design and implementation, do not 

substantially reduce implementation-level vulnerabilities when using today’s 

software development practices, and lack thorough penetration analysis at EAL4 

and below. There is, therefore, an effort to promote a new regime that addresses 

these concerns. 

Capability Maturity Model

Late in 1986, the DoD asked the Software Engineering Institute (SEI) (a DoD 

sponsored federally funded research and development center focused on improving 

the state of the practice of software engineering) to develop a method for assessing 

the capability of software contractors. The Software Engineering Institute 

developed a process maturity framework that would assist organizations in 

improving their software engineering processes. In September of 1987 the SEI 

published the process maturity framework and a maturity questionnaire to be used 

as a simple tool to identify areas where an engineering organization’s software 

process needed improvement. This initial work was based on the premise that the

quality of a software product is largely determined by the quality of the process 

used to develop and maintain it. 

Over the next several years the DoD, defense contractors, and the SEI gained 

experience in using the maturity framework and questionnaire, and interest in 

software process and software process improvement grew substantially. The SEI

used its experience in conducting software process assessments and extensive 

feedback from government and government contractors to mature the framework 

and to evolve it into the Capability Maturity Model (CMM) for Software.15 The

CMM provides a structured approach to apply the principles of Total Quality

Management to software development and maintenance. It helps software 

 

15 Paulk 1993

Mission Impact of Foreign Influence on DoD Software_____________________________33 
Findings______________________________________________________________________

organizations gain control of their software processes, identifies key practices that 

organizations should adopt to achieve improvement, and provides a framework for 

process improvement that allows organizations to develop higher quality software

at lower cost. Studies of the effectiveness of the CMM conducted by the SEI16 and 

others17 clearly demonstrate that organizations can gain substantial benefits from

investing in software process improvement: earlier detection of software defects

during the development process, reduction of defects in deployed software, 

reduction in calendar time to develop software systems, and overall productivity 

improvement. 

Since 1993, momentum behind the process improvement concepts has increased 

dramatically and the concepts embodied in the CMM have been applied to other 

aspects of the engineering process: e.g., managing the engineering workforce using 

the People Capability Maturity Model18, improving the software acquisition 

process using the Software Acquisition - Capability Maturity Model (SA-CMM)19, 

improving systems engineering process using the Systems Engineering Capability 

Maturity Model20, and improving organizational and project management using the 

Integrated Product Development Capability Maturity Model.21 To respond to the 

growing interest in maturity models and the need to integrate them in a coherent 

way, in 1998 the Office of the Under Secretary of Defense for Acquisition and 

Technology, with co-sponsorship from the National Defense Industrial Association, 

initiated the Capability Maturity Model Integration (CMMI) project to establish an

overall framework that could accommodate current and future models. This work

has resulted in the release of the initial CMMI product suite in 2002 and most

recently in the CMMI for Development Version 1.2.22

While use of the CMMI products by DoD contractors and others continues to grow

substantially and organizations that adopt the models continue to show substantial 

improvements in their ability to develop higher quality products with improved 

schedules and lower costs23, it is important to note two key points for 

the purposes of this report. 

First, while the CMMI product suite includes rigorous methods to assess an 

organization’s capabilities, and many individuals are trained and authorized to 

conduct quality assessments, the assessments produced are assessments of 

organizations’ potential to create high quality products, but not a guarantee that 

they will do so on any particular project. Process assessments by themselves do not 

examine the outputs of any development effort and are therefore silent with respect 

to the quality attributes of any particular product. A positive process assessment 

 

16 Herbsleb 1994 17 Dion 1993, Lipke 1992, Wohlwend 1993 18 Curtis 2003

19 Cooper 2002 20 EIA 1998 21 DoD 1996 22 CMMI Product Team 2006 23 Goldenson 2003

34________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

finding lowers the risk that an organization will produce a low quality product but 

the quality of the product itself must be assessed using other methods. 

Second, while today’s models help organizations improve the overall quality of the 

products they produce, they provide no guidance for dealing with specific security 

concerns such as protecting against the intentional insertion of malicious code 

during the development process. Further research and development is needed to 

augment today’s models with specific security improvement practices that would 

be effective at protecting against the threat of errors that would inadvertently 

introduce security vulnerabilities or attacks that would lead to intentionally 

embedded malicious code. The current CMMI models are a good foundation for 

these new practices and building the new practices on that foundation would help 

promote faster transition of the practices to the large and growing community of 

DoD contractors and other software developers that have already invested in 

adopting the CMMI models. Also, as mentioned above, process assessments must

be augmented with improved product assessments to provide the level of assurance 

needed for critical systems. 

Existing DoD Information Assurance Policies to Address

Software Vulnerability 

Several national security and DoD information assurance policies provide guidance 

applicable to assuring software for the DoDs most critical systems. DoD Directive 

8500.1 on information assurance specifies that information assurance requirements 

be included during the acquisition of all DoD information systems. This policy 

also directs compliance with the National Security Telecommunications and 

Information Systems Security Policy #11, which requires that all information 

assurance and information assurance-enabled IT hardware, firmware, and software

be properly evaluated and validated by specifically defined criteria. Additionally,

DoD 8500.1 directs the thorough assessment of risks for software with limited 

warranties or software that is freeware or shareware. 

Risk assessments are made within the certification and accreditation processes.

The DoD is now using the DoD IA Certification and Accreditation (C&A) Process

(DIACAP) for systems. DIACAP requires identification of the security 

requirements and an independent analysis certifying the completion of those 

requirements. Accreditation occurs when the residual risks are managed and the 

system is allowed to go operational. The definition of “system” varies. For the 

most part, a system is comprised of a number of hardware and software 

components. Information technology products should not be confused with the 

system itself, and the verification of the security requirements is resolved by 

analyzing the entire system and not merely the individual products of which it is 

composed. The role of software assurance within the overall certification and 

accreditation of systems is critical. Many of the security requirements will be

implemented in software, or use software in conjunction with hardware support at 

the system level. 

Mission Impact of Foreign Influence on DoD Software_____________________________35 
Findings______________________________________________________________________

Although it is not practical to ensure that all software is vulnerability free, gaining 

confidence in the software development practices of the developers is crucial. A

third party product evaluation process should provide usable information to make 

certification and accreditation both more effective and more efficient.

Unfortunately, the current use of Common Criteria falls well short of this goal. In 

addition to product certifications, particularly critical systems may need to be 

formally modeled, formally specified and developed, thereby adding a 

mathematical basis to the development of the software. Assurance is additionally

gained by independence in the certification and accreditation processes. The search

for vulnerabilities should start with ensuring the proper security requirements, 

searching for design vulnerabilities, building vulnerability searches during the 

development of the code, and by having approved configuration management and 

change management procedures in place throughout the entire lifecycle. The level 

of assurance is also affected by the supply chain: Who built the code? Where was 

the software developed? What control processes were in place? How was it 

distributed? Who integrates it into the final product? Who administers the code? 

How are upgrades performed, and by whom?

Appendix C describes three large DoD programs that incorporate extensive 

software, and how issues of assurance were managed in these programs. 

FINDING: The Task Force identified considerable variation in the extent to which 

the Systems Assurance Problem is impacting next-generation DoD systems. That 

impact ranges from extensive with the introduction of inter-networked COTS and 

open source IT into the Army’s Future Combat System (FCS) program, to only 

slight in the USAF F-22 program. 

Ongoing Efforts in Software Assurance 

DoD programs are addressing the implications of the Systems Assurance Problem 

on a program-by-program basis. Currently, there is no comprehensive policy in 

effect to address this problem. Acquisition programs addressing the Systems

Assurance Problem, such as FCS, while managing risk in a reasonable way, are 

assuming too much without adequate analysis. This is being encouraged by 

adoption of strategies or assumptions whose very applicability is highly doubtful 

(e.g., that the profit motive of COTS provider will weed out foreign intelligence 

front companies or that DoD can make blind purchases where vendors do not know

their products are destined for DoD use). Managing the systems assurance problem 

is best accomplished by augmenting and amplifying activities not currently second

nature within acquisition programs: enterprise architecture, systems engineering,

information assurance, program protection, vulnerability detection, etc. 

The DSB explored the security risks due to globalization in a DSB Task Force on 

“Globalization and Security,” December 1999. DoD and the intelligence 

community have been steadily working the software and systems assurance 

problem. In 2002, the Intelligence Community Acquisition Risk Center (CARC)

acquisition process of the CIA was broadened to include the entire IC, pursuant to 

36________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

DCID 7/6. The ASD(NII)/DoD CIO established the Software Assurance Initiative

in October of 2003. Based upon the findings and recommendations of the 

ASD(NII)/CIO Software Assurance Initiative, the USD(AT&L) and

ASD(NII)/DoD CIO established the Software Assurance Tiger Team (described

further in the next section). In addition, beginning in 2005, the Committee on

National Security Systems (CNSS) established the Globalization of IT Working 

Group (GITWG) to examine the problem from a national perspective and develop a 

national strategy. 

FINDING: DoD Critical Systems and networks remain vulnerable to the 

sophisticated capabilities of Nation-state adversaries. USD(AT&L) and 

ASD(NII)/DoD CIO, through the efforts of the DoD Software Assurance Tiger Team 

and the CNSS Globalization of IT Working Group (GITWG), have developed a 

comprehensive strategy and CONOPS for addressing the systems assurance 

problem within DoD and an approach for the Federal Government at large. 

DoD efforts, culminating in the DoD Software Assurance Tiger Team, have led to a 

Systems Assurance Concept of Operations (CONOPS). Within the DoD System 

Assurance CONOPS, operational needs are translated into a requirement for

assurance through a prioritization process, which identifies the critical systems. 

Acquisition programs for these critical systems employ systems engineering 

processes with measures to identify critical subcomponents, and then deploy 

designs to protect them. These critical subcomponents are then subject to more

rigorous oversight, source selection, design, production, and test (e.g., F-22). Most

importantly, such components are protected from components of lesser criticality 

by functions implemented with the same level of assurance as the functions they 

are defending. 

To compete for system procurements, industry suppliers must meet security and 

trustworthiness requirements commensurate with the criticality of the component 

and in light of all-source threat information. The Science and Technology strategic 

element is envisioned to identify best-of-breed tools and techniques, and to provide 

such tools and expert support to acquisition programs. It should also provide

incentives to and coordinate with industry to invest in developing standards and 

tools for vulnerability prevention, detection, and mitigation. Outreach efforts focus

on standards activities and seek to build a national market for relevant classes of 

assured products and the tools that support building, testing and certification. 

In the opinion of the Task Force, the systems assurance CONOPS, properly 

resourced, is an effective way for DoD to organize its risk manage processes to 

address the system assurance problem efficiently and cost effectively. Details of 

the Systems Assurance CONOPS are described in the recommendations. Success 

of the program also hinges on a significantly enhanced IC role only touched upon 

in the CONOPS. This fuller role for Intelligence and its relationship to the 

CONOPS will be discussed in the recommendations. Therefore, the Task Force 

endorses the engineering-in-depth concept of the DoD Tiger Team 2006, which 

will be explained later in this report. 

Mission Impact of Foreign Influence on DoD Software_____________________________37 
Findings______________________________________________________________________

Other Efforts within DoD and Government Agencies

Aside from the efforts of the DoD Software Assurance Tiger Team to strengthen

DoD policies on software assurance, DoDs broader involvement in software

assurance remains fragmented. The focus is on defense-in-depth, the Information 

Assurance Vulnerability Alert (IAVA) software patching process, and the decisions 

of individual program managers within the services to stipulate software assurance 

contract requirements--code review, need for security clearances for custom code 

developers, vetting of COTS vendors, etc. The DoD has recently issued policy on

software assurance procedures required when contracting for managed enterprise 

services, but there is no overarching policy or guidance in place to support program

managers in managing these risks. 

Most other government agencies simply do not have DoDs focus on software 

assurance, both because they have less at stake and far fewer resources. In 2006, 

the Committee on National Security Systems sponsored a Global Information 

Technology Working Group to propose ways to mitigate risks of supply chain

attacks on software and hardware used within the National Security Systems. The 

report, entitled “Framework for Lifecycle Risk Mitigation for National Security 

Systems in the Era of Globalization,” was released in May of 2006. The Working 

Group found the risk to national security systems from globalization to be 

increasing rapidly and judged DoDs defense-in-depth approach as no longer 

sufficient given the new challenges of globalization. Many of the Group’s 

recommendations for the DoD parallel those of the Tiger Team, whose members

participated in the effort. Some of the Working Group’s key recommendations 

were: 

• Adopt a “defense in breadth” policy to encourage and even mandate the use 

of a broad range of security policies and procedures that mitigate the risks

from globalization. 

• Identify standards and best practices for establishing security requirements 

and better assured IT products and services by bringing together key 

elements of the U.S. Government, industry, and academia. 

• Create a national clearinghouse for all-source information about suppliers of 

software and hardware, to improve the government’s understanding of any 

risks associated with the use of specific suppliers in acquisitions. 

• Advance U.S. capabilities to test and evaluate IT products to determine 

proper assurance levels, including the creation of a national focal point to 

coordinate test and evaluation advancements across government, industry 

and academia. 

The Working Group was co-chaired by DoD and DHS. In addition to DoD, DHS is 

one of the few Federal agencies actively engaged in seeking broad-ranging 

38________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

mitigations to the software assurance risk posed by globalization. DHS efforts in

this area, which are coordinated with DoD/NII, focus on working with the software

development industry and academia to raise the bar on acceptable levels of 

unintentional vulnerabilities routinely written into COTS software. DHS is looking

at how to encourage universities to inculcate the importance of developing secure 

software into the curricula. DHS is also sponsoring the creation of an acquisition 

management guide for software assurance, aimed at assisting government program

managers and contracting officers with incorporating requirements for software 

assurance within their Request for Proposals (RFP) for custom code development

and COTS purchases and integration. 

Supplier Trustworthiness Considerations 

FINDING: DoD does not consistently or adequately analyze and incorporate into its 

acquisition decisions the supply chain threat information that is available. 

It is not currently DoD policy to require any program, even those deemed critical 

by dint of a Mission Assurance Category I status, to conduct a counterintelligence 

review of its major suppliers, unless classified information is involved. Indeed, the 

current DoD acquisition model for procurement of hardware, software and systems

does not require a counterintelligence review of the proposed supply chain for any 

acquisition. Some programs do conduct such analysis of their own volition, but 

such analyses do not follow a particular methodology and typically focus on quality 

and availability of product. Even if such analyses are performed, there is no

accepted process for excluding the supplies that fail the evaluation. 

 

A few programs, such as FCS, do require that the prime contractor make an effort 

to review information on its subcontractors. Even in the unusual circumstances 

where such reviews are conducted, they do not involve the use of all-source 

analysis or a methodology to conduct the review. Up until now, most programs 

conduct no systematic counter-intelligence review of the supply chain, and 

programs could not request assistance from the ICARC or even learn what 

information was already available there. 

Recently, DoD has established a nascent presence in ICARC. However, programs 

are generally unaware of that presence, and are not required to utilize it. In any

event, the current presence in ICARC of two DoD officers would be insufficient to 

review even the most critical systems. 

Supplier trustworthiness enters into existing DoD acquisition processes primarily 

for protection of classified information and for research technology protection. The 

notion of supplier assurance included within the Systems Assurance CONOPS is 

only incidentally addressed by the policies for protection of classified or research 

technology protection. Programs protected by these policies may still have flagrant

failures of supplier assurance, both because those policies that do exist are often not 

adhered to, and because the policies are inadequate to the task. 

Mission Impact of Foreign Influence on DoD Software_____________________________39 
Findings______________________________________________________________________

Protection of classified information is addressed through the National Industrial 

Security Program (NISP) and Operating Manual (NISPOM) and the associated

personnel security processes. Properly applied, these policies ensure that classified 

information is only distributed to suppliers that are not under foreign ownership 

control or influence, or that any preexisting foreign ownership or influence is 

adequately mitigated through proxies and special security agreements, and that 

these suppliers have adequate security practices and vetted personnel to store and 

properly use the classified information. Research technology protection is 

implemented through policies on program protection, the use of anti-tamper and the 

provision of counterintelligence support to prevent technology espionage. 

These traditional counterintelligence and security activities are principally designed

to protect classified information and technology from espionage as it enters the 

U.S. industrial base or is used in an operational setting. The supplier assurance 

element of system assurance is concerned with the protection of DoD systems and 

networks from corruption through the incorporation of tainted components from the 

supply chain. These supply chain risks exist regardless of whether classified 

information is distributed to the supplier, and even if DoD research technology is 

not involved. From a systems assurance perspective, supplier trustworthiness 

considers adversarial control and influence of the business or engineering processes 

of the supplier, as well as the strength of the business and engineering processes 

from outside penetration. 

Other National Security Acquisition Models 

The intelligence community has a more rigorous process to conduct all-source 

analysis of its suppliers, aimed at discovering counterintelligence threats, as well as

companies with criminal, terrorist, fraud or financial issues. The process is used in 

some parts of the intelligence community to examine all primes awarded contracts,

whether classified or not, as well as any subs doing classified work. Other parts of 

the intelligence community use the process more selectively, targeting high risk

areas, and particularly software and hardware buys. Some parts of the intelligence 

community require that all custom code be written by U.S. citizens, and even only 

by cleared individuals. However, the intelligence community does not routinely 

require its contractors to develop software and systems through a process such as 

that proposed by the DoD Tiger Team. 

Detecting Vulnerabilities 

FINDING: The growing complexity of the microelectronics and software within its 

critical systems and networks makes DoDs current test and evaluation capabilities 

unequal to the task of discovering unintentional vulnerabilities, let alone malicious 

constructs. 

Vulnerabilities are weaknesses in software. As with other disciplines of

engineering, such weaknesses result from design or implementation of the system. 

Also, such weaknesses can be unavoidable, accidental, or intentionally introduced, 

40________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

and intentionally introduced vulnerabilities are expected to be well concealed. For 

large scale software, most vulnerability detection techniques struggle toward high 

reliability detection of accidental weaknesses, and are far more likely to find

accidentally introduced weaknesses, where there is no effort at obfuscation. In this 

context, finding deeply hidden functionality such as well concealed malicious 

functionality is a much harder problem. 

For most software systems, because the number of combinations of internal states 

is practically infinite, it is not possible to effectively uncover such hidden 

functionality through blind testing. Discovering such hidden functionality requires 

thorough analysis by human experts working with powerful tools in processes not 

conducive to automation, and this level of reverse engineering and thorough 

manual analysis is rarely performed except for things like nuclear command and 

control systems. Moreover, the art of finding hidden functionality is interleaved in

a number of ways with the art of hiding functionality, so it is not a skill easily

taught broadly without complication, lest too many people are in the art of hiding 

functionality. 

FINDING: The problem of detecting vulnerabilities is deeply complex and there is 

no silver bullet on the horizon. 

Source Code Analysis Tools 

One class of source code analysis tools, model checking, has improved 

dramatically over recent years. Research has produced tremendous progress in

software analysis tools and techniques for verifying safety and security of software 

prior to software deployment. However, it is also important to understand the 

limits of what such techniques might ever be capable of achieving. Progress over 

recent years includes lowering false positives from hundreds of false positives per 

true positive to a level where false positives and true positives are roughly equal,

while dramatically increasing the number of bugs found and breadth of types of

bugs found. Some of the current tools can find the vast majority of bugs in

immature codebases. Perhaps more importantly, for very mature codebases, 

including large codebases with millions of lines of code, such tools can even 

quickly and efficiently find prior to deployment roughly a third of the bugs ever 

publicly found after deployment. Other tools scale to codebases including tens of 

millions of lines of code. However, it is not clear that any tool will ever be able to 

find more than half the bugs without improving languages and tools for specifying 

or expressing desired behavior through means more clear than source code. 

Software has continued growing exponentially in size and complexity, further 

complicating such analysis. Massive growth of the codebases for various operating 

systems and applications was described earlier. Some operating systems and 

critical applications such as databases already have codebases including tens of 

millions of lines of code.

Moreover, the sophistication of the United States potential adversaries has also 

grown over these years, and most of the newly improved source code analysis tools 

Mission Impact of Foreign Influence on DoD Software_____________________________41 
Findings______________________________________________________________________

are publicly available to potential adversaries. In this context, with challenges 

growing exponentially harder as there is continuous, strong progress in the 

performance of model checking tools, there is no consensus on whether gains or 

losses are being made on this problem. 

Binary Code Analysis Tools 

Because what you see in source code is not always what you execute in binary 

machine code, analysis of source code is not sufficient. The notion of Binary 

Analysis is often associated with “Reverse Engineering” which Chikosfy and Cross 

defined as “the process of analyzing a subject system to create representations of 

the system at a higher level of abstraction.” This type of analysis is utilized 

whenever software is under scrutiny and source code is not provided, or the source 

code cannot be trusted. It is often used to gain insight into code of questionable

pedigree or quality in a search for flaws or malicious intent or -- in the context of 

modernization activities -- where the source code has been lost or corrupted. 

Binary code analysis tools have been improving. However, binary code analysis 

does not yet scale to support analysis of most software systems. Given the 

scalability of model checking and its relative effectiveness in finding accidental 

vulnerabilities in large scale software systems, automation of reverse engineering 

of models for model checking from binaries seems to be a promising area for 

research progress. However, even if that automation of reverse engineering could 

scale to the scale of current model checking, the effectiveness of such techniques 

would still be limited to accidental vulnerabilities. If the number of accidental 

vulnerabilities can be dramatically reduced, the opportunity for adversaries to 

intentionally introduce vulnerabilities—masquerading as non-attributable 

accidental vulnerabilities—could be dramatically reduced. Moreover, automation 

of such reverse engineering may also lend itself to more powerful analysis 

techniques, such as theorem proving, that are currently less scalable but more

effective in detecting hidden functionality in the very small software systems that 

are currently tractable. 

The broad activity of Binary Analysis falls into three basic sub-categories: static 

analysis, dynamic analysis, and hybrids. Static analysis typically involves taking an 

executable artifact (e.g., an *.exe file) and disassembling or decompiling the binary 

to produce native assembly code or a higher level symbolic language for an analyst 

to review. Dynamic Analysis typically involves executing the binary in a closed

or safe environment and observing its behavior for a period of time to establish 

some level of confidence in its normal behavior and identify any abnormal

behavior. Hybrids often involve reverse engineering the binary to produce a higher 

level symbolic language for mechanical reasoning, and human analyst review to 

produce the test cases for dynamic analyses most likely to uncover hidden 

functionality. Moreover, it often makes sense for this to be an iterative process, as

those dynamic analyses may create structures meriting more thorough static 

analysis. This is true for several reasons. Data can generate code, code can be 

metamorphic and polymorphic, and many software systems tested are built in a 

42________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

manner that residuals of one test vector may interact with the behavior of another 

test vector. In this context, hybrid iteration between static and dynamic analyses is 

often required to uncover deeply buried functionality. 

Static Binary Analysis 

Experienced analysts look for clues in the disassembled code that allow for 

conclusions about the behavior of the binary. There are a number of mature 

disassembly tools that are available today (e.g., IDA Pro) that support this type of 

analysis. Depending on the application, an analyst may be looking for general 

functionality, potential vulnerabilities, or nefarious behavior where security is a 

concern. This type of analysis is very laborious and does not currently scale well,

as analyzing low level assembler code (the result of disassembly) is a very time

consuming, tedious task that requires special expertise that is not widely available. 

To address this issue, there is emerging work to address the scalability issue that 

focuses on a disassembler providing an “intermediate representation” of binary 

functionality that can be further analyzed by other tools that are specialized in

identifying specific nefarious behavior or vulnerabilities. Examples include 

Grammatech’s CodeSurfer for x86, the Software Engineering Institute’s Function 

Extraction Program, or work within KDMs proposed Ecosystem. Specific

techniques include Affine Relational Analysis (ARA), Value Set Analysis (VSA),

and Aggregate Structure Identification (ASI). However, although some of these 

techniques offer fidelity conducive to model checking, techniques with such 

fidelity are not known for scaling beyond executable sizes involving hundreds of 

kilobytes, let alone today’s software systems of tens of millions of megabytes, or 

tomorrows systems of hundreds of millions of megabytes. 

However, the stunning distance that needs to be covered should be noted in 

context; the investments needed to produce such high fidelity techniques were 

small, made only within the last few years, and are already beginning to bear 

substantial fruit. In this context, continued and substantially amplified investments

in this area seem not only appropriate, but also potentially critically important 

given the fidelity they may offer in helping automate the process of revealing 

hidden functionality. 

Dynamic Binary Analysis 

Dynamic Analysis involves analysis of the software or system in its run-time 

environment and is often referred to as “black box testing,” as analysis is done from 

an external perspective. Typically, tools such as “debuggers” and “fuzzers” are 

used. Debuggers are programs used to debug other programs and provide the 

ability to trace code execution. Fuzzers are tools that supply permuted data to

program inputs to exercise the code. Dynamic Analysis tools typically check for 

known security vulnerabilities, configuration issues, run-time exceptions, memory 

leaks/corruptions, or other suspicious Input/Output (I/O) activity. Most of these 

techniques are targeted at pre-production/integration testing and system-level virus 

Mission Impact of Foreign Influence on DoD Software_____________________________43 
Findings______________________________________________________________________

and vulnerability scanning to protect against known software vulnerabilities and 

malicious code signatures, and to enforce security policies. 

Additionally, there are a number of mature tools that provide the ability to 

instrument the execution environment (e.g., Holedek) and that look for specific 

vulnerabilities (e.g., International Business Machines (IBM) Purifies for memory 

leaks). Such tools can provide insight into existing vulnerabilities due to poor 

implementation but are hit or miss with respect to identifying code of malicious

intent, as the triggers for such intent must be fired while the code is in its monitored 

state. 

Given that such tools do not consistently identify malicious code, they are often 

coupled with static analysis for generation of test cases to drive such binary 

analysis. In this context, static analysis can identify edge cases, corner cases, and

test values relative to constants and decision points in the code, and dynamic 

analysis can map the state of such behavior in fuller context than other forms of 

static analysis. 

Government Access to Source Code

The tools discussed above are primarily useful during code development. The 

question naturally arises about their utility for the purposes of acceptance testing or 

certification of product, which could either be done by an independent laboratory or 

by the U.S. government itself. It is tempting to consider having the government

take the source code of a commercial product and run its own vulnerability 

assessment tools against it. However, this is problematic – if not impossible - for

vendors to support for multiple reasons, including in particular the cost of 

supporting this testing and the risk to the vendor’s intellectual property. 

Many vendors’ licensing agreements explicitly prohibit decompilation or reverse 

engineering of products except under limited circumstances. There are tools 

available that can decompile products for purposes of finding security 

vulnerabilities. Given that license agreements typically do not allow source access 

and prohibit most decompilation, the U.S. government would need to clarify the 

protections it would provide to industry, both in the use of their source code and in 

the information it derives from that code. This issue is complicated by the lack of

governmental incentives to protect intellectual property and the lack of a practical 

remedy for the vendor if their source code is lost or compromised. 

In a global environment some vendors might well decide that, if they release source 

code to one government, they should also release to others. Indeed, one major

vendor has taken this approach.24 While some governments would report 

vulnerabilities that were found, others might prefer to use that knowledge for their 

own purposes. 

 

24 See http://www.microsoft.com/industry/government/programs/gsp.mspx.

44________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

There is already a burgeoning trade in third parties selling information on nonpublic security vulnerabilities by subscription. In some cases, the information may 

be sold to bad actors, while in other cases, the information is sold to firms with 

arguably high concerns over their security, such as financial institutions. As DoD 

moves to apply testing mechanisms to commercial software, it needs to consider

what policies will be applied to notification of the vendor, and how the information 

will be disseminated prior to the issue being fixed, or even after it is fixed. 

Aside from the legal and ethical issues associated with government access of

source code, there are multiple technical and cost challenges associated with using

third-party automated tools against a vendor code base. The high rate of false 

positives on many vulnerability finding tools would burden the vendor with costly

support to a government team that would have little in-depth knowledge of the code 

being examined. Moreover, in the case of large programs there is the likelihood 

that the tools would not scale to handle the vendor’s code base. 

Best Practices for Code Development 

While there is no silver bullet that will make software more secure, this section 

summarizes a set of process improvements that are known to reduce vulnerabilities 

in software. The recommended process improvements address four phases: design, 

coding, testing and response. There is no reliance on a spiral, agile or waterfall 

development model. 

This section does not address the need for training of development personnel, but it 

is assumed that all engineering staff will attend ongoing security training. Few

schools teach security from the perspective of reducing vulnerability to attack and 

increasing assurance, so industry must fill that void. 

Design

Design is the critical first stage in building secure software. Unfortunately there are

few general models or scalable tools that help deliver secure designs for COTS 

software. However, the process of hazard analysis, sometimes referred to as threat 

modeling, is useful for understanding the threats posed to software and the errors 

that can lead to successful attacks. The threat modeling process, defined in25 calls

for structured decomposition of the application into the following elements: 

processes, data flows, data stores, external entities and trust boundaries. Element 

types can be attacked in specific ways – for example a data store (such as a file or a 

database) can be tampered with, denied service, or viewed. The aggregate of all 

elements within the application and the different types of attacks that can be 

launched against each element comprises a list of potential threats (or hazards) to 

the system. Each threat type can be mitigated in well-understood ways with

security features. For example tampering can be mitigated with integrity

technologies such as permissions and message authentication codes or with 

attention to assurance techniques. 

 

25 Howard and Lipner 2006

Mission Impact of Foreign Influence on DoD Software_____________________________45 
Findings______________________________________________________________________

Another important design concept is the understanding of how exposed the 

application is to attack. The most extreme case is unauthenticated and remotely 

accessible network end-points opened by a privileged process that runs by default.

Information about exposure of an application can be derived from the threat model. 

The goal of any product development team over time should be to reduce the 

product’s exposure. 

Coding

A review of the history of reported software vulnerabilities over the last five years 

indicates that most security bugs that pose material risk to software users are 

implementation flaws. In general, these flaws could have been prevented during 

the development phase. The following paragraphs summarize some key techniques 

that have proven effective for improving software security and removing 

vulnerabilities during implementation. 

The compilers that support the development of software in higher-level languages, 

such as C and C++, must add defenses to the generated code. At a minimum, these 

defenses should include detection of stack-based buffer overruns. While such 

defenses do not solve the buffer overrun problem, they do add a hurdle for attackers 

to jump over. 

Buffer manipulation functions in the C and C++ languages (for example: strcpy, 

strncpy, strcat, strncat, and sprint) have proven to be a continuing source of

software vulnerabilities for all vendors. These dangerous functions should be

removed over time and new code should not use these dangerous functions; more

robust and predictable functions should be used instead, such as StrSafe or Safe

CRT.26 

Regardless of the programming language used, static analysis tools should be used 

to detect some classes of coding errors. These tools should be run regularly and 

bugs triaged and fixed. It is also beneficial to use multiple tools – different analysis

techniques detect different classes of bugs. While some static analysis tools have 

evidenced high “false alarm rates” – requiring an unacceptable level of human 

review of erroneous reports – the market is producing additional static analysis

tools every year and available tools have proven effective at analyzing even large 

and complex commercial software. 

There are two major classes of analysis tools – those that inspect source code, and 

those that inspect the compiled executable code. Both have value in that they find

different classes of bugs. Software developers need to move towards using both 

types of tools. However, developers should exercise caution in relying heavily on 

static analysis tools. Tools can help scale the security analysis process in that they 

are rapid, but they are no replacement for skilled human inspection. In addition, 

some tools that simply scan for certain patterns in code are a waste of time, because 

 

26 Howard 2002, Lovell 2005

46________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

their false alarm rates are very high. Most of these tools simply look for bad 

coding constructs without regard for the nature of the data or any other contextual 

consideration. 

Software engineering organizations should consider external design and code 

review by code-security analysts. Review by another set of knowledgeable 

engineers – either inside or outside of the organization developing the software – 

can be effective. However, the vast complexity of much commercial software is 

such that it could take months or even years to understand. 

Testing

“Fuzz testing” can be very effective at finding security bugs. If an application 

processes complex data structures or network traffic, then it should be “fuzzed.”

Fuzzing means building deliberately malformed data and having the application 

consume the data. If the application fails, the developer should review the failure 

to identify the error and fix it if appropriate. There are two major ways to build

malformed data: the first is to randomly corrupt well-formed data and the second is 

to intelligently corrupt well-formed data. The latter approach means that the tool 

performing the fuzz test must understand the protocol being fuzzed, which makes

the tool more complex and also results in more effective testing. Tools are critical 

for fuzz testing to be successful because massive quantities of malformed data must

be created. A typical fuzz testing process requires that a minimum of 100,000 

malformed files be generated for each file format consumed by the application

under test. 

A benefit of fuzz testing is that once the test harness is built, there is no need for 

human intervention other than to review software failures. Effective fuzz testing

requires an understanding of code coverage. If a fuzz testing process only exercises 

25 percent of the data-parsing code, then the fuzz testing process is ineffective. It 

is imperative that the tests touch almost all, if not 100 percent, of the code. 

Another form of security testing is penetration testing in which skilled attackers 

conduct a directed search for vulnerabilities. Such testing is useful to a point, but is 

expensive, yields relatively few bugs, and requires a great deal of skill and 

experience to perform. With that said, the bug quality from penetration testing can 

be very high if the team performing the review is highly skilled. If the product 

under review is to be used in sensitive environments or used by large number of 

customers, then a penetration test might be beneficial. 

Security Response Processes 

As the preceding paragraphs have repeatedly made clear, there is no silver bullet 

for achieving secure COTS software. As a result, vulnerabilities will continue to be 

discovered in fielded software for the indefinite future. Many COTS vendors have 

recognized this fact and integrated a security response phase into their software 

development process. Part of the role of a security response process is to accept 

reports of newly discovered vulnerabilities, investigate them, and act to protect 

Mission Impact of Foreign Influence on DoD Software_____________________________47 
Findings______________________________________________________________________

users of the vulnerable software. This action may include maintaining 

communication with the finder of a product vulnerability, releasing a security patch

or update, releasing an advisory with information for users, and providing 

information to suppliers of anti-malware or intrusion prevention/detection products 

that customers may use to block exploitation of a vulnerability. By maintaining 

24x7 response capabilities with the maturity to manage complex relationships with 

security researchers, vendors can promote responsible vulnerability disclosure. This

enables vendors to release patches before exploits can be launched and reduces the 

impact of “zero-day” attacks. 

The impact of a security response process extends beyond its immediate role of 

providing users with fixes and mitigations for newly discovered vulnerabilities. A

well-organized security response process will identify new classes of security 

vulnerabilities and ensure that design guidance, development tools, and testing 

practices are updated to prevent the new class of vulnerability from being 

introduced into future software releases. Such a process will also incorporate a

search for related vulnerabilities in fielded software so that users of the software 

can eliminate all similar problems by applying a single security update. 

Software Assurance in Computer Science Education 

One of the root causes of poor software assurance is the current culture of software 

development. Developers are, in general, not indoctrinated in either the techniques 

or the values of secure coding practice in their degree programs. As a result, many 

commercial software vendors have to spend extraordinary time and money 

educating otherwise bright developers on the principles and practice of secure 

coding basics as well as why it matters. It may be relatively easy to teach

developers how to validate input, but it is hard to convince them that they need to 

do this properly every time. Vendors will always need and want to indoctrinate

their employees in vendor-specific coding practices, but they should not need to be 

teaching the basics of good, defensible programming. 

FINDING: The academic curriculum and courseware in computer science does not 

adequately teach software developers to design, develop and test with a defensive 

mindset, nor is there adequate training in assurance and security techniques. 

University programs must change so that businesses are not teaching remedial 

secure coding practice. While some computer science curricula include a security 

module, it is typically focused on the basics of security features and functions (e.g., 

authentication, access control, and audit), rather than on the overall practice of 

secure development. 

Most developers do not have a defensive mind set (e.g., “first, assume an

attacker...”), nor do they follow principles of building functionality to do what is

intended and explicitly prevent or prohibit what is not intended. In other words, 

developers often explicitly want to allow functionality to be extensible – at some

point in the future - without considering the security implications. 

48________________________________________________________DSB Task Force on
_____________________________________________________________________Findings 

Ideally, secure development practice would be embedded within every university

class, so that the principles of secure coding and security-oriented development: 

• Are seen as part and parcel of any development effort, 

• Are emphasized repeatedly, and 

• And are more likely to stick as both a cultural value and as practical 

knowledge. 

To incorporate the issue of malicious coding or “supply chain corruption” into this, 

educational improvements should include both secure coding and, specifically, 

defensive coding. 

Defensive coding should mean that students’ code is actively attacked as part of 

classroom exercises. For example, a computer science professor at one university 

has red teams and blue teams attack one another’s code as part of each homework 

assignment, and the defensibility of code is part of a student’s grade. A subtle but 

important aspect of this could be assignments to subtly corrupt software so that it 

does something other than what it is supposed to do without that code being easily 

detected. Teaching students that this can happen and how to look for it is another 

way to change the mindset of people who write code. 

Universities (with some notable exceptions) have been resistant to changing their 

curricula to emphasize secure coding practice. Several large vendors have 

attempted to influence various accreditation bodies (e.g., the Association of 

Computing Machinery (ACM), and Institute of Electronics and Electrical 

Engineering (IEEE)) to address this issue. Most universities have, to date, not

changed their curricula. 

Conclusion 

All of the considerations just listed seem to point to an intractable problem. The 

Nation’s defense is dependent upon software that is growing exponentially in size 

and complexity, and an increasing percentage of this software is being written offshore in easy reach of potential adversaries. That software presents a tempting 

target for a nation-state adversary. Malicious code could be introduced 

inexpensively, would be almost impossible to detect, and could be used later to get 

access to defense systems in order to deny service, steal information, or to modify 

critical data. Even if the malware were to be discovered, attribution and intent 

would be difficult to prove, so the risk of detection for the attacker would be small. 

Against this backdrop of potential disaster, practical experience and belief paint a 

picture of aggravating and continuous software problems, but not ones that are 

lethal. However, there are some systems on which, to varying degrees, life depends 

(e.g., power, health). In this sense, DoD systems are among the most critical

because their national security mission is often measured in fatalities, and failures

Mission Impact of Foreign Influence on DoD Software_____________________________49 
Findings______________________________________________________________________

that would be innocuous in another context can be lethal and lead to mission 

failure. 

If the attacker cannot be deterred and its malware cannot be found, what is to be 

done to provide assurance that DoD software will perform in mission-critical

situations? First, there never will be an absolute guarantee. But as in many issues

in defense planning, software assurance comes down to intelligent risk 

management. The risk of vulnerable software can be managed through a suite of

processes and mitigation strategies detailed in the Task Force recommendations, 

and this risk can be weighed against the attractive economics and enhanced

capabilities of mass-produced, international software. 

50________________________________________________________DSB Task Force on
______________________________________________________________Recommendations 

RECOMMENDATIONS 

DoD Procurement of COTS and Off-Shore Software 

RECOMMENDATION: DoD should continue to procure from, encourage and 

leverage the largest possible global competitive market place consistent with 

national security. 

The reasons underlying DoD use of commercial software described in the 1999 

DSB report “Globalization and Security” remain as true today as when that report 

was written. Much functionality required by DoD for its warfighting mission can be 

more effectively obtained from commercial industry from the perspective of cost, 

schedule and performance. In fact, failure to use commercial solutions for much 

functionality would be cost prohibitive, even assuming that functionality could be 

produced by the traditional DoD industrial base. 

It is a reality of the market place that the supply for IT will globalize. Competitive

forces drive companies to seek technical talent, cost savings, new product markets, 

and 24-hour production cycles. Such globalization appears to lead to higher

degrees of competitiveness, leading to better products and services at lower prices.

Thus the DoD must necessarily continue to purchase software written offshore. 

DoD has greatly benefited from these circumstances. In addition to cost savings – 

DoD shares in costs spread over the entire market of consumers – product 

maintenance, technology refresh, and market innovation all benefit DoD. So long 

as DoD is not put in a position of being denied the best technology (reverseInternational Traffic in Arms Regulations (ITAR)) through the loss of U.S. industry 

competitiveness, and so long as commercial products destined for DoD systems are 

not used inconsistently with the levels of assurance that can reasonably be expected 

from those products, DoDs agile use of commercial technology in support of the 

warfighter is another avenue of competitive advantage. 

Increase U.S. Insight into Capabilities and Intentions of 

Adversaries 

RECOMMENDATION: The IC should be tasked to collect and disseminate 

intelligence regarding the intents and capabilities of adversaries, particularly 

nation-state adversaries, to attack and subvert DoD systems and networks through 

supply chain exploitations, or through other sophisticated techniques. 

Based upon the staggering consequences of defensive failure, a path forward 

toward an actionable understanding of nation-state adversarial intents and 

capabilities must be identified, resourced and executed. Components of this path 

should include: 

Mission Impact of Foreign Influence on DoD Software_____________________________51 
Recommendations______________________________________________________________ 

• The IC must be tasked and resourced to aggressively collect, analyze and

report on the capabilities, methods, intentions, and targets of foreign 

offensive services targeting the U.S. This insight must be in sufficient 

detail to be actionable by U.S. defensive players. 

• Change the culture, through education, to take into account the real threat 

coming from the capabilities of nation-state adversaries. DoD can no 

longer plan and operate as if its mission-critical systems were functioning in 

a cyber environment free of such adversaries. 

• The national security community needs to foster improved analytical

capabilities that can discern the intent of broad patterns of intrusions and 

organize countermeasures that blunt the overall efforts in addition to 

incident by incident response efforts. Of course, sophisticated adversaries 

can attempt to compromise people with access to IT systems, a threat that 

requires its own rigorous protections. 

All indications are that targeted attacks against defense systems will increase in

sophistication and stealth. Federal enterprises in general need to develop better 

detection and analytical capabilities to more rapidly identify, assess and respond to 

stealthy attacks. DoD needs to understand both how attacks are occurring and the 

types of data sets being targeted. 

RECOMMENDATION: DoD should increase relevant knowledge and awareness 

among its cyber-defense and acquisition communities of the capabilities and intents 

of nation-state adversaries. 

It is vital that senior leaders, acquisition officials, program management staff and 

trusted industry partners understand the reality of the threat, vulnerability and 

consequence of the nation-state adversary targeting DoD software systems. In order 

to ensure their understanding, barriers to sharing threat information from the

offensive operations community must be identified and changed. The vehicles for 

communicating threat to the acquisition community (e.g., System Threat 

Assessment Report (STAR)) have to be evaluated for adequacy. In addition, the 

changes described here will require a cultural change that must leverage education 

and training of senior executives and the acquisition workforce. 

The Task Force earlier described the natural hesitance to share sensitive operational 

information. However, it is necessary that the IC develop policies to mandate the 

timely cleansing and communication of threat information about the capabilities 

and intents of nation-state adversaries to senior leadership within the acquisition 

and defensive operations communities. In addition to leadership, mechanisms will

have to be developed to enable technical experts within the defensive operations 

and acquisition communities to understand what the technical threat is. 

52________________________________________________________DSB Task Force on
______________________________________________________________Recommendations 

The STAR is generally tailored to describe the threat to the intended system in the 

operational setting, rather than from a full lifecycle perspective, and may not fully 

consider the sophisticated capabilities of the nation-state adversary. Moreover, the 

STAR is generally not required before Milestone B of the DoD program structure. 

The ability of the nation-state adversary to attack technology through lifecycle 

exploit should be described to the Project Management Office earlier within the 

lifecycle. 

System Engineering and Architecture for Assurance 

RECOMMENDATION: DoD should allocate assurance resources among 

acquisition programs at the architecture level based upon mission impact of system 

failure. 

Classic risk management principles require starting by identifying assets to be 

protected, determining the importance of those assets, determining threats to those 

assets, and then mitigating those threats. In considering the importance of an asset, 

it is important to consider not just the asset alone, but also dependencies (e.g., 

which other assets will fail if this one fails). 

DoD cannot cost effectively achieve a uniformly high degree of assurance for all 

the functionality it uses across its many and varied mission activities. Allocating

criticality of function levies a requirement for assurance of that function, and also 

of those functions that defend it. Systems identified as critical must then allocate 

criticality at the sub-system and assembly level. 

To properly allocate scarce assurance resources, DoD must allocate criticality at the

system-of-systems and enterprise architecture level. This analysis should occur 

early within the system life-cycle, and should render a prioritization decision no 

later than Acquisition Milestone A, to allow programs of record to respond 

appropriately to their criticality. 

DoD categorizes systems by mission assurance category and confidentiality level 

for information assurance purposes. If these categorizations are made to link the 

system’s criticality to its role within the DoD warfighting mission from a systemof-systems or architecture perspective, it would constitute an architecture-level 

allocation of criticality. Currently, allocation of mission assurance category and 

confidentiality level does not appear to systematically drive an allocation of the

requirement for assurance at the subsystem, assembly, and component level. 

While DoD determines how to identify its system criticality, the Task Force 

recommends that the USD(AT&L) and the ASD(NII)/CIO empanel a stakeholder 

group composed of service representatives, the Joint Staff and OSD to identify a 

short list of critical systems to which the CONOPS would be sensibly applied in

light of current acquisition lifecycle exigencies. 

Mission Impact of Foreign Influence on DoD Software_____________________________53 
Recommendations______________________________________________________________ 

The CONOPS is not intended to be applied to legacy system functionality, but will 

apply to new systems and modifications to critical legacy systems. If a software 

threat is discovered in an acquisition program, for example because of a previously

undetected supply chain threat, then vulnerability management systems should be 

applied to determine the vulnerability in legacy systems. 

Currently, systems engineering processes do not adequately identify the 

requirement for assurance, do not adequately engineer for the system risks resulting

from the composition of individual components with software and hardware 

assurance risks, and do not adequately manage system assurance risks. Even 

within a DoD Critical System, not all functions will have the same criticality to the 

mission-worthiness of the system. 

For critical systems, DoD should implement enhancements to systems engineering 

processes to meet systems assurance requirements. These assurance requirements

will be established for critical-system acquisition programs through a prioritization

process involving the following factors: 

• Assessing the vulnerabilities of alternative system designs from a failure 

modes perspective. 

• Minimizing the number and criticality of components requiring greater 

assurance. 

• Acquiring these components from assured suppliers and managing the risks 

inherent in the use of less assured products. 

• Defending intrinsically critical functionality with mechanisms that are

considered to have the same criticality as the components they are

defending. 

The DoD Tiger Team has termed this system engineering process “Engineering in

Depth.” 

For each critical system or component systems designers should ask: “What is the 

worst thing that a malevolent insider could do”; and then ask, “How could such an 

action be mitigated”? Red Teams of specialized personnel to address system, and 

system-of-system, attack scenarios should be employed very early in the 

architecture processes and continue throughout system development. Red teams 

need not be large, but do require a few key people with substantial knowledge of 

computer science and development, system vulnerabilities, and potential attack 

tools and methods. 

Mission and information assurance cannot be added as an appliqué late in the 

process, or after system development. It must be an integral part of development to 

provide graceful degradation, isolation, multi-patching, replaceable modules, and

other techniques to manage risk. Critical systems must be able to recognize an 

attack or undesired state change, resist by preventing further damage, and recover 

such that critical functions can be performed at critical times. Creating these 

54________________________________________________________DSB Task Force on
______________________________________________________________Recommendations 

capabilities will be difficult and will be expensive, so identifying truly critical 

systems and prioritizing them will be both challenging and essential. 

Eliminate Excess Functionality in Mission-Critical Components 

Each new capability introduces opportunity for new vulnerabilities and excess

capability means unnecessary vulnerability. This means that there is a potential 

downside to every new capability incorporated. The addition of a new side door to 

a relatively secure building means added convenience, but introduces the

requirement for additional physical security -- added functionality, added

vulnerability. It is necessary to question closely the need for each additional 

capability. In this context, accepting features of no use to the DoD with the risk of 

adding vulnerability seems an inappropriate course. 

Frequently, however, the acquisition system is biased in favor of excess 

functionality, without factoring in the risk that such unneeded functionality brings. 

In a competitive evaluation, when all systems meet the parameters for needed 

functionality and cost, those extras can be the tie breaker ...in the wrong direction. 

Even the requirements system in advance of actual acquisition happily compiles a

long list of “nice-to-haves” —really a list of dangerous ingredients. The remedies 

to this are good system design and careful evaluation of the cost of adequately 

defending mission-critical functionality from “nice-to-have” functionality. 

Improve the Quality of DoD Software 

The DoD can effectively raise the “signal-to-noise ratio” against software attacks

by raising the overall quality of the software it acquires. If there were fewer 

unintentional bugs in software, the visibility of poorly written malware might be 

increased. While general improvements in information assurance will not, per se, 

prevent a determined attacker from corrupting the software supply chain, there are 

several compelling benefits in improving the overall assurance/security-worthiness 

of COTS: 

• A sophisticated adversary would have to work harder to introduce an 

exploitable vulnerability instead, as is currently the case, of relying upon the 

plausible deniability of a common programming error to avoid attribution of

malicious intent. Furthermore, a sophisticated adversary would have less 

confidence that its malware would remain undetected, invisible in a world 

containing far fewer distracting vulnerabilities. That uncertainty could be a

deterrent in itself. Any attacker now has a plethora of exploitable defects to 

choose from. 

 

• Eliminating common, easily-exploitable defects in software will, as one

software industry executive has put it, “help get 16-year-olds out of DoD 

networks.” The “signal to noise” ratio for defenders improves as easy 

attacks are rendered more difficult and thus, more scarce. By reducing the 

resources that must be expended to combat opportunistic attacks, 

Mission Impact of Foreign Influence on DoD Software_____________________________55 
Recommendations______________________________________________________________ 

redirecting saved resources can be used to prevent, detect, and respond to 

more sophisticated adversaries. 

Improve Tools and Technologies for Assurance 

Improve Trusted Computing Group Technologies

The Trusted Computing Group is a not-for-profit organization formed to develop, 

define, and promote open standards for hardware-enabled trusted computing and 

security technologies, including hardware building blocks and software interfaces,

across multiple platforms, peripherals, and devices. TCG specifications claim to

enable more secure computing environments without compromising functional 

integrity, privacy, or individual rights. The primary goal is to help users protect 

their information assets (data, passwords, keys, etc.) from compromise due to 

external software attack and physical theft. The Trusted Computing Group was 

initially formed by personal computer manufacturers, suppliers and software 

companies AMD, Hewlett-Packard, IBM, Infineon, Intel Corporation, Microsoft, 

and Sun Microsystems, Inc. Today it has over 120 members from across 

computing, including component vendors, software developers, systems vendors

and network and infrastructure companies. 

The centerpiece of the Trusted Computing Group initiatives is the Trusted Platform 

Module (TPM): a semiconductor chip or chipset that is embedded on the

motherboard of personal computers and other computing platforms and 

components. Trusted Computing Group functionality has also been integrated 

directly into certain mass-market chipsets. Since each TPM chip or chipset is 

unique to a particular device, it establishes machine identity that cannot be forged 

and binds keys to a specific machine state. Therefore, it can be used to authenticate 

a hardware device, and can be used to verify that the system seeking access is the 

expected system. 

TCG-compliant modules and components are designed to prevent software attack 

and they are capable of preserving software assurance once an assurance level has 

been established. However, the TCG specifications are silent on determination of 

initial assurance levels. NSA and others have identified a number of improvements 

and complementary practices that would strengthen TCG-compliant systems, 

including privacy-preserving attestation, virtualization, and architectures that 

provide richer software assurance measurement and monitoring capabilities. 

Given that vulnerability detection can never be perfectly reliable, it seems 

necessary to bound the harm that can be done with hidden functionality escaping 

detection. A variety of TCG technologies lend themselves to helping enforce 

separation of information so that processes from one domain will not harm 

processes or information in another. However, at present, these protections are not 

provably strong. For these reasons, the Task Force proposes that the U.S. 

Government fund unclassified research to analyze and improve the strength of TCG 

technologies for providing such separation properties. The goal of such a program 

56________________________________________________________DSB Task Force on
______________________________________________________________Recommendations 

should be security and virtualization software and chipset design that are formally 

proven to provide the desired separation properties under all circumstances. 

Improve Effectiveness of Common Criteria 

Currently, the official DoD-wide evaluation/validation scheme is the National 

Information Assurance Partnership based upon the Common Criteria. The reality 

today is that it would be far easier and more effective to improve Common Criteria 

than to invent a new scheme specific to the DoD or to DHS. 

Specifically use of the Common Criteria and NIAP practices should include: 

• Assessing vendor software developmental processes and vulnerability

mitigation processes to give confidence in their change-management 

procedures throughout the software products lifecycle. 

• Crediting vendors for the effective use of automated vulnerability reduction 

tools during all areas of the software development lifecycle. 

• Rating the effectiveness of the automated vulnerability reduction tools. 

• Use of automated tools for vulnerability analysis during EAL4 and below 

evaluations. 

• Timely and cost efficient evaluation/validation schemes reducing artificial 

artifact creation. 

• Policies and processes for sharing of vulnerabilities within the acquisition 

processes. 

The National Information Assurance Partnership (NIAP) Common Criteria 

Evaluation and Validation Scheme (CCEVS) has begun to develop an evaluation 

process that appears to meet many of the objective outlined above. The Common 

Assurance Assessment (CAA) has been developed with the cooperation of the 

United Kingdom’s (U.K.) Common Criteria scheme, and has been used for an 

initial “alpha test” trial evaluation in the United States. A second trial evaluation, 

to be conducted by the U.K. scheme, is planned for 2007. CAA is still under 

development and there are many issues yet to be resolved. However, it holds 

promise because it focuses on a vendor’s development process as actually 

conducted, and because it examines the actual process and artifacts associated with

development rather than artificial documentation written solely for the evaluation

process. DoD should continue to develop and evaluate CAA with the aim of using 

it as a foundation for a new way of gaining insight into the assurance of COTS 

software. 

Commercial development processes are changing. As part of that change, new 

artifacts are being created (e.g., threat models). To the extent these artifacts are 

reflective of real software security and are actually produced during development, 

they can be relied upon in a certification process. However, sometimes the artifacts 

created may not actually reflect accurately the product. This occurs, for example, 

when that artifact (e.g., a design) is not followed precisely in the implementation. 

To the extent the vendor's artifacts are not sufficient -- either because the 

Mission Impact of Foreign Influence on DoD Software_____________________________57 
Recommendations______________________________________________________________ 

government wants something the vendor did not create or because the artifact 

provided is not good evidence -- it is reasonable to assume the government will

want some other artifact created. The problem is that any artifact created after the 

fact did not influence the product and thus meets no business need aside from 

certification.

It would be beneficial for government and industry to work more closely together 

to align artifacts created by reasonable development practices and what the 

government relies upon. Where there is no synergy, there are only two 

possibilities. First, the industry has created something for its own purposes that the 

government does not want to use, or second, the government shows a reasonable 

need for the item and industry creates it solely for the purpose of certification. This

becomes a cost of doing business. 

Improve Usefulness of Assurance Metrics

There is a natural tension between the U.S. Government’s need to know the 

security-worthiness of what they procure and vendor’s need to avoid disclosing 

particular vulnerabilities. One way to satisfy both needs is to develop a weighted 

index of the security-worthiness of software. A weighted score could be generated 

via testing based on some combination of: 

• The utility of the tool itself: what vulnerabilities it finds, how well it finds

them and how accurately (e.g., some sense of the false positives and false 

negatives generated by the tool). 

• The amount of code coverage of the tool -- how broadly the tool is run 

against the software, and how broad is the range of vulnerabilities checked. 

• The test results against a particular product, weighted for the severity of 

outstanding (unfixed and/or non-mitigated) issues. 

The issue is DoDs desire to know what the vendor knows. Put another way, what 

DoD should want is the vendor to say: “These are the tools we used; we covered 

“n” percent of the code base, and here is what we found.” 

The vendor could use an automated tool of choice (presumably, what is used during 

development), a laboratory could revalidate the results, and there could be some

“rating” of the tool (by NIST) for what it finds and does not find. The goal would 

be not to disclose the details of specific vulnerabilities found, except to the vendor. 

The U.S. Government would thereby get an idea of the overall security-quality of 

software weighted for a number of critical factors: “a goodness meter.” 

To make this feasible NIAP should develop a ratings methodology for development

processes, as well as automated vulnerability-detection tools and a weighted metric 

(or collection of metrics) to use against commercial software.

58________________________________________________________DSB Task Force on
______________________________________________________________Recommendations 

Promote the Use of Automated Tools in Product Development

Tools for the detection of vulnerabilities continue to improve and proliferate. 

Different vendors will choose to use different tools; no one tool is right for every

company. The DoD may well have an interest in determining how good the tools 

are that vendors use, but DoD should not be in the position of dictating particular 

tool use by vendors. Requiring vendors to validate their products using product X

(even if it is done by a lab) effectively means all vendors selling to the government

must purchase a product X license or service, because nobody wants to be surprised 

by the test results from a lab. Creating de facto standards is inappropriate and DoD 

cannot reasonably pick a “code scan” winner that will be equally deployable, cost 

effective, useful, scalable, etc. in all environments. Furthermore, different types of

tools have different utility to different vendors. A vendor of a protocol-heavy

product may derive greater benefit from using a protocol fuzzer than a static 

analysis tool, for example. 

Markets should pick winners; that said, DoD could, in theory, rate vulnerability 

analysis tools for what they find and how well they find it by using a neutral third 

party like the National Institute of Standards and Technology (NIST) or a 

commercial evaluation. Such ratings should clearly reflect the range of size and 

complexity of the code base where the analysis tool is found effective. This would 

be a benefit to vendors who want to use such tools and have no idea how good a 

tool is, or who have limited ability to vet them. However, there is an advantage in 

having multiple tools on the market. Small, innovative startups need to be able to 

use these tools, not merely large, established vendors. Having a number of tools on 

the market at different price points will help. 

More Knowledgeable Acquisition of DoD Software 

Increase Transparency and Knowledge of Suppliers’ Processes 

RECOMMENDATION: DoD should implement a scalable supplier assurance 

process to assure that critical suppliers are trustworthy. DoD should coordinate 

with the Director of National Intelligence (DNI) to leverage the all-source threat 

assessment capability resident in the DNIs Intelligence Community Acquisition Risk 

Center (CARC), possibly shaping this into the foundation of a national supply chain 

threat assessment capability. 

When government agencies contract for software development in response to a 

specific requirement or statement of work, they should specify the process that the 

contractor will be required to use, the tests that the contractor will conduct, and 

documentation and deliverables that the contractor must produce. In contrast, 

vendors of COTS software apply processes that are dictated by their own 

perceptions of customer demand and the best ways to meet it. Each software 

vendor devises its own process in response to its business needs, and there is no 

requirement for a vendor to make either its process or the artifacts the process 

produces available to customers or third-party reviewers. 

Mission Impact of Foreign Influence on DoD Software_____________________________59 
Recommendations______________________________________________________________ 

 

In order to gain meaningful assurance of COTS software, DoD must understand the 

actual processes used to develop that software. Gaining this insight into vendors’ 

development processes is not the same as mandating a process and verifying that it 

has been followed – software development processes are core to vendors’ success 

in the worldwide government and commercial market, and any successful vendor 

would be hamstrung by DoD processes that conflicted with that vendor’s ability to 

be successful in the broader marketplace. No product evaluation regime in effect

today provides insight into a vendor’s real development processes and their 

effectiveness at producing secure and trustworthy software – so the software

assurance challenge for DoD is to define an evaluation regime that is capable of

reviewing vendors’ actual development processes and rendering a judgment about 

their ability to produce assured software. 

An evaluation regime that meets DoDs requirement for assured software must have 

the following properties:

• It must examine code and the processes used to design, implement and test 

that code, because software vulnerabilities are most often created at the 

implementation (code) level. 

• It must assess the tools vendors use, their effectiveness at finding 

vulnerabilities, and their integration into vendor development processes, 

because effective software development processes depend heavily on the 

use of automated tools to detect and remove vulnerabilities. 

• It must include some opportunities to interview development staffs, review 

their training, and assess their ability to produce assured software, because 

commercial vendors rely on the competence and commitment of their 

employees as well as (or, in some cases, instead of) formal processes. 

• It must provide an extraordinarily high standard of protection for vendors’ 

intellectual property, because source code and development processes are 

the crown jewels – along with employees, literally the only assets – of 

software vendors. Under Common Criteria, which arguably exposes less 

information to evaluators than the process being envisioned, the contracts 

that vendors sign with the commercial laboratories of their choice can 

provide very strong commercial remedies for any mishandling of vendor

proprietary information. Any new evaluation scheme should provide more 

relevant information regarding assurance than the Common Criteria. 

• It must include an assessment or scoring mechanism that allows DoD 

decision-makers to compare very different kinds of products and processes, 

because different software products must meet different requirements and 

face different threats and because vendors apply different processes. The 

only feasible way to provide such a scoring mechanism is to examine a 

60________________________________________________________DSB Task Force on
______________________________________________________________Recommendations 

software development process at a fundamental level and evaluate the 

elements of the process as a whole made up of individual parts. 

DoD procurement and security professionals need to better understand and leverage 

key business drivers to gain the assurance that vendors are applying appropriate 

security controls over their products. For example, COTS vendors execute control 

over their source code to ensure that there is a clear chain of custody to protect 

intellectual property, to ensure that coders do not inadvertently introduce unwanted 

code elements such as those that may be covered by alternative licensing schemes 

such as GPL, and to ensure quality control and adherence to their respective 

development guidelines. Weakness in any one of these three areas could be costly 

to a vendor, damaging its brand reputation and costing it market share. Ultimately,

understanding the processes and controls used by vendors is a sophisticated 

approach to managing COTS acquisition risks, and can be used in conjunction with 

such approaches as analyzing the historical security relationships of countries 

where products are developed or the particular citizenship of those in the software 

supply chain. 

DoD needs to develop a policy requiring a thorough counterintelligence scrub of its 

key suppliers for critical systems. DoD should subject to an all-source assessment 

any company conducting classified work for such systems, and any company 

writing software or selling a COTS product that will be utilized as a critical 

component in a critical system. At present such analysis is conducted for the IC by 

the DNIs Community Acquisition Risk Center (CARC), which has some eight 

years of experience and a demonstrated threat analysis methodology. It is 

recommended that DoD identify a point of contact within its

security/counterintelligence entities to conduct required threat assessments for

programs. OSDs Counterintelligence Field Activity already has a nascent presence 

in the ICARC, as does one or more of the service counterintelligence shops. 

Suppliers should be characterized in terms of the direct threat that they present to 

DoD acquisition programs, which is a requirement consistent with ICARCs current 

charter. However, suppliers should also be reviewed for any indirect threat they 

pose through weaknesses in security-related engineering and business practices and 

procedures. CARC methodologies do not currently encompass all of these issues. 

All these considerations should enter acquisition through source selection

decisions. 

Components Should be Supplied by Suppliers of Commensurate 

Trustworthiness

RECOMMENDATION: DoD acquisition processes should require that products 

possess assurance matching the criticality of the function delivered. 

The critical components of critical systems demand higher levels of assurance. In 

this context, critical components are software custom code and COTS that an 

Mission Impact of Foreign Influence on DoD Software_____________________________61 
Recommendations______________________________________________________________ 

engineering analysis of the system designates as necessary to ensure at least a 

defined level of minimal performance. 

RECOMMENDATION: DoD should require that all custom code written for 

systems deemed critical be developed by cleared U.S. citizens. 

Cleared personnel should also review legacy custom code being incorporated into 

new critical systems for malicious code or vulnerabilities. 

While it is impractical to conduct any significant review of COTS software

packages used even in critical systems, it should be a requirement of new systems

that such COTS be verified to the extent practicable if it is designated a critical 

component. The level and extent of verification should be determined by the 

Program Office as a part of its overall risk mitigation strategy to ensure operational 

capability of the system. 

Acquisition Incentives for Higher Quality Code

The U.S. Government collectively provides a very large market for software and

services. The collective buying power of the U.S. Government is such that it can 

force change on its suppliers to a degree no other market sector can reasonably do, 

with or without the formal regulation that serves as a baseline for suppliers. The 

U.S. Government taken as a whole seems unaware or unwilling to use its clout in 

the marketplace. There are some strong pockets attempting to change this that have

met with mixed success. In particular, some efforts have been hampered by a lack 

of dialogue with industry about what is feasible in terms of product change 

timeframes. Procurement should be used to push for constructive security change, 

but it must include sufficient vendor notice and feedback mechanisms, some 

grandfathering, and should acknowledge product lifecycles (in which major 

product changes take years, not months to implement). 

DoD should alter the purchasing dynamic with the vendor community by insisting 

on more security-worthy software through their procurement cycle. This should be 

done by providing a generally uplifting effect on software instead of merely 

imposing more cost without commensurate benefit or by excluding classes of 

vendors. Companies will not build a robust, secure version of a product for DoD 

and a buggy, insecure version of the product for their commercial customers. 

RECOMMENDATION: DoD should provide incentives to industry to produce 

higher quality code. 

There will never be a single set of best practices, testing tools, methodologies, or 

development process that works for all vendors -- nor is that desirable, since 

innovation requires change. That said, it is reasonable to expect some cohesiveness 

to formulate around good development practice and to expect industry to do more

over time to implement strong development processes that improve securityworthiness and quality. 

62________________________________________________________DSB Task Force on
______________________________________________________________Recommendations 

In the past, market dynamics have not penalized poor quality software, and in some

cases, and has even created concerns that such poor software generates a market for 

maintenance services and security products. It is, of course, not that simple; most 

vendors provide security patches for free and many security products protect 

against more than vulnerabilities (e.g., unsafe user behavior such as clicking on 

attachments from unknown sources). While the popular sentiment is “caveat 

emptor” (let the buyer beware), the fact is that customers generally have 

insufficient information about the quality and security-worthiness of commercial 

software to make fully informed purchasing decisions, or to know what the 

lifecycle costs of securing the software will be. Several factors work against quality 

being a measurable factor prior to purchase: 

• Many vendors charge for maintenance, which includes both patches and 

upgrades. Producing patches thus becomes a revenue source for vendors 

and a reduced (and perverse) incentive to provide stable software. This 

bundling provides an advantage to customers in that both enhanced 

functionality and fixes to broken functionality are typically covered by 

maintenance charges, but it also penalizes customers who want stable 

software and do not need or want new features or upgrades. 

• Many patches, particularly in security, are issued on unpredictable 

schedules. Customers do not have any way of knowing what their actual 

patching costs will be. This would include patch analysis, testing, 

downtime, actual patch application, and recertification of systems. The 

license cost (including maintenance) is typically a fraction of the overall 

lifecycle costs from the customer perspective, and the larger portion cannot 

adequately be factored into purchasing decisions (unless, of course, one 

opts for software as a service, in which case the vendor assumes more of the 

risk of unstable software, as the vendor is typically charging the customer a 

fixed rate to both supply and support the software). 

• Many vendors do not have good insight into what producing patches 

actually costs them in terms of lost developer productivity, opportunity cost 

(e.g., other features they could have built with developer resource focused

on patches), and so on. Also, as noted above, maintenance may be a revenue

center for some vendors. 

• Industry analyst firms generally do feature-to-feature comparisons of 

software products but in general do not do cost of ownership comparisons. 

Doubtless the great difficulty of comparing lifecycle costs is part of this, but

the fact that so many analysts are also paid by vendors for consulting 

probably contributes to their reluctance to do head-to-head cost comparison

for fear of alienating their paying (vendor) customers. 

• The IT market tends to reward time-to-market for cutting edge technologies, 

which means the incentive is to skimp on security, testing and other

Mission Impact of Foreign Influence on DoD Software_____________________________63 
Recommendations______________________________________________________________ 

“quality” portions of development processes in favor of getting product out 

the door quickly and grabbing market share. Customers who adopt the 

newest technologies may often suffer through the poor quality phase of the 

product lifecycle in part because they have no alternatives, and because the 

cost to switch is too high. 

To remedy this, DoD needs to help change the market dynamic through both 

positive and negative incentives so that they get better quality software, and to 

make better risk-based and “total cost”-based acquisitions. Note that vendors who 

build better quality COTS software (for DoD) are unlikely to sell lower quality

software to other customer sectors; in fact, it is likely that any positive impact from

DoD helping to raise the bar will accrue to other sectors of critical infrastructure. 

The pace of introduction of new software applications and new functionality far

outpaces traditional product evaluation schemes and system certification and

accreditation processes. To ensure that the DoD has access to and understanding of

novel, state-of-the-art software it must continue to develop and exploit rapid 

evaluation processes and techniques. This should not be restricted to applications 

that might only be used in classified environments but should also be used to 

evaluate software that might enhance or influence unclassified networks and 

systems. This rapid evaluation capability, while segmented and separated by 

various levels of classification, should include where appropriate participation by 

universities and institutions involved in software development assessment and 

certification.

Technically, shipping products in a default secure configuration (and making it

easy to maintain a reasonably hardened security configuration) is not a quality 

measure in the sense of defects per thousand lines of code is a quality measure. It 

does, however, go to cost of security ownership, lifecycle costs and the overall 

security posture of a product. If a vendor can ship a product in a pre-hardened 

condition, that saves customers the cost of reading documentation, tweaking 

multiple controls to lock the product down, and testing that the hardened

configuration works in their environment. The cost avoidance to customers by the 

vendor doing this upfront is tremendous. DoD has already used this successfully in 

contracting vehicles. The USAF recently required a hardened configuration as part

of an enterprise license agreement; they claim this will save the USAF millions

over the lifecycle of the contract. 

Risk-Based Acquisition

Requiring or dictating a standard development process is not the path of greatest

benefit to DoD. Having said that, knowing what vendors do as part of their 

development process helps DoD evaluate risk. Also, the mere fact of asking what 

vendors do to engineer security and quality into their lifecycle puts the vendor 

community on notice that it is important to DoD. 

64________________________________________________________DSB Task Force on
______________________________________________________________Recommendations 

The DoD/DHS software assurance forum has been working on a procurement guide

focused on software assurance, which helps procurement officers glean (through a 

series of questions) what vendors have done (and not done) as part of their secure 

development process, how they handle vulnerabilities, and so on. Such a document, 

when reviewed by a larger audience and finalized, could be used as part of IT

procurement cycles to help DoD better evaluate risk. 

As long as this is sensible, the questions are phrased to allow expository answers, 

and the benefit derived is commensurate with the cost of vendors completing it, this 

is one way for DoD both to know what they are getting and to put vendors on 

notice that quality and security-worthiness has become a purchasing criteria for 

DoD. There also needs to be some way for vendors to complete these questions so 

they are not repeating the same questionnaire for the same product (or subsequent 

releases of it) needlessly. 

A Research and Development Program on Assurance is Needed 

RECOMMENDATION: DoD should establish and fund a comprehensive Science 

and Technology Strategy and research programs to advance the state-of-the-art in 

vulnerability detection and mitigation within software and hardware. 

NSA has established a Center for Assured Software, which is currently working a 

number of these issues. NSA should be resourced to act as the Executive Agent to 

manage the R&D program through the Center for Assured Software and to 

coordinate across the community to provide vulnerability detection and mitigation

support to national security acquisition programs. 

The goals of the classified and unclassified research and development investments

in assurance should be to develop the technology to effectively take accidental 

vulnerabilities out of systems development and to improve Trusted Computing 

Group technologies in order to bound the risks presented by intentionally planted 

software. This program should monitor what markets are delivering, identify gaps 

between what the market is delivering and what DoD needs, and fill this gap. 

 

Among the research programs that should be pursued are: 

• Verification and model checking along with other forms of testing and static 

analysis. 

• How hardware based security mechanisms can be used to improve software

assurance. 

• Development of high assurance components such as is accomplished within

the Multiple Independent Levels of Security (MILS) program and the High 

Assurance Platform (HAP), and how to leverage the use of such high 

assurance components within system design. 

Mission Impact of Foreign Influence on DoD Software_____________________________65 
Recommendations______________________________________________________________ 

Modest government unclassified research investments in model checking on source

code are producing very valuable results already in broad use, and since these 

techniques still have substantial room for progress, continued and amplified 

investments in these tools seems prudent. In addition, since current model

checking tools scale relatively well and emerging automated techniques for 

extracting immediate representations of binaries now provide enough fidelity to 

facilitate model checking, new and increased investments in scaling of immediate 

representation extraction for model checking also seem prudent. 

Automation of reverse engineering may also lend itself to more powerful analysis 

techniques, such as theorem proving, that are currently less scalable but more

effective in detecting hidden functionality in the very small software systems that 

are currently tractable. Theorem proving has been exceptionally valuable in the 

design of microprocessors with tens of millions of transistors, but has not scaled

well in design and verification of software systems. However, theorem proving 

remains one of the few techniques capable of proving the absence of certain forms 

of hidden functionality. In this context, modest investments toward improving 

scalability of theorem proving seem worthwhile. Although successes have been 

harder to win, this area is not without recent successes of unclassified research

investments, such as Proof Carrying Code and A Computational Logic for 

Applicative Common Lisp (ACL2) proofs of separation kernels. 

The Task Force proposes unclassified investments in research and development of 

new and improved technology in three areas: 

• Improving the scaling and improving the breadth and depth of accidental 

vulnerabilities found through model-checking-based source code analysis 

tools. 

• Development of model checking on binaries through improvement of 

intermediate representation extraction techniques and their scalability. 

• Scaling theorem proving for software systems. 

The goal of such unclassified investments should be to develop technology that can 

reliably and effectively take accidental vulnerabilities out of the system. This

would reduce the opportunity for adversaries to intentionally introduce 

vulnerabilities that masquerade as non-attributable accidental vulnerabilities. This,

in turn, would force U.S. adversaries to more deeply and carefully hide malicious 

functionality, at greater expense, and possibly requiring a larger talent base more 

easily detected through intelligence means. 

Classified Investments

Growing current investment in model checking of source code and investing in 

research toward model checking of binary code and scalable theorem proving of 

binary software all seem likely to provide help of a value that is many times the 

level of investment. However, none of these techniques will be able to resolve 

sufficiently the problem of reliably detecting well hidden malicious functionality. 

66________________________________________________________DSB Task Force on
______________________________________________________________Recommendations 

For this reason, it seems important to not only make the above unclassified 

investments, which will provide the greatest relief, but to make these investments 

in parallel with investments in classified applications of such knowledge. 

The National Agenda for Software Assurance 

RECOMMENDATION: The DoD should advance the issue of software assurance 

and globalization on the national agenda as part of a coordinated effort to reduce 

national cyber risk. 

The mandate of this Task Force was to address the systems assurance problem from

the DoD perspective. DoD is addressing this issue aggressively because of the 

importance of maintaining mission-critical capabilities, but must be cognizant of

the importance and benefits of advancing the issue of software assurance beyond 

the DoD realm. In reality, DoDs mission is inexorably linked to and reliant upon 

the work of related government agencies from the Intelligence Community to 

Homeland Security, and to companies that provide U.S. critical infrastructure. 

Accordingly, this report should be read in the context of the even broader cyber risk 

that faces DoD, the U.S. Government generally, and the private sector. This risk

emanates from two key factors: first, the national dependency on interconnected IT

systems in public and private institutions for the Nation’s national security, public 

safety and economic prosperity; and, second, the widespread vulnerability of these 

systems to attackers. A nation-state adversary cares only about fulfilling its

mission, not about what is attacked, whether it is the DoD warfighting capability or 

the Hoover Dam. A holistic, coordinated approach to address the Nation’s cyber 

risk must be a high priority for the national agenda. 

One specific area that warrants DoD priority engagement of key government and 

private stakeholders is the supply chain risk to national security systems, a risk 

which has been exacerbated by globalization. This issue has been the focus of the 

Committee on National Security Systems’ (CNSS) Global Information Technology 

Working Group, and its recent report, “Framework for Lifecycle Risk Mitigation

for National Security Systems in the Era of Globalization.” This report was 

endorsed unanimously by the 24 agencies with national security systems that 

comprise the CNSS. DoD should work closely with DHS to ensure that the U.S. 

Government expeditiously resources and implements the recommendations of this

report. 

RECOMMENDATION: DoD should work with its industry partners and 

commercial industry to improve the assuredness of COTS software. 

Industry development processes and product evaluations (especially Common 

Criteria) should be brought into better alignment. Such coordination should enable

product developers to produce the relevant product information evaluators need. 

Common Criteria should be considered in the evaluation of COTS products. 

Industry should employ modern secure development practices, such as threat 

Mission Impact of Foreign Influence on DoD Software_____________________________67 
Recommendations______________________________________________________________ 

modeling, use of vulnerability analysis tools, and focused security testing. Such 

modifications to industry development practices and evaluation processes will give 

integrators and end users products with better defined assurance properties. 

68________________________________________________________DSB Task Force on
______________________________________________________________________Appendix 

APPENDIX 

Mission Impact of Foreign Influence on DoD Software_____________________________69 
Appendix______________________________________________________________________ 

70________________________________________________________DSB Task Force on
______________________________________________________________________Appendix 

Appendix A. 

Terms of Reference 

Mission Impact of Foreign Influence on DoD Software_____________________________71 
Appendix______________________________________________________________________ 

72________________________________________________________DSB Task Force on
______________________________________________________________________Appendix 

Appendix B. 

Task Force Membership 

CHAIRMAN 

Dr. Robert Lucky Telcordia Technologies 

EXECUTIVE SECRETARY 

Mr. Robert Lentz OASD (NII) 

MEMBERS 

Mr. Scott Charney Microsoft 

Ms. Mary Ann Davidson Oracle 

Mr. James Gosler Sandia National Laboratories 

Mr. Paul Hoeper Private Consultant 

Dr. Joe Markowitz Private Consultant 

Mr. Richard Pethia SEI, Carnegie Mellon University 

Mr. Andy Purdy Private Consultant 

Mr. Steve Schanzer S2 and Associates, Inc. 

Dr. Trey Smith SAIC 

Hon. John Stenbit Private Consultant 

Mr. Brian Witten Symantec 

Mr. Larry Wright Private Consultant 

GOVERNMENT ADVISORS 

Mr. William Dawson CIA 

Mr. Richard Hale DISA 

Mr. Craig Hasson NSA 

Mr. Larry Huffman DISA 

Mr. Joe Jarzombek DHS 

Mr. Mitch Komaroff OASD (NII) 

Mr. Phil McConnell CIA 

Mr. Wadiah Mikhail OSD/IP 

Mission Impact of Foreign Influence on DoD Software_____________________________73 
Appendix______________________________________________________________________ 

OBSERVERS 

Dr. Greg Larsen IDA 

Mr. Bill Neugent MITRE 

Mr. Robert Reynolds IDA 

MILITARY ASSISTANT 

CDR Cliff Phillips U.S. Navy, Defense Science Board 

SUPPORT STAFF 

Ms. Michelle Ashley SAIC 

Ms. Diana Conty SAIC 

Mr. Jonathan Hamblin SAIC 

74________________________________________________________DSB Task Force on
______________________________________________________________________Appendix 

Appendix C. 

Descriptions of Example Software-Intensive Programs 

in DoD 

Blue Force Tracking (BFT)

Blue Force Tracking is an automated, friendly-force reporting system. Its use in 

Operation Enduring Freedom (OEF) and Operation Iraqi Freedom (OIF) demonstrated 

the value of a digitized army and provided the operational evidence of the value of NetCentric operations. The combination of Blue Force Tracking with the Army’s platformlevel battle command system, FBCB2, generates and distributes a common view of the

battle space at the tactical and operational levels. In OEF/OIF, Force XXI Battle 

Command, Brigade-and-Below/Blue Force Tracking (FBCB2/BFT) enabled tactical units 

to perform in conditions that would have significantly degraded operations in the first 

Gulf War. Combat deaths from friendly fire were dramatically reduced relative to the

earlier conflict.1

 Furthermore, in some critical situations units were able to maneuver 

based only on FBCB2/BFT reports and map displays. 

In 2002, the Army G6/CIO and Program Executive Office for Command, Control, and 

Communications - Tactical (PEO C3T) initiated an effort to deploy Blue Force Tracking 

to the U.S. Army, U.S. Marine Corps, and U.K. Army units that would fight in OEF/OIF. 

Drawing on previous experience with a Ku-band architecture fielded for Balkan 

peacekeeping operations, the office of the G6 designed an architecture that uses

commercial L-band satellite links for beyond-line-of-sight communication. There are 

presently more than 20,000 platforms equipped with FBCB2/BFT in Iraq and 

Afghanistan. 

This program has used both commercial and military devices as hardware. FBCB2/BFT 

uses COTS products and components from the Defense Information Infrastructure 

Common Operating Environment as appropriate, keeping in perspective the intended 

“small computer” characteristic of the FBCB2 design. Blue Force Tracking was

delivered to troops in Afghanistan and Iraq using Intel computers. The software code is a 

combination of Linux, GOTS, and COTS (including Oracle-based software.) Software is

upgraded and maintained via physical distribution of hard drives with masters. The

masters are delivered to operational units, which then clone them for installation in 

platforms. 

• Information Safeguards:2

 FBCB2 processes, sends, receives, displays and 

stores information classified up to SECRET level. (Note: BFT is not accredited to 

 

1 In the first Gulf War, friendly fire caused 25.6% of combat deaths. Through the end of “major combat operations” in the Second

Gulf War (May 2, 2003), friendly fire caused only 6.5% of the combat deaths. Sources: Oscar Avilla “U.S. Won with Few 

Casualties,” Chicago Tribune, May 3, 2003 and Peter Pae “’Friendly Fire’ Still a Problem,” Los Angeles Times, May 16 2003. 2

 From Test & Evaluation Master Plan Part 1b (23 Aug 04) at 

www.hqda.army.mil/tema/TEMP%20101/PART1/PART%201B%20FBCB2%2023%20Aug%2004.doc

Mission Impact of Foreign Influence on DoD Software_____________________________75 
Appendix______________________________________________________________________ 

operate at the SECRET level. The system runs a Type II encryption. Training 

and Doctrine Command Systems Manager (TSM) FBCB2 has accepted this 

limitation for the present based on operational need while efforts continue 

towards a Type I implementation and accreditation). 

No software source selection decisions on FBCB2/BFT have been made since 1995. 

Supplier assurance was not an explicit requirement of the RFP process. Likewise, 

Foreign Ownership, Control or Influence of COTS component suppliers was not a 

criterion in the selection process. The Program Manager has, however, identified and 

reviewed the software security and configuration management policies used by the lead 

systems integrator. FBCB2/BFT has a current STAR (System Threat Assessment 

Report) dated 7 March 2005. The formal policy for handling source and executable code 

is in final draft as part of an amendment to the 30 Nov 2005 Program Protection Plan. 

FBCB2/BFT has succeeded in delivering a Net-Centric capability to warfighters that has 

dramatically increased mission effectiveness. The system incorporates commercial, 

COTS, GOTS and Open Source IT hardware and software. The overall approach to 

system security was developed under existing policies. Because information rides on 

commercial links, encryption and authentication mechanisms have been a critical element 

in information assurance and in protecting the FBCB2/BFT network from intrusion. 

FBCB2/BFT has been operationally effective in war. 

While the Task Force sees no evidence that system effectiveness was degraded by foreign

influence on its component hardware or software, it must be noted that the United States 

was facing an unsophisticated adversary, which is not the main focus of this paper. BFT 

Project Management Officer (PMO) made no effort to identify the pedigree of system

components of BFT through CI support to source selection. It has been significantly 

aided in this decision by the lag-time since last source selection for COTS integration, 

which may pre-date attention to the Systems Assurance Problem. Future source selection 

of COTS integration decision will in all likelihood be supported by intelligence support 

as in FCS described below which, while far from ideal, are stronger than used in BFT. 

Future Combat Systems

The Task Force received a summary briefing on FCS Software Assurance from Army

and contractor personnel on 17 October 2006. Subsequently, on 14 November 2006, two 

members of the Task Force3

 received a thorough briefing on FCS Information Assurance 

from the programs information assurance deputy. 

The FCS program will develop and field a mobile, self-healing, “plug and play” network 

that will link together a family of light, mobile and survivable manned vehicles; 

unattended aerial vehicles; unattended ground vehicles; highly capable sensors and 

advanced lethal munitions within a Brigade Combat Team. 

 

3 Trey Smith and Page Hoeper

76________________________________________________________DSB Task Force on
______________________________________________________________________Appendix 

Each FCS Brigade Combat Team will be networked through the Army Battle Command 

System. Vertical networks will link command echelons while horizontal connections will 

tie together mounted, dismounted and airborne combat units. The network architecture 

will include every stationary and moving platform in the battle space. The Army Battle

Command System will be interoperable with theater, joint and combined command and

control systems. FCS network connections will include the JWICS (Joint Worldwide 

Intelligence Communication System), the SIPRNET, and the NIPRNET/Internet. 

The IT hardware and software within FCS includes COTS, GOTS, Open Source, 

Proprietary and Military Unique components. For software in particular, about 27 

million source lines of code are COTS or open source. This constitutes over 42% of the 

total delivered executable source lines of code. 

The System of Systems Common Operating Environment (SOSCOE) and the Integrated

Computer System/Operating System (ICS/OS) rely predominately COTS and Open

Source software. The ICS/OS is almost 99% COTS/OS. The SOSCOE, essentially the 

“middleware” for FCS, is almost 80% COTS/OS. 

As with many other DoD software applications, the use of COTS/GOTS/OSS is essential 

to achieving required capabilities within time and budget constraints. In some cases there 

may be no other practical way to deliver the required capabilities. Furthermore,

COTS/GOTS/OSS can be highly secure. The FCS operating system, part of the ICS, 

employs LynxOS-SE, a security enhanced real time operating system from LynuxWorks. 

The FCS program office has assessed that there is a low to moderate risk that malicious 

code could be inserted into the FCS Master Software Baseline and exploited. The 

program has identified the following counter measures to reduce that risk to an 

acceptable level: 

• Establish “software pedigree.” 

• Incorporate malicious code detection tools into the software development process. 

• Execute defined software configuration management processes. 

• Detect and remove “dead” code. 

• Use secure code development processes. 

Regarding the first bullet above, the Future Combat System Chief Information Officer 

(FCS CIO) provided initial guidance (pending Program approval) on the use of foreign 

code for FCS. Key points include: 

• Government assumption that the profit motive will assure clean code in “shrink

wrapped” (consumer) software. 

• Code certification for software that is specifically developed for a known 

government use. 

• Acceptance of foreign software for use in areas that are not critical to the 

performance of SOSCOE. 

Mission Impact of Foreign Influence on DoD Software_____________________________77 
Appendix______________________________________________________________________ 

• Purchase of foreign software via a “blind buy,” in which the seller has no 

knowledge of who the buyer is or how the product will be used. 

• Approval of Open Source Software only under stringent conditions. 

Recognizing that the above points are in draft, the Task Force would urge caution in 

accepting the proposition that the profit motive and intent to sell software to a mass

market will induce sufficient testing to produce clean code. The Task Force is similarly

skeptical of the proposition that very much FCS software can be acquired through blind 

buys, where the seller would not be aware of the ultimate user or the intended placement

or use of the software.. And the Task Force lacks confidence in current tools for 

detecting malicious code. 

Malicious code is a key concern of the FCS Program. According to the Deputy for

Information Assurance, the Program recognizes that current automated tools cannot 

detect all malicious code and inherent vulnerabilities. Current policy is line-by-line code 

inspection, which the program recognizes is not feasible. At present, the effort to detect 

malicious code depends on detection of anomalous behavior. 

The FCS Program recognizes that where malicious code is concerned, prevention during 

development and maintenance is the best policy. Prevention includes careful vetting of 

software pedigree, especially for the SOSCOE and the ICS/OS. Software maintenance 

will be secured through a Public Key Infrastructure (PKI) access control. 

The FCS Program appears to have a robust and detailed information assurance plan. 

Software assurance is a component of this plan. The Task Force recommends that DoD 

NII meet with the FCS information assurance deputy to exchange views on how best to 

assure that FCS is not compromised by foreign influence on its software and overall 

information technology. 

Near Real-Time, Sensor-to-Weapon Considerations

Software assurance is more mature and well developed in DoD weapons systems,

particularly those with direct, near real-time linkage from the sensor to the weapon 

control system. At the same time, the size, complexity and potential vulnerability of the 

networks that connect sensors to weapons are increasing. Systems are beginning to 

migrate toward industry standard and Internet protocol (IP) technologies. Evidence 

gathered during this study shows that sensor-to-weapon networks range from secure, 

special purpose data and communications links, such as the USAF F-22 program, to 

networks that rely on industry standard protocols and links, such as the Army’s FCS. 

The constantly increasing capabilities offered by industry standard protocols drives an 

irresistible tendency to replace relatively secure special-purpose communications 

protocol stacks with the general purpose Internet protocol (IP) stack. 

Given this tendency, assurance practices, such as those embedded in the FCS program 

must be well supported and stringently implemented. The program has established an 

FCS Software Assurance Focus Group to define policies and direction to ensure “due 

diligence” in identifying, assessing and managing software information assurance risks 

78________________________________________________________DSB Task Force on
______________________________________________________________________Appendix 

associated with the development and acquisition of software for the FCS master software 

baseline. The Focus Group consists of a lead system integrator, government, and subject 

matter experts. The Group has established a four-pronged approach centered on software 

acquisition processes, software development processes, software testing requirements and 

software configuration management execution. The Focus Group maintains proactive 

processes to identify and manage future risks. The practices and processes employed in 

the FCS program may indeed offer protection from less sophisticated, weakly resourced 

adversaries, but do not appear sufficient to protect program capabilities from damage by a 

sophisticated nation-state adversary intent on damaging FCS effectiveness. 

F-22 Program Overview

The F-22 Raptor is a fifth generation stealth fighter aircraft. Raptor formally entered 

U.S. Air Force service in December 2005 as the F-22A. Its advanced capabilities depend

on sophisticated software and hardware to process and analyze signals and data. Given 

the central and critical nature of these systems, the F-22 initiated development with 

defined security requirements intended to eliminate the possibility of malicious software. 

The program developed a security architecture including firewalls to protect key

components and then established criticality classifications for each Computer Software

Configuration Item (CSCI). The software development processes were tailored to match

the criticality of the items and the program. 

The F-22 computing system architecture is segregated into two domains based on the 

criticality of the data. There is a non-trusted or non-sensitive environment that handles 

non-critical data and operations that do not require stringent controls and protection. 

There is a Trusted Computing Base (TCB) domain that contains software that processes 

sensitive data or algorithms. It comprises all the avionics software and data that is 

sensitive or critical to platform and mission performance. The TCB was built in 

compliance with the TCB specifications. The TCB domain protects all data through the 

means of a firewall provided by software and hardware specifically designed for the 

protection of the classified information. All TCB components performing the firewall 

functionality are classified as Protection-Critical Trusted and are subjected to more 

stringent development processes. Any classified information that is transferred outside 

the TCB is encrypted. Protections within the TCB also ensure that data is only shared 

between software applications that have a predetermined (system design) “need to know” 

via defined interfaces. The build process creates access control rights tables through the

Privilege Control Table Toolkit, which is also created using protection critical processes. 

F-22 Software assurance is maintained through security policies which are defined and 

enforced through the F-22 Weapon System Certification and Accreditation (C&A) Plan 

(WS SCAP) and Air Vehicle C&A Plan. Security Functional and Assurance 

Requirements are based on legacy processes including NISPOM, Joint Air

Force/Army/Navy (JAFAN) 6/3, 6/4, 6/9, and DoD 8500.1, Department of Defense 

Instruction (DODI) 8500.2 

Mission Impact of Foreign Influence on DoD Software_____________________________79 
Appendix______________________________________________________________________ 

Software Development 

The F-22 Software is developed via the F-22 Weapon System Software Development

Plan (WS SDP). It includes specific process requirements for trusted and ProtectionCritical Trusted Software. Compliance with assurance requirements are substantiated via 

process verification and documentation. Specific requirements prohibit software

developed by any foreign national that is part of the trusted software load. Above and 

beyond all this, protection-critical trusted software requires a code review independent of 

the developing organization to ensure that all such code meets its functional requirements 

and contains no unwanted code and accesses only data needed to meet its functional 

requirements. 

The only software developed by foreign partners that is part of the F-22 Air Vehicle is the 

embedded software for the Heads-Up Display (HUD). This software displays symbology 

and resides outside the TCB (no access to classified information) and does not have 

access to critical information. 

Test and evaluation 

Software Tools used to develop, integrate and test the F-22 OFP are part of the 

System/Software Engineering Environment (S/SEE), which governs the acceptance of 

software development tools. All tools go through a Product Security Evaluation (PSE) on 

isolated computer networks prior to being accepted for use on the F-22 program. These 

tools test for unexpected behaviors, events and data flow and analyze source objects for 

non approved components (e.g. shareware). 

Future Plans 

Modernization of the F-22 avionics envisions the incorporation of commercial software 

products. In fact, current F-22 modernization efforts are incorporating commercial 

operating systems (OS) such as the Green Hills Integrity 178B. This software was 

developed to standards that go beyond current F-22 requirements in order to meet

National Security Telecommunications and Information Systems Security Policy

(NSTISSP) 11. This software also meets Separation Kernel Protection Profile (SKPP) 

requirements. It was developed by NSA and industry and approved through NSA. It is 

now being evaluated to Evaluation Assurance Level 6+ (EAL 6+) by the Air Force 

Research Laboratory. 

Conclusions 

Risk from malicious software was mitigated by the F-22 program based on conscious 

decisions since program initiation. These decisions cover all sources of malicious 

software from both foreign sources and U.S. citizens. Established facility, personnel and 

process security requirements help to ensure protections from malicious software. The F22 program stands at one extreme of the software development and assurance spectrum 

as currently executed in DoD. However, the cost and investment required to develop 

systems in a similar fashion would be prohibitive for many DoD programs. The F-22 

80________________________________________________________DSB Task Force on
______________________________________________________________________Appendix 

appears to be at the high end of weapons programs when measured against current efforts 

for secure software development of its most critical systems. 

Mission Impact of Foreign Influence on DoD Software_____________________________81 
Appendix______________________________________________________________________ 

Appendix D. 

Task Force Findings and Recommendations 

Findings 

• The software industry, as well as the software talent base, is becoming 

increasingly global, and this trend appears to be irreversible. 

• DoD has become increasingly dependent for mission-critical functionality

upon highly interconnected, globally-sourced, information technology of 

dramatically varying quality, reliability and trustworthiness. 

• Adversaries’ use of low-level cyber attack techniques to exploit weak

information assurance controls and vulnerable software has led to 

successful attacks upon sensitive but unclassified (SBU) systems and 

networks of DoD and the defense and commercial industrial base. This has 

occurred notwithstanding extensive DoD efforts in security and information 

assurance. 

• The enormous functionality and complexity of IT makes it easy to exploit 

and hard to defend, resulting in a target that can be expected to be exploited

by sophisticated nation-state adversaries. 

• Nation-state adversaries are able to employ a full spectrum of offensive 

intelligence trade-craft, including attacks that subvert the supply chain, to 

damage or defeat mission-critical systems. The risk from such supply chain 

exploits can only increase as larger portions of the supply chain become

more accessible to the adversary through global sourcing. 

• Nation-state adversaries’ penetration of sensitive-but-unclassified systems 

and networks could allow them to steal system information or tamper with 

system artifacts, enabling them to target existing and future DoD Systems. 

• DoDs defensive strategies and techniques remain inadequately informed of

the sophisticated capabilities of nation-state adversaries to exploit globally 

sourced, ubiquitously interconnected, COTS HW/SW within DoD Critical 

Systems, and the potential consequences of system subversion. 

• The Intelligence Community (IC) does not deliver timely, actionable

intelligence regarding the intents and capabilities of nation-state adversaries 

to attack and subvert DoD systems and networks through supply chain 

exploitations, or through other sophisticated techniques. 

82________________________________________________________DSB Task Force on
______________________________________________________________________Appendix 

• The risk of undetected subversion of custom software is considerably 

greater than the corresponding risk for COTS. 

• Software deployed across DoD continues to contain numerous 

vulnerabilities and weak information security design characteristics. DoD 

and its industry partners spend considerable resources on patch 

management, while gaining only limited improvement in defensive posture. 

• The primary processes relied upon by DoD for evaluation of the assurance 

of commercial products, FIPS and NIAP Common Criteria Evaluation 

Process, do not address software vulnerabilities except for higher assurance 

levels (if at all). Moreover, these processes do not scale to the volume of 

software critical to the DoD mission. 

• The Task Force identified considerable variation in the extent to which the

Systems Assurance Problem is impacting next-generation DoD systems. 

That impact ranges from extensive with the introduction of inter-networked 

COTS and open source IT into the Army’s Future Combat System (FCS) 

program, to only slight in the USAF F-22 program. 

• DoD Critical Systems and networks remain vulnerable to the sophisticated

capabilities of Nation-state adversaries. USD(AT&L) and ASD(NII)/DoD 

CIO, through the efforts of the DoD Software Assurance Tiger Team and 

the CNSS Globalization of IT Working Group (GITWG), have developed a 

comprehensive strategy and CONOPS for addressing the systems assurance 

problem within DoD and an approach for the Federal Government at large. 

• DoD does not consistently or adequately analyze and incorporate into its

acquisition decisions the supply chain threat information that is available. 

• The growing complexity of the microelectronics and software within its

critical systems and networks makes DoDs current test and evaluation 

capabilities unequal to the task of discovering unintentional vulnerabilities, 

let alone malicious constructs. 

• The problem of detecting vulnerabilities is deeply complex and there is no 

silver bullet on the horizon. 

• The academic curriculum and courseware in computer science does not 

adequately teach software developers to design, develop and test with a 

defensive mindset, nor is there adequate training in assurance and security

techniques. 

 

Mission Impact of Foreign Influence on DoD Software_____________________________83 
Appendix______________________________________________________________________ 

Recommendations 

• DoD should continue to procure from, encourage and leverage the largest 

possible global competitive market place consistent with national security.

• The IC should be tasked to collect and disseminate intelligence regarding 

the intents and capabilities of adversaries, particularly nation-state 

adversaries, to attack and subvert DoD systems and networks through 

supply chain exploitations, or through other sophisticated techniques. 

• DoD should increase relevant knowledge and awareness among its cyberdefense and acquisition communities of the capabilities and intents of

nation-state adversaries. 

• DoD should allocate assurance resources among acquisition programs at the 

architecture level based upon mission impact of system failure. 

• DoD should implement a scalable supplier assurance process to assure that 

critical suppliers are trustworthy. DoD should coordinate with the DNI to 

leverage the all-source threat assessment capability resident in the DNIs 

Intelligence Community Acquisition Risk Center (CARC), possibly shaping

this into the foundation of a national supply chain threat assessment 

capability. 

• DoD acquisition processes should require that products possess assurance 

matching the criticality of the function delivered. 

• DoD should require that all custom code written for systems deemed critical 

be developed by cleared U.S. citizens. 

• DoD should provide incentives to industry to produce higher quality code. 

• DoD should establish and fund a comprehensive Science and Technology 

Strategy and research programs to advance the state-of-the-art in 

vulnerability detection and mitigation within software and hardware. 

• The DoD should advance the issue of software assurance and globalization 

on the national agenda as part of a coordinated effort to reduce national 

cyber risk. 

• DoD should work with its industry partners and commercial industry to 

improve the assuredness of COTS software. 

84________________________________________________________DSB Task Force on
______________________________________________________________________Appendix 

Appendix E. 

Briefings Presented to the Task Force 

NAME TOPIC

23 FEBRUARY 2006

Mr. Jeffrey Green, DoD General Counsel Task Force Ethics

Dr. James Lewis, CSIS Foreign Influence on DoD Software 

Mr. Taylor Scott, DIA Chinese Cyber Threat (Classified) 

Mr. Donovan Lewis, DIA IT Globalization and DoD Network 

Security (FOUO) 

Mr. Robert Reynolds, IDA Software Assurance Threats (Classified) 

24 FEBRUARY 2006

Mr. Kris Britton, NSA Software Assurance and Vulnerability 

Discovery (Classified) 

Dr. Catherine Mann, 

Institute for International Economics

Globalization of Information Technology 

Mr. Phil McConnell, CIA Risk Management of the Intelligence 

Community Acquisition Risk Center 

(CARC) (FOUO) 

Mr. Mitchell Komaroff, OASD (NII) DoD Software Assurance Tiger Team

Strategy 

Mr. William Archey, 

American Electronics Association 

Trends in Globalization and Offshoring 

22 MARCH 2006

Mr. Jeffrey Payne, Cigital, Inc. Software Security 

Dr. Brian Chess, Fortify Software, Inc. Software Security and Validation (Static 

Analysis) 

Ms. Susan Lee, Johns Hopkins University Countering Untrustworthy Software

Dr. William Howard, Private Consultant DSB Task Force on High Performance 

Microchip Supply 

Mission Impact of Foreign Influence on DoD Software_____________________________85 
Appendix______________________________________________________________________ 

NAME TOPIC

18 APRIL 2006

Mr. David Grawrock, Intel Corporation Trusted Platforms

Mr. Grant Wagner, NSA Trusted Platforms and Software Security 

Mr. Joe Jarzombek, DHS Overview of the DHS Software Assurance 

Program

16 MAY 2006

Mr. Robert Alexander, U.S. Army

Mr. Tom Plavcan, U.S. Army

Mr. Jack Saylor, 

Information Assurance Security Office 

Blue Force Tracker Program

Ms. Audrey Dale, NSA Common Criteria Evaluation and Validation 

Scheme (CCEVS) 

Mr. John Goodenough, 

Software Engineering Institute 

Mr. Bill Scherlis, 

Carnegie Mellon University 

Software Assurance Opportunities 

16 JUNE 2006

Dr. Ben Calloni, Lockheed Martin Multiple Independent Layers of Security 

(MILS) Program

Mr. Frank Hecker, Mozilla Foundation Open Source Software 

29 AUGUST 2006

Mr. Brian Rianhard, Lockheed Martin F-22 Software 

17 OCTOBER 2006

Mr. Rand Blazer, SAP America, Inc. Perspective on Software in a Global 

Environment 

Mr. Edgar Dalrymple, U.S. Army

Mr. Robert Myers, SAIC 

Future Combat System (FCS) Software 

86________________________________________________________DSB Task Force on
______________________________________________________________________Appendix 

Appendix F. 

References 

[CMMI Product Team 2006] 

CMMI Product Team; CMMI for Development, Version 1.2, (CMU-SEI-2006-TR-008) 

Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2006 

[Cooper 2002] 

Cooper, J.; Fisher, M. Software Acquisition Capability Maturity Model (SA-CMM), 

Version 1.03, (CMU-SEI-2002-TR-010) Pittsburgh PA: Software Engineering Institute, 

Carnegie Mellon University, 2002 

[Curtis 2003] 

Curtis, B.; Hefley, W.; Miller, S. Overview of the People Capability Maturity Model (PCMM), (CMU-SEI-2003-MM-001) Pittsburgh, PA: Software Engineering Institute, 

Carnegie Mellon University, 2003 

[Dion 1993] 

Dion, R. “Process Improvement and the Corporate Balance Sheet.” IEEE Software, 10, 4 

July 1993): 28-35. 

[DoD 1996] 

Department of Defense. DoD Guide to Integrated Product and Process Development 

(Version 1.0) Washington, DC: Office of the Under Secretary of Defense (Acquisition 

and Technology), February 5, 1996. 

[EIA 1998] 

Electronic Industries Association. Systems Engineering Capability Maturity Model 

(EIA/IS-731). Washington, DC: Electronic Industries Association, 1998. 

[Goldenson 2003] 

Goldenson, D. & Gibson, D. Demonstrating the Impact and Benefits of CMMI: An 

Update and Preliminary Results, (CMU-SEI-2003-SR-009) Pittsburgh, PA: Software 

Engineering Institute, Carnegie Mellon University, 2003. 

[Herbsleb 1994] 

Herbsleb, J.; Carleton, A.; Rozum, J; Siegel, J.; & Zubrow, D. Benefits of CMM-Based 

Software Improvement: Initial Results (CMU-SEI-94-TR-13) Pittsburgh, PA: Software 

Engineering Institute, Carnegie Mellon University, 1994. 

[Howard 2002] Strsafe.h: Safer String Handling in C 

"http://msdn.microsoft.com/library/en-us/dnsecure/html/strsafe.asp" 

[Howard and Lipner 2005] Howard, M. and Lipner, S. The Security Development 

Lifecycle. Microsoft Press 2005. 

Mission Impact of Foreign Influence on DoD Software_____________________________87 
Appendix______________________________________________________________________ 

[ISS 2007] IBM Internet Security Systems, “X-Force 2006 Trend Statistics”, January 

2007. http://www.iss.net/documents/whitepapers/X_Force_Exec_Brief.pdf 

[Lawrence 2006] Kenneth L. Lawrence (MAJ, USA) and Glen Foster. “Clarifying the 

DoD Vulnerability Management Program.” August 30, 2006. Joint Task Force-GNO 

Technical Bulletin 06-006 

[Lemos 2006] Robert Lemos, “Security flaws on the rise, questions remain”

SecurityFocus, 2006-01-05 http://www.securityfocus.com/news/11367

[Lipke 1992] 

Lipke, W. & Butler, K. “Software Process Improvement: A Success Story.” Crosstalk 5, 

9 (September 1992): 29-39. 

[Lovell 2005] Repel Attacks on Your Code with the Visual Studio 2005 Safe C and C++ 

Libraries http://msdn2.microsoft.com/en-us/library/8ef0s5kh(VS.80).aspx

[Messmer 2007] Messmer, Ellen, “Software vulnerabilities spiked 39% in 2006”, 

Network World, 01/30/07, http://www.networkworld.com/news/2007/013007-ibmsecurity-report.html

[Paulk 1993] 

Paulk, M.; Curtis, B.; Chrissis, M.; Weber, C. Capability Maturity Model for Software 

(Version 1.1) (CMU-SEI-93-TR-024) Pittsburgh, PA: Software Engineering Institute, 

Carnegie Mellon University, 1993. 

[Sims 2005] 

Sims, Jennifer E. and Burton Gerber, eds. Transforming U.S. Intelligence. 

Washington: Georgetown University Press, 2005 

[Wohlwend 1993] 

Wohlwend, J. & Rosenbaum, S. “Software Improvements in an International company” 

212-220. Proceedings of the International Conference on Software Engineering, 

Baltimore, Maryland, May 17-21, 1993. Los Alamitos, CA: IEEE Computer Society 

Press, 1993 

88________________________________________________________DSB Task Force on
______________________________________________________________________Appendix 

Appendix G. 

Abbreviations & Acronyms 

ACL2 A Computational Logic for Applicative Common Lisp 

ACM Association of Computing Machinery 

ARA Affine Relational Analysis 

ASD(NII) 

Assistant Secretary of Defense for Networks and Information 

Integration 

ASI Aggregate Structure Identification 

ASIC Application-Specific Integrated Circuit 

BFT Blue Force Tracking

C&A Certification and Accreditation 

C2 command and control 

CAA Common Assurance Assessment 

CARC Community Acquisition Risk Center 

CC Common Criteria 

CMM Capability Maturity Model

CMMI Capability Maturity Model Integration 

CNSS Committee on National Security Systems 

CONOPS Concept of Operations 

COTS Commercial-off-the-shelf

CSCI Computer Software Configuration Item

CSIS Center for Strategic and International Studies 

DHS Department of Homeland Security 

DIACAP DoD IA Certification and Accreditation Process 

DNI Director of National Intelligence 

DoD Department of Defense 

DoD CIO Department of Defense Chief Information Officer 

DODI Department of Defense Instruction 

EAL Evaluation Assurance Level

FBCB2 Force XXI Battle Command, Brigade-and-Below 

FCS Future Combat Systems 

Mission Impact of Foreign Influence on DoD Software_____________________________89 
Appendix______________________________________________________________________ 

FCS CIO Future Combat Systems Chief Information Officer 

FIPS Federal Information Processing Standards 

FTE full time equivalent

GAO Government Accountability Office 

GITWG Globalization of IT Working Group 

GOTS Government-off-the-shelf 

HAP High Assurance Platform 

HUD Heads-Up Display

HW hardware

I/O input/output

IA Information Assurance

IAV Information Assurance Vulnerability

IAVA Information Assurance Vulnerability Alert 

IAVB Information Assurance Vulnerability Bulletin 

IAVM Information Assurance Vulnerability Management 

IAVT Information Assurance Technical Advisory 

IBM International Business Machines 

IC Intelligence Community

ICARC Intelligence Community Acquisition Risk Center

ICS Integrated Computer System

IEEE Institute of Electronics and Electrical Engineering 

IP Internet Protocol

ISC Internet Systems Consortium

IT Information Technology

ITAR International Traffic in Arms Regulations 

JAFAN Joint Air Force/Army/Navy 

JWICS Joint Worldwide Intelligence Communication System

RFC Request for Comments 

MILS Multi-Independent Levels of Security 

NIAP National Information Assurance Partnership 

NIPRNET Non-classified Internet Protocol Router Network 

NISP National Industrial Security Program 

90________________________________________________________DSB Task Force on
______________________________________________________________________Appendix 

NISPOM National Industrial Security Program Operating Manual 

NIST National Institute of Standards and Technology

NSA National Security Agency 

NSTISSP 

National Security Telecommunications and Information Systems 

Security Policy 

OEF Operation Enduring Freedom

OIF Operation Iraqi Freedom

OMB Office of Management and Budget 

OS Operating System

OSS Open Source Software 

OUSD(AT&L) 

Office of the Under Secretary of Defense for Acquisition, Technology 

and Logistics 

PEO C3T 

Program Executive Office for Command, Control, and 

Communications - Tactical 

PKI Public Key Infrastructure 

PMO Project Management Officer 

PSE Product Security Evaluation 

R&D research and development 

RAM Random-Access Memory

RFP Request for Proposal 

SA-CMM Software Acquisition - Capability Maturity Model 

SAP Systems, Applications and Products 

SBU Sensitive But Unclassified

SEI Software Engineering Institute 

SIBS Software Industrial Base Study 

SIPRNET Secret Internet Protocol Router Network 

SKPP Separation Kernel Protection Profile 

SLOC source lines of code 

SOSCOE System of Systems Common Operating Environment 

STAR System Threat Assessment Report 

SW software

TCB Trusted Computing Base 

TCG Trusted Computing Group 

Mission Impact of Foreign Influence on DoD Software_____________________________91 
Appendix______________________________________________________________________ 

TPM Trusted Platform Module 

TSM Training and Doctrine Command Systems Manager 

UAV Unmanned Aerial Vehicle

U.K. United Kingdom

U.S. United States 

USAF United States Air Force 

VSA Value Set Analysis 

WMD Weapons of Mass Destruction 

WS SCAP Weapon System Certification and Accreditation Plan 

WS SDP Weapon System Software Development Plan 

Y2K Year 2000

92________________________________________________________DSB Task Force on