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