As to the first point, Equifax could be liable as they are the one operating the system (for profit), and they're the one processing personal information using it.

If they had been using commercial software they might have been able to shift the liability (if it existed) to the vendor based on it being not fit for purpose, but as they were using open source, no such option would be open to them.

How is that a "product liability" issue, as put forth by OP? What faulty product did they sell to consumers?

Well they sold services which made use of a vulnerable version of struts.... You can argue services != products, but It could be argued a similar approach could apply.

The fact that they didn't sell those services to consumers but that consumers are the ones impacted is actually a big part of the problem.

There's an externality here in that the people who suffer the loss have no part in the transaction (they are neither buyer no seller) so have no way to, in an economic sense, impact Equifax's behaviour, which does lead to the idea that regulation could be an appropriate approach.

> The fact that they didn't sell those services to consumers but that consumers are the ones impacted is actually a big part of the problem.

Perhaps, but it's a different problem that product liability.

> which does lead to the idea that regulation could be an appropriate approach.

CRAs are already regulated.

If I can jump ahead a little, are you saying that bad (e.g. fraudulently-inserted) CRA data cannot rise to the level of actual damages?

Who's doing the fraud? Is it Equifax, which is in good faith recording the information provided by its customers (credit companies, banks, etc)? The credit company that is reporting in good faith to Equifax (or another CRA), but is tying it to the wrong person because an account was fraudulently opened? Is it the person who used stolen ID data to open the account? Is it the thief who originally stole the data?

The US doesn't have a data-protection law, but how can you say their recording of the information is in good faith if they allow unauthorized people to make spurious changes via their systems and security practices?

> allow unauthorized people to make spurious changes via their systems and security practices?

I don't follow. Who's the unauthorized party that's "allowed" to make spurious changes via their systems and security practices?

Those who use the holes in their infrastructure, did you see the story about a database being accessible with default credentials? There is some question of scope for that particular issue, but it bodes duplication in the company's practices elsewhere.

You mean the web site that didn't have any non-public data, and was actually not in active use for 3 years? I agree that was sloppy, but the site didn't have the level of security requirements that one of the main sites or their internal network had. Do you put a $100 lock on a $5 bike?

And how was this "allow[ing] unauthorized people to make spurious changes"? No data was changed in the breach.

> What was the faulty product in this case? Struts? Why is Equifax liable?

Struts had provided a remedy for the fault, months prior. Equifax had _failed_ to implement that remedy, because it was 'difficult', 'complex' (due to its own application / deployment / infrastructure), for several months, on a highly sensitive service.

> Equifax had _failed_ to implement that remedy, because it was 'difficult', 'complex' (due to its own application / deployment / infrastructure), for several months, on a highly sensitive service.

Can you cite your source for these claims?

I don't work for Equifax, so I can't give you any inside information which confirms why they didn't patch Struts. However it is common knowledge among security professionals that it was the unpatched Struts vulnerability that lead to the data compromise. [0]

[0] https://krebsonsecurity.com/2017/09/equifax-hackers-stole-20...

It was also announced by Equifax themselves so of course it's common knowledge. I'm not sure of your point here.

https://investor.equifax.com/news-and-events/news/2017/09-15...

"Upon discovering a vulnerability in the Apache Struts web application framework as the initial attack vector, Equifax patched the affected web application before bringing it back online."

He already made his point: "Struts had provided a remedy for the fault, months prior."

According to your quote, they patched only after they were the victims of a breach; they should have been pro-active and dealt with the issue as soon as the vulnerability was made public.

You're assuming that they took no action, as opposed to not being 100% effective in their detection and coverage. There's no evidence that they simply ignored it. If they're using Struts, all they had to do is miss one instance of the wrong jar somewhere in their software ecosystem.