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.

Vulnerabilities / Threats //

Vulnerability Management

10:00 AM
Dan Cornell
Dan Cornell

Better Collaboration Between Security & Development

Security and development teams must make it clear why their segment of the development life cycle is relevant to the other teams in the pipeline.

For more than 10 years, I've been preaching the idea that collaboration between security and development teams is critical. This is especially true for teams that have different stakeholders and work across time zones and geographic regions. Despite my efforts in evangelizing the message, I continue to see examples of poor communication that hurt teams' constant pursuit of organizational security.

Over the last decade, I've continued to see a large number of security teams use PDF documents as their standard mode of communication to highlight vulnerabilities for remediation by development teams, but this archaic practice lacks the context that is necessary for the development team's buy-in and understanding. This results in vulnerabilities being improperly fixed or completely ignored by development teams as they field a growing list of tasks and promises to customers. That doesn't mean that developers don't care about security; rather, communication is the problem.

Bringing teams together to collaborate isn't enough if they don't understand how to effectively communicate. Each team must make an effort to communicate why their segment of the development life cycle is relevant to the other teams in the pipeline. So, what can the security team members do if they want development to work with them in fixing vulnerabilities? A good start would be providing developers with context regarding the vulnerabilities that are being identified, in addition to communicating what tools they've been using to identify these vulnerabilities, avoiding the exported PDF at all costs.

In my past experience, I've seen it proven time and time again that collaboration has a direct impact on organizational success, and there is data that supports these observations. In fact, effective collaboration has the ability to reduce the mean time to fix (MTTF) vulnerabilities by up to 44%, in Denim Group's experience, proving that this need has not changed over the last decade. While some security professionals believe that the responsibility of fixing vulnerabilities is completely up to the development team, they must remember that security isn't their only task. By reducing the development team's workload through more effective communication of vulnerabilities, security teams can help foster stronger working partnerships, all while speeding up vulnerability remediation.

This proposition then raises the question: How can disparate teams cultivate stronger collaboration? First, security teams must develop a clean set of vulnerabilities to provide to developers. Doing things such as culling false positives, reprioritizing vulnerabilities, and capturing sufficient context are all steps that must be taken into account when creating a streamlined and easy-to-understand list. Once the security team drafts a clean list of vulnerabilities, they then need to determine which ones the development team must address. As I noted earlier, developers are often inundated with tasks such as writing new features and functions, or fixing non-security-related bugs, and in order to increase collaboration, they should not be forced to fix things that don't actually need to be fixed. This places more responsibility on the security teams by making them prioritize the vulnerabilities they want to deliver and ensure that the development teams can fix them.

Next, after determining what vulnerabilities are worth the developers' time, security teams should bundle vulnerabilities into software defects, being sure to avoid creating a new software defect for every vulnerability they identify, as this can easily begin to overwhelm the development teams they work with. This holds especially true because a majority of technical vulnerabilities are easily fixed with a small code change, and by sending too many defects, security teams are actually slowing down what should be a relatively easy process. By bundling like vulnerabilities together, security teams are minimizing the steps that developers need to take, minimizing their workload which can assist in bringing these teams closer.

Increased collaboration between security and development teams is critical — and necessary if a business wants to be successful. By streamlining communication, teams can address vulnerabilities faster, and more efficiently. Maintaining collaboration is an ongoing effort for organizations that must be prioritized, and while there are tools that can assist, it is not solely a technological issue. Teams working with — not in competition of — one another must be a goal of the security industry in order to maintain success. This need has grown increasingly important, as threat actors are constantly finding new ways to infiltrate security systems, so strong team collaboration is your first and best defense.

Related Content:

Learn from industry experts in a setting that is conducive to interaction and conversation about how to prepare for that "really bad day" in cybersecurity. Click for more information and to register for this On-Demand event. 

A globally recognized application security expert, Dan Cornell holds over 20 years of experience architecting, developing and securing web-based software systems. As Chief Technology Officer and Principal at Denim Group, Ltd., he leads the technology team to help Fortune 500 ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
9 Tips to Prepare for the Future of Cloud & Network Security
Kelly Sheridan, Staff Editor, Dark Reading,  9/28/2020
Malware Attacks Declined But Became More Evasive in Q2
Jai Vijayan, Contributing Writer,  9/24/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-09-30
SonicWall SSL-VPN products and SonicWall firewall SSL-VPN feature misconfiguration leads to possible DNS flaw known as domain name collision vulnerability. When the users publicly display their organization’s internal domain names in the SSL-VPN au...
PUBLISHED: 2020-09-29
In goxmldsig (XML Digital Signatures implemented in pure Go) before version 1.1.0, with a carefully crafted XML file, an attacker can completely bypass signature validation and pass off an altered file as a signed one. A patch is available, all users of goxmldsig should upgrade to at least revisio...
PUBLISHED: 2020-09-29
IBM Security Secret Server (IBM Security Verify Privilege Vault Remote 1.2 ) could allow a local user to bypass security restrictions due to improper input validation. IBM X-Force ID: 184884.
PUBLISHED: 2020-09-29
An out-of-bounds read information disclosure vulnerabilities in Trend Micro Apex One may allow a local attacker to disclose sensitive information to an unprivileged account on vulnerable installations of the product. An attacker must first obtain the ability to execute low-privileged code on the ...
PUBLISHED: 2020-09-29
An out-of-bounds read information disclosure vulnerabilities in Trend Micro Apex One may allow a local attacker to disclose sensitive information to an unprivileged account on vulnerable installations of the product. An attacker must first obtain the ability to execute low-privileged code on the ...