Skip to main content
June 10, 2014

NIST Updates Guidance On Securing Software Supply Chains

An updated guide on risk management practices recommends that companies pay more attention to the security of their software supply chain.

A draft release of an updated risk management guide from the National Institute of Standards and Technology (NIST) is warning federal agencies and other firms that operate “high impact systems” to pay more attention to how the software they buy was made. The government’s lead agency for technology best practices warned that federal agencies have less visibility into — or control over — how the technology they purchase is made. That lack of knowledge constitutes a major security risk they must address. NIST issued the warning as part of a draft document: Supply Chain Risk Management Practices for Federal Information Management Systems and Organizations. (NIST SP 800-161), released on June 3. The agency is seeking comments through July 18, 2014. The second draft follows a first, released in August, 2013. The document is designed to guide federal departments and agencies in identifying, assessing, and mitigating supply chain risks to what it terms “Information and Communications Technology,” or ICT. It integrates ICT supply chain risk management (SCRM) into federal agency enterprise risk management activities. According to NIST, federal agencies have less understanding of “how the technology that they acquire is developed, integrated and deployed, as well as the processes, procedures and practices used to assure the integrity, security, resilience and quality of the products and services,” the report warns. The security of software development environments should be part of every organization’s risk management plan, NIST says. Among other things, the Institute recommends:
  • Limiting access to software development environments and other ICT supply chain infrastructure and monitor remote access to those environments.
  • Adopting “architectural designs, software development techniques and systems engineering principles that promote effective information security.”
  • Structure internal intrusion monitoring and anomaly detection services to look for supply-chain related vulnerabilities, including back doors and malicious code implanted during software development.

In the report, organizations are advised to achieve software supply chain security, in part, by mapping their information systems supply chain and their operational dependencies on external organizations and suppliers. If no program already exists to do so, NIST advocates creating an “acceptance testing” program that assesses third-party software security, including searches for exploitable vulnerabilities, back doors or other malicious code. (Veracode’s Vendor Application Security Testing (VAST) is a good example of just such a third-party assessment program.) The security of software supply chains is becoming a source of concern for security-conscious firms. Recent years have seen sporadic reports of security lapses in software and hardware supply chains. In 2012, Microsoft’s Malware Protection Center (MMPC) said it had observed an increase in malicious code infections linked to freeware and pirated software that is distributed globally. Malware authors, Microsoft said, were wrapping free versions of Adobe Flash and other applications with malicious wares. More recently, the Russian government claimed that teapots imported from China that apparently came implanted with malicious software that could enable the kettles to connect to wi-fi enabled devices within 200 meters and infect them. The cyber risk of third-party suppliers for everything from laptops to automobiles is difficult to assess, though there are startups that are attempting to elucidate that market. What is clear: regulators and industry groups are taking notice. Already, the Financial Services ISAC (FS-ISAC) has issued guidance on how to manage the security of third-party service and product providers, which includes a call for better policies governing the use of open source and third-party components, as well as static binary analysis for third-party software modules. OWASP, also, has put the security of third-party software components on its Top 10 list of web application security concerns. Finally, for banks, the Office of the Comptroller of the Currency recommended that regulated entities assess and manage third-party risk in their October, 2013 Bulletin (2013-29). For more on threats to supply chain security, check out our video series Talking Code, collaboration between Security Ledger and Veracode. You can also check out the Veracode Web page for information on Veracode’s VAST application security testing program.

Further Learning on NIST

Paul Roberts is an experienced technology writer and editor that has spent the last decade covering hacking, cyber threats, and information technology security, including senior positions as a writer, editor and industry analyst. His work has appeared on NPR’s Marketplace Tech Report, The Boston Globe,, Fortune Small Business, as well as ZDNet, Computerworld, InfoWorld, eWeek, CIO , CSO and He was, yes, a guest on The Oprah Show — but that’s a long story. You can follow Paul on Twitter here or visit his website The Security Ledger.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.