Five bogus reasons developers don’t practice secure coding.
Successful prevention, built in up front, relies on developing secure coding competencies. Every developer is capable of becoming a security-minded gatekeeper, and that makes for better products. As usual, defense in-depth begins—and ends—with people.
The simple fact is software security just isn’t much of a priority for nearly half of software developers worldwide. Let’s take a look at five of those reasons that, in the end, turn out to be terribly misguided:
1. Secure application development is just too costly. If this sounds like you, you’ve got company. According to a recent Trust in Computing survey conducted by comScore (on behalf of Microsoft), thirty-four percent of developers say cost is the primary reason for not using a secure application development process. But wait a minute. Is no one in these organizations reporting the cost of fixing bad, insecure software after it has been released (or should we say, after it has escaped)?
The fact is you’re going to pay for software security, whether it’s good, bad, or nonexistent. And bad and nonexistent cost more. A lot more.
2. Application security just takes too long for accelerated release cycles. A secure coding approach may take longer than developing the insecure alternative and can impact usability. Resorting to shortcuts has only reinforced the old adage, “there is never enough time to do things right, but there is always time to do them over.”
3. There’s a lack of management approval and support for secure development. The need for security-oriented mindsets and secure coding standards should not only be baked into the software, but also into the corporate culture itself, modeled and reinforced from the top down.
The release of vulnerable software ends up costing more, and it puts the entire organization at risk. And it’s simply not necessary.
4. Our software sits behind a firewall, so we don’t have to worry about security. Firewalls are also only as good as their rule sets and configurations make them. They are not only complex, but error-prone. Filtering rules must be judiciously written and constructed in order to correctly implement the security policy. When they are not, those rules can be circumvented. Moreover, bad administrative practices can create gaps, and modifications to one or more rules may have repercussions for others.
5. We rely on “find and fix” solutions to secure our code. This after-the-fact approach to security is the very antithesis of making applications secure at the source, where security vulnerabilities are eliminated long before applications are deployed. The earlier you can weed out defects in the development cycle, the less schedule impact, cost, and risk for all concerned.