Growing concerns related to dependencies on software-reliant information communications technology (ICT) and Internet of Things (IoT) devices are pushing changes in governance associated with supply chain risk management (SCRM). The possibility of disruption exists because the software that enables critical capabilities is vulnerable and exploitable. Exploit potential is often more about the vulnerability of assets in target organizations than the ingenuity of the attackers. Several
recent reports identify the source of the breaches to be within the software. Consequently, organizations expanding the use of network-connectable devices need comprehensive software security initiatives to address weaknesses resulting from technological vulnerabilities and a lack of “cyber hygiene” (lack of caution) among those who develop and use software applications and software-reliant IoT devices.
Exploitable weaknesses, known vulnerabilities and even malware can be embedded in software without malicious intent. Indeed, sloppy manufacturing hygiene is more often the cause of exploitable software. Such poor hygiene can be attributed to the lack of due care exercised by supply organizations with developers, integrators and testers who are often unaware of or untrained on software security, compounded by inadequate testing tools and the failure of suppliers to prioritize addressing the risks associated with the poor security of the software they deliver to the organizations that use it.
- Control 2 – Inventory and Control of Software Assets
- Control 3 – Continuous Vulnerability Management
- Control 18 – Application Software Security
How do organizations proactively protect themselves from being victims of software provided by others? As a start, they use contracts to set supply chain expectations for their suppliers. Sample software procurement language is available for free to assist organizations in developing their contracts and establishing test criteria as part of software SCRM due-diligence. Procurement requirements should contain these specifications, at a minimum:
- Software composition analysis of all compiled code found in the supplier product to identify all third-party open source components via a software bill of materials and to identify all known vulnerabilities listed in Common Vulnerabilities and Exposures (CVE) in publicly available databases, such as the NIST-hosted National Vulnerability Database (NVD);
- Static source code analysis of all available source code found in the supplier product to identify weaknesses listed in Common Weakness Enumeration (CWE);
- Malware analysis of supplier-provided software to determine whether any known malware exists in that software, along with a risk assessment of mitigation controls;
- Validation of security measures described in the product’s design documentation to ensure they are properly implemented and have been used to mitigate the risks associated with use of the component or device.
To facilitate achievement of these requirements, internationally recognized information-sharing standards associated with software security automation are freely available. For example, ITU-T’s Cybersecurity Information Exchange (CYBEX) X.1500 series provides a set of standardized means for identifying, reporting and exchanging cybersecurity information. The ITU-T X.1500 CYBEX ensemble of techniques is a collection of best-of-breed standards from government agencies and industry, and it is an essential enabler to slow the contagion of cyberattacks that target exploitable software. Key for SCRM, ITU-T offers standards for vulnerability/state exchange and event/incident/heuristics exchange. These include standards for exploitable weaknesses (CWEs, ITU-T X.1524), known vulnerabilities (CVEs, ITU-T X.1520) and malware (MAEC, ITU-T X.1546).
These are the same software security enumerations that have been co-sponsored by the U.S. government, and are also the same as those that organizations should use to check software in fulfilling contract terms and conditions.
At a minimum, enterprises with products on “whitelisted” approved or “assessed and cleared” product lists, should test those products for exploitable weaknesses, known vulnerabilities and malware.
- If suppliers do not mitigate exploitable weaknesses or flaws in products (which are difficult for users to mitigate), then those weaknesses represent vectors of future exploitation and zero-day vulnerabilities that put the enterprises that use the products at risk.
- If suppliers do not mitigate known vulnerabilities prior to delivery and utilization, then users cannot have any level of confidence that patching and reconfiguring will be sufficient or timely to mitigate exploitation.
- If suppliers do not check that the software they deliver does not have malware (typically signature-based), then users are at risk of using software with malware pre-installed.
For SCRM due-diligence to be sufficient, it requires third-party testing of software and software-controlled products, either by an independent lab or as part of acceptance testing by acquiring enterprises. Many tools and services find weaknesses and vulnerabilities in source code and binaries, and report a software bill of materials detailing the open source components in both source and binary code files. At a minimum, there should be a requirement for suppliers to provide a bill of materials with test reports that offer evidence of mitigations associated with CWEs, CVEs and malware. Organizations not doing this as part of SCRM due-diligence are very much at risk of compromise and exploitation.
Because enterprises know that they cannot trust third-party suppliers to mitigate risks attributable to exploitable software, they have learned to implement SCRM due-diligence that includes testing requirements to address mitigations for CWEs, CVEs and malware. Without it, those enterprises should not be surprised if they are in the headlines for breach reports.
