Home » Developer Relations » Marketing to Developers » The DevSecOps Tool Buyer’s Journey

Marketing to Developers The DevSecOps Tool Buyer’s Journey

Author Photo

Patrick O'Fallon

July 27, 2017

We live in a constantly evolving and adapting world. DevOps is no stranger to this concept, as it has introduced rapid adaptation, automation, and amplified the pace of software delivery. As a result, DevOps has been a major force to help drive innovation, and has been widely adopted as a methodology of the modern technical world. As quickly as the DevOps revolution continues to move, the need to secure this modern process is paramount to a successful DevOps process. DevOps teams now have the power to make rapid and systemic changes to their software and infrastructure. But rapid and systemic change to critical infrastructure has generally been a risky proposition to those in charge of security. DevSecOps practitioners do not have an easy job ahead of them, but fortunately they are well capable of identifying the vulnerability landscape, and vetting appropriate tools to help streamline their process.

Setting the stage

Today’s DevOps teams are doing amazing things. By leveraging great tools in orchestration, containerization, continuous delivery, continuous integration, and testing automation, developers are able to streamline their infrastructure and optimize delivery of high-quality applications. This leads to the first step of the DevSecOps buyer’s journey—identifying the areas in which to eliminate vulnerabilities. Not every development persona is strong in security vulnerability identification, but many DevOps teams and DevSecOps practitioners can quickly flush out key domains in which to secure their delivery process.

  • Infrastructure is one of the obvious starting points to identify potential vulnerabilities. This could be any architecture, whether cloud, hybrid-cloud, or redundant architectures. For many modern DevSecOps professionals, it is difficult to get the necessary on-demand visibility to Amazon, Azure, and Google Cloud. Security threats that DevSecOps teams would like to see clearly within this domain include risky traffic/port permissions, root account access, unenforced password policies, public visibility of critical infrastructure, non-enforcement of best practices, encryption verification, and backup efficacy, among many other infrastructure-related items.
  • Vulnerable Code is generally the next logical place that DevSecOps teams will try to secure. The good news is that DevOps by its very nature has made vulnerable code much less of a risk through rapid deployment of patching/new releases, rapid rollback to working code, and more effective testing and automation. Yet, DevSecOps professionals need to be ready for unexpected and unplanned vulnerabilities, and there is a need for more visibility and faster incident identification. These two features will be very important to the buyer during this journey.
  • Continuous Integration/Continuous Delivery is another place for DevSecOps teams to identify security risks to their process, even though CI/CD drastically improves the success of the DevSecOps process. Potential security risks in this domain include deployment issues that create rogue objects within the application or the infrastructure, and unplanned/unexpected threats (as discussed earlier). CI/CD both inherently increase the ability to remediate any issue across disparate environments. The DevSecOps practitioner will be looking for a tool to increase the efficacy of the CI/CD process, such as faster issue identification, faster notification, and better visibility into risks and vulnerabilities during or upon delivery of new releases. Then they can leverage their CI/CD process for quick remediation and resolution.

The tool for the job

As the DevSecOps buyer’s journey progresses, these DevOps practitioners need to find the right tools and technologies to assist them in their security strategies. The good news is that DevOps practitioners are already great at finding the right tool for the job. Chances are, they have already built a suite of DevOps tools that have amplified their pace and quality of delivery. This poses a unique challenge/proposition for vendors to stand out, because vendor tools need to not only clearly speak to the challenges of modern DevSecOps practitioners, but if they don’t also prove valuable, they will be quickly eliminated from the tech stack. At this stage of the buyer’s journey, DevSecOps teams are looking for:

  • Better Visibility
  • Faster Issue Identification
  • Integration into modern DevOps tools
  • Ease of Use
  • API Access
  • Automation / Orchestration Capabilities
  • Reduction of Human Interaction in the Process


As an example, DevSecOps practitioners are looking for a dashboard that reports risks and vulnerabilities, and prioritizes these items by issue severity. This makes way for better visibility and faster issue identification.


Lets face it, DevSecOps professionals are developers at their core. Therefore, these tools need to be easy to implement, and need to give them the power to unleash their developer expertise to better secure their critical services. This means API access and the ability to add DevOps methodologies to the process.


Yet even though DevSecOps professionals will be looking for the ability to code their best practice for the tool that they select, these are busy professionals, and there is an expectation of out-of-the-box integration into modern DevOps tools and infrastructures at a fundamental level. Then, they will leverage advanced features when they need them.

The end result

Once the DevSecOps practitioner makes their buying decision, it is critical to discover what factors add to the success of the buying decision. DevSecOps practitioners will weigh their choice in the same way they measure the other tools. They will expect to have a robust vulnerability/threat management framework that accounts for risk mitigation and fits in seamlessly to their current DevOps stack. Also, they will measure the reduction of human-time and resources devoted to management of the DevSecOps process. Lastly, they will ensure that the tool is measurable and testable to verify the effectiveness of the security process. In the event the tool is deemed successful, this can turn into a very sticky relationship for a vendor, and earn some faithful tech evangelists. If not, you can bet that the DevSecOps practitioner will move very rapidly to replace and remediate.