Security remains a top DevOps initiative. As cloud migration continues, IT teams are well aware of how this vastly expands their attack surface and opens the door to more security vulnerabilities. Further increasing the risk is the rise of remote and dispersed workers. For organizations undergoing a DevOps journey, a shift-left mindset is essential when it comes to security. 

IT organizations need to incorporate tools and automation throughout the entire software delivery pipeline to identify threats and vulnerabilities as early and often as possible. However, the technical aspect is just one piece of the DevSecOps puzzle. We also must consider how humans factor into DevSecOps. 

Listen to: Humans of DevOps – [EP93] The Importance of Humans in Cybersecurity with Brian Smith

Recently DevOps Institute CEO, Jayne Groll, addressed this in Enterpriser’s Project, “Automation is a necessary element, but organizations cannot buy their way into DevSecOps without human acceptance of their personal responsibility for security. Shift-left is as much a human initiative as a technical one.”

We decided to extend this topic to the DevOps Institute Ambassadors to see if they agree that the obstacles to DevSecOps are as much human as they are technical. Here’s what they said:

“I tend to agree. The problem that DevSecOps is trying to solve is the friction that exists in a value stream if product enhancements aren’t meeting security standards. It causes vulnerabilities to appear as defects that need remediation – or if they need to wait for security testing to support them at the end of their development cycle. The worst-case scenario is when vulnerabilities result in a breach and require a number of people to effectively down tools and process the resultant unplanned work. To solve this, both security and development people need to align expectations and practices at the level of the organization’s risk type, likely requiring them to modify their way of working, collaborate closely and learn from one another. To expedite this, tools can be used to automate the heavy lifting for the value stream team through ensuring standards are met (checklists) and providing pre-blessed libraries of code artifacts.” – Helen Beal, Chief Ambassador, DevOps Institute

“Agree completely. The humans of the DevSecOps movement include both operational teams and developers. Developers often have been missing from this conversation. While developers may consider security as important, and look at implementing scanning tools, they often do not consider good security practices in the one-off build and release scripts they create. One-off scripts are difficult to secure and often touch high-vulnerability assets, like production. Let us not forget the end-user either. Users need more help understanding the important role they play. From avoiding phishing emails, to better managing their user IDs and passwords, users can be a weak link in the security chain. Humans from developers to end-users, and everyone in between, will need to take security much more seriously today and in the future.” – Tracy Ragan, CEO and Co-Founder, DeployHub

“Totally agree! A cultural shift is required as well as the challenging task of recruiting multi-talented people. Developers/engineers want to move fast, use the latest libraries, etc. Security wants to analyze all attack vectors of all versions of this. Ops like stability and availability in a traditional sense. All have different goals and objectives. 

Let’s expand the well-known ‘you built it, you run it,’ saying to ‘you build it securely and you run it securely.’ Combined goals, aims and accountability build a DevSecOps culture. – Ryan Sheldrake, Field CTO, Lacework 

“I agree in a way. Technology evolves faster than legislation – take Uber or Bolt services for example, or Revolut before that company got a bank license. As far as I know, those services were existing somehow outside of the legislation construct, and by that, there were no rules as to how to approach the whole situation from a legal point of view. Also, what we should keep in mind – security does not go well with tight schedules. Security needs time to be reviewed thoroughly, twice or thrice or more, just in case. Otherwise, shenanigans might ensue.” – Maciek Jarosz, DevOps and Process Expert, Business Practitioner

“Completely agree. DevOps is a cultural problem not a technical one. Technical solutions accelerate delivery and expedite processes, but without a culture to support the technology, one is simply left with all the old problems. Companies try to transform and expect buying technology is a quick solution. However, when the company still uses multiple levels of change management, lacks shared baseline environments for dev, test and prod, and cannot commit to organization-wide visibility, they cannot simply apply a technical fix. These are cultural issues that must be solved slowly, from a bottom-up and top-down perspective. Teams must commit to the culture and management must accept a loss of control over basic functions mitigated by increased observability. Sometimes, teams make a quick change, and everyone buys in for the first six months, then problems start to occur and they too often return to old administrative solutions rather than committing to the new culture and process. Spurred by continuous learning, DevOps is a constant change that must be reinforced daily at multiple organizational levels.” – Mark Peters, Technical Lead, Novetta

