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

4/30/2013
01:42 AM
50%
50%

Building A Detente Between Developers And Security

Don't give a long list of software defects to the developers if you value a good working relationship

Running static code analysis on software to pinpoint potential security flaws will generally turn up a long list of issues that need to be triaged.

Yet sending the list to developers and expecting them to fix the issues is a quick way to create a dysfunctional software-security life cycle. Instead, security teams need to understand developers' priorities before requesting that they fix their code. Using members of the security team who have development experience, for example, can help the two side more effectively communicate, says Chris Wysopal, chief technology officer and co-founder of application-security firm Veracode.

"Developers can smell a nondeveloper really, really quickly," says Wysopal. "A lot of security teams don't have the knowledge of how to fix these issues."

All software companies have difficulties eradicating software flaws. In 2012, the number of vulnerabilities publicly reported grew 26 percent to 5,225, according to security testing lab NSS Labs. Of the 10 software developers with the most vulnerabilities disclosed, only four had fewer vulnerabilities than their previous year, and only Microsoft did better than its 10-year average.

No wonder, then, that executives are concerned about the state of software security. More than 70 percent of C-level executives rated application vulnerabilities as their top security concern, according to the (ISC)2 Global Information Security Workforce Study released at the RSA Conference in February. The previous year's study found the same trend, says W. Hord Tipton, executive director of (ISC)2.

"This is one of the few times I've seen the same concern, the same top-priority issue surface on top of the list of things that keep people awake at night," Tipton says. "The problem is that we keep finding the same bugs, [and] we don't even fix the simple things."

Poor communication and significant friction between developers and the software-security team is a key reason that software issues continue to go unaddressed. While managers and executives worry about application security, that rarely translates into a broad business-focused effort to improve software security: Only about 12 percent of the security professionals have a role in software development, according to the (ISC)2 study.

[Fear of business disruption and downtime often leaves enterprises hesitant to scan the critical applications that hackers are most likely to target in their quest for exploitable vulnerabilities. See Too Scared To Scan.]

To cross the divide between the two groups, companies should first educate their developers in the importance of software security and how vulnerabilities can impact the business's bottom line, says Jacob West, chief technology officer for Hewlett-Packard's Enterprise Security Products group. Developers should also be trained in how to avoid common mistakes and write more secure code. Furthermore, to ease the burden on developers, the software security lead should attempt to automate any task that may slow down the process.

"We should be automating those small tasks as much as possible, so we are not adding unnecessary overhead to the developers' lives," West says. "A lot of those little things -- run a scan here or turn on an option there -- are some of the things that make a new security initiative really annoying."

The Denim Group, for example, has created a tool to help security teams track and analyze software vulnerabilities that have been submitted for analysis. The results of a vulnerability scan can automatically be added to the current prioritized list and any duplicates removed.

Companies should also select someone from the development group as a security lead and anoint them as the resource for security.

"Having that sort of resource as part of your team can really streamline the interaction between the security group and the development organization," West says.

Finally, companies should have tangible goals and metrics associate with the development process, so that developers and the security team have a yardstick by which to measure their progress, he 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. Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline ... 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
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Can you smell me now?
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-11844
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
CVE-2020-6937
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
CVE-2020-7648
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
CVE-2020-7650
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
CVE-2020-7654
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.