Table of Contents

An efficient DevSecOps transformation relies on two forces to fully unfold: the right tools and the application of a true culture change. DevSecOps enthusiasts advocate that leveraging one without the other will most probably lead to complete failure in the implementation of healthier security practices.

It can seem daunting, confusing, and too huge of a transformation to handle. However, how difficult is it really to carry out DevSecOps practices within a team? What are the pitfalls of a DevSecOps model implementation? I’ll be addressing the obstacles on the sometimes sinuous road to DevSecOps, considering the culture shift required, the toolchain, and the opposition of speed and safety.

Resisting the DevSecOps culture shift

56 percent of survey respondents in the 2021 Upskilling Enterprise DevOps Skills Report state that DevSecOps is a must-have in the automation tool category. However, DevSecOps isn’t solely a collection of tools for the automation of security. It’s a true mindset, an outlook, a mentality - it’s about finding the balance between innovative practices, communication and collaboration, and the prioritization of security across teams.

Because DevSecOps is an equilibrium, it’s common for teams to go off-track along the way, and hit important roadblocks that prevent them from achieving security goals. Learning about these issues from the get-go is one of the keys to DevSecOps success. This brings us to the first obstacle to DevSecOps implementation: when teams don’t welcome the deep culture shift that it represents.

The pre-DevSecOps cultural baggage

Nowadays, an increasing proportion of teams understand that building and automating security throughout the software development cycle is the key to efficient product development. However, the shift to a DevSecOps mindset is easier said than done. It requires teams to alter their outlook on the software development cycle as a whole. Application Security Testing (AST) solutions allow security to become an innate component of development, instead of an added piece, appended once products are more or less completed, towards the end of the product cycle.

It’s no secret that developers and security teams have often been in conflict, historically: developers are traditionally more focused on expediting product development, while security teams address the reduction of constant security risks. This is why teams that only pay attention to the tactical implementation of DevSecOps will most likely fail: the McKinsey annual IT strategy Survey 2021 states that cultural issues pose a great threat to DevSecOps. It is key that enterprises embrace a strong culture of continuous learning and change within the traditional patterns of communication across teams.

Knowledge is power: learning DevSecOps

Breaking down the robust silos between software and security teams is a crucial step for DevSecOps implementation. This can only be achieved through a mindset of understanding the challenges faced by respective counterparts, in an effort to fulfill continuous knowledge acquisition. CISOs must spend a fair amount of time learning about the issues preventing each division from operating with security in mind, first and foremost.

DevSecOps knowledge across teams can ease tension, reduce friction, and harbor the collaborative and collective energy needed for durable implementation. Switching the focus on security calls for keeping communications and outreach channels wide open way beyond the IT team. Not considering DevSecOps as a culture to be shared across whole enterprises, including stakeholders and user communities, could result in failing the implementation of quality, automation, and system stability.

Gates vs Guardrails

In any case, there’s always the discussion of how security mechanisms are implemented. If DevSecOps is to succeed and achieve faster time to market, gates are to be avoided at all costs. Integrating modern software development and security practices demands fewer gates and more guardrails.

The wrong toolchain for DevSecOps

An abundance of tools on the market

DevSecOps implementation comes with an impressive assortment of innovative tools and technologies. Teams diving into it will probably have perused many options such as:

• Static application security testing (SAST)
• Software composition analysis (SCA)
• Interactive application security testing (IAST)
• Dynamic application security testing (DAST)

The possibilities are quasi-endless. So endless in fact that teams are often outfaced by the sheer amount of tools, practices, and protocols available to them. It can be overwhelming, and enterprises might be tempted to be just a little too greedy when selecting their DevSecOps toolchain. This can result in decision fatigue as well as analysis paralysis. Ultimately, the main objective of DevSecOps sometimes ends up omitted: ​​that of catering to the utmost security of the entire software development lifecycle (SDLC) - code analysis, software composition analysis, and run-time security analysis.

Implementing tools without strategy

