What proposed regulation could address a current failure to value bugs in the existing market?

The parent post suggested regulation as a solution for:

> Rewards that pay the bills and not whatever big tech companies have in their couch cushions.

I don't know how this would work and am interested in learning.

> If a company has a security hole that leads to disclosure of sensitive information, it should be fined

What's a "security hole"? How do you determine the fines? Where do you draw the line for burden of responsibility? If someone discovers a giant global issue in a common industry standard library, like Heartbleed, or the Log4J vulnerability, and uses it against you first, were you responsible for not discovering that vulnerability and mitigating it ahead of time? Why?

> such fines can be used for rewards.

So we're back to the award allocation problem.

> This creates an actual market for penetration testing that includes more than just the handful of big tech companies willing to participate.

Yes, if you can figure out how to determine the value of a vulnerability, the value of a breach, and the value of a reward.

There's a reason Good Samaritan laws are built around rendering aid to injured humans: there is no equivalent if you go down the street popping peoples' car hoods to refill their windshield wiper fluid.

It'd be one thing if these were isolated incidents, but they're not.

Furthermore, the methods you mention simply aren't effective. Our economy is now so consolidated that many markets only have a handful of participants offering goods or services, and these players often all have data and computer security issues. As for divestiture, most people don't own shares, and those who do typically don't know they own shares of a specific company. Most shareholders in the US are retirement or pension funds, and they are run by people who would rather make it impossible for the average person to bring real consequences to their holdings for data breaches, than cause the company to spend money on fixing the issues that allow for the breaches to begin with. After all, it's "cheaper".

It's a very different system from software's "NO WARRANTY OF ANY KIND".

Congrats, the brakes failed, you caused bodily damage to an innocent bystander. Do you take full responsibility for that? I guess you do.

Now build a security solution that you sell to millions of users. Have their private data exposed to attackers because you used a third party library that was not properly audited. Do you take any responsibility, beyond the barebones "well I installed their security patches"?

> It is well known that while the pure engineering disciplines, those that make cars and planes and boats, mostly know what they're doing... the software engineering industry knows how to produce code that constantly needs updates and still manages to segfault in so much as a strong breeze, even though memory safety has been a well understood problem for longer than most developers have been alive.

We're aligned there. In a parallel universe, somehow we find a way to converge. Judging by the replies and downvotes, not on this universe.

That's sort of make it look worse then, doesn't it? The main issue isn't that subtle. Even the wikipedia mentions it:

> points should always be validated before being relied upon for any computation.

Moreover the paper https://eprint.iacr.org/2015/565.pdf also mentions a few times:

> Algorithm 2 assumes that the input point P is in E(Fp2)[N], i.e., has been validated according to Appendix A

Appendix A:

> The main scalar multiplication routine (in Algorithm 2) assumes that the input point lies in E(Fp2 )[N]. However, since we have #E(Fp2) = 392 · N, and in light of small subgroup attacks [39] that can be carried out in certain scenarios, here we briefly mention how our software enables the assertion...