Key Criteria for Evaluating Developer Security Toolsv1.0

1. Summary

Software needs to be written, built, and deployed with security in mind. This is true for both the application being created and the activities involved in its creation. In an ideal world, developers would be security engineers also and would build appropriate risk-mitigation features into their software applications, as well as follow appropriate procedures and apply policies to mitigate potential risk. The reality for many organizations, however, is that the urgency for software updates or new software often outweighs the ability to apply appropriate security at every step throughout the development and operation of a software product’s lifecycle.

Expanding the DevOps movement by considering security alongside every development or operational step in an application’s lifecycle, DevSecOps has become as popular a term as DevOps itself. Unfortunately, just as with DevOps, DevSecOps is not a single product or SKU that an organization can procure. There is no “one-size-fits-all” approach. The term itself may be defined differently to take into account the specific needs of an organization or department and touches all people, processes, and tooling across a software development workflow.

One key approach, often the one most associated with the term “DevSecOps,” is the focus on development security tools with a “shift-left” mindset; that is, tools that consider security as early as possible in the software development lifecycle. This mindset involves rapid security education, insights, and direct feedback to developers and engineers early in the development process. We describe this in more detail later.

This Key Criteria report examines the capabilities and trends that decision makers should look for when adopting that shift-left mindset to increase application security and release velocity, while reducing cost and risk.

The report also considers how to evaluate vendors’ capabilities to provide security-related insights, automation, and compliance closer to the developer—earlier in the development workflow—addressing ways to reduce risk while writing code, storing code, and deploying it across process and pipeline. Among our findings:

• Development security tooling reduces risk and increases developer velocity by applying and enforcing “shift-left” security practices.
• Developer security tooling automation can close the gap between security engineers and developers without sacrificing development speed.
• Developer security tooling integrates with existing development and operational tools to increase the visibility of security-related events across development, operations, and security teams.
• Developer security tooling delivers value by building on software and architecture (cloud and on-prem) vulnerability scanning, application and infrastructure hardening, and other well-established areas of IT security.

Developer security tools and a “shift-left” mindset are key building blocks for helping enterprises reduce the security risks associated with building and deploying applications. In addition to establishing security as a first-class citizen across the development workflow, this approach offers more traditional enterprises with long-established software development practices a connection point to leading-edge best practices, enabling them to develop and deliver software both quickly and in compliance with organizational policies.