Enterprises Pressure Software Vendors To Clean Up Their Apps

More businesses are flexing their procurement muscles to pressure software vendors into supplying them with more secure code as their own in-house secure development programs mature.

New data gathered from software security testing-as-a-service vendor Veracode found that software vendors actually do a better job following their customers' application security policies than those of the industry: While 38 percent of vendor-supplied applications comply with their enterprise customers' policies for secure software, only 10 percent of software vendors' products tested by Veracode comply with OWASP's Top 10, and just 30 percent with the CWE/SANS Top 25. The enterprises covered in the report make more than $500 million in revenues.

"The realization that's happening now is that the supply chain is a big part of application security problems," says Chris Wysopal, CTO and co-founder of Veracode, which based its report on data from 939 application builds submitted to the company between January 2011 and June 2012. "Attackers are going more after the application tier, [including elements] that were not built by [the enterprise], but by someone else."

[Vulnerable technology supply chains have become a concern of security professionals and politicians alike, but a few steps could help minimize the possibility of attacks. See Preventing Infrastructure From Becoming An Insider Attack.]

The number of vendors getting their applications security-tested by Veracode grew nearly 50 percent during that 18-month period, much of which was prompted by prospective or existing customers requiring their vendors do so. The financial services, software/IT services, and technology industries are leading the way, according to Veracode's findings, accounting for more than half of the software assessment projects.

This trend jives with the latest findings of the Building Security In Maturity Model (BSIMM) study, BSIMM4, which was released in September by Cigital. Large enterprises, especially in the financial, pharmaceutical, and energy industries, for example, are driving the testing of third-party software, says Sammy Migues, a principal at Cigital who works on BSIMM. BSIMM is basically a case study of real-world software security initiatives, based on in-depth measurement of major enterprises.

"Firms are saying, 'I know you, software producer, don't have security compliance requirements, but I have compliance requirements out the wazoo, and you can no longer sell me software that makes it difficult for me to achieve compliance. That's unacceptable,'" Migues says.

Migues says some BSIMM participants are concerned about bugs popping up in external code they are deploying. "They are seeing more bugs in other people's code," but, of course, BSIMM participants are enterprises that are employing secure software development practices, he says. Some of these organizations then must have binary analysis performed on the external code or perform static analysis on the external code integrated into their apps, he says.

Some 22 of the 51 enterprises participating in the BSIMM4 report say they now include software security responsibilities in their service-level agreements with vendors, Migues says. "The next level of maturity for activity is creating an SLA boilerplate with legal and slapping it into the majority of outsourcing projects. Twenty-one of the 51 firms, about 40 percent, are doing that," he says.

Conventional wisdom used to be that if you don't ask for security requirements in software, you won't get them, and if you do, you're probably not going to get them, either, says Mano Paul, software assurance adviser for the ISC2. But that's now changing, he says.

"There has been awareness and recognition that, in fact, we are losing control of the software development process. But that cannot continue because losing control of security aspects are relevant when we outsource and procure software," Paul says.

The best bet is not to accept on face value that software vendors have cleaned up their code, but rather, verify it, he says.

"In the early days, security was always an afterthought. Now security is being asked for and mandated by regulations and other driving forces that make it become part of the product itself to integrated it or make it part of the SDL [secure development lifecycle]," he says. "The trend is [going] in the right direction ... but fully secure software is not going to happen."

It's more about making it harder for attackers to exploit software, he says, by adopting best practices and writing more secure and clean code.

Veracode, meanwhile, also found that most of its enterprise customers are still in the early phase of formal vendor software-testing programs: Less than one in five of its enterprise customers asked for a code-level test from at least one vendor. The SaaS vendor split enterprises into two categories: those with a formal or an informal method for choosing apps for testing. Those with a formal protocol had buy-in from security, business, and procurement teams, and strongly mandate vendor application testing. Others use more of a case-by-case, informal approach.

Some 45 percent of vendor applications became compliant within a week under the more formal enterprise programs, and 28 percent in the ad-hoc ones, according to Veracode's data. A tough security policy wasn't necessarily successful, however. "Setting a less rigorous compliance policy that vendors perceive as achievable encourages higher vendor participation," the report says.

Next Page: Vendor Fail Most vendor apps -- 62 percent -- fail compliance in their first tests. The top flaws discovered in both Web- and non-Web apps were more of the same old, same old. Web apps contained bugs such as information leakage (79 percent), cross-site scripting (71 percent), cryptographic issues (67 percent), directory traversal (67 percent), CRLF injection (63 percent), time and state (51 percent), insufficient input validation (48) percent, and SQL injection (40 percent).

Non-Web apps contained cryptographic issues (62 percent), error handling (58 percent), directory traversal (57 percent), numeric errors (43 percent), buffer management errors (42 percent), and buffer overflow flaws (41 percent), as well as other bugs.

Veracode's Wysopal says he was surprised that vendor software performed so poorly against the OWASP Top 10 vulnerabilities. "A lot of enterprises are putting in place fairly weak policies, weaker than the OWASP 10. Some say, 'Just don't have critical vulnerabilities in your apps,'" he says. "So that's allowing more vendors to pass ... and sell to them. My theory is that enterprises don't want to be too harsh. They want vendors to do some testing, and they want the egregious bugs to be taken out, but they don't want it to be too difficult to do business with them. Most businesses are practical and pragmatic."

The best bet is to have a policy for your software vendors, he says, and not an ad-hoc one. "Case by case does not work well," Wysopal says.

Veracode's Enterprise Testing of the Software Supply Chain report is available here for download.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.