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
7 Truths About BEC Scams
Ericka Chickowski, Contributing Writer,  6/13/2019
DNS Firewalls Could Prevent Billions in Losses to Cybercrime
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/13/2019
Cognitive Bias Can Hamper Security Decisions
Kelly Sheridan, Staff Editor, Dark Reading,  6/10/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
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-12855
PUBLISHED: 2019-06-16
In words.protocols.jabber.xmlstream in Twisted through 19.2.1, XMPP support did not verify certificates when used with TLS, allowing an attacker to MITM connections.
CVE-2013-7472
PUBLISHED: 2019-06-15
The "Count per Day" plugin before 3.2.6 for WordPress allows XSS via the wp-admin/?page=cpd_metaboxes daytoshow parameter.
CVE-2019-12839
PUBLISHED: 2019-06-15
In OrangeHRM 4.3.1 and before, there is an input validation error within admin/listMailConfiguration (txtSendmailPath parameter) that allows authenticated attackers to achieve arbitrary command execution.
CVE-2019-12840
PUBLISHED: 2019-06-15
In Webmin through 1.910, any user authorized to the "Package Updates" module can execute arbitrary commands with root privileges via the data parameter to update.cgi.
CVE-2019-12835
PUBLISHED: 2019-06-15
formats/xml.cpp in Leanify 0.4.3 allows for a controlled out-of-bounds write in xml_memory_writer::write via characters that require escaping.