Category: culture

To understand the current and future state of DevSecOps, we gathered insights from 29 IT professionals in 27 companies. We asked them, "Do you have any concerns regarding the current state of DevSecOps?" Here's what they told us:

Culture

• I feel like most organizations know what to do to improve their security posture and simply don’t act on it. This could be because of prioritization, but then you have to ask about why prioritization uses the methods it does. The simple answer is the cost of being bad at security for many firms just isn’t much. Look at Equifax, they exposed millions of Americans' data who never consented to even provide them that data, and other than a trip to DC, nothing happened. Why prioritize security when it the cost of being bad at it is so much less than the cost of being second or third to market with features? This may seem grim, and that’s only because it is.
• The fact that there’s a name for DevOps plus security shows that security is still an outsider to DevOps. We need to reach a point where developers truly accept that security can’t be separated from their work, and where security professionals accept they have to be part of the solution. Security professionals are in great demand, and it can be difficult to have full-time security professionals on every DevSecOps team. That tends to separate the security function from the rest of DevOps and makes it harder for security to truly be part of the end-to-end process.
• The focus today is still largely on project activities aimed at automation. We need to get past this and look at program level coordinating activities. This includes emphasizing key business security requirements like compliance and risk. The discussion will naturally turn toward continuous compliance and continuous risk rather than project concepts like continuous integration and continuous deployment.
• Security checks and balances are viewed negatively by DevOps teams. Extreme frustration forced to use old operating systems from five years ago, things don’t move fast, most organizations are still struggling. As DevOps teams pay more attention to Ops, DevOps, and CSOs coming together to get the new services launched.
• The most limiting factor for DevSecOps today is the remaining fuzziness about its definition and who needs to understand it and be actively involved in it. As an industry, we need to be realistic about what DevSecOps is and is not. A strong, automated DevSecOps approach is not going to protect our organizations from social engineering, network penetration, or myriad other security risks and is not a replacement for a broad security approach, so organizations that choose DevSecOps instead of a security practice (rather than in conjunction with one) are falsely comfortable. Likewise, we should not understate its definition, equating DevSecOps to a handful of security scans and failing to implement it as a practice across organizational functions. Finally, the industry still speaks about DevSecOps as a separate practice, and while it is probably still important to do so in order to keep awareness of the topic high, it’s important that we begin to understand it as a default practice of good DevOps and consider it essential to any strong DevOps practice.
• Conversations around DevSecOps are predominantly focused on tools and technology, the application of tools, and how to approach newer DevOps methodologies. There is very little discussion in the community (both in security and DevOps) on collaboration, shared ownership, KPIs for governance and cultural change that is required for successful DevSecOps. We are still in a transitional period, so it’s important that these cultural elements become a more prominent area of focus for DevSecOps.
• A failure of leadership is often at the root of the issue. One of the concerns regarding the current state of DevSecOps is just how long it takes an organization to begin to make the cultural changes necessary for DevSecOps to be successful. Often times it’s the organization simply trying to do the day-to-day job.
• Many organizations still haven’t embedded security throughout their deployment pipelines and are leaving vulnerabilities in their products to be discovered and leveraged by hostile elements. The race to beat hackers is never-ending, and organizations must adopt a comprehensive and continuous approach to security to protect their customers and users. DevSecOps is a great step, but it must be implemented in practice in order to work.
• 1) The main concern remains the complete integration of process, culture, technology, and operations to solve for a comprehensive and supportable DevSecOps implementation. 2) The industry at large implements DevSecOps using several detective and corrective measures. SAST/DAST tools record unwanted defects acting in a detective capacity, for example. Corrective measures might simply include pulling requests to fix and reinsert into the DevSecOps pipeline. That’s all well and good, but preventing security defects from creeping into code and configuration is also about improving process and culture. 3) Again, not truly applying DevSecOps is a concern. As well, often organizations are too quick to adopt new technologies without knowing the potential impacts due to the many unknowns. Combined with this is the fact that many of the tools that are relied on traditionally take some time to catch up. A good example of this is vulnerability scanning for containers. There are a few tools out there, but most of them are not very good.

