> If you’re poisoned by a burger you can sue the restaurant that sold it - so why can’t you take a software developer to court if their negligent coding lets hackers empty your bank account?
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.
Right; in sales contracts, as I understand it, the obligation is that of a prudent person's ordinary care. Virtually everything we do to help secure applications is extraordinary; it's hard to suggest that a standard of care over security that isn't even consistently practiced by banks and by the military could bind on the developers of photo sharing applications.
This all not to mention the explicit waiver of liability that accompanies virtually every product or software service offered in the US.
Virtually everything we do to help secure applications is extraordinary; it's hard to suggest that a standard of care over security that isn't even consistently practiced by banks and by the military could bind on the developers of photo sharing applications.
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 understand what you're saying but feel like I must be writing unclearly, because I'm not suggesting that photo sharing apps should be held to the same standard of care as banks, or even that anyone advocating liability believes they will be. What I'm saying is that the standard of care most generalist software developers consider when they think about liability is, contrary to expectations, a standard not consistently applied even in sensitive industries that are intrinsically and demonstrably motivated to defend against security flaws even in the absence of meaningful regulations.
Okay, so that standard is not currently applied as one would expect. That doesn't necessarily mean it couldn't be so applied. I think the question here is, how much more expensive is software development when held to this standard?
I don't propose an answer -- I'm curious what you think.
The key word there is "prevailing quality standards". If a developer writes something, in good faith, that's vulnerable to SQL injection, or stores passwords in plaintext on a server, is that negligence?
No. Developers in highly sensitive industries where we can safely presume the highest prevailing standards of care --- banks, for instance --- on projects that have documented standards of code safety and review far exceeding those of the industry as a whole --- have routinely managed to "ship" code containing SQL Injections.
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.
Well, I would contend the "line" would be "an accredited penetration tester can't break your software", much like a health inspection is "an accredited health and safety inspector can't find anything wrong with your business".
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".
>an accredited penetration tester can't break your software
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.
Also most project are developed by a team with designers, developers, Q&A and they have a project leader etc. etc.
the outcome of their work is a collective responsability.
Maybe, it depends. What does the app do? If it's just a photo-sharing application, or a weekend project, then no. There's no expectation for the former to be secure, or for the latter to be a full-fledged product that meets standards.
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.
I think it would be very easy to convince a jury under a straightforward liability framework that "failure to handle SQL injection is negligent". Which is unfortunate, because "failure to handle SQL injection" is by itself a mostly meaningless statement. Most SQL Injection flaws are indeed very dumb, very obvious bugs. But there are bugs that end up vectoring to SQL injection that are not obvious at all.
The question then becomes, who decides what that falls under? It's the kind of question that results in laws against braiding hair without a Cosmetology license.[1] And it's a lot easier to code for public consumption, given that all you need is a computer and an internet connection.
> why can’t you take a software developer to court if their negligent coding lets hackers empty your bank account?
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.
Comments
> If you’re poisoned by a burger you can sue the restaurant that sold it - so why can’t you take a software developer to court if their negligent coding lets hackers empty your bank account?
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.
Right; in sales contracts, as I understand it, the obligation is that of a prudent person's ordinary care. Virtually everything we do to help secure applications is extraordinary; it's hard to suggest that a standard of care over security that isn't even consistently practiced by banks and by the military could bind on the developers of photo sharing applications.
This all not to mention the explicit waiver of liability that accompanies virtually every product or software service offered in the US.
Virtually everything we do to help secure applications is extraordinary; it's hard to suggest that a standard of care over security that isn't even consistently practiced by banks and by the military could bind on the developers of photo sharing applications.
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 understand what you're saying but feel like I must be writing unclearly, because I'm not suggesting that photo sharing apps should be held to the same standard of care as banks, or even that anyone advocating liability believes they will be. What I'm saying is that the standard of care most generalist software developers consider when they think about liability is, contrary to expectations, a standard not consistently applied even in sensitive industries that are intrinsically and demonstrably motivated to defend against security flaws even in the absence of meaningful regulations.
Okay, so that standard is not currently applied as one would expect. That doesn't necessarily mean it couldn't be so applied. I think the question here is, how much more expensive is software development when held to this standard?
I don't propose an answer -- I'm curious what you think.
The key word there is "prevailing quality standards". If a developer writes something, in good faith, that's vulnerable to SQL injection, or stores passwords in plaintext on a server, is that negligence?
No. Developers in highly sensitive industries where we can safely presume the highest prevailing standards of care --- banks, for instance --- on projects that have documented standards of code safety and review far exceeding those of the industry as a whole --- have routinely managed to "ship" code containing SQL Injections.
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.
Well, I would contend the "line" would be "an accredited penetration tester can't break your software", much like a health inspection is "an accredited health and safety inspector can't find anything wrong with your business".
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.
Two problems.
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".
>an accredited penetration tester can't break your software
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.
Also most project are developed by a team with designers, developers, Q&A and they have a project leader etc. etc. the outcome of their work is a collective responsability.
Maybe, it depends. What does the app do? If it's just a photo-sharing application, or a weekend project, then no. There's no expectation for the former to be secure, or for the latter to be a full-fledged product that meets standards.
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.
I think it would be very easy to convince a jury under a straightforward liability framework that "failure to handle SQL injection is negligent". Which is unfortunate, because "failure to handle SQL injection" is by itself a mostly meaningless statement. Most SQL Injection flaws are indeed very dumb, very obvious bugs. But there are bugs that end up vectoring to SQL injection that are not obvious at all.
The question then becomes, who decides what that falls under? It's the kind of question that results in laws against braiding hair without a Cosmetology license.[1] And it's a lot easier to code for public consumption, given that all you need is a computer and an internet connection.
[1]http://www.dailypaul.com/249310/federal-court-rules-utah-s-a...
> why can’t you take a software developer to court if their negligent coding lets hackers empty your bank account?
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.