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.

Cloud

5/8/2020
10:00 AM
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

Why DevSecOps Is Critical for Containers and Kubernetes

DevSecOps is a big and sometimes difficult shift for organizations. The key to success? Take small steps.

DevOps has enabled organizations to harness the automation and speed of deployment that cloud-native technologies such as containers and Kubernetes provide. However, if security is not tightly integrated into DevOps, organizations' ability to take full advantage of the cloud-native model is severely diminished. If this sounds familiar, your company is at best getting less bang for its cloud-native buck and at worst putting the business and customers at risk.

Indeed, today's rapid and frequent development cycles demand that security be an integral and shared part of the entire app life cycle: DevSecOps. For example, it is best practice never to patch a running container but, rather, to always rebuild and redeploy. To do this well and at speed, organizations must use automated unit and functional tests, and they need to integrate automated security gates.

In fact, you really can't make the shift to a true DevSecOps model without investing in automation throughout the infrastructure and application life cycle. For example, solutions such as Ansible and Kubernetes operators have enabled organizations to add automation to Kubernetes itself. ArgoCD is another solution that is getting some real traction by applying the GitOps model to Kubernetes cluster configurations. (After all, it's just as important to manage the configurations for your application platform as it is for the applications themselves.)

Not all of the security tools companies have been accustomed to using will work well in this new model. Containers and Kubernetes have created challenges for traditional security tools that can't adapt to the degree of automation and the speed of deployment that these and other cloud-native technologies deliver. Fortunately, there is a broad ecosystem of container/Kube-native solutions available, ranging from analysis tools that integrate with the CI/CD pipeline to the container runtime and to Kubernetes network security. Moving forward, container-optimized operating systems will change how we think about managing and securing the host operating system itself.

Culture and Process
But DevSecOps is not just about tools; it's also about culture and process.

In many companies, the role of security is still isolated to a specific team in the final stage of development. This model runs completely counter to the cloud-native development model, in which there is a shared responsibility for security (and everything else). If teams can't see the benefits of collaboration and instead stick to their own silos, it can indicate a lack of communication that will most certainly lead to a debilitated application development pipeline — which can then lead to an inability to compete as customers go elsewhere for the apps and services they demand.

With that said, DevSecOps is a big and sometimes difficult shift for organizations. Team members need to understand that this direction is supported by their management and that it will be valuable to both them and their organizations to collaborate and to update their skill sets for the technologies that support and enable a more dynamic development and deployment pipeline.

The key to getting there is to take small steps. It is helpful to start with a pilot project: Identify a project and cross-functional team (app dev, ops, security) to implement a DevSecOps pipeline and process. Identify goals and use cases, and prepare to iterate. Once the team is working well, document the implementation and the results, including business value (such as faster time to market or ability to address security issues up front). At Red Hat's Open Innovation Labs, we've seen organizations that have adopted DevSecOps improve their time to market by 81% (moving from a 38-week deployment cycle to a 7-week cycle), and a 97% improvement in confirming functionality is complete (from 4 weeks to 4.5 hours).

Once the project has been successfully completed, recruit key and enthusiastic contributors and executive sponsors across the appdev, operations and security teams to evangelize and help expand the model to other parts of the organization. But, again, continue to plan to adapt. As much as possible, give teams the agency to meet goals in the way that works best for them, while also providing guidance on best practices and supporting consistency.

If DevSecOps is put effectively into motion, each team will certainly have plenty to promote — most notably, its ability to enable the organization to fully leverage the power of cloud-native models in general and containers and Kubernetes specifically.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's featured story: "How InfoSec Pros Can Help Healthcare During the Coronavirus Pandemic."

Kirsten works closely with Red Hat's many security professionals across the Red Hat portfolio of enterprise-ready open source offerings. Kirsten is a diversified software management professional with 15+ years of experience in application development and ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
News
US Formally Attributes SolarWinds Attack to Russian Intelligence Agency
Jai Vijayan, Contributing Writer,  4/15/2021
News
Dependency Problems Increase for Open Source Components
Robert Lemos, Contributing Writer,  4/14/2021
News
FBI Operation Remotely Removes Web Shells From Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/14/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-3035
PUBLISHED: 2021-04-20
An unsafe deserialization vulnerability in Bridgecrew Checkov by Prisma Cloud allows arbitrary code execution when processing a malicious terraform file. This issue impacts Checkov 2.0 versions earlier than Checkov 2.0.26. Checkov 1.0 versions are not impacted.
CVE-2021-3036
PUBLISHED: 2021-04-20
An information exposure through log file vulnerability exists in Palo Alto Networks PAN-OS software where secrets in PAN-OS XML API requests are logged in cleartext to the web server logs when the API is used incorrectly. This vulnerability applies only to PAN-OS appliances that are configured to us...
CVE-2021-3037
PUBLISHED: 2021-04-20
An information exposure through log file vulnerability exists in Palo Alto Networks PAN-OS software where the connection details for a scheduled configuration export are logged in system logs. Logged information includes the cleartext username, password, and IP address used to export the PAN-OS conf...
CVE-2021-3038
PUBLISHED: 2021-04-20
A denial-of-service (DoS) vulnerability in Palo Alto Networks GlobalProtect app on Windows systems allows a limited Windows user to send specifically-crafted input to the GlobalProtect app that results in a Windows blue screen of death (BSOD) error. This issue impacts: GlobalProtect app 5.1 versions...
CVE-2021-3506
PUBLISHED: 2021-04-19
An out-of-bounds (OOB) memory access flaw was found in fs/f2fs/node.c in the f2fs module in the Linux kernel in versions before 5.12.0-rc4. A bounds check failure allows a local attacker to gain access to out-of-bounds memory leading to a system crash or a leak of internal kernel information. The hi...