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.

Application Security

11/30/2020
07:00 AM
Chris Eng
Chris Eng
Commentary
Connect Directly
Twitter
RSS
E-Mail vvv
50%
50%

Why Vulnerable Code Is Shipped Knowingly

The business priority of speed of development and deployment is overshadowing the need for secure code.

The push to develop and deploy applications faster has evolved from simply a goal for developers to a business-level priority that affects every organization's bottom line. To meet this goal, companies have begun to de-silo development, operations, and security, moving toward a DevSecOps model to deliver increased agility and speed in the software development life cycle (SDLC).

Related Content:

Developers' Approach to App Testing Could Cut Flaw Fix Times by 80 Days

The Changing Face of Threat Intelligence

New on The Edge: 9 Cyber Disaster-Recovery Planning Tips for a Disaster-Prone Time

Often lost in the chaos of this cultural shift to a "need for speed" SDLC approach is the misalignment between DevOps and security practitioners' goals. Both teams must strive to balance their respective goals: getting new features out the door and minimizing software risk. We know this misalignment contributes to vulnerable code being shipped more often than it should be, but what most people don't realize is that this is happening knowingly, and quite often. According to a recent ESG research report, almost half (48%) of organizations are regularly pushing vulnerable code, and they know it.

The simple question this statistic raises is: why? Cybersecurity continues to be a priority concern for every organization, with one vulnerability holding the potential to diminish a brand's reputation — that took decades to build — in just a few seconds. So why are developers knowingly deploying vulnerable code?  

The findings of the report help shed some light on the reasons:

  • 54% of organizations push vulnerable code in order to meet a critical deadline, with plans to remediate in a later release.
  • 49% of organizations push vulnerable code because they think it holds very low risk.
  • 45% of organizations publish vulnerable code because the vulnerabilities were discovered too late in the cycle to resolve them in time before the code was deployed.

This data helps us understand that the business priority of speed of development and deployment is overshadowing the need for secure code. Organizations are acknowledging various risks regarding cybersecurity, speed, and business objectives, and they're willing to take on some of these risks because priorities are in opposition to one another. To address the frequency of knowingly publishing vulnerable code, we must look at the underlying causes that have caused such a challenging situation to arise.

First, developers — who ultimately own the responsibility for fixing flaws in code — don't have the training or access to security tools with the proper integrations to be effective at mitigating vulnerabilities. ESG's report found:

  • 29% of developers lack the knowledge to mitigate issues identified with current testing tools.
  • 26% of developers found difficulty or a lack of integration between different AppSec vendor tools to cause challenges.
  • 26% of developers said testing tools added friction or slowed down development cycles.
  • 35% of organizations say less than half of their development teams are involved in formal AppSec training.
  • Less than half of developers are engaged in formal AppSec training more than once a year.

These challenges can and should be addressed to help developers reduce the volume of vulnerable code being shipped.

As security continues to shift left into the hands of developers, organizations need to continue to prepare for this culture change by modernizing their approach to AppSec.

For AppSec managers and CISOs looking to create an integrated DevSecOps approach, some common elements of effective AppSec programs include:

  • Application security controls being highly integrated into the CI/CD toolchain.
  • Application security training being an essential part of the training that is included for development security training programs.
  • Application security and development best practices being documented and communicated.
  • Security issues and continuous improvement metrics being tracked for development teams.

It's up to security and development team leaders to formalize an AppSec strategy that encompasses training, goal setting, tool integration, and policy enforcement without introducing too much friction.

Even with a robust application security program, organizations will still deploy vulnerable code! The difference is that they will do so with a thorough and contextual understanding of the risks they're taking rather than allowing developers or engineering managers — who lack security expertise — to make that decision. Application security requires a constant triage of potential risks, involving prioritization decisions that allow development teams to mitigate risk while still meeting key deadlines for delivery.

As application security has matured, no single testing technique has helped development teams mitigate all security risk. Teams typically employ multiple tools, often from multiple vendors, at various points in the SDLC. Usage varies, as do the tools that organizations deem most important, but most organizations end up utilizing a set of tools to satisfy their security needs.

Lastly, while most organizations provide developers with some level of security training, more than 50% only do so annually or less often. This is simply not frequent or thorough enough to develop secure coding habits. While development managers are often responsible for this training, in many organizations, application security analysts carry the burden of performing remedial training for development teams or individual developers who have a track record of introducing too many security issues. Organizations should seek more hands-on training tools that offer secure coding practices through interactive exercises based on modern threats that developers can practice exploiting and patching. A labs-based approach to developer enablement can improve time to resolve flaws and help developers learn to avoid flaws altogether.

Chris Eng is Chief Research Officer at Veracode. Throughout his career, he has led projects breaking, building, and defending software for some of the world's largest companies. He is an unabashed supporter of the Oxford comma and hates it when you use the word "ask" as ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
vtompkins105
50%
50%
vtompkins105,
User Rank: Apprentice
11/30/2020 | 3:55:09 PM
Kinda old news.
I have found this to be the case going back 30+ years. Back then it was more about system crashes. Now those crashes open holes for the attackers to walk through.
Edge-DRsplash-10-edge-articles
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
News
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Commentary
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-24119
PUBLISHED: 2021-05-14
A heap buffer overflow read was discovered in upx 4.0.0, because the check in p_lx_elf.cpp is not perfect.
CVE-2020-27833
PUBLISHED: 2021-05-14
A Zip Slip vulnerability was found in the oc binary in openshift-clients where an arbitrary file write is achieved by using a specially crafted raw container image (.tar file) which contains symbolic links. The vulnerability is limited to the command `oc image extract`. If a symbolic link is first c...
CVE-2021-22866
PUBLISHED: 2021-05-14
A UI misrepresentation vulnerability was identified in GitHub Enterprise Server that allowed more permissions to be granted during a GitHub App's user-authorization web flow than was displayed to the user during approval. To exploit this vulnerability, an attacker would need to create a GitHub App o...
CVE-2021-27737
PUBLISHED: 2021-05-14
Apache Traffic Server 9.0.0 is vulnerable to a remote DOS attack on the experimental Slicer plugin.
CVE-2021-32054
PUBLISHED: 2021-05-14
Firely/Incendi Spark before 1.5.5-r4 lacks Content-Disposition headers in certain situations, which may cause crafted files to be delivered to clients such that they are rendered directly in a victim's web browser.