03:29 PM
Connect Directly

Enterprises Pressure Software Vendors To Clean Up Their Apps

New Veracode software security report, BSIMM4 findings show enterprises driving third-party software vendors to write more secure code

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 Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

1 of 2
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Strategist
11/14/2012 | 1:57:26 AM
re: Enterprises Pressure Software Vendors To Clean Up Their Apps
Readers, do you think software developers should be required to get some sort of security certification?- (Posted by Tim Wilson, editor)
Four Faces of Fraud: Identity, 'Fake' Identity, Ransomware & Digital
David Shefter, Chief Technology Officer at Ziften Technologies,  6/14/2018
Meet 'Bro': The Best-Kept Secret of Network Security
Greg Bell, CEO, Corelight,  6/14/2018
Containerized Apps: An 8-Point Security Checklist
Jai Vijayan, Freelance writer,  6/14/2018
Register for Dark Reading Newsletters
White Papers
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2018-06-20
CheckSec Canopy 3.x before 3.0.7 has stored XSS via the Login Page Disclaimer, allowing attacks by low-privileged users against higher-privileged users.
PUBLISHED: 2018-06-20
Stack-based buffer overflow in ntpq and ntpdc of NTP version 4.2.8p11 allows an attacker to achieve code execution or escalate to higher privileges via a long string as the argument for an IPv4 or IPv6 command-line parameter. NOTE: It is unclear whether there are any common situations in which ntpq ...
PUBLISHED: 2018-06-20
The parse() method in the Email::Address module through 1.909 for Perl is vulnerable to Algorithmic complexity on specially prepared input, leading to Denial of Service. Prepared special input that caused this problem contained 30 form-field characters ("\f").
PUBLISHED: 2018-06-20
Multiple cross-site request forgery (CSRF) vulnerabilities in totemomail Encryption Gateway before 6.0.0_Build_371 allow remote attackers to hijack the authentication of users for requests that (1) change user settings, (2) send emails, or (3) change contact information by leveraging lack of an anti...
PUBLISHED: 2018-06-20
A flaw was found affecting the Linux kernel before version 4.17. By mmap()ing a FUSE-backed file onto a process's memory containing command line arguments (or environment strings), an attacker can cause utilities from psutils or procps (such as ps, w) or any other program which makes a read() call t...