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
COVID-19: Latest Security News & Commentary
Dark Reading Staff 4/7/2020
The Coronavirus & Cybersecurity: 3 Areas of Exploitation
Robert R. Ackerman Jr., Founder & Managing Director, Allegis Capital,  4/7/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
State of Cybersecurity Incident Response
State of Cybersecurity Incident Response
Data breaches and regulations have forced organizations to pay closer attention to the security incident response function. However, security leaders may be overestimating their ability to detect and respond to security incidents. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-20637
PUBLISHED: 2020-04-08
An issue was discovered in Varnish Cache before 6.0.5 LTS, 6.1.x and 6.2.x before 6.2.2, and 6.3.x before 6.3.1. It does not clear a pointer between the handling of one client request and the next request within the same connection. This sometimes causes information to be disclosed from the connecti...
CVE-2020-11650
PUBLISHED: 2020-04-08
An issue was discovered in iXsystems FreeNAS 11.2 and 11.3 before 11.3-U1. It allows a denial of service.
CVE-2020-11653
PUBLISHED: 2020-04-08
An issue was discovered in Varnish Cache before 6.0.6 LTS, 6.1.x and 6.2.x before 6.2.3, and 6.3.x before 6.3.2. It occurs when communication with a TLS termination proxy uses PROXY version 2. There can be an assertion failure and daemon restart, which causes a performance loss.
CVE-2020-2732
PUBLISHED: 2020-04-08
A flaw was discovered in the way that the KVM hypervisor handled instruction emulation for an L2 guest when nested virtualisation is enabled. Under some circumstances, an L2 guest may trick the L0 guest into accessing sensitive L1 resources that should be inaccessible to the L2 guest.
CVE-2020-1627
PUBLISHED: 2020-04-08
A vulnerability in Juniper Networks Junos OS on vMX and MX150 devices may allow an attacker to cause a Denial of Service (DoS) by sending specific packets requiring special processing in microcode that the flow cache can't handle, causing the riot forwarding daemon to crash. By continuously sending ...