The tools are out there, and so are the practices and protocols. What’s preventing teams from succeeding in their DevSecOps mindset? Implementing tools without a clear overall strategy for DevSecOps implementation.

Security tools are essential for enabling, unlocking, and automating the full potential of DevSecOps. However, using the right toolsets that integrate wholly with existing environments is key. Security should support development throughout the build, testing, and deployment processes. All tools should be API-enabled to be leveraged by developers in full automation, which also considers all DevSecOps tools as an interoperable whole.

Most importantly, the implementation of DevSecOps tools calls for strategy - and quite a lot of it, at that. This brings us to a quick walkthrough of the different phases of a DevSecOps strategy: plan, code, build, test, release, and deploy.

Plan

DevSecOps’ initial stage, planning, requires a fair amount of collaboration, communication, discussion, strategy, and review. Starting from a thorough security analysis, teams should create an outline of the security testing to come. One of the tools available for DevSecOps planning is IriusRisk, which is a collaborative threat modeling design tool.

Code

The code phase aids developers in writing more secure code, thanks to security practices such as pre-commit hooks, code reviews, and static code analysis.

Build

Once developers commit to the code source repository, the build phase can begin. The corresponding tools gravitate around the automation of security analysis all throughout the product build. Some practices include static application software testing (SAST), software component analysis, and tools which can be hooked up to a CI/CD pipeline for automation of tests.

Test

Testing uses tools such as dynamic application security testing (DAST).

Release

By this point, the executable and application code will have been deeply tested, so the release phase simply secures the runtime environment infrastructure, using the principle of least privilege (PoLP) for example.

Deploy

Security concerns during deployment are those which occur against the live production system, monitored by validating Production TLS and DRM certificates.

Speed over safety: focusing on time to market

I love data because data don’t lie: DevSecOps is gaining popularity at a soaring rate. Though tech leaders are increasingly turning towards DevSecOps practices, the pre-DevSecOps mindset has conditioned teams to prioritize speed over safety and quality. Deploying products out into the market is a crucial aspect of the development cycle, though it shouldn’t be a reason to sacrifice security. When time to market is the primary concern, strategic DevSecOps mistakes happen, like skipping penetration testing. The end result is the slowing down of product lifecycle time - if you’re not testing, you have no idea where your product’s vulnerabilities are, the very vulnerabilities that will pop up at some point if left unfixed.

Acceptance vs integration of security

There’s a difference between accepting and integrating security. The latter happens when DevSecOps tools and processes are accepted without ever being discussed within teams. A given change is implemented without full collaboration and communication around the culture and mindset of DevSecOps. This goes against the very essence of DevSecOps, which is a complete transformation, rather than a hard stop. It’s an incentive to collaborate and make security a process connected to all steps throughout the development cycle. Security must be integrated across teams, not simply accepted.

Disrupting the engineer workflow

DevSecOps aims to reduce friction during the process of breaking down silos. However, the opposite effect sometimes happens, when the new tools introduced into the pipeline end up disrupting the existing engineer workflow. It’s important to bring in security control one process at a time, to allow maximum potential success rate, and give an opportunity to adapt across teams. CISOs should monitor how well teams are coping with the changes, especially engineers, whose starting point for security processes should be existing tools. The cultural transformation represented by DevSecOps isn’t immediate: it is durable, strong, and takes time.

The bottom line

Enthusiasts may present DevSecOps as revolutionary, but truly implementing it across teams is quite the opposite. It is a long, thorough process. Introducing a mindset that goes from “us VS them” to effective collaboration, communication, and monitoring is a tough task. Many meet obstacles down the road and make mistakes that cost time and resources.

That’s why it’s important to introduce security from the start of the pipeline, and to ensure every team member, from IT to leadership and developers, shares the responsibility for security practices. Security tools, processes, and controls should be integrated throughout the workflow, enabling automated security checks at every single step of software development and delivery. After all, maybe DevSecOps is a journey, not an end-goal…