Don’t build security tools, build developer tools instead

This post originally appeared on CSO Online, on November 3rd, 2017.

Application security leaders and vendors have long been chasing the elusive goal of getting developers to embrace security. This desire is partly driven by the value of building in security, but the main cause is sheer volume and pace. Developers outnumber security people 100 to 1, and the speed of modern development makes it impossible for any external team to keep up. And yet, time after time, we fail to achieve this goal.

Security solutions integrate with development tools, security needs get added to the regular requirement flow, and security training gets repeated quarterly, and yet security is forgotten the moment the security team stops being involved. How can we break this cycle?

The path to success is to stop building security tools that think about dev, and start building dev tools that handle security. This may appear like a semantic difference, but in fact it overhauls the way we look at security tools and programs.

First, it focuses on the developer’s needs.

When a security team sets a process, it typically starts with their needs. They need to know what the developers are doing, ensure certain controls are applied, and require certain tests to run. Understandably, the process or tools focus heavily on satisfying the security, compliance or governance needs, and on the needs of the security team.

To get true dev engagement, we need to see developers as the most important user of our solution, and think about security and compliance as the supporting functions. How would this security practice help reduce the chance of an outage? How would it improve communication and collaboration across the team? How does it empower more junior developers to take on bigger tasks?

If you can reframe security needs with developer goals in mind, you stand a much better chance of having them fulfilled.

Next, it changes your starting point.

Almost without fail, we try to adapt security practices to the dev workflow. We try to run static analysis in the build process, only to find out it takes too long to fit. We apply this analysis in the IDE but don’t trust developers to dismiss false positives in the results. We alert about a known vulnerability to a developer who isn’t equipped to triage it.

Good developer tools start from the other side. How does the development process work? At what point would this security control provide the most value or be least obtrusive? What are the key requirements to successfully integrate at that point? Armed with answers to this type of questions, you should build your security solution with the right priorities in mind.

These questions may also uncover existing tools in the pipeline that can be used for security process. For instance, on separate episodes of The Secure Developer podcast, the PagerDuty security team discussed using Splunk for security purposes, and Chef Adam Jacobs described how InSpec can help your security posture.

Lastly, it replaces the products you’ll compare yourself to.

Developer tools have evolved dramatically over the last decade, driven by the DevOps revolution and the empowerment of dev. Based on the most successful tools, best practices evolved, ranging from usability to pricing to the importance of documentation.

So instead of comparing your web app firewall to your network firewall, compare it to a successful APM (application performance monitoring) tool. Contrast your App Sec testing tools with linters and code review tools, not network security scanners. These are tools that successfully found their way to the hearts and practices of developers, who now depend on them regularly. If you mimic how such tools work, you’ll easily fit the developer mental model and process.

While my examples focus a bit more on tools than processes, the principle applies to both. Secure development practices would benefit just the same from putting the developer’s needs at the center, starting from the current dev methodologies, and comparing to other practices and processes the engineering team employs. An enforced security practice is constantly at risk of being overlooked, but a development practice, even one that deals with security, can stick around far more naturally.

To get developers bought into security, don’t build security tools. Build developer tools that help security, and see the huge difference in adoption it will make.