Key Criteria for Evaluating Development Security Solutionsv2.0

An Evaluation Guide for Technology Decision-Makers

Table of Contents

  1. Summary
  2. Development Security Tool Primer
  3. Report Methodology
  4. Decision Criteria Analysis
  5. Evaluation Metrics
  6. Key Criteria: Impact Analysis
  7. Analyst’s Take
  8. About Don MacVittie


Development security solutions help development and security teams detect code vulnerabilities earlier and resolve them faster; they’re useful to any development environment, no matter the methodologies applied.

In our first iteration of this report published in 2021, development operations (DevOps) and security were still learning to get along after a historically rocky start. Since that version was released, the sector has settled into several areas of focus, and development security has become central in the DevOps market. This report will discuss development security solutions. The other topics that were discussed in version 1.0 of this report have either been moved to their own reports as their importance became better recognized by the market, or become features in other solutions as they settled into their correct market segments.

Security testing of code and included libraries have always been an issue in software development. Not only is security testing of code a time-consuming endeavor, but generally, developers do not write insecure code on purpose, so they’re not who should be testing the code for security issues. That task is best left to test tools and test teams. However, there have never been enough security analysts to adequately perform security testing on applications, and many security analysts don’t have a broad background in development or don’t have experience with the tools at hand.

The point of development security solutions is to offer easy ways for developers and others to integrate security testing and resolution into the code they are writing or deploying. These tools offer code-centric security at every step of the software development lifecycle (SDLC). From plug-ins for integrated development environments (IDEs) to runtime monitoring, the best of these tools try to shift security left while protecting what is deployed.

These tools generally offer automation, security guidance, and even enforcement at each step: from the period during which the code is being developed to the point when it is integrated to the time when the final product is produced, and even as the final product is running. The idea is to catch development errors immediately, as well as to find any issues caused by integration at build time and any runtime issues before the code goes into production.

There should be additional checks performed while protecting application code in production, though this depends upon the nature of the security issue; zero-day issues, for example, cannot by definition be detected before deployment. The earlier an issue can be detected in the SDLC, the fewer changes are required in the code to resolve it. The simplest case is a defect detected while code is being written. Flagging insecure code while the offending lines are being laid down means that the amount of code that has to change is just what is currently being written, and the developer’s mind is focused on that code. If instead, vulnerabilities are flagged once the application is in production, the developer has already moved onto something else, and the insecure code is now part of an entire environment that could require widespread modification based upon the changes to the problem source.

In the end, detecting vulnerabilities earlier and resolving them faster is what these tools are all about. Elevating security into the mindset of developers and the toolsets of DevOps is part of achieving that goal. Automating security scanning and testing is also core to these applications, as manual testing has never been able to keep up with software development, and in an agile environment that is at least doubly true.

The GigaOm Key Criteria and Radar reports provide an overview of the development security tool market, identify capabilities (table stakes, key criteria, and emerging technology) and evaluation metrics for selecting a development security product suite, and detail vendors and products that excel. These reports give prospective buyers an overview of the top vendors in this sector and help information technology (IT) decision-makers evaluate solutions and decide where to invest.

How to Read this Report

This GigaOm report is one of a series of documents that helps IT organizations assess competing solutions in the context of well-defined features and criteria. For a fuller understanding, consider reviewing the following reports:

Key Criteria report: A detailed market sector analysis that assesses the impact that key product features and criteria have on top-line solution characteristics—such as scalability, performance, and TCO—that drive purchase decisions.

GigaOm Radar report: A forward-looking analysis that plots the relative value and progression of vendor solutions along multiple axes based on strategy and execution. The Radar report includes a breakdown of each vendor’s offering in the sector.

Solution Profile: An in-depth vendor analysis that builds on the framework developed in the Key Criteria and Radar reports to assess a company’s engagement within a technology sector. This analysis includes forward-looking guidance around both strategy and product.

Full content available to GigaOm Subscribers.

Sign Up For Free