Overview[edit | edit source]
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 licenses 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).
Risks of COTS software[edit | edit source]
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. . . .
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.