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.
Comments
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...