Moving beyond ‘moving left’: The case for developer enablement

Feb 17, 2017 / 3 min read

Table of Contents

Looking beyond the “move left” mentality
Introducing the case for developer enablement
What does developer enablement look like?

The original version of this post was published on SecurityWeek.

For far too long software security has been comprised of a curious bifurcation of roles. Developers develop and IT security testers test for security issues. Fortunately, a confluence of circumstances has forced a recalibration of the developer’s role in software security. In fact, I think we are about to see a new wave of what I call developer enablement.

You have likely heard the rumblings of this evolution expressed as “moving left.” The phrase sprung from the visualization of software development as a left to right progression of tasks, beginning with design and architecture and moving right to deployment.

Looking beyond the “move left” mentality

Unfortunately, moving left falls short of capturing the idea accurately or with any real level of inspiration. With the growing adoption of Agile and CI/CD, the world of development is no longer a straight line, but rather a continuous cycle–one in which there is no “left.”

This outdated metaphor has also proven to be an empty assertion. Vendors claiming to move left do not actually move the actual test nor the process of remediating the test results any deeper into the developer’s world. Instead, they just move the button to launch a test closer to the developer. Therefore, it resolves nothing and does nothing to enable the developer.

While I find “moving left” to be an annoying term, the concept grew out of the belief that identifying vulnerabilities late in the development process–often post build–makes the job of finding and remediating vulnerabilities harder and more time consuming. Asking a developer to go back to a previous build to remediate vulnerabilities is painful. It also affects the development cycle of the current build. As much as we have evolved, developers are still incented to deliver their code on time over and above producing secure code.

Introducing the case for developer enablement

Developer enablement is about giving developers the knowledge and tools to discover vulnerabilities as early in the development process as is practicable. This enables them to reduce remediation time while increasing productivity. Makes sense, right?

The implication for this statement is that a working relationship exists between development and IT security. While this has not always been the case, I get the impression from industry analysts and actual practitioners that this evolution is indeed happening and the pace is accelerating. Organizations are creating software security groups that own the problem. These groups are actively engaging and, in some cases, enabling development.

What does developer enablement look like?

It starts with education. The obvious nirvana state is to teach developers how not to code in vulnerabilities at all. You can employ the standard methods of instructor-led and eLearning. The problem is that developers are notoriously hard to pin down for training. Additionally, the growing millennial workforce resists traditional education methods. Some of the challenges are addressable by breaking courses into “snackable” segments and by giving developers real incentives to take security-related courses.

The best way to educate developers, however, is to teach them practical lessons in real time while they are developing. This is a more evolved form of training. It requires tools that can live in the development environment and spot vulnerabilities in the code while developers are coding or before the build stage. This doubles the level of enablement by identifying actual problems as early as possible and by using the detection as a teachable moment. The developer is alerted to the problem, provided a description of the vulnerability and how it can be exploited, and provided guidance to remediate the problem on the spot.

Boom! That is developer enablement. To summarize in three points:

The lessons take place in real time in a practical setting, facilitating the learning process. The hope is that after repeated exposure to the process the developer stops committing the errors that create the vulnerability.
The developer is empowered to remediate the vulnerability on the spot. This eliminates the need for the highly intrusive pattern of returning to previous builds to fix test findings. Developer enablement has a direct impact by increasing productivity and lowering remediation costs.
The tool collects data on developer behavior, providing insights into repeated issues for one developer or the group. Such patterns indicate the need for education, enabling effective targeting for training that maximizes impact and minimizes interruption.

Continue reading.