A little more than a week before the Colonial Pipeline attack, two government agencies issued an overview and guidance on how software buyers and vendors could identify, assess and mitigate software supply chain risks.
In that 16-page document, “Defending Against Software Supply Chain Attacks” the National Institute of Standards and Technology (NIST) and the Cybersecurity and Infrastructure Agency (CISA), call attention to many things that have since garnered attention of the highest levels of private industry and government, as I wrote recently in detailing President Joe Biden’s executive order.
But there’s something in the guidance from NIST and CISA worth calling increased attention to, and that’s the increased expectations that your customers will have of you as a software supplier.
By now, you and your customers, and the technology vendors you use, are well aware of the risks of not taking the steps to secure the software supply chain, of which open source software is a huge part. Our own audit team uncovered 89 security vulnerabilities per audit project, an increase of 98% over 2019. Some 46% of those vulnerabilities had a “high” CVSS severity rating according to the National Vulnerability Database. High-risk vulnerability discovery increased 65% in 2020, according to Help Net Security. And I recently read another report from a firm that analyzed NIST’s National Vulnerability Database only to discover that a record 18,103 security vulnerabilities were disclosed in 2020, at an average rate of 50 CVEs per day.
Knowing the stakes are unbelievably high, everyone, from the private to the public sector, is now looking for actionable solutions. As part of their recommendations for customers on ensuring secure software supply chains, NIST, CISA and the U.S. Federal Government are clear that software buyers should be looking for some basic assurances from the vendors they work with.
NIST and CISA recommend taking two steps toward “prevention” by making sure suppliers have strong software composition analysis capabilities. First, they recommend asking vendors whether they use a software development lifecycle that uses secure software development practices and looks for vulnerabilities and weaknesses in source code and compiled code, and demonstrates the degree of rigor applied. Secondly, they recommend requesting a software component inventory (e.g. software bill of materials) that articulates the components and other attributes of delivered software. Going one step further, NIST and CISA even suggest using that as criteria in a buying decision, writing that, “if a vendor cannot provide a component inventory, consider using that as a differentiator when selecting among competing products.”
These have long been our recommendations. In fact, Alex Rybak, director of product management, back in January predicted that the automated and evolving Software Bill of Materials (SBOM) would move from being a nice-to-have to a competitive necessity.
“Continued concerns over data privacy, security and product safety, coupled with OpenChain receiving ISO certification (ISO 5230) to put more clarity around open source licensing, will push software vendors to provide a full asset portfolio view and chain of custody for identifying components that may present vulnerabilities,” he wrote in February. “These assurances will increasingly become part of software contracts between vendors, customers, and partners.”
