11:00 AM
Connect Directly
E-Mail vvv

Why DevOps Fails At Application Security

In a recent survey of developers, nearly half of respondents admit to releasing applications with known vulnerabilities at least 80 percent of the time.

As the pace of application development speeds up, how are enterprises ensuring those comprehensive security needs are being met? Despite the allocation of significant budget to the development of applications, and the continued pressure to release and update applications quickly, enterprises are still unable to secure their applications against attacks.

In a perfect world, applications would always be coded securely, pass all vulnerability scans and penetration tests, and never encounter zero-day attacks. Unfortunately, we know all too well that there’s no such thing as invulnerable code. In today’s world of rapid software release cycles, the remediation of legacy applications is usually regarded by application development teams as a tiresome and cumbersome task of questionable value, and one that slows down the pace of business and innovation.

At Prevoty, we surveyed more than 200 application and software developers to gain a better understanding of the pressures they face to release applications. We found that more than 70 percent of the respondents admit that this pressure to release updates often override security concerns, and 85 percent said that vulnerability remediation has an impact on the ability to get products and features out on schedule and on budget.

Due to the increasing pressures to release applications, update features, and fix bugs quickly, more than half of survey respondents also said they have a release cycle of one week or less, regardless of development workflow methodologies such as agile, SCRUM, Crystal, etc. Furthermore, nearly 80 percent of developers polled worry that their clients won’t trust applications if they admit there is a security flaw.

The evolving and amorphous nature of application attacks also poses a unique threat, and leaves developers without the ability to architect applications in ways that would prevent future attacks. After all, developers aren’t hackers by nature, so how do they stay ahead of never-before-seen attacks or new malware created by the hacking community? Application developers are in the business of building technology – not breaking it – so they’re not usually looking at code through the lens of a hacker.

To try and combat this while still meeting short release cycles, development teams have adapted their security practices to try to keep up with emerging threats and attacks. The practices most frequently employed are application vulnerability scans, penetration tests, and dedicated in-house security resources. Our research found that at least 82 percent of respondents say their companies perform some vulnerability scanning and/or penetration testing prior to application release.

But despite this emphasis on testing, the research also revealed something alarming: applications are still being released even before all known vulnerabilities can be fixed. More specifically, nearly half of developers admit to releasing applications with known vulnerabilities at least 80 percent of the time. That is a disturbingly high percentage of developers releasing or updating a production application, knowing that they’re vulnerable to an attack.

We’ve all seen how destructive major data breaches can be, and they seem to be increasing in frequency and scale all the time. It should be businesses’ top priority to make sure that all known vulnerabilities are being remediated. Unfortunately, at this time, the burden of the remediation process does not align developers with application security. Instead, it’s largely viewed as a threat to the overall goal of delivering business value to the organization at large, leaving too much sensitive data at risk.


Julien Bellanger is the cofounder and CEO of Prevoty, a next-generation application security platform. Most recently, Julien founded Personagraph, an Intertrust company focused on mobile user privacy. Before joining Intertrust as director of corporate development, he built ... View Full Bio
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
10/24/2015 | 3:24:21 PM
DevOps failing with Application Security
There were many good points raised with the article, and as pointed out, it's a mad rush to get the product with enough features out the door or to get it to market that security is often left out. Security should be built into the total time frame on an approximate 75% development total budgeted time, and around about 25% for the application security teams to look at it and root out the bugs in the code. As said, the developers are only looking at the code to put in features with seeing it only from a development standpoint/through development glasses, while the security team looks at it from the vulnerability viewpoint, and where the inherent weaknesses are hiding in the application. THe DevOps teams are too close to the application to see it from the vulnerability point of view to really do the job; however the bigger problem isn't with them, but the senior organizational management, such that until or unless the security of the produced products impacts the organizational financial bottomline, such as it is with the car/truck/vehicle makers, or the pharmaceutical industries, it won't happen.  THe software development application businesses have been enjoying a freedom from having to do thorough testing of their applications up through this point, but they need to be held accountable for the consequences by the exploited vulnerabilities when it occurs. Legislation/regulatory standards (with significant penalties for the weaknesses-vulnerabilities to be incurred upon hacks), so need to be put into place for the senior management to actually think about and plan for  the necessity of having secure applications when they are released into the market place for the public. Without something of that sort to be done, no organizational senior management, Board, or especially the stockholders to care about any application other than to get it out the door so that money can be made for profit on the product. 
User Rank: Apprentice
10/15/2015 | 8:03:02 AM
Devops fail application security
Shipping the product to market has always been a priority.Considering security concerns increases the schedule and budget however it is critical.A mindset shift towards security can achieve this purpose.


Stakeholders ,devops need to ennsure proper time allotment and budget allotment toward security,the consequences must be revealed of not introducing secuity in the code.

When the impact is known it will immediately ensure that security has taken into consideration.


User Rank: Apprentice
10/14/2015 | 4:06:09 PM
Secure code has never been easier with this DevOps tool
Hey Julien –

Great article!

It really captured exactly what's not being discussed enough in the cybersecurity space. True data-centric security starts with the developer and the application-level.

Disclaimer: I work for a company called Crypteron. At Crypteron, we are intimately aware of the new challenges and responsibilities facing developers nowadays. Secure coding has long been too difficult, complex, time-consuming - and not really "secure."


Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.