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

1/22/2021
04:30 PM
50%
50%

Speed of Digital Transformation May Lead to Greater App Vulnerabilities

The fastest-moving industries are struggling to produce secure code, according to AppSec experts.

Digital transformation initiatives have become a common way for companies to make their businesses more agile and to adapt quickly to market changes. But faster software development speeds and the greater number of applications may be causing vulnerabilities to be more common, application-security experts said this week.

Industries such as manufacturing, IT, and retail each have a large share of companies whose applications are always vulnerable, according to the AppSec Stats Flash monthly report from WhiteHat Security. Seventy percent of applications at manufacturing companies, 56% of IT applications, and 56% of retail applications have at least one serious vulnerability affecting the software for the entire year, the report stated.

Related Content:

Breach Data Shows Attackers Switched Gears in 2020

Special Report: Understanding Your Cyber Attackers

New From The Edge: Hacker Pig Latin: A Base64 Primer for Security Analysts

Along with government agencies, healthcare, and real estate, these industries have the largest share of applications that have year-round vulnerabilities, the report states.

"These industries fall into a group of industries that have seen their number of applications per organization increase dramatically over the last several years as their business become increasingly digital," says Zach Jones, senior director of detection research at WhiteHat Security. "For most organizations, achieving an average time to fix of less than 30 days on high- and critical-risk vulnerabilities is a policy that is rarely achieved."

As more companies pursue digital transformation initiatives — a process to become more digitally native — the rate of software creation quickens and feature deployment increases. 

WhiteHat Security's data shows a significant gap between companies that typically have a large volume of applications and those industries that are pushing digital transformation initiatives. Industries that typically have fewer applications — such as agriculture, waste management, and construction — are much more likely to have shorter exposure windows.

Manufacturing, IT, and retail are some of the most enthusiastic supporters of digital transformation initiatives and among the industries dealing with a large share of eternally vulnerable applications. 

"Organizations at large have increased the rate and volume of applications they are pushing into production while reducing the time to release these applications," WhiteHat states in its report. "Consequently, the focus on fixing critical vulnerabilities and vulnerabilities has dropped, resulting in the rise in the time-to-fix for these vulnerabilities."

Companies focused on fast DevOps-style development are more likely to use open source applications, and that means their development teams need to pay more attention to vulnerable components and not just to vulnerabilities in their own code, according to Veracode.

In the past year, 31% of applications have had more vulnerabilities in open source application components, rather than the custom-code components, says Chris Wysopal, co-founder and chief technology officer at Veracode.

"People want to use those environments because there is more open source available, but it is a double-edged sword," he says. "More open source available means you can go faster, but there are often more of the vulnerabilities in the open source rather than the code that you have written."

Some industries are becoming overwhelmed with vulnerabilities. Public administration, educational services, and utilities all take at least 365 days to fix the average vulnerability, according to the WhiteHat report. On average, critical- and high-severity vulnerabilities take less than 200 days to fix, while low-severity vulnerabilities take more than 320 days.

"Leaders and developers must be incentivized to care about building secure applications and remediating issues when they are found," WhiteHat's Jones says. "Typically, most engineering organizations are measured and compensated on feature delivery alone, and it is extremely uncommon to see a feature requirement contain any language around security requirements unless it is a specific security feature."

Cybersecurity is the top investment priority for digitally mature companies, followed by cloud and data analytics, according to an annual survey by Deloitte.

Companies should not make unrealistic goals, and driving down the time from more than 200 days to under 30 days is not going to happen overnight, says Jones. In fact, many companies never fix vulnerabilities in less than a month. 

"Setting an unrealistic policy is something we see occur very often, and it results in policy violations becoming normalized and thus ignored," he says. "Set a threshold that will mean something and that you can act on. Then when you are achieving that threshold, tighten the policy."

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
News
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Edge-DRsplash-10-edge-articles
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
News
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
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
Building the SOC of the Future
Building the SOC of the Future
Digital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-25284
PUBLISHED: 2021-02-27
An issue was discovered in through SaltStack Salt before 3002.5. salt.modules.cmdmod can log credentials to the info or error log level.
CVE-2021-3144
PUBLISHED: 2021-02-27
In SaltStack Salt before 3002.5, eauth tokens can be used once after expiration. (They might be used to run command against the salt master or minions.)
CVE-2021-3148
PUBLISHED: 2021-02-27
An issue was discovered in SaltStack Salt before 3002.5. Sending crafted web requests to the Salt API can result in salt.utils.thin.gen_thin() command injection because of different handling of single versus double quotes. This is related to salt/utils/thin.py.
CVE-2021-3151
PUBLISHED: 2021-02-27
i-doit before 1.16.0 is affected by Stored Cross-Site Scripting (XSS) issues that could allow remote authenticated attackers to inject arbitrary web script or HTML via C__MONITORING__CONFIG__TITLE, SM2__C__MONITORING__CONFIG__TITLE, C__MONITORING__CONFIG__PATH, SM2__C__MONITORING__CONFIG__PATH, C__M...
CVE-2021-3197
PUBLISHED: 2021-02-27
An issue was discovered in SaltStack Salt before 3002.5. The salt-api's ssh client is vulnerable to a shell injection by including ProxyCommand in an argument, or via ssh_options provided in an API request.