There’s news going around about the Solarwinds CISO potentially being held personally accountable by the SEC for the 2020 build pipeline hack against their Orion systems management platform.
Making vendors accountable for product security is probably a good idea, equivalent to food producers being accountable for their product. It’s faintly bizarre that clickwrap EULAs allow software vendors to state so much caveat emptor. Although when I, not a lawyer, try to consider changes, all I can see is how they’d fail.
- a lot of vendor contracts have some form of fit for purpose warranty clause to cover that it does X, not Y, and the customer holds the bag if they use the software in an unintended way. In other words, if you use the floor wax as a dessert topping, that’s on you buddy. Does this clause still hold if the vendor is responsible for hacks against the customers’ deployed software stack? I think not, because that’s an unintended use. I expect that means a wave of contract clarification to put more teeth into the definition of intended use, if any change in the status quo occurs.
- Practically all vendor contracts limit the vendor’s liability, though the amount of limitation is open to argument. Maybe the vendor accepts no liability, or maybe they accept up to a dollar figure set by their insurance provider. Is that still relevant if the government holds the vendor responsible for unexpected outcomes, or can customers start to sue vendors because their laptop SSD failed after they installed a Photoshop license? This seems unlikely, but to be determined if it would it be an ignored risk or an addressed one in future legislation.
- vendors currently commit to timely patches of discovered issues, which customers then choose not to install. Does the vendor become responsible for the customer not installing the patch? What about EOL software, is the vendor forced to maintain everything forever because some customers won’t upgrade? Or is this the end of on-premises software? That seems unlikely, but so does any right to force customer behavior with the software.
- How does the vendor demonstrate that they’ve done enough? What even is enough? Does this become a “I know it when I see it” situation, or does FedRAMP become the baseline for every organization in the US, or is this precedent only used when a particular regulator is angry at a particular vendor? I suspect the latter, which is not a great answer.
I do wonder if there’s a single individual on the hook when a farm ships some e.coli tainted lettuce though? The answer unsurprisingly appears to be “it’s complicated”. Oh, and that pipeline is full of subcontractors too. That said, I did find a case where the e-staff and board was held personally responsible.
CISO is already a tough job, if this precedent sticks, it’s going to be even worse. They realize that they’re on the hook, what do they do? They try to solve the problem. I would expect them to stop the use of open source software because it’s an uninsurable gap, as well as renegotiate their supplier contracts to include liability insurance. That last one might be tough to get the big shops like Microsoft or Amazon to do, but certainly an option with the average vendor.
Let’s go back and hammer on that point a little more… how does open source software survive when liability insurance is a requirement? The only way is for each OSS package to have a corporate sponsor who carries the insurance, and the only way for that to really work is that the sponsor reviews and approves all changes (a process that is sure to stop at the sponsor’s next layoff round, if it ever starts). It’s not impossible, but:
- the cost-benefit ratio of another software vendor using and improving a package that their competitor sponsors gets really skewed
- the days of a heroic developer scratching an itch become seriously numbered.
Thing is, all of this slows down project rollout and development by a lot, if only by raising a lot of questions that have to be answered with discussions outside of R&D. Renegotiating a single contract is already weeks or months of lead time. That kind of delay on every package inclusion makes security into a problem for day to day operations, which is not a recipe for CISO longevity. I doubt the slowdown of decreasing open source and increasing compliance standards across the whole industry would be easy to swallow.
The only way I see this concept working is if the e-staff and board share responsibility. That increases the vendor onus from the current level, but doesn’t make the resulting slowdown one person’s fault. It still leaves open the really ugly question of setting the bar. Which vulnerabilities are too much risk? Which hacks trigger court cases and penalties? What happens if politically connected or too-big-to-fail vendors are not prosecuted but smaller ones are?
More reading:
Monkeynoodle.Org 