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
97% of Americans Can't Ace a Basic Security Test
Steve Zurier, Contributing Writer,  5/20/2019
How Security Vendors Can Address the Cybersecurity Talent Shortage
Rob Rashotte, VP of Global Training and Technical Field Enablement at Fortinet,  5/24/2019
TeamViewer Admits Breach from 2016
Dark Reading Staff 5/20/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
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
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-7068
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7069
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have a type confusion vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7070
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7071
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure.
CVE-2019-7072
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .