Application Security

3/21/2017
06:55 PM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%

The True State of DevSecOps

Automation improving, but security needs to find ways to slide into DevOps workflow and toolchain.

As enterprises increasingly unite security principles and standards within DevOps practices, they're speeding up software delivery and improving security in the process.

A new tide of research and anecdotal evidence indicates that the marriage of the two, known as DevSecOps, is helping them get better at automating security testing and improving security attributes of applications earlier in the development process.

But at the same time, the data and war stories show that there's still a lot of work to go before DevSecOps work patterns fully mature within the enterprise. At most organizations, it's still a struggle to fold security tools into the DevOps-optimized software delivery pipeline. And the majority of DevOps stakeholders still see security as an inhibitor to DevOps agility.

The most recent research came by way of Sonatype this week with its DevSecOps Community Survey. On the good news front, the study shows that in the past three years, the ratio of organizations that test applications throughout the development lifecycle compared to just in production has grown significantly, with close to 2x gains at nearly every early stage step in the development process.

Those organizations that test or analyze for security requirements throughout the entire development process increased from 15% of organizations in 2013 to 27% today. What's more, among those organizations with high DevOps maturity practices, 42% reported that they test throughout the lifecycle. That higher rate is likely influenced by higher rates of automation: 58% of highly mature DevOps shops automate security testing compared to just 39% of other organizations.

Nevertheless, security still suffers from a perception problem. The survey showed that 59% of organizations believe security is an inhibitor to DevOps agility. A big part of the difficulty is that many security testing tools today are still too far removed from the typical developer's workflow and tool chain.

While the DevSecOps ideal is to embed security testing directly into the software delivery process, actually doing it is "a whole other ball game," said Adam Jacob, CTO of Chef, an IT workflow automation vendor that plays heavily in the DevOps world, in a recent podcast.

"If you can't figure out how to manage that security posture the same way you manage the rest of what you do, it's really difficult to then tell a software developer that it’s their responsibility to ensure that that posture is good or bad," he explains. "You can't really ask them to understand the posture of what it's going to be like when it's deployed.

"Because the distance from a software developer making a decision to a software developer talking about how that software should be in production - and what its posture ought to be - is so vast. And their ability to influence it is so low."

Of course, security professionals struggle to bring these tools closer to the developer because the majority of security testing tools were designed for traditional waterfall-development models.

"For those of us who have been involved on the front lines of traditional AppSec activities such as penetration testing, dynamic- or static-code analysis, it may be obvious that the traditional tools and techniques we use were built more for waterfall-native rather than DevOps-native environments," says Oleg Gryb, chief security architect for Visa. "Yet for executives who came to security from infrastructure, networking, or development domains and have never run a security scan, the challenges of bringing traditional tool sets and practices into the new velocity expectations of DevSecOps may not be so obvious."

This causes big hiccups in testing, such as in the case of compliance validation. A survey published last week from Chef reports that 64% of DevOps shops have regulatory standards to follow. Of those, 73% wait to assess compliance after development, and 59% wait all the way until code is already running in production. This results in a lot of added strain on developers and inconsistent security, to boot.

The Chef survey showed that after a compliance violation is found, one in four organizations need weeks or months to remediate them. In a DevOps world where dozens or even hundreds of builds a day are the delivery norm, this is a positive geologic age in time progression before fixes are made.

According to DJ Schleen, security architect at Aetna, this will require security leaders to not only look for better tools but also get creative about where and how security controls are automated into the workflow.

[Chef executives will present Defining DevOps Metrics at Interop ITX on Tuesday, May16, at the MGM Grand in Las Vegas.]

"We need to identify ways to observe and collect data in both a passive and an active way. Passive ways of producing data could include methods to calculate defect density for a collection of code after a static code analysis has been performed, or to calculate the risk ranking for a codebase based on code smell - whereas an active way of producing data may be the action of pausing the release pipeline to perform a vulnerability scan itself," he says.

Schleen says active collection is tricky when integrating automated tools."When you are generating data in an active way, you can potentially be a bottleneck in your release pipeline," he notes.

Additionally, security folk would also do well to challenge their comfort zone with regard to tools, says Troy Marshall, DevSecOps and cloud reliability leader for Ellucian, a developer of software for higher education. That's exactly what his firm had to do when it found that the commercial dynamic application security testing (DAST) tool it was using prior to its DevOps transformation wouldn't fit well into its new software delivery tool chain.

"We looked at a lot of other commercial tools and decided that the available open source tooling was sufficient for our minimum viable product," he says, explaining that there have been bumps along the way but his team has made it work.

Related Content:

 

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
New Free Tool Scans for Chrome Extension Safety
Dark Reading Staff 2/21/2019
Making the Case for a Cybersecurity Moon Shot
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  2/19/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-9015
PUBLISHED: 2019-02-22
A Path Traversal vulnerability was discovered in MOPCMS through 2018-11-30, leading to deletion of unexpected critical files. The exploitation point is in the "column management" function. The path added to the column is not verified. When a column is deleted by an attacker, the correspond...
CVE-2019-9016
PUBLISHED: 2019-02-22
An XSS vulnerability was discovered in MOPCMS through 2018-11-30. There is persistent XSS that allows remote attackers to inject arbitrary web script or HTML via the form[name] parameter in a mod=column request, as demonstrated by the /mopcms/X0AZgf(index).php?mod=column&ac=list&menuid=28&am...
CVE-2018-20784
PUBLISHED: 2019-02-22
In the Linux kernel before 4.20.2, kernel/sched/fair.c mishandles leaf cfs_rq's, which allows attackers to cause a denial of service (infinite loop in update_blocked_averages) or possibly have unspecified other impact by inducing a high load.
CVE-2019-9003
PUBLISHED: 2019-02-22
In the Linux kernel before 4.20.5, attackers can trigger a drivers/char/ipmi/ipmi_msghandler.c use-after-free and OOPS by arranging for certain simultaneous execution of the code, as demonstrated by a "service ipmievd restart" loop.
CVE-2019-9004
PUBLISHED: 2019-02-22
In Eclipse Wakaama (formerly liblwm2m) 1.0, core/er-coap-13/er-coap-13.c in lwm2mserver in the LWM2M server mishandles invalid options, leading to a memory leak. Processing of a single crafted packet leads to leaking (wasting) 24 bytes of memory. This can lead to termination of the LWM2M server afte...