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.

Risk

10/13/2015
11:00 AM
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

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
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
kwestrom
50%
50%
kwestrom,
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. 
TejGandhi1986
50%
50%
TejGandhi1986,
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.

 

https://ca.linkedin.com/pub/tej-gandhi/2b/a88/a10
Dave787
100%
0%
Dave787,
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."

 

 
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/21/2020
Cybersecurity Bounces Back, but Talent Still Absent
Simone Petrella, Chief Executive Officer, CyberVista,  9/16/2020
Meet the Computer Scientist Who Helped Push for Paper Ballots
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/16/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-25514
PUBLISHED: 2020-09-22
Sourcecodester Simple Library Management System 1.0 is affected by Incorrect Access Control via the Login Panel, http://<site>/lms/admin.php.
CVE-2020-25515
PUBLISHED: 2020-09-22
Sourcecodester Simple Library Management System 1.0 is affected by Insecure Permissions via Books > New Book , http://<site>/lms/index.php?page=books.
CVE-2020-14022
PUBLISHED: 2020-09-22
Ozeki NG SMS Gateway 4.17.1 through 4.17.6 does not check the file type when bulk importing new contacts ("Import Contacts" functionality) from a file. It is possible to upload an executable or .bat file that can be executed with the help of a functionality (E.g. the "Application Star...
CVE-2020-14023
PUBLISHED: 2020-09-22
Ozeki NG SMS Gateway through 4.17.6 allows SSRF via SMS WCF or RSS To SMS.
CVE-2020-14024
PUBLISHED: 2020-09-22
Ozeki NG SMS Gateway through 4.17.6 has multiple authenticated stored and/or reflected XSS vulnerabilities via the (1) Receiver or Recipient field in the Mailbox feature, (2) OZFORM_GROUPNAME field in the Group configuration of addresses, (3) listname field in the Defining address lists configuratio...