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.

Endpoint

8/19/2019
10:00 AM
Jeff Williams
Jeff Williams
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

Tough Love: Debunking Myths about DevOps & Security

It's time to move past trivial 'shift left' conceptions of DevSecOps and take a hard look at how security work actually gets accomplished.

The security community talks a lot about DevSecOps — look at any vendor's marketing materials. But very few are suggesting any significant changes to the way that security is practiced. DevOps is a fundamental shift in the way we think about building software and is intended to dramatically improve speed and quality. At its core, DevOps prescribes the following:

  • Get work flowing by breaking it into small pieces
  • Create tight feedback loops
  • Create a culture of innovation and learning

The exact problems that used to plague software are still major problems for security. Most organizations only do security on a subset of their code, such as the "critical" or "externally facing" applications and APIs, leaving the vulnerability backlog rampant across the portfolio and the attack visibility practically zero. The truth is, there are a few DevOps myths that are making the problem worse. Here are six:

Myth 1: "DevOps Is All About Automation." The automation is often the most visible part of DevOps, and it may be all that security folks perceive. The reality is that automation can also help to explain how your software factory actually works to the security team. Challenge security to experiment with applying the DevOps techniques to their own work and help them get started on their own DevOps journey.

Myth 2: "We Need to Shift Security Left." "Shift left" is a catchy phrase, but don't just push legacy security tools onto developers who don't have the background to use them. Instead, help developers find modern security tools that integrate into the DevOps pipeline, produce accurate and usable results, and aren't just DevOps lipstick on traditional security tools. Hopefully, your security team will come to realize that security can achieve the same kind of DevOps transformation and benefits as development.

Myth 3: "Increasing Velocity Reduces Security." Security doesn't actually have anything to do with velocity. But often the same automation and processes that lead to high-quality software can be leveraged by security to deliver assurance much faster and more reliably. DevOps actually establishes the infrastructure that security has been lacking for so long. By turning security into code, organizations can dramatically increase the speed, coverage, and accuracy of their security efforts.

Myth 4: "DevOps Makes Security Harder." Many security folks are already overwhelmed with the scale and complexity of their challenge, and they may view DevOps as making their job harder. They may unwittingly slow, derail, or undermine your DevOps transformation, so bring them along on the journey. Include the security team in your planning. Have them read "The Phoenix Project" and have regular interaction with development teams.

Myth 5: "Developers Don't Care about Security." This is one of the most pernicious myths in DevOps. After teaching application security to thousands of developers, my impression is that developers are smart, interested, and curious about security. They want to learn to do things right and avoid security vulnerabilities. Consider that in many organizations, security is poorly defined, a moving target, and full of landmines that can derail projects or careers. Consider becoming part of a development team for a time and working to make security explicit and fully automated so that anytime applications are "clean" they can go into production at whatever velocity the project wants.

DevOps has been widely adopted and has achieved impressive results across a wide array of organizations. It's time to move past trivial "shift left" conceptions of DevSecOps and take a hard look at how security work actually gets accomplished. You'll find massive bottlenecks, wasted effort, duplicated work, feedback loops of weeks, months, or years, and many other problems. Let's call an end to security exceptionalism — there's nothing that special here. The vast majority of security is working on well-understood problems such as injection, path traversal, cross-site scripting, etc. Let's unleash the power of DevOps and radically improve security.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: Modern Technology, Modern Mistakes.

A pioneer in application security, Jeff Williams is the founder and CTO of Contrast Security, a revolutionary application security product that enhances software with the power to defend itself, check itself for vulnerabilities, and join a security command and control ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
mdwydick
50%
50%
mdwydick,
User Rank: Apprentice
8/20/2019 | 10:14:54 AM
How is "Shifting security to the left" a 'myth' ?
Hello!

Overall, I feel like this is an article trying to play 'devil's advocate' for DevOps teams and developers. I understand where you are coming from for most of the claims made on the post and can even get behind some of the 'myths' but the "Shift-left" one does not really make sense. You are not supporting the case that "Shifting security to the left" is a myth, you are merely saying that legacy tools shouldn't be pushed on DevOps teams. A stronger claim would try to explaining that 'shift left' is an impossible task or that it does not result in cost savings, which, is quite the opposite; but that's what I would do if I am trying to debunk that claim.  

Also, shifting secuirty to the left is not just about the tools but also about processes that need to be in place to support secuirty through the pipeline. An example of this would be architecting an application with security in mind, threat modeling, having 'security standards' in place so developers can reference them as they start to code, providing training to developers and DevOps team on application security topics so they can have an existing awareness prior to start building their applications. I feel like the article is norrowing the definition of shift left security to 'archaic tools' when it's quite the oposite (At least in my experience). 

Finally, I would have added a final myth saying that "Security is only the responsability of security professionals" because that is not the case.  In this day and age, everyone in a corporation is responsible for security and should be held accountable for it; if I click on a phishing email, I am sure I would get in as much trouble (if not more) as the team managing the email security tool. So, ultimetely, a better approach would be to marry development and security and have DevSecOps instead of just SecOps. 

Hope to see more DevOps and AppSec articles! :)
NSA Appoints Rob Joyce as Cyber Director
Dark Reading Staff 1/15/2021
Vulnerability Management Has a Data Problem
Tal Morgenstern, Co-Founder & Chief Product Officer, Vulcan Cyber,  1/14/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This is not what I meant by "I would like to share some desk space"
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-27221
PUBLISHED: 2021-01-21
In Eclipse OpenJ9 up to version 0.23, there is potential for a stack-based buffer overflow when the virtual machine or JNI natives are converting from UTF-8 characters to platform encoding.
CVE-2021-1067
PUBLISHED: 2021-01-20
NVIDIA SHIELD TV, all versions prior to 8.2.2, contains a vulnerability in the implementation of the RPMB command status, in which an attacker can write to the Write Protect Configuration Block, which may lead to denial of service or escalation of privileges.
CVE-2021-1068
PUBLISHED: 2021-01-20
NVIDIA SHIELD TV, all versions prior to 8.2.2, contains a vulnerability in the NVDEC component, in which an attacker can read from or write to a memory location that is outside the intended boundary of the buffer, which may lead to denial of service or escalation of privileges.
CVE-2021-1069
PUBLISHED: 2021-01-20
NVIDIA SHIELD TV, all versions prior to 8.2.2, contains a vulnerability in the NVHost function, which may lead to abnormal reboot due to a null pointer reference, causing data loss.
CVE-2020-26252
PUBLISHED: 2021-01-20
OpenMage is a community-driven alternative to Magento CE. In OpenMage before versions 19.4.10 and 20.0.6, there is a vulnerability which enables remote code execution. In affected versions an administrator with permission to update product data to be able to store an executable file on the server ...