Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

5/10/2013
12:23 AM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

Erase The Line Between QA Defects And Security Flaws?

Is a defect a defect by any other name? Some testing advocates push for industry to stop segregating security from the rest of quality testing categories

When it comes time to test applications for flaws, when is a bug a security defect, and when is it a quality defect? According to some developer experts, during preproduction the line can be so blurry that the industry would do well to quit trying to draw it and instead endeavor to do testing that reduces overall defect rates so that the code quality and, consequently, security increase across the board.

"The way we view it is that for developers, a defect is a defect. We believe the overlap in quality and security is huge, and you really shouldn't distinguish between a security defect and a quality defect," says Zack Samocha, project director for Coverity Scan at testing vendor Coverity. [Why does SQL injection linger? See 10 Reasons SQL Injection Still Works.]

Amid a flurry of new reports released about the state of secure application development, a bit of a silver lining peeped through the clouds this week with the release of the "2012 Coverity Scan Open Source Report," which showed that the overall code quality improved within a set of 450 million lines of open-source code examined by Coverity in 2012. Among the common types of code defects fixed were some of those most likely to cause security vulnerabilities, including control flow issues, null pointer dereferences, and resource leaks.

From a security angle, Samocha believes that the takeaway from the report is that if an organization can push to get developers to improve the overall code quality, then security will see commensurate improvements in the process.

"You need to think about your code quality and code practice, in general," he says. "To be successful with security, you need to have security as a part of developer requirements, part of their defects to fix, unrelated to security or quality."

The logistics behind this rising tide to flaw discovery could put more urgency behind remediation of security problems during preproductions, if done right. As things stand, security issues are often left unfound or unfixed in the rush to ship code. Defects with security implications would be more likely to trip the development "circuit breaker" during QA if policies mandate higher levels of quality before code is made live.

"One of the things that is a truism in software development is if you actually put a requirement or something at the end, and it stops them from shipping something, the software producers, in general, are really attuned to that," says Mike Armistead, vice president and general manager of HP Fortify. "When you do put that bar there, the right thing starts to happen."

But getting rid of the distinction between quality and security defects could mean asking developers and QA testers to test for flaws they may not have experience with. According to Dan Cornell, principal of Denim Group, getting these populations on board for this kind of testing will require education and clear directions from management.

"Developers and testers already have jobs to do, and, prior to your current initiative, those jobs probably didn't require them to do security testing," he wrote recently. "Assuming you want to developers and testers to adopt new practices and new tools at any sort of scale you need to show them what they need to do and be as specific and prescriptive as possible so that you minimize the impact on all the other stuff the developers and QA testers are supposed to do."

However, taking the tack of putting development defects all in the same bucket during developer testing doesn't necessarily mean security gets subsumed by QA and developers. It just improves the refinement process prior to bringing in secure development experts.

"If you do it well, then later in the cycle if security audit is testing something, hopefully they will just find the things only they can find, rather than all of the defects a developer could have fixed earlier in the cycle," Samocha says.

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.

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
GDPR Enforcement Loosens Amid Pandemic
Seth Rosenblatt, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-4306
PUBLISHED: 2020-05-29
IBM Planning Analytics Local 2.0.0 through 2.0.9 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: ...
CVE-2020-4352
PUBLISHED: 2020-05-29
IBM MQ on HPE NonStop 8.0.4 and 8.1.0 is vulnerable to a privilege escalation attack when running in restricted mode. IBM X-Force ID: 178427.
CVE-2020-4490
PUBLISHED: 2020-05-29
IBM Business Automation Workflow 18 and 19, and IBM Business Process Manager 8.0, 8.5, and 8.6 could allow a remote attacker to bypass security restrictions, caused by a reverse tabnabbing flaw. An attacker could exploit this vulnerability and redirect a vitcim to a phishing site. IBM X-Force ID: 1...
CVE-2020-5572
PUBLISHED: 2020-05-29
Android App 'Mailwise for Android' 1.0.0 to 1.0.1 allows an attacker to obtain credential information registered in the product via unspecified vectors.
CVE-2020-5573
PUBLISHED: 2020-05-29
Android App 'kintone mobile for Android' 1.0.0 to 2.5 allows an attacker to obtain credential information registered in the product via unspecified vectors.