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.
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-12512
PUBLISHED: 2021-01-22
Pepperl+Fuchs Comtrol IO-Link Master in Version 1.5.48 and below is prone to an authenticated reflected POST Cross-Site Scripting
CVE-2020-12513
PUBLISHED: 2021-01-22
Pepperl+Fuchs Comtrol IO-Link Master in Version 1.5.48 and below is prone to an authenticated blind OS Command Injection.
CVE-2020-12514
PUBLISHED: 2021-01-22
Pepperl+Fuchs Comtrol IO-Link Master in Version 1.5.48 and below is prone to a NULL Pointer Dereference that leads to a DoS in discoveryd
CVE-2020-12525
PUBLISHED: 2021-01-22
M&M Software fdtCONTAINER Component in versions below 3.5.20304.x and between 3.6 and 3.6.20304.x is vulnerable to deserialization of untrusted data in its project storage.
CVE-2020-12511
PUBLISHED: 2021-01-22
Pepperl+Fuchs Comtrol IO-Link Master in Version 1.5.48 and below is prone to a Cross-Site Request Forgery (CSRF) in the web interface.