“Yes, indeed it’s both the human behavior as well as technical factors that create obstacles to DevSecOps culture. It requires delivery teams – developer, security, and IT operations teams willing to share their expertise and work in a cross-functional manner. The stakeholders in leadership roles can help understand the business impact otherwise and make sure that everyone takes security into consideration. In such an environment, developers will be more likely to ask their security counterparts for advice, and security teams will be more likely to give it.” – Parveen Kr. Arora, co-founder and director, VVnT Foundation

“I VERY strongly agree. The fact we have had to create a term called DevSecOps, after DevOps, shows the human issue. We have read too much into the term DevOps and immediately assumed it is just about development and operations, more often with development pushing the case. Security, business and all other elements of an enterprise should always have been included, but they were not. This is purely a human thing. It is a hangover of our tribalistic nature to create small groups within a large group and become protective of it. The inclusion, or non-inclusion, of security in DevOps, is a result of this. It is only by overcoming our nature of creating sub-cultures within a culture that are defensive of each other, and instead be collaborative, that we can truly include security as part of our delivery and supporting practices.  – Stephen Walters, Field CTO, CEM Digital

“In some ways, humans are more of an obstacle. There is lots of technology available to make systems more secure, the challenge is getting humans to use it or change their behaviors around how they manage security. A typical challenge is moving responsibilities (like vulnerability scanning, managing networks and firewalls or access management) from a siloed security team into the product team. We know this enables the teams to work quicker and improves security but, it requires humans to collaborate and trust each other to make those sorts of changes, and that doesn’t happen overnight.” – Craig Cook, Principal Engineer, Catapult CX

“Absolutely agree. Traditionally, Security was that all-powerful team sitting in their Castle, who would surface out at the time of a release and ‘bless’ the software. Or Not. And then, all hell would break loose. I still remember the days in the early 2000s when I was Build Engineer for a large Enterprise and as part of the Release Checklist, the Release Manager would come out with a BOM (bill of material) and I had to account for every binary (jar, war, config), etc. in his list – the entire process was a nightmare.

And now, with DevSecOps saying that I will automate all this and more through a button click, this is bound to upset the castle, right? Only when put in the right perspective, it’s just enabling the castle and making it more powerful. And getting their skin involved earlier in the game. So yes, it’s all a ‘human problem.’ “ -Savinder Puri, Global Head – Agile, DevSecOps and Cloud platform solutions, Zensar Technologies

“Yes, I agree. Working with so many organizations, I found the first pushback when we discuss DevSecOps is, ‘No thank you we already have a security team and security tools,’ and then I spend the next few meetings explaining what is the difference between DevSecOps and having external security team and why they do not necessarily overlap.

In these discussions, I use two terms, DevSecOps and DevOps + Security, which helps me entertain the idea that first, security is not the sole responsibility of the security team anymore, and second that security should be part of the developers’ key chain.

This mindset change is not always easy, and people involved in the discussion tend to push back as it appears for the developers that you are adding more responsibilities on them and for the security folks that you are taking away part of their core controls, which is not the case.

DevSecOps came to make developers able to build and deliver better quality software with fewer security threats, with the ability to take action on any introduced security vulnerability immediately without waiting for the security team to test and formally report these findings just days before the production goes live. At the same time, it helps the security experts to have better visibility on what is happening across the development cycle and be able to confidently report on the overall security posture of the whole organization at any time. In short, it is a win-win situation.” – Samer Akkoub, Senior Alliances/Channels Solutions Architect (APJ) | GitLab

The verdict is in: the obstacles to DevSecOps are as much human as they are technical.

As organizations aim to improve security, DevOps Institute Ambassadors agree that humans play just as important of a role in DevSecOps transformations as automation. A security-minded culture, visibility and collaboration must be built into every shift-left security strategy to minimize vulnerabilities and respond quickly to threats. 

Learn more about getting certified in DevSecOps