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

DevSecOps An Effective Fix for Software Flaws

Organizations seeking to fix flaws faster should look to automation and related methodologies for success, says a new report.

Knowing a vulnerability's severity might not tell you anything about how quickly that vulnerability will be fixed. But knowing what kind of development model the company is using could tell you a lot. Those are some of the conclusions of a new study that looks at how many vulnerabilities appear in enterprise software and how long they hang around once they're discovered.

The ninth edition of Veracode's "State Of Software Security" report concludes that the greatest indicator of how quickly an organization will fix the vulnerabilities it finds correlates to how many times each year developers scan their code for issues. It's a marker that Chris Eng, vice president of research at Veracode, says he sees as a stand-in for the type of development discipline the company uses.

"We used scan frequency as kind of a proxy for DevOps because if you're scanning really often — daily or or more often — it indicates that you're doing a lot with automation," Eng says. "We can surmise from that that you're probably a DevOps shop." He contrasts organizations that scan their code hundreds of times a year with those that run one or two scans a year, and says the differences are borne out in what Veracode sees in code defects and remediation.

Veracode judges the duration of a flaw based on how many times the same issue shows up in a scan after its initial discovery, Eng says. "If the flaw shows up three, four, five times, we can see that this was discovered in January, and you scanned it every month, and it's still there in May—then in June it goes away. So you assume that to mean that they closed it after four months," he explains.

Eng's use of "months" as the time scale for remediation is not arbitrary. According to the Veracode research, more than 70% of all flaws were still present a month after initial discovery, and nearly 55% had not been remediated after three months. In fact, while roughly a quarter of all code flaws were dealt with inside 21 days, another quarter were still open issues after a year.

The length of time from discovery to fix varied according to the flaw's severity — but not very much, Eng says. Based on a scale that rates the most severe issues a 5 and the least severe a 1, he explains, "We expected the fives to be fixed the fastest and then the fours, threes, twos, but it wasn't like that." While the flaws rated 5 were repaired fastest, 3s were fixed faster than 4s — and 5s weren't fixed all that quickly, either.

It takes 14 days to get 25% of the 5s fixed, 64 days to get to the 50% mark on repairs, and 206 days before 75% have been corrected, Eng says. The great variation in time to repair is how often the code is scanned for flaws, he says.

In the population that scans their code 300 times a year or more, Eng says, "They're fixing a quarter of the flaws that we detect within three days, half within five days, and 75% within seven days." Just as important, Eng says, those high-frequency companies eventually remediate 100% of the flaws found.

"Compare that to the ones that are scanning one to three times a year," he says. "Even to get to the 50% mark it's almost a year, and to get to the 75% mark it's almost four years."

This report surprised Eng in several ways, but ultimately, he says, "We feel like we have good evidence that the DevSecOps thing actually does work. We see that in the 'fix velocity' chart, and that was that was a huge, huge takeaway for us."

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.

Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and ... 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
Can Your Patching Strategy Keep Up with the Demands of Open Source?
Tim Mackey, Principal Security Strategist, CyRC, at Synopsys,  6/18/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-3896
PUBLISHED: 2019-06-19
A double-free can happen in idr_remove_all() in lib/idr.c in the Linux kernel 2.6 branch. An unprivileged local attacker can use this flaw for a privilege escalation or for a system crash and a denial of service (DoS).
CVE-2019-3954
PUBLISHED: 2019-06-19
Stack-based buffer overflow in Advantech WebAccess/SCADA 8.4.0 allows a remote, unauthenticated attacker to execute arbitrary code by sending a crafted IOCTL 81024 RPC call.
CVE-2019-10085
PUBLISHED: 2019-06-19
In Apache Allura prior to 1.11.0, a vulnerability exists for stored XSS on the user dropdown selector when creating or editing tickets. The XSS executes when a user engages with that dropdown on that page.
CVE-2019-11038
PUBLISHED: 2019-06-19
When using gdImageCreateFromXbm() function of gd extension in versions 7.1.x below 7.1.30, 7.2.x below 7.2.19 and 7.3.x below 7.3.6, it is possible to supply data that will cause the function to use the value of uninitialized variable. This may lead to disclosing contents of the stack that has been ...
CVE-2019-11039
PUBLISHED: 2019-06-19
Function iconv_mime_decode_headers() in versions 7.1.x below 7.1.30, 7.2.x below 7.2.19 and 7.3.x below 7.3.6 may perform out-of-buffer read due to integer overflow when parsing MIME headers. This may lead to information disclosure or crash.