Supply Chain Assurance Overview
September 2011 • CERT Research Report
Robert J. Ellison, Christopher J. Alberts, Rita C. Creel, Audrey J. Dorofee, Carol Woody
In this section of the research report, the authors attempt to integrate development and acquisition practices with risk-based evaluations and mitigations.
Software Engineering Institute
The term "supply chain" has a long history in the business community and includes recent trends such as such just-in-time inventory. In the past, the business community considered supply chains as relevant only to the delivery of physical products. Now the business community uses the technology supply chain to develop most IT systems (hardware, software, public and classified networks, and connected devices), which together enable the uninterrupted operations of key government and industrial base actors, such as the Department of Defense, the Department of Homeland Security, and their major suppliers. While we have decades of physical supply chain data that have led to effective management practices, we have limited experience with software supply chains. While no perfect solution exists, much can be done to enable organizations to reduce risk effectively and efficiently while leveraging the significant opportunities afforded by supply chains.
On-time delivery and costs often get the most commercial attention, but some of the most serious risks are associated with system assurance, the confidence that the system behaves as expected. Software defects, such as design and implementation errors, can lead to unexpected behaviors or to system failure. Defects that enable an attacker to purposely change system behavior are often referred to as vulnerabilities. The source of such vulnerabilities is the supply chain, which includes commercial product vendors, custom development and integration contractors, and suppliers and subcontractors to those organizations. This research considers how to better manage the acquisition of software developed through a supply chain to reduce the likelihood of operational vulnerabilities.
Unfortunately, exploitable software defects are widespread. MITRE has analyzed successful attacks and identified more than 600 common software weaknesses, described in its Common Weakness Enumeration (CWE). Many of the CWE defects are widely known, as are the techniques that eliminate them. But those techniques are frequently not applied. For example, countermeasures for SQL injections are well established, yet SQL injections still rank second on the MITRE/SANS list of the top 25 most dangerous software errors. Veracode's State of Software Security Report released on September 22, 2010 warns that most software is very insecure. Regardless of software origin, 58 percent of all applications submitted to Veracode for testing did not achieve an acceptable security score upon first submission.
Software supply chain security issues do not vanish when an acquisition is completed. Product designers base their decisions on the data available and the threats known at the time of development. Product assessments performed as part of the initial acquisition for a commercial component are valid only at that time. Some examples of sources of risks that may emerge during deployment include the following:
- New attack techniques and software weaknesses cannot be foreseen.
- Product upgrades that add features or change design can invalidate the results of prior risk assessments and may introduce vulnerabilities.
- Corporate mergers, new subcontractors, or changes in corporate policies, staff training, or software development processes may eliminate expected supply chain risk management (SCRM) practices.
- Product criticality may increase with new or expanded usage.