How Software Supply Chain Security Regulation Will Develop, and What Will It Look Like?

The escalation of international legislative interest in regulating the software supply chain has led to an increasing likelihood that tools such as software bills of materials (SBOMs) and AppSec solutions will become essential for companies doing business in the public sector or in highly regulated industries. However, the process of building and enforcing effective regulations presents challenges as well. As regulations grow in importance, what effect will that have on software supply chain regulation? And let’s not forget the topic that affects everything tech these days: AI.

Influencing regulations 

Regulations are not birthed solely in government or legal circles. There’s a combination of influences that drive the adoption of regulation. For example, as liability shifts towards software producers, this won’t go unnoticed by the insurance industry. We can anticipate that insurers will intervene to ensure that organizations properly disclose the extent of their cybersecurity measures. Otherwise, claims will be denied and insurance will be withheld.

There’s also a business motivation for regulation. Companies will want to demonstrate to public and private customers that they are responsible corporate citizens and reliable business partners. There may be initial costs, but over time they will reap the benefits of having software supply chain security that their competitors don’t. Then, everyone else will have to catch up and good AppSec will become standard, especially as regulations will increasingly require companies to fulfill certain security criteria. Partly this is a cultural shift that embraces the value of trustworthiness in driving revenue; it’s also an acceptance of the fact that building a robust security framework that meets regulatory guidelines will ultimately be a successful marketplace differentiator.

SBOMs and due diligence 

Under regulations and cybersecurity strategies from the U.S, the EU and as far afield as Australasia, SBOMs are likely to play an increasingly important role in the due diligence process. Nevertheless, opinion is divided as to how much emphasis should be put on SBOMs alone. On the one hand, encouraging or compelling vendors to produce SBOMs makes them accountable for what’s in their software. It makes them more responsible for managing their own software supply chain risk, and it makes them more reliable.

However, the information that SBOMs provide is only valuable if the buyer knows what to do with it. SBOMs are one element of an evolving security posture based on trustworthiness, transparency, and disclosure. At present, that responsibility is migrating towards the producer, and we can expect to reach an equilibrium between what the seller is entitled to understand about the buyer’s intended use, especially in sophisticated environments, and the buyer’s ability to use data about pedigree and providence, not just SBOM data.

Importantly, as part of every procurement process, sellers should know what’s in their tools and buyers should know that what they’re getting is secure.

What’s next for software supply chain security regulation?

Assuming that current trends in regulation continue, we can expect SBOMs to proliferate, along with increased adoption of existing technologies that manage security risks. But what’s next?

The answer lies in bringing together and applying other guidelines, methodologies, and verification practices. For example, NIST provides us with the Secure Software Development Framework (SSDF), a set of fundamental, well-established, secure software development practices that should be integrated with every software development lifecycle (SDLC) implementation, such as doing static analysis, defining vulnerabilities, using the right compiler settings, and other processes you can implement and decisions you can make while you’re building your software to make it more secure. Hand-in-hand with this, and with the use of SBOMs, you can verify your security measures by applying standards such as the Cybersecurity Maturity Model Certification (CMMC) to attest to your commitment to security best practices.

These processes and tools will continue to develop to satisfy regulations like FARs and DFARs and will inevitably evolve as the use of software components, dependencies, and the attack surface continues to expand. What’s likely is that all these tools and practices will coalesce into regulated standard operating software supply chain security procedures.

How does AI figure in these considerations?

In the next year or so, we can expect software supply chain security to include AI — and that technology will certainly be regulated. The EU has just gone through the first step of a three-step process of passing an AI statute. The UK is working on one, and there are hearings in the U.S. Congress. In February 2023, the American Bar Association (ABA) issued a statement of principles around AI, which includes some considerations about the use of AI in software development.

Perhaps the most challenging thing when considering including AI in this discussion is defining it clearly, because it’s difficult to regulate what you can’t define. This is where NIST may play an important role with its AI management framework, currently a set of voluntary guidelines that could pave the way for workable and transparent regulations.

The main concern is that heavy regulation could stifle innovation, particularly when competing with companies in countries with fewer limitations. The most important thing is to focus on the outcome, which is to improve security and accountability without stifling innovation. If nothing else, developing regulations encourages us to start thinking about what we can do to improve software supply chain security organically, to drive us to do better due diligence ourselves, and to be more responsible and accountable before we need to feel the force of law.