58% of software is vulnerable to security breaches
NCC, 29 March 2010
From Ovum Butler:
VeraCode has issued a report that summarizes its experience of analyzing 1,600 applications comprising 50 billion lines of code on behalf of its clients. The results from the report show that 58% of software is vulnerable to security breaches that are similar to the recent Google and US Department of Defense cyber attacks. They strengthen the case for using open source software, and raise concerns about outsourced software development. However, the biggest impact will be on the software procurement process.
VeraCode has shown that it is feasible and beneficial for large organizations to require sup liers to submit their code to security analysis and, as this practice becomes more common, it will become more acceptable to software vendors.
Software suppliers must expect to prove that their code is secure
VeraCode achieved a seven-fold increase in revenue bookings in 2009. This shows that it is surmounting the critical business barrier to becoming accepted by the software providers. Most of its revenues come from large organizations, mainly in the financial services and government sectors, demanding that software is independently examined by a security code specialist before they will buy it. These organizations have the market power to force vendors to comply and, in return for their due diligence efforts, receive a high-level report about the security rating of their selected product. Apart from being able to compete for the business, the vendor also receives a detailed report about any security shortcomings that it needs to rectify, without having to pay for the service. Many vendors remain reluctant to open up their products to third parties. However, as the practice becomes more widespread and the benefits better known, organizations will be less reluctant to participate. VeraCode’s results show that while this is still an embryonic market, the barriers are coming down and the use of code testing tools should form an important component of any organization’s application testing strategy.
Open source software is “enterprise quality”
VeraCode found that it is a myth to say that open source software is inherently risky. It had less potential “back doors” through which information might leak than commercial software, and flaws were remediated in less than half the time. Conversely, outsourced development is bad for application security: 94% of applications tested failed on first submission. Generally, current outsourcing contracts prevent code analysis, but this is because those contracts were drawn up before the benefits of code testing were better understood. This situation will change as the contracts come up for renewal and customer power will force service providers to put their house in order. OVUM
The cloud service model is well suited to code analysis
Code analysis is a resource-hungry activity that is only performed intermittently. This makes it ideally suited to be provided by a cloud service. Developers find it helpful if they can analyze code modules within their development environment, but application-level analysis requires the resources of an external service. Also, the purchase of testing tools that will spend most of their time as shelfware is not cost effective.
Analysis of executable code is the only way to audit complete applications
Enterprises buy many of their critical applications and do not have access to the source code. Even when they develop the applications in-house, they incorporate components from third parties and they only get the binary code. It is impossible to fully analyze an application without access to all of its code. So enterprises have to work with what is available. VeraCode’s founders started developing the technology to analyze executable images when they worked for @Stake before its acquisition by Symantec in 2004.
Enterprises are less reluctant to share their executable code with a trusted third party than to share source code. VeraCode has found that most code providers also provide debug tables so that defects can be pinpointed and remediation facilitated.
However, binary code analysis has limitations. It may not find all configuration and deployment issues. There may be difficulties distinguishing a security flaw from a “feature”. The analysis may not be able to determine whether a particular vulnerability is accessible in the environment in which the application will be deployed. However, these limitations should not detract from the valuable information that can be obtained.
