This all not to mention the explicit waiver of liability that accompanies virtually every product or software service offered in the US.
Providers are held to a higher standard because the means of securing their product/service are within their control. The standard of care is very context-specific. Photo sharing applications will not be held to the same standards as banks or the military any more than mom-and-pop delis are held to the same security standards as JFK airport or Dodgers stadium.
This all not to mention the explicit waiver of liability that accompanies virtually every product or software service offered in the US.
This is why liability waivers are now standard issue, so that liability for simple negligence is no longer an issue. But note that such waivers do not absolve the developer of liability for gross (i.e., intentional or pervasive) negligence.
I don't propose an answer -- I'm curious what you think.
This is easier to understand when you realize that "SQL Injection" really means "any sequence of conditions allowing an adversary to corrupt an SQL query issued by the application", and that those sequences of conditions can be long, complicated, deeply buried and not at all evident from the overt behavior of the application.
So now you have a problem: SQL Injection that is obvious from the moment you enter a single quote character in a login form is an obvious signal of slipshod development, but there are injection vulnerabilities that no reasonable person could say were obvious. Where are you going to draw the line, and, just as importantly, how are you going to articulate the line so that cases can be heard with predictable decisions? Because unpredictable outcomes are a tax.
But that opens up a can of worms of who does the accrediting, who pays for them, are they a governmental agency, and perhaps the most overriding thought of "How many users do you have using your software before you're required to get your code inspected".
Which is, obviously, one hell of a rabbit hole to be delving down, and probably a terrible idea. But as seen with a decent amount of companies online recently (LinkedIn and Dropbox come to mind), good security just isn't happening.
First: every piece of software shipped has to be pentested? Most software, by a long stretch, isn't. App pentesting is very expensive.
Second: what testing team? You really mean, "a good pentest team". But as we've seen with PCI, regulated testing is a race to the bottom, and your certification has as much to do with which QSA you pick as anything else. There are lots of terrible pentest teams out there. Every IT and network consulting shop has a line item now for "web application security testing".
This sounds like an employment act for pen-testers.
Which would probably be good for me, since I could pivot to doing that. And I would, because I'd be a fool to keep on writing software under that kind of regime.
I'm even more frightened by the maze that "accredited pen-tester" would entail.
On the other hand, if it is a file-sharing saas targeting small businesses, the failure to handle SQL injection or store passwords properly would be negligence.
[1]http://www.dailypaul.com/249310/federal-court-rules-utah-s-a...
It should be noted that the linked article is talking about the UK where things are different. In the US you are allowed to sue, for any reason. Whether you can find a lawyer willing to take your case, and whether a judge subsequently decides your case has any merit, is a separate matter.
Whoever came up with this example doesn't know much about law (and IANAL). To prevail in a court of law, the hamburger plaintiff would need to show a violation of prevailing standards of behavior, for example, health codes. But if a threat is unknown at the time of the injury, the defendant is generally held blameless.
An example is Legionnaire's Disease, which was ultimately traced to a decision to turn down water heater thermostats to save energy during the 1970s oil crisis. The hotel operators could hardly be held accountable for "negligence" in a case like this, where they had no possible way to anticipate a side effect of a reasonable decision.
It should be the same with software -- if a developer writes code in good faith and meets prevailing quality standards, he shouldn't be held to account for an exploit that arises later.
If the developer worked in collusion with hackers, that would be different, but it's not what's being discussed.