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
US Turning Up the Heat on North Korea's Cyber Threat Operations
Jai Vijayan, Contributing Writer,  9/16/2019
Preventing PTSD and Burnout for Cybersecurity Professionals
Craig Hinkley, CEO, WhiteHat Security,  9/16/2019
NetCAT Vulnerability Is Out of the Bag
Dark Reading Staff 9/12/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
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-3738
PUBLISHED: 2019-09-18
RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to an Improper Verification of Cryptographic Signature vulnerability. A malicious remote attacker could potentially exploit this vulnerability to coerce two parties into computing the same predictable shared key.
CVE-2019-3739
PUBLISHED: 2019-09-18
RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to Information Exposure Through Timing Discrepancy vulnerabilities during ECDSA key generation. A malicious remote attacker could potentially exploit those vulnerabilities to recover ECDSA keys.
CVE-2019-3740
PUBLISHED: 2019-09-18
RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to an Information Exposure Through Timing Discrepancy vulnerabilities during DSA key generation. A malicious remote attacker could potentially exploit those vulnerabilities to recover DSA keys.
CVE-2019-3756
PUBLISHED: 2019-09-18
RSA Archer, versions prior to 6.6 P3 (6.6.0.3), contain an information disclosure vulnerability. Information relating to the backend database gets disclosed to low-privileged RSA Archer users' UI under certain error conditions.
CVE-2019-3758
PUBLISHED: 2019-09-18
RSA Archer, versions prior to 6.6 P2 (6.6.0.2), contain an improper authentication vulnerability. The vulnerability allows sysadmins to create user accounts with insufficient credentials. Unauthenticated attackers could gain unauthorized access to the system using those accounts.