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
Crowdsourced vs. Traditional Pen Testing
Alex Haynes, Chief Information Security Officer, CDL,  3/19/2019
BEC Scammer Pleads Guilty
Dark Reading Staff 3/20/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
The State of Cyber Security Incident Response
The State of Cyber Security Incident Response
Organizations are responding to new threats with new processes for detecting and mitigating them. Here's a look at how the discipline of incident response is evolving.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-15583
PUBLISHED: 2019-03-25
Cross-Site Scripting (XSS) vulnerability in point_list.php in GNUBOARD5 before 5.3.1.6 allows remote attackers to inject arbitrary web script or HTML via the popup title parameter.
CVE-2017-7340
PUBLISHED: 2019-03-25
A Cross-Site Scripting vulnerability in Fortinet FortiPortal versions 4.0.0 and below allows an attacker to execute unauthorized code or commands via the applicationSearch parameter in the FortiView functionality.
CVE-2014-9187
PUBLISHED: 2019-03-25
Multiple heap-based buffer overflow vulnerabilities exist in Honeywell Experion PKS all versions prior to R400.6, all versions prior to R410.6, and all versions prior to R430.2 modules, which could lead to possible remote code execution or denial of service. Honeywell strongly encourages and recomme...
CVE-2014-9189
PUBLISHED: 2019-03-25
Multiple stack-based buffer overflow vulnerabilities were found in Honeywell Experion PKS all versions prior to R400.6, all versions prior to R410.6, and all versions prior to R430.2 modules that could lead to possible remote code execution, dynamic memory corruption, or denial of service. Honeywell...
CVE-2019-10044
PUBLISHED: 2019-03-25
Telegram Desktop before 1.5.12 on Windows, and the Telegram applications for Android, iOS, and Linux, is vulnerable to an IDN homograph attack when displaying messages containing URLs. This occurs because the application produces a clickable link even if (for example) Latin and Cyrillic characters e...