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 of critical infrastructure exists because the software that enables these 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 breach reports show that the source vectors of attack are in 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.

How do organizations proactively protect critical infrastructure from being the victim 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 criteria should contain these specifications, at a minimum:

1. 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);
2. Static source code analysis of all available source code found in the supplier product to identify weaknesses listed in Common Weakness Enumeration (CWE);
3. Malware analysis of supplier-provided software to determine whether any known malware exists in that software, along with a risk assessment of mitigation controls;
4. 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.

Read more at Software Supply Chain Risk Management: Enabling Resilience in National Critical Infrastructure

Share your opinion below or send us a message for further information. Subscribe to get updates.

• BV, Ascenz Join Forces in Ship Performance, Monitoring
• The Missing Link in Sales Performance
• What Facebook’s Content Strategy Means for Publishers
• Microsoft announces Workplace Analytics, a tool that aims to improve employee productivity
• This is what the next generation of IT services looks like

Facebook

Linkedin

Twitter

email