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

Not Every Security Flaw Is Created Equal

You need smart prioritization to close the riskiest vulnerabilities. Effective DevSecOps leads the way, according to a new study.

Just as middle-distance runners have long thought the limits of human endurance would prevent anyone from running a four-minute mile, many enterprises today believe there is a similar barrier to achieving both speed and quality with software delivery.

With applications evolving so quickly, the question is whether application security can keep pace. At most enterprises, software is rife with vulnerabilities, and security and development teams can face a mountain of identified but open vulnerabilities. More than 85% of all applications have at least one vulnerability in them, and more than 13% have at least one critical severity flaw, according to new research from CA Veracode.

Drawn from scans of more than 2 trillion lines of code, the data from the report provides a deeper understanding of the most common vulnerabilities, enterprises' ability to fix flaws after they're identified, and best practices to close flaws and reduce software risk more quickly. Greater agility is essential for delivering the competitive advantages that come with bringing quality software to market first.

It shouldn't surprise anyone in the security or development community that fixing flaws takes time. This is due in part to the sheer volume of software in production and the fact that app scans routinely identify new flaws. The most important function of an application security program is how effectively flaws are fixed once they are discovered. The most prevalent flaw types — such as information leakage, cryptographic issues, SQL injection, and cross-site scripting — appear year after year. That means organizations have made very little headway in creating awareness within their development organizations about serious vulnerabilities. This is most likely the result of organizations struggling to embed security best practices into their software development life cycle, regardless of standards in use.

CA Veracode's 2018 State of Software Security Report found that more than 70% of all flaws remain one month after discovery, and nearly 55% remain three months after discovery. Data also showed one in four high and very high severity flaws are not addressed within 290 days of discovery. In some of the worst-case scenarios, flaws lingered unaddressed for more than three years.

On average, one week after first discovery, organizations close out only about 15% of vulnerabilities. Within one month, closure rates reach just under 30%, and by the three-month mark, organizations haven't even made it halfway, closing only a little more than 45% of all flaws.

Flaw Persistence and Application Risk
Looking at the data another way, about one-quarter of all flaws will persist after 472 days. Viewing flaw persistence and fix velocity in this way is important because fixing flaws isn't just a mile marker for appsec programs; it's also a benchmark for measuring application risk. Detecting flaws doesn't reduce risk; fixing them does.

Consequently, organizations need to find effective ways to prioritize which flaws they fix first. Logically, you'd expect security teams to make a big push to fix the highest-impact vulnerabilities first — those that are less complicated to attack, offer more opportunity for full application compromise, and are more likely to be remotely exploitable. While some organizations are doing a good job prioritizing by flaw severity, our findings indicate that they're not considering other risk factors such as the criticality of the application or exploitability of flaws.

Contrary to what some security staffers might believe, developers simply can't wave a magic wand over the portfolio to fix the majority of flaws in an instant, or even a week. On top of that, teams must contend with other factors such as quality assessment, product release cycles, and other exigencies of delivering software to the real world. The sheer volume of vulnerabilities present in most organizations' application portfolios makes it necessary for them to make daily trade-offs between security, practicality, and speed. There are just too many vulnerabilities for organizations to tackle all at once, which means it requires smart prioritization to close the riskiest vulnerabilities first. Not every flaw type is created equal.

Why DevSecOps Works
Embedding security design and testing directly into the continuous software delivery cycle of DevOps is necessary for enterprises. This is the genesis of DevSecOps principles, which offer organizations a balance of speed, flexibility, and risk management. The difficulty is that, until now, it has been tough to find concrete evidence of DevSecOps' security benefits. Our analysis shows a very strong correlation between high rates of security scanning and lower long-term application risks, which we believe presents a significant piece of evidence for the efficacy of DevSecOps. The most active DevSecOps programs fix flaws more than 11.5 times faster than the typical organization.

The faster organizations close vulnerabilities, the less risk software poses over time. This holds true across industries and geographic regions; the more frequent the security scans, the faster fixes are made. By staying on top of new flaws as they are discovered, effective DevSecOps teams minimize the creation of new security debt.

Organizations that embed security checks into ongoing software builds, folding in continuous improvement of the application's security posture alongside feature improvement, will become both more agile and more secure. The earlier in the software development life cycle a security flaw is discovered the faster, easier, and cheaper it is to fix; therefore, organizations need to find ways to move the focus on security earlier in the development process.

One of the easiest and most effective ways to communicate that security is a priority for an organization is to begin offering training on how to write secure code. By educating developers on basic techniques, they can take ownership that is a little more personal because no developer wants to write insecure code. The next step is to bring security and development teams into closer contact, so each understands the others' processes and pain points. In addition, organizations must reduce friction with automated testing tools that can keep pace with accelerated development timelines. Solutions that check for flaws during the coding process enable developers to address vulnerabilities early on when fixes are more cost efficient. And because DevSecOps is equally concerned with security when software is in production, development teams need tools for testing applications after release.

Related Content:

 

Black Hat Europe returns to London Dec. 3-6, 2018, with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.

Chris Eng (@chriseng) is vice president of research 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 ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
AI Is Everywhere, but Don't Ignore the Basics
Howie Xu, Vice President of AI and Machine Learning at Zscaler,  9/10/2019
Fed Kaspersky Ban Made Permanent by New Rules
Dark Reading Staff 9/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-16317
PUBLISHED: 2019-09-14
In Pimcore before 5.7.1, an attacker with limited privileges can trigger execution of a .phar file via a phar:// URL in a filename parameter, because PHAR uploads are not blocked and are reachable within the phar://../../../../../../../../var/www/html/web/var/assets/ directory, a different vulnerabi...
CVE-2019-16318
PUBLISHED: 2019-09-14
In Pimcore before 5.7.1, an attacker with limited privileges can bypass file-extension restrictions via a 256-character filename, as demonstrated by the failure of automatic renaming of .php to .php.txt for long filenames, a different vulnerability than CVE-2019-10867 and CVE-2019-16317.
CVE-2019-16307
PUBLISHED: 2019-09-14
A Reflected Cross-Site Scripting (XSS) vulnerability in the webEx module in webExMeetingLogin.jsp and deleteWebExMeetingCheck.jsp in Fuji Xerox DocuShare through 7.0.0.C1.609 allows remote attackers to inject arbitrary web script or HTML via the handle parameter (webExMeetingLogin.jsp) and meetingKe...
CVE-2019-16294
PUBLISHED: 2019-09-14
SciLexer.dll in Scintilla in Notepad++ (x64) before 7.7 allows remote code execution or denial of service via Unicode characters in a crafted .ml file.
CVE-2019-16309
PUBLISHED: 2019-09-14
FlameCMS 3.3.5 has SQL injection in account/login.php via accountName.