Some snippets from his blog:
There is no serious developer out there that wants to build an insecure application. It's just that there are any number of time constraints that they frequently work under that conspire to make the overall application less secure.
Mike, I agree fully. But the latter (the time constraint) is being used as a ruse for many security vulnerabilities that exist in your application. If the application is widely deployed such as browsers, then god save you. Your ruse will not work. What I would like to point out is that there are multitudes of open source tools out there that you can integrate into your builds which can perform security analysis as you develop your software. I agree that in many areas of software development, there is a scarcity of tools. In these cases, intuition/best practices/code review help. The key point is that security has to stop being an "after-thought" of any design.
I find FindBugs to be an excellent free static analysis tool, that can be used whenever to peek at some of the security vulnerabilities that you may have. It is better than nothing.
You know, if you develop insecure software, your competition is going to benefit. An example is what Joern Wettern writes in the Redmond Magazine column, titled "A Better Internet Explorer".
One of the main reasons for the success of Firefox is IE's reputation for being vulnerable to a wide range of exploits.
Isn't that Ouch? Now it will be hard for IE to gain back the folks that went the firefox way. Of course there are other reasons - firefox is cross platform. It is free and we trust Mozilla Foundation to not do any evil.
Mike says:
Unfortunately, we're soon approaching a time when some company will be sued for security breaches related to an application. The reasoning will be that there is no real good reason for making data that belongs to somebody else available to people who shouldn't have it because the application was not secure. In time, a court is going to see that kind of activity as a form a reckless disregard equivalent to a car manufacturer selling cars with faulty brake systems.
True. A faulty car can kill. A faulty software can kill and can also cause massive damages to finance, prestige etc.
The answer is processes at work and in education. Processes should exist to foster secure coding. Plus the educators at schools and universities, where software development is taught, need to inculcate curriculum on secure coding. Refer to Mary Ann Davidson's blog entry on "Supply Chain Problem".
Happy software development!!!
No comments:
Post a Comment