Risk

9/22/2010
02:47 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

Most Third-Party Software Fails Security Tests

Veracode report shows eight of 10 applications at risk of failing PCI compliance audit

Enterprise software developers often get a bad rap for poor security in their applications, but new data shows that many software suppliers' products were less secure than internally developed enterprise ones.

More than 80 percent of the time, third-party software failed security tests with Veracode, according to a report published today by Veracode. And Veracode found that 57 percent of all applications contained security flaws. More than 80 percent of both internally developed and commercial applications don't comply with the OWASP Top 10 list of critical Web application errors to avoid.

"We're still finding that a lot of work needs to be done in software security. Still over half of all [apps] are failing acceptable levels of security in their first [testing]," says Sam King, vice president of product marketing for Veracode. Today's State of Software Security Report (PDF) follows a previous one issued in March by Veracode, which found that most software applications remain riddled with security holes, with 58 percent failing in their first tests.

So the state of software security hasn't changed much since earlier this year, King says.

But improvement in software security depends on how you measure it. Gary McGraw, CTO at Cigital and one of the creators of the Build Security In Maturity Model (BSIMM), says the BSIMM program has seen improvement among organizations working at it. "Veracode measures pieces of code from different sets of companies. My results show there's an improvement among people who already have been doing secured software initiatives for a while," McGraw says.

Even so, he says it's worrisome that Veracode found so many bug-ridden apps. "It's rather distressing that they are finding so much," McGraw says.

Dan Kaminsky, renowned security researcher, says there's a misconception that all software is secure until proved otherwise.

"This is not reality. Pretty much all code is horribly broken until there have actually been consequences to the code being bad," Kaminsky says. "Those consequences are when someone gets hacked, or they may have an audit done and [then] the developers having to do more work. Until those consequences [occur], there will always be badly written code."

In its new report, Veracode took a closer look at third-party applications: Third-party code makes up about 30 percent of all applications the security firm tested, and Veracode estimates it makes up anywhere from 20 to 37 percent of all highly critical applications. "There's an abundance of third-party code in [enterprise] applications," says Chris Eng, senior director of research at Veracode. "We have this idea of looking at apps labeled as enterprise apps as being all internally developed. But when you look into them more deeply, you see between 30 and 70 percent of an internal app is comprised of [some] third-party code. We all know there's a lot of code reuse -- no application is entirely from scratch."

Eng says some of the third-party apps that Veracode tested had never been analyzed before, many from smaller software firms. "We're seeing a lot of new applications," says Eng, who notes that Veracode's data is based on 2,900 applications, versus 1,500 in its previous report. "So you're going to have some failing."

Veracode's King says in some cases enterprises are using older versions of third-party code. "In some cases, they are doing a risk assessment against older versions of those apps. This is an exercise in justification to move to the latest version of the [third-party] software," she says.

Cigital's McGraw says big software vendors, such as Microsoft, Google, and EMC, are making strides in writing more secure code. "In some cases, they have a really long way to go -- Adobe is still getting beaten up," he says.

And open-source software made a fairly good showing in the report: Forty-two percent of open-source submissions scored acceptable security in Veracode's tests, compared with 46 percent of internally developed apps and 35 percent of commercial software. "Open source had a surprisingly good showing," researcher Kaminsky says. "When more users are using a particular package, the more likely one of those users had audits and pushed back to the original developers" to make them compliant, he says.

Among the good news in Veracode's new report is that remediation -- developers fixing bugs -- is occurring more speedily. And remediation is actually a better indicator of the improvement of software security, Veracode's King says.

Organizations fix bugs within 12 to 19 days now, versus the 36 to 82 day time frame found in the previous report. The average now is 16 days. Why the big improvement? "There are better tools, education, and pressure to remediate in the enterprise," she says.

Other findings: Sixty percent of all of the assessments in the report were for cloud- and Web-based apps. While about 40 percent of all apps in the previous report were non-Web-based, 45 percent were this time. "That's driven by customers shifting their attention away from just Web applications to their back-end legacy apps," King says.

And 56 percent of finance-related apps failed in their first tests, while cross-site scripting (XSS) remains the No. 1 flaw in apps: It was found in one half of all apps. More than 40 percent of the apps had at least one cryptographic issue, although these flaws -- unencrypted or inadequate encryption of data -- accounted for only 6 percent of all vulnerabilities.

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

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

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Higher Education: 15 Books to Help Cybersecurity Pros Be Better
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/12/2018
'PowerSnitch' Hacks Androids via Power Banks
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/8/2018
6 CISO Resolutions for 2019
Ericka Chickowski, Contributing Writer, Dark Reading,  12/10/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: When Harry Met Sally
Current Issue
10 Best Practices That Could Reshape Your IT Security Department
This Dark Reading Tech Digest, explores ten best practices that could reshape IT security departments.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-7690
PUBLISHED: 2018-12-13
A potential Remote Unauthorized Access in Micro Focus Fortify Software Security Center (SSC), versions 17.10, 17.20, 18.10 this exploitation could allow Remote Unauthorized Access
CVE-2018-7691
PUBLISHED: 2018-12-13
A potential Remote Unauthorized Access in Micro Focus Fortify Software Security Center (SSC), versions 17.10, 17.20, 18.10 this exploitation could allow Remote Unauthorized Access
CVE-2018-8033
PUBLISHED: 2018-12-13
The OFBiz HTTP engine (org.apache.ofbiz.service.engine.HttpEngine.java) handles requests for HTTP services via the /webtools/control/httpService endpoint. Both POST and GET requests to the httpService endpoint may contain three parameters: serviceName, serviceMode, and serviceContext. The exploitati...
CVE-2018-20127
PUBLISHED: 2018-12-13
An issue was discovered in zzzphp cms 1.5.8. del_file in /admin/save.php allows remote attackers to delete arbitrary files via a mixed-case extension and an extra '.' character, because (for example) "php" is blocked but path=F:/1.phP. succeeds.
CVE-2018-20128
PUBLISHED: 2018-12-13
An issue was discovered in UsualToolCMS v8.0. cmsadmin\a_sqlback.php allows remote attackers to delete arbitrary files via a backname[] directory-traversal pathname followed by a crafted substring.