I would agree with this overall conclusion. The elements that determine if an application is secure is far more complex than simply the language that has been selected. However, I would argue that some languages are more conducive to organized and easy to manage code that follows an MVC approach. Similarly some frameworks provide security controls that are enabled by default to aid in the security of an application. However, framework and language selection are meaningless if security is not baked in to the entire application life cycle.
Here are the three primary findings from the report.
- Empirically, programming languages / frameworks do not have similar security postures when deployed in the field. They are shown to have moderately different vulnerabilities, with different frequency of occurrence, which are fixed in different amounts of time.
- The size of a Web application’s attack surface alone does not necessarily correlate to the volume and type of issues identified. For example Microsoft’s .NET (ASPX) and Struts (DO), with near-average attack surfaces, turned in the two lowest historical vulnerability averages. ASPX and DO websites have had an average of 18.7 and 19.9 serious vulnerabilities respectively.
- Perl (PL) had the highest average number of vulnerabilities found historically by a wide margin, at 44.8 per website and also the largest number currently at 11.8.ties have taken over 50 days to fix.
The full report requires registration and can be viewed here
Here is a rebuttal to some of the claims made by the report: http://pinvoke.wordpress.com/
As mentioned in the above link I encourage you to take these results with a grain of salt. The data is gathered from existing WhiteHat sentinel customers and is obtained from an automated tool (technically it is automated discovery with manual verification). The sample population is not necessarily a reflection of the critical web applications at large, nor is an automated tool able to fully analyze the security of a site. In fact, automated tools are often strong in the areas of input injection based attacks and weaker in areas of authentication, access control, session management and custom logic flaws.
If you are going to take away one item from this study then I hope it is this: there is no magic bullet or super secure programming language. If you want something good then you have to work hard for it. Security is a continuing effort that requires the support of everyone involed (dev, QA, managers, etc) and must be an essential component of each step of the SDLC.
-Michael Coates