NIST Updates Guidance for Supply Chain Security Management  

The National Institute of Standards and Technology (NIST) has updated its cybersecurity supply chain risk management (C-SCRM) guidance in an effort to help organizations protect themselves as they acquire and use technology products and services.

The document provides guidance on identifying, assessing and responding to cybersecurity risks throughout the software supply chain at all levels of an organization.

It encourages organizations to consider the vulnerabilities not only of a finished product they are considering using, but also of its components—which may have been developed elsewhere—and the journey those components took to reach their destination.

The publication also offers key best practices for organizations to adopt as they develop their ability to manage cybersecurity risks within and across their supply chains.

Casey Bisson, head of product and developer relations at BluBracket, a provider of code security solutions, explained that safety and security are often overlooked because most buyers expect it as a baseline requirement for a product to enter the market.

“One of NIST’s responsibilities is to provide standard measures of product safety. The guidance on software supply chain security is a great start,” he said. “Software organizations that already have practices and measures to ensure the safety of their software supply chain should be able to adopt these easily.”

He explained that enterprises that haven’t yet adopted these practices and measures can use the NIST guidance as a framework for minimum required controls.

Mike Parkin, senior technical engineer at Vulcan Cyber, a provider of SaaS for enterprise cyberrisk remediation, added that threat actors have attacked though third parties, both through the supply chain and support vendors, in some very high-profile breaches.

“With the disruption to the supply chain over the last couple of years, organizations are struggling to meet their needs and that may prompt some to cut corners when vetting the security of new supply sources,” he said. “This guidance from NIST will hopefully serve as a reminder to not ignore security concerns in an effort to make up for supply chain disruptions.”

NIST Guidelines

Parkin pointed out that, at almost 350 pages, the NIST guidelines are comprehensive and go into depth on multiple points.

“The bottom line is that securing the supply chain is a complex task, with multiple moving pieces and a lack of visibility, and organizations need to leverage available tools to do it,” he said. 

Bisson explained NIST has been working on the problem for over a decade, but their efforts got a big boost with an executive order last year requiring it to publish standards and for federal agencies to comply with those standards for all purchases.

“The guidance NIST published is actually fairly narrow and acknowledges the rapid evolution of the problem space,” he said. “The authors made great efforts at articulating recommendations that avoided any specific technology that might become obsolete tomorrow. It lays the foundation for an iterative approach to a complex problem.”

Longer Supply Chains

He explained the steady transformation of every business into a software business has multiplied and lengthened the software supply chains we depend on.

“A single software product is usually composed of dozens or thousands of discrete software components in multiple layers,” Bisson said. “The business functionality is delivered in one layer, while infrastructure capability is provided as a service at another layer.”  

Simultaneously, he added, the explosion of open source that has powered a significant part of software growth has complicated those supply chains.

Enterprises looking for an accountable party—”a single throat to choke”—often find their software is built on volunteer contributions from a community that doesn’t respond well to demands.

“Most enterprises face a complicated external software supply chain, but supply chain risks don’t end at a company’s firewall,” Bisson said. “Every company that has code has an internal supply chain from developer to deployment.”

He pointed out that dozens of companies have had code leaked from private repositories just this year, revealing secrets that were used to power further attacks on those enterprises—stolen OAuth secrets from one company led to stolen code from another, in one example Bisson cited.

“Securing internal supply chains is more than just access management, it requires mitigating risks related to code theft by removing secrets from the code,” Bisson said. 

From Parkin’s perspective, there are multiple factors that come into play when trying to secure the supply chain.

He explained organizations only ever have full visibility into their own environment, which means they have to trust their vendors are following best practices.

This means they need to include contingencies for when a third-party vendor is breached or build processes that severely restrict the damage that can occur if a breach does happen.

“It’s even more complicated when an organization needs to deal with multiple vendors to compensate for shortages or disruptions,” he said. “Even with the correct risk management tools, it can be hard to account for everything in play.”

Nathan Eddy

Nathan Eddy is a Berlin-based filmmaker and freelance journalist specializing in enterprise IT and security issues, health care IT and architecture.

nathan-eddy has 242 posts and counting.See all posts by nathan-eddy