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

07:00 AM
Chris Eng
Chris Eng
Connect Directly
E-Mail vvv

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
Newest First  |  Oldest First  |  Threaded View
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.
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
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
PUBLISHED: 2021-05-12
Affected versions of Atlassian Jira Server and Data Center allow an unauthenticated user to enumerate users via an Information Disclosure vulnerability in the QueryComponentRendererValue!Default.jspa endpoint. The affected versions are before version 8.5.13, from version 8.6.0 before 8.13.5, and fro...
PUBLISHED: 2021-05-11
In the Linux kernel 5.11 through 5.12.2, isotp_setsockopt in net/can/isotp.c allows privilege escalation to root by leveraging a use-after-free. (This does not affect earlier versions that lack CAN ISOTP SF_BROADCAST support.)
PUBLISHED: 2021-05-11
A flaw was found in the hivex library in versions before 1.3.20. It is caused due to a lack of bounds check within the hivex_open function. An attacker could input a specially crafted Windows Registry (hive) file which would cause hivex to read memory beyond its normal bounds or cause the program to...
PUBLISHED: 2021-05-11
A flaw was found in ImageMagick in versions before 7.0.11 and before 6.9.12, where a division by zero in WaveImage() of MagickCore/visual-effects.c may trigger undefined behavior via a crafted image file submitted to an application using ImageMagick. The highest threat from this vulnerability is to ...
PUBLISHED: 2021-05-11
A flaw was found in ImageMagick in versions before 7.0.11, where a division by zero ConvertXYZToJzazbz() of MagickCore/colorspace.c may trigger undefined behavior via a crafted image file that is submitted by an attacker and processed by an application using ImageMagick. The highest threat from this...