Why Legal Regulation Shifts Responsibility for Software Supply Chain Security to Vendors

In the face of increasingly impactful malicious attacks, governments of leading economies have turned their attention to the software supply chain security. Regulations like the EU’s Digital Operational Resilience Act (DORA) for financial institutions and the Cyber Resilience Act (CRA) for software and hardware providers Australia’s 2023-2030 cybersecurity strategy, and the U.S. government’s national cybersecurity strategy have turned a spotlight on the regulation of the software supply chain and could create significant change in application and software security, particularly when it comes to liability. 

The importance of protecting customers

We all sign end-user license agreements (EULAs) but customers vary hugely in terms of sophistication. There are government and military customers of software that have big security budgets. There are big corporations, Fortune 500 banks, and regulated industries, and then there are community hospitals and public school systems and small businesses, and sometimes they’re all users of the same software. 

Sophisticated customers understand what security issues they face and have the budget, resources, and tools to implement vulnerability detection, protection, and response. Those without the capability or budget to address the issue of vulnerable software risk losing their entire operations. Recently, a major U.S. hospital network, Prospect Medical Holdings, fell victim to a ransomware-based cyberattack that disrupted 16 hospitals in California, Connecticut, Pennsylvania, and Rhode Island, and 166 outpatient centers and clinics, leading to some hospitals having to stop operations and divert patients to other facilities. The attack was so serious that radiology, diagnostic, and heart health facilities were forced to close, and the FBI is investigating. 

This kind of attack is not unprecedented, and it illustrates why it’s so important for vendors to help protect those customers who have fewer security capabilities or less knowledge with which to mitigate risks.

Challenges with regulation

Formalized regulation is one way of addressing this problem, but it has issues of its own. We know how to innovate breathtakingly quickly. What we don’t know how to do is respond as quickly with regulation and appropriate checks and balances that don’t hobble innovation. This isn’t necessarily a new quandary. Typically, innovation in information and communication technology has outpaced regulation, and the latter has always had to play catch-up. 

The current debate about AI is a perfect example. Entrepreneurs are leading the way with incredible innovation, but the risks are only now beginning to be understood, and the power of technology is overwhelming.

The same thing is happening with software supply chain security. The legal and regulatory system is beginning to come up with some tentative innovations that could change the way we contract and deploy technology in a new definition of what constitutes due diligence. Every one of these transactions is governed by a contract or a statute, and the nature of that contract is changing dramatically to push the burden onto both the developers and sellers as well as the old classic caveat emptor burden on the buyer to be aware of what they’re getting.

From “caveat emptor” to “caveat venditor”

We’ve reached a stage of maturity and complexity in the software and applications industry that requires this new level of due diligence. As the software supply chain becomes more complicated, allowing the risk of purchase to fall entirely on the buyer is no longer acceptable or fair. We’ve seen this pattern before with manufactured goods like cars, household appliances, and electrical hardware. Initially, the notion of caveat emptor – buyer beware – was king. It was the buyer’s responsibility to check that your intended purchase did what you expected and worked properly, but as these items became more complex, it was clear that buyers/end-users didn’t always have the expertise to make these judgments. They needed to be protected by warranties because only the manufacturers and vendors had the know-how to suitably assess and guarantee their products. Established in law, caveat emptor shifted to caveat venditor – seller beware.

The concept of warranties has become increasingly specific and granular warranties have been incorporated in U.S. federal acquisition regulations, defense acquisition regulations, and all the state acquisition regulations that mirror them. Now the contracts at every level of government reflect a general acceptance that there are some things that the buyer doesn’t necessarily have the expertise to know. This statutory shift in federal contracting has now begun to enter the marketplace for software and applications, shining a light on elements of trustworthiness in contractual transactions within this market. Concepts of disclosure, candor, and clarity about the provenance of software components and dependencies increasingly need tools like software bills of materials (SBOMs) as part of software contracts.

What does this new due diligence look like? 

Although it’s not yet fully part of the statutory scheme, SBOMs are mentioned in this year’s White House cybersecurity strategy as an option, and the likelihood is that they’ll be required in any serious software transaction in the near future.

What is also evolving is a new sense of a much more balanced relationship between the buyer and the seller, especially with sophisticated products, and in sensitive environments like critical infrastructures and national security environments. There’s much more tolerance for spreading the pain so that all the burden doesn’t fall on the buyer. So, what exactly is the seller’s responsibility?

Increasingly, we’re seeing efforts to ensure that there’s explicit language where the seller is expected to know about their own supply chain and fully disclose that to the buyer just as the buyer should explain to a seller how they intend to use the product, what the context is, and what some of the risks are. Then, the seller has the opportunity to say whether the product would be used appropriately and if the intended use might be risky. This process provides the vendor with the opportunity to raise certain legitimate disclaimers to ensure that the buyer fully understands where there’s a risk that the vendor can’t cover. It leads to more open and transparent transactions.

The bottom line is that it shifts the risk balance from the side of the buyer to more shared responsibility with the seller. In the U.S. that’s going to be reflected in federal acquisition regulations (FARs), the Defense Federal Acquisition Regulation Supplement (DFARS), and state acquisition regulations supporting contracting. More balanced due diligence will become part of the contracting environment for all software and applications adopted by the public sector, and we anticipate that the private sector will follow this lead.