The Term "DevSecOps"

• I worry about it being a buzzword like "Scrum,” and “DevOps.” Focus on what the umbrella term means in term of practices. This is a process that will never be done and you cannot buy off the shelf.
• It sounds like a buzzword but I also see people embracing it. DevSecOps is in the middle ages of what we have seen in the DevOps world. Stay with it and make what they can out of it.
• I wish it wasn’t a buzzword. DevSecOps needs to be genuinely put into practice by larger companies. Legacy enterprise is slow to change. Gartner gets people excited but it takes a long time to be implemented in large enterprises.
• Some still think it’s a myth. It should just be "DevOps" with security as part of the methodology.

It’s Early/Change

• DevOps is going super mainstream, but automated security is only being done by a select group of advanced companies (5%). DevSecOps is where DevOps was five to seven years ago.
• Fear of being transparent with others within the company. Gartner survey in using DevOps collaborating with the security teams. I think it’s getting better but it’s still scary. There is some resistance to making a mistake, involving others, and asking for help. There are persistent staffing shortages with a real lack of developers with security knowledge.
• Both K8s and the Istio service mesh are relatively new technologies. There is confusion about the capabilities and the native security features offered. There is a learning curve. Vendors need to help educate about security is going to require a lot more work, knowledge, and tools to automate. Istio is 10X more complex than K8s. Istio sells getting microservices deployed in a relatively easy to digest manner but it’s very complex to get started, to secure it, and maintain. It’s an expertise that doesn’t exist.
• Organizations started at DevOps and now understand security is an important piece of their DevOps journey, maturing their processes to support DevSecOps. As the processes mature and more investments are made into integrating security as part of the DevOps value chain, security will get better integrated and mature for the teams and increase the confidence of brands and customers in software applications.
• DevSecOps is still in its infancy. The concern I have as a consumer is I have to put my trust in all the businesses that they’re going to do the right thing. More do not do the right thing than do. Until people take it more seriously, problems will continue to grow.
• The DevSecOps space is still very immature—just a small percentage of DevOps teams have moved to DevSecOps. Formulating a strategy that moves security at the speed of business is not only possible but can be facilitated by platforms that currently exist in the marketplace.

Other

• Yes, it doesn’t cover 100% of development within the enterprise, the tools are costly, and there is not enough expertise. Separately, security tools are not automated, thus it requires manual review.
• Go back to the value stream side. When people think DevOps, they think the more automated the process is, the more DevOps you are. You really need to sync operations with the development process with the release process with a threat model for every feature. Don’t get stuck on the idea that it’s only automation. Automate whatever you can incorporate the tools for automated scanning, do pen testing as part of the process. The product is continuously evolving, there is no end, so continuously do DevSecOps.
• Our data has no security or integrity at its core, yet it is increasingly important in our economy. We’re in an application first world and we need to move to a data first world. We create data silos and security risks by being application first.
• Unfortunately, traditional security solutions such as next-generation firewalls and endpoint security lack adequate visibility into containerized environments – they are functionally blind to container attacks, and it’s not possible to configure these tools to be container-aware. Because of this, teams implementing DevSecOps must take care in ensuring the solutions they have in place and may be accustomed to are truly capable of the task at hand.
• Not all developers are educated on security best practices. Colleges and universities are not “required” to teach such classes. And, companies are not allocating resources to train the staffs.
• The security folks aren’t always included because “everything-as-code” can alienate security experts who come from the legacy IT side of the house. We need a way to bridge that gap because the security teams have knowledge and skills that must be applied to this new world. Without that bridge, we risk making the same security mistakes all over again.
• The lack of adequate data protection in containers should be concerning. While there are initiatives and plenty has been written about the security shortcomings, actual product solutions are few. Containers and DevOps are consistently mentioned together. DevOps employs containers and container use typically means there’s a DevOps environment. In addition, leaving the data center further complicates the challenge. The edge is another environment to watch. IoT data is quickly becoming a key data contributor in DevOps deployments. And containers can exist on a device as simple as an IoT Gateway.

Here's who provided their insights: