Tuesday, February 27, 2024

What a woman named EULA has to say about the software liability question

For close to a year, there has been a lot of discussion of liability for software suppliers. This came about after the White House put out a document and talked with reporters about the need to “…place liability ‘where it would do the most good’. This meant primarily ‘the company that is building and selling the software’”. I’ve written 5 or 6 posts on the question; the one I like best is here.

However, after I wrote these posts, the White House (and DHS) didn’t drop everything they were working on and immediately adopt my opinion in full; I was amazed that didn’t happen. This just goes to show there’s no accounting for tastes…

The WH (and a lot of other people, unfortunately) seems to believe that software developers are currently getting away with grand larceny, since their malfeasance is the root of many (and really most) software breaches. Moreover, today there’s no way that those evil developers can be held liable for those breaches.

I want to discuss the lack of liability first. I honestly don’t know what this means. As long as one party has standing to sue another in court for any sort of damages, there is liability. If anyone knows of a state in which it’s forbidden for a software customer to sue the developer of the software – or knows of some obscure provision of federal law with the same effect – please let me know. However, this simply isn’t the case.

On the other hand, there is one thing currently placing a big obstacle in the path of small software users who wish to sue a software developer for a hack caused by alleged insecure development practices: the EULA (End User License Agreement). Of course, we all approve the EULA without reading it, whenever we want to use a new software product or online service.

I don’t think EULAs should be banned altogether, but it should be illegal to include a blanket disclaimer of liability for all software flaws – although perhaps a few test cases in court could establish this principle without requiring legislation (BTW, since bigger companies can negotiate their procurement contract terms with their suppliers directly, I think the government shouldn’t intervene on their behalf. But since small organizations and individuals have almost no bargaining power - and it might violate antitrust law if they banded together to force terms on a developer - there needs to be some intervention by governments to protect end users from these one-sided “agreements”).

However, in the various articles declaiming the damages caused by software suppliers, I have never seen any passage that points to EULAs as the heart of the software liability “problem”. One statement they almost all seem to include is that there needs to be some sort of “safe harbor” for software developers who follow “good” software development practices. In other words, if a software developer is sued, their only possible defense is to point out that they followed the practices laid out in some document like the NIST Secure Software Development Framework (or SSDF for short).

Sounds simple, right? Just take a look at the SSDF; then imagine the pressure you’d be under if you were a supplier in a court of law and the only way you could avoid bankruptcy because of a lawsuit from an aggrieved customer was to somehow “prove” that you had followed the SSDF. Here’s just one of the many Practices required by the SSDF:

Implement Roles and Responsibilities (PO.2): Ensure that everyone inside and outside of the organization involved in the SDLC is prepared to perform their SDLC-related roles and responsibilities throughout the SDLC (SDLC stands for “Secure Software Development Lifecycle”).

Think of all the documentation you would need to gather to prove you had followed this Practice. For a large percentage of the employees in your organization, you would have to show a) they understood their SDLC-related role(s) and responsibilities and b) they were “prepared to perform” them throughout the SDLC lifecycle (for most employees, this probably means during every moment they were employed by the software developer).

What if the supplier couldn’t find some of the required documentation, especially for employees who left the company long ago? Would they be SOL? Even more importantly, the jury (probably not made up of highly educated software engineers) would need to determine where the line falls between the supplier’s complying and not complying with this Practice. Where will they draw that line?

Moreover, these questions will come up for every Practice and Task in the SSDF. The supplier’s lawyers will have to argue each one of those in front of the jury, against the lawyers for the plaintiff. Then the jury will need to deliberate on each of them. Even more importantly, they will have to make a decision, for each Practice and Task, whether the supplier “complied” with it.

Finally, the jury will have to look at the list of SSDF Practices and Tasks that the supplier “complied with” and compare that with the list they didn’t “comply with”, then come up with a single up-or-down decision on whether or not the supplier “followed” the SSDF. If they decide the supplier did follow it, they will be allowed to continue in business (minus a big chunk of change for the legal defense). But if the jury decides the supplier didn’t follow the SSDF, they might just head down the hall to Bankruptcy Court and save a trip back to the courthouse.

Does anyone think this very complex “safe harbor” is practical? If not, what if someone creates a “simple” standard, in place of the SSDF, that just listed maybe five steps the supplier needs to follow to receive safe harbor? And suppose each of these is a “no-brainer” - e.g., “You must lock the door of your office before going home every night”. That would make it a cinch for every supplier who was sued to receive safe harbor. But is that fair to the plaintiffs? No matter how strong a case they might have, there would be no possibility of ever holding the supplier liable for the damages they caused.

Even more importantly, why should the burden be on the supplier to prove they developed the software using safe practices? Even if they didn’t follow a few of the SSDF Practices, shouldn’t there also be a burden on the customer (the plaintiff) to prove they followed safe practices in using the software?

For example, what if the supplier diligently provided a patch for every important vulnerability they identified in their software over the ten years that the customer used the software – yet the customer never applied a single one of those patches? Moreover, what if the customer’s loss was caused by a hacker who exploited one of those important vulnerabilities? Is that irrelevant to the question of whether the supplier is liable for the breach? If the only consideration preventing the supplier from being held liable is whether they followed the SSDF to the letter of the law – as it would be in this case – the answer is Yes. It doesn’t matter what the customer did or didn’t do; the breach is the supplier’s fault.

The only good aspect of the proposal to automatically hold a supplier liable for a customer breach, unless they can prove they’ve followed the SSDF or a similar framework, is there’s no way it will ever be implemented; it is clearly unfair to the suppliers. Liability for any organization, whether they’re a software supplier, a liquor distributor or a truck driving school, can only be determined in a court of law. Furthermore, it needs to be determined by a judge or jury that considers all the evidence, not just whether the supplier has followed every provision in a document like the SSDF, which is mostly incomprehensible to both judge and jury.

Of course, this means that cases dealing with software liability may take a long time to be adjudicated. But there is one way this process could be expedited without trampling on fundamental rights: The judge or jury should not be required to make an up-or-down decision on the supplier’s liability based on their “compliance” with a single document. Instead, there could be questionnaires available for judges and juries, which could be used in cases where liability for software defects is in question. The questions would be about recommended cybersecurity practices for both suppliers and their customers; the judge or jury could decide whether they were needed in any particular case.

Both parties would be required to answer the questions that apply to them. For example, the supplier might be asked how quickly (if ever) they issued patches for serious vulnerabilities identified in their products. And the customer might be asked how quickly they applied each patch to the supplier’s product in their environment (of course, there would need to be at least some evidence to back up both the supplier’s and the customer’s answers).

Who should develop these guidelines? Maybe NIST. Or maybe organizations outside of government, like the Linux Foundation or OWASP. Any party wishing to participate in drawing up the guidelines should be allowed to do so.

You may wonder (I certainly have) why this idea – that software developers should be assumed to be liable unless they can prove they complied with a set of ambiguous safe harbor provisions – was ever taken seriously. I think it is because some people in government get frustrated by the fact that it takes so long for cases dealing with issues like software liability to be decided by the court system. Surely, they think, there must be a more expeditious way of settling these disputes! And if we need to cut one or two corners with the legal system, isn’t that a small price to pay for resolving these cases?

Those people are right that there is a more expeditious way of resolving cases involving software liability – it’s called regulation. If you’re concerned that software suppliers aren’t following secure development practices and are therefore putting their customers at risk, then draft a law that requires that suppliers follow the SSDF religiously and get fined for any violations.

Of course, you’ll need to get that law passed by Congress. Currently, it’s hard to see Congress agreeing to name a post office after George Washington, let alone to extend government regulations into a brand new area (plus probably to create a new agency to enforce the law, since there is currently no federal agency that I know of, other than the FDA, that has regulatory jurisdiction over suppliers of products consumed by the private sector – other than for safety considerations[i]).

Creating regulations is hard, and it’s probably impossible in the current political environment. But that doesn’t excuse throwing away time-tested legal concepts like determination of liability in a court of law and equal treatment of opposing parties in court cases. If it’s a choice between waiting for a slow judicial system and taking an end run around that system and singling out a particular class of defendants as liable before a trial even takes place, I’ll take the former any day.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.

My book "Introduction to SBOM and VEX" is now available in paperback and Kindle versions! For context, see this post.


[i] This excludes the nuclear power industry and the military. In both of these “industries” there are regulations that apply to suppliers for cybersecurity and other areas of risk.

No comments:

Post a Comment