> I think you could stand a chance if you designed your product to fit the limitations of what we can deliver reliably. You'd lose most of your features. You'd ship boring CRUD stuff exclusively on your own dedicated hardware, and you'd build it with minimal library support. It would be excruciating, but people do it. Just not for any of the kinds of software we normally interact with.
I think we are in agreement then. If you are targeting K8S or Electron, you've already lost the battle against many threat-models that matter for liability. I think what you are pushing back against is people imagine bug-free software and they think "oh maybe 4x more expensive and it will look like it's from 2005" while the reality is more like table-stakes of 10x more expensive and it will look like it's from 1980.
I personally think that the tradeoffs are worth it for more industries than currently make it, but I don't think the law can be nuanced enough to both be effective and not cause massive collateral damage to many other industries. Look at the chilling effect regulation has had on software in the medical industry, and yet those regulations seem to have done little to increase the resources required for an attacker who wishes to exfiltrate patient data.
Nate Lawson used to tell me (I assume he'd still tell me) that companies trying to ship secure software need to budget 10x for verification what they do for implementation. The best companies in the world don't even budget 1x. I'm not sure it's reasonable to ask them to. I think we'll know stuff in 10 years that will change how we look at things.
But rewind to last year, when I was still at Latacora. Ask me the question: can I hire you to make my development process more secure? Sure, I think I can add value there. Ask me instead: can I hire you to make my software liability-proof? Not a chance.
Take 9 strong software security people and divide them into 3 teams. Give each team a stretch of time to find vulnerabilities. There will be a ton of overlap in the findings, but each team will find different things. One team will happen to have a specialty in the low-level details of the platform it's running on; another will spend 80% of their cycles thinking about SSRF and HTTP desync vulnerabilities; still another will happen to have a reliable process for exhaustively testing authorization. Don't get me started on K8s or Electron or cryptography or iOS or browser extensions or Node.js.
And that's all for pretty standard app stack stuff. None of those problems are the subtext for Perlroth's book; the vulnerabilities she's trying to write about are in low-level C/C++ code. The biggest security teams in the world have build enormous, carefully-instrumented fuzzing farms for this stuff and they don't find everything.
I literally mean nobody.
I think you could stand a chance if you designed your product to fit the limitations of what we can deliver reliably. You'd lose most of your features. You'd ship boring CRUD stuff exclusively on your own dedicated hardware, and you'd build it with minimal library support. It would be excruciating, but people do it. Just not for any of the kinds of software we normally interact with.