RSA 2006: Secure Software is up to Business

One of the themes discussed at RSA 2006 was Secure Software. Secure software is up to businesses and most businesses are not doing enough to build and buy securely written software, according to a panel of corporate security executives, academics and professional software developers speaking at the RSA Security Conference 2006 yesterday.

Here are a couple articles on what was discussed at RSA 2006:,10801,108716,00.html

One panel member agreed that education helps, but developers also need tools that flag potential flaws as the code is being written and that can fix them automatically. However, I only partly agree with the one panelist's comments as code scanning tools alone are not the answers. I particularly liked the way Michael Howard describes his thought --which I summed up in points below --about using source code scanning tools alone:

If Developer do now know how to write Secure Code

If Designer do not know how to design secure systems

If Tester do know how to test Security-posture of a system


Tools will provide very little help

Code analysis tools have to keep the number of false positive low

Because of this high bar, many tools will miss real bugs

Design bug will not be found by a source code analysis tool


Tools are used to force policies or “just in time learning”


"Not-so-knowledgeable-developer" + great tools == marginally more secure code

Therefore, we can not look for quick fixes for Security as it is too important and too complex. Now I am not saying make all developers security specialist as that is not feasible. But what is wrong with training developers so they understand the major vulnerabilities that exist and how to program against them?. Then have an IT Sec Pro team that consists of not just Infrastructure people but also a small core group of developers who are highly trained in Security. This team would then be involved in conducting Security code reviews and penetration testing of Applications during the Application Software Development Lifecycle.

This is too complex of a problem to leave up to a tool alone but rather one in which Architects, Developers, Testers and Business have to work together to solve.