7 most common ways to fail at DevSecOps

DevSecOps initiatives are fraught with peril and require careful consideration of culture, learning, process and business needs. Here's how companies tend to fail in those areas.

Missed target arrows bullseye
Thinkstock

Organizations adopt DevSecOps for a variety of reasons: to enable digital transformation projects, deliver value faster, gain a competitive advantage, lower the cost of security remediations, and more. Despite the rush to adoption, organizations sometimes fail with their DevSecOps initiatives, and the reasons for those failures are avoidable. Here are the most common causes for DevSecOps efforts to fail.

1. Failure to establish a learning culture

A recent report from McKinsey identified that talent and cultural issues pose the greatest challenge to technology transformations, which includes DevSecOps. Organizations that embrace a culture of continuous learning and experimentation, then, will be more successful with DevSecOps. The seminal work “The DevOps Handbook” emphasizes that to be successful with DevSecOps and building on the success of high-performing organizations, a learning culture is key.

This is facilitated through daily learning, reserving time for organizational learning and improvement, and a concentrated investment in upskilling the workforce. This can be accomplished with investments in learning subscriptions, tuition assistance, and certification reimbursement. Brown bag sessions where subject matter experts from inside and outside the organization share expertise and lessons learned are also effective.

2. Neglecting cross-functional education

There is an often unspoken but widely recognized tension between development and security teams. Building on the need for learning, cross-functional education must be pursued as part of a broader imperative to break down silos and relieve that tension.

The 2020 FOSS Contributor Survey conducted by The Linux Foundation and Harvard’s Laboratory for Innovation Science found that the average free and open-source software (FOSS) developer spends only 2.3% of their time improving the security of their code. They use terms such as “soul-withering” to describe secure coding and security. In a time where organizations are looking to “shift security left," developers are in a prime position to mitigate security vulnerabilities before commits and production promotion and they must understand the organizational value of secure coding and be incentivized to pursue it.

On the flip side, we are finding ourselves in environments where everything is becoming code. From application code, infrastructure-as-code (IaC)/compliance-as-code, Kubernetes manifests and continuous integration/continuous delivery (CI/CD) pipeline YAML templates, code is everywhere. Security professionals do not need to be excellent developers, but they should understand coding practices at a high level and be able to review templates for common misconfigurations and vulnerabilities. This would also improve collaboration and common ground between the two groups.

3. Neglecting to communicate business value

Any endeavor, including DevSecOps, should be tied to key business objectives and goals. DevSecOps is a transformational journey that requires buy-in and engagement from critical stakeholders across the organization.

For this reason, it is critical to communicate the business value of DevSecOps. Senior leadership must clearly understand the “why” of pursuing DevSecOps. One of the most effective ways to do this is through metrics. Many are familiar with the DevOps Research and Assessment (DORA) metrics from the popular book “Accelerate,” but that is just a start. Organizations can, and should, use additional metrics as well. As Bill Nichols from the Carnegie Mellon Software Engineering Institute (SEI) states, “measurements must be accessible, available and related to business goals.”

Communicating the business value of DevSecOps adoption and using metrics to support it can go a long way in securing support from key stakeholders and executive leadership within your organization.

4. Being too risk averse; fearing failure

Again, high-performing organizations and teams successfully adopting DevSecOps embrace a culture of learning. The antithesis of this is being too risk adverse and fearing failure. Failure is a natural byproduct of the learning process.

If your teams and staff are not in a position where they can make mistakes, learn lessons, and iterate to correct failures, the chances of successfully adopting DevSecOps are slim. Teams must be empowered to learn, identify their weaknesses, build on them, and improve in competencies. This only happens in an environment built on transparency, safety, and trust.

Another way to be overly risk averse is allowing security to be the primary point of friction with DevSecOps implementations. A common complaint about security in environments implementing DevSecOps is that it is too cumbersome and slows down innovation and delivery. This complaint is not entirely without merit. Organizations must find ways to implement security with as little friction as possible. This is done by integrating with developer workflows, embedding security subject matter experts with development teams, establishing security champions among development, and, as discussed below, embracing a culture of security across the organization.

5. Tool sprawl and fragmentation

The increased pace of digital transformation and innovation is spurring rapid growth of the cloud-native landscape. That growth provides a vast and rich selection of tools and applications to help facilitate organizations' DevSecOps goals. However, that rapid proliferation of tooling also creates a more complex and disjointed environment for many organizations. Look no further than the most recent Cloud Native Computing Foundation (CNCF) landscape to get an idea of how diverse this landscape has become.

hughes landscape big Cloud Native Computing Foundation

CNCF Cloud Native Interactive Landscape 2021

Organizations run into challenges around visibility and productivity due to toolchain sprawl. They are also seeking to embrace toolchain management options to get a handle on the sprawl and the associated inefficiencies it is causing.

These issues are not isolated to DevOps. Security is also encountering its own challenges associated with tool sprawl. The 2020 Cloud Security Alliance (CSA)  “Cloud-Based Intelligent Ecosystems” findings show that most organizations are struggling with identifying how well their security tooling is working, if it is generating value ROI, and that their teams are struggling to even keep up with the tools in their environments.

In a rapidly dynamic and evolving IT ecosystem like we find ourselves in, tool sprawl and fragmentation are real threats. They impact visibility, productivity, and most importantly, security. Threats continue to proliferate and if your organizations lack real visibility and control, you are certainly at risk and you do not even know it.

6. Weak security culture

Organizations and the industry simply do not have enough security professionals. The ISC2 2020 Cybersecurity Workforce study identified a global shortage of 3.12 million cybersecurity professionals.

Security professionals are outnumbered at organizations compared to their development and operations counterparts. Couple that with the reality that developers are in a key position to mitigate security concerns earlier in the software development lifecycle (SDLC) and operations teams are primed to identify operational anomalies and it must be a team effort.

Establishing a security culture starts with the realization that security is the responsibility of everyone involved. Communication and awareness of the primary security concerns and principles can also go a long way.  Security teams and staff must shift from being seen as the office of “no” and instead viewed as a collaborative partner that can help achieve shared outcomes, while integrating key security requirements throughout those endeavors.

7. Thinking you can “buy” DevSecOps

Many organizations mistakenly begin their pursuit of DevSecOps through the lens that you can simply “buy” DevSecOps. For example, “If we implement CI/CD pipelines, we are doing DevSecOps.” This is not true.

DevSecOps is a methodology, one that is facilitated through people, processes and technology, with the first two potentially being even more important than the last. Without making the effort to implement a culture aligned with agile and DevSecOps principles, it is unlikely you will see a successful DevSecOps implementation to maturity.

The same can be said for failing to update and implement new organizational processes aligned with said principles and practices. Forcing old operating models into modern technologies and practices simply lead to confusion, inefficiency, and frustration across the organization. This will be present among the teams striving to facilitate DevSecOps and the leadership anticipating key business outcomes tied to a successful DevSecOps implementation. 

Implementing DevSecOps is no easy task. That said, when done correctly, patiently while focusing on key competencies, it can reap tremendous benefits for organizations. Not only is there potential for increased rates of delivery, responsiveness to user and market demand and competitive advantage, but DevSecOps can mitigate vulnerabilities sooner, cheaper, and far more efficiently than traditional methods.

Related:

Copyright © 2021 IDG Communications, Inc.

How to choose a SIEM solution: 11 key features and considerations