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

10/22/2019
07:05 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

About 50% of Apps Are Accruing Unaddressed Vulnerabilities

In rush to fix newly discovered security issues, developers are neglecting to address older ones, Veracode study finds.

The latest edition of Veracode's annual "State of Software Security" study released this week shows that many enterprise organizations are at increased breach risk because of aging, unaddressed application security flaws.

Veracode recently analyzed data from application security tests on more than 85,000 applications and found that, on average, companies fix just 56% of all software security issues they discover between initial and final scans. Most of the flaws that are fixed tend to be newly discovered ones, while older, previously discovered issues are neglected and allowed to accumulate dangerously.

The resulting "security debt," as Veracode calls it, is increasing breach risks at many organizations. "Security debt — defined as aging and accumulating flaws in software — is emerging as a significant pain point for organizations across industries," says Chris Wysopal, founder and CTO at Veracode. "Just as with credit card debt, if you start out with a big balance and only pay for each month's new spending, you'll never eliminate the balance."

Veracode's new report marks the 10th time the company has released an annual assessment on the state of application software security. The 85,000 applications that were tested for the latest study is more than 50 times larger than the 1,591 applications tested for the first edition.

The study showed over half of all applications are accruing debt in the form of unfixed security vulnerabilities between initial security scanning and the last scan because developers are more focused on new issues.

The median time to fix newly discovered vulnerabilities is 59 days, which is about the same as 10 years ago. But the average number of days to fix flaws jumped from 59 days in the first report to 171 days in the latest. The data shows that while typical median fix times haven't gotten worse in 10 years, security debt is getting much deeper, Wysopal says.

Eighty-three percent of the applications in Veracode's study had at least one security flaw in them on initial scan, up from 72% in the first study. Sixty-six percent of applications failed initial tests based on OWASP's Top 10 and the SANS Top 25 standards.

At least some of increase in the number of flaws discovered during initial scan had to do with the broader set of applications that were tested for the latest study. The vulnerability scanning capabilities that exist today are also better than they were a decade ago, resulting in more vulnerabilities being discovered.

"With a 50-fold increase in sample size, we did see the overall prevalence of flaws rise 11%," Wysopal says. The good news, however, is that the proportion of those flaws assessed to be of high severity dropped 14% over the same period, he says. Only 20% of applications in Veracode's study had high-severity flaws at initial scan, down from 34% in the first report.

Not very surprisingly — and consistent with results in Veracode's previous reports — the flaws that get the most attention are also the most severe ones. Veracode found that developers fix 76% of the most critical vulnerabilities and 69% of the slightly less critical but still severe flaws.

"This tells us developers are getting better at figuring out which flaws are necessary to fix first," Wysopal notes.

The data suggests that finding and fixing vulnerabilities has become as much a part of the process as improving functionality, Wysopal says. "As developers become more responsible for securing their software, this shift in mindset is critically important."

The Same Old Same Old
Veracode found that many of the most common security flaws that are present in application software these days are the same as those from 10 years ago. Among them are cryptographic errors and information leakage flaws, input validation issues, and weak credential management.

At the same time, a few other vulnerabilities types — such as buffer overflow and buffer management errors — have become less prevalent because less code is written in languages, such as C and C++, that are susceptible to these flaws.  

"The other flaw categories remain prevalent as developers aren't educated about cryptographic issues, information leakage, CRLF, and input validation errors, so they keep making the same mistakes over and over again," Wysopal says.

The frequency and the cadence of software security tests have a direct impact on response times, according to Veracode. Organizations in the security vendor's study that scanned applications less than once a month, for instance, required a median time of 68 days to remediate security issues, while those that scanned daily required just 19 days.

Most organizations, however, appeared nowhere close to doing scans that frequently. Only a third of the applications in the Veracode study, for example, were scanned between two and six times per year, while another 36% were scanned just once a year. Less than 1% of the applications were scanned 260 times or more per year.

Significantly, Veracode found that applications with the highest scan frequency also had five times fewer unaddressed security issues on average compared with the least scanned apps. The data suggests that implementing DevOps and DevSecOps models can have a huge impact on securing application software, according to Veracode.

Related Content:

This free, all-day online conference offers a look at the latest tools, strategies, and best practices for protecting your organization’s most sensitive data. Click for more information and, to register, here.

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
christophertbish
50%
50%
christophertbish,
User Rank: Apprentice
10/23/2019 | 4:40:17 AM
thank pro
thank for somuch
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19642
PUBLISHED: 2019-12-08
On SuperMicro X8STi-F motherboards with IPMI firmware 2.06 and BIOS 02.68, the Virtual Media feature allows OS Command Injection by authenticated attackers who can send HTTP requests to the IPMI IP address. This requires a POST to /rpc/setvmdrive.asp with shell metacharacters in ShareHost or ShareNa...
CVE-2019-19637
PUBLISHED: 2019-12-08
An issue was discovered in libsixel 1.8.2. There is an integer overflow in the function sixel_decode_raw_impl at fromsixel.c.
CVE-2019-19638
PUBLISHED: 2019-12-08
An issue was discovered in libsixel 1.8.2. There is a heap-based buffer overflow in the function load_pnm at frompnm.c, due to an integer overflow.
CVE-2019-19635
PUBLISHED: 2019-12-08
An issue was discovered in libsixel 1.8.2. There is a heap-based buffer overflow in the function sixel_decode_raw_impl at fromsixel.c.
CVE-2019-19636
PUBLISHED: 2019-12-08
An issue was discovered in libsixel 1.8.2. There is an integer overflow in the function sixel_encode_body at tosixel.c.