Security Tools Can't Just Be Friction Free. Was SCA the Tipping Point?

As always, you can subscribe to our newsletter at www.crashoverride.com. This article is cross-posted here on Linkedin for comments and discussions. 

Common thinking has always been that if you want to get developers to lead the adoption of security tools then you need to make them as easy as possible to implement and use. It is what is usually referred to as being ‘friction free’.

A few weeks ago I wrote an article ‘Developers Only Pay Lip Service to Security. Get Over It.’ in which I restated this, with a twist. 

I have found that ALL developers will always do the right thing if

1) It's easy.

2) It doesn’t get in their way.

3) It doesn't give them more work.

Better still ALL developers will do the right thing if

4) It solves a problem that they have.

The frictionless part is of course items 1, 2 and 3. After publishing that article, a few CSO’s messaged me, saying that in their experience that is increasingly no longer enough. Today it must include 4, solving a problem that developers themselves have. Before someone suggests it in the comments, that is not getting security off their backs. 

I started speaking to a number of engineering leaders that I trust and what I am learning is that frictionless security tools are now table stakes. If you aren’t friction free then you are stalled out of the gate, and it is no longer a differentiating factor in trials and sales. People told me that a lot of tools that claim to be friction free aren’t but that’s another topic 

There seems to have been a tipping point when companies deployed Software Composition Analysis or SCA. SCA is deployed in almost every developer pipeline and baked into Github in the form of Dependabot. What is interesting is that Dependabot didn't start life as a security tool, it started life as Bump, an application, created by GoCardless in 2015 which helped keep project dependencies up to date. It was an application that first solved a developer problem dealing with dependency hell, and then built in the feature to solve the security problem of identifying vulnerable libraries. 

We learned this lesson the other way around at SourceClear when we initially struggled to get the tool deployed in developers pipelines. We had a call graph so could tell what methods were being called which reduced false positives and therefore friction by 95% in most cases, but it was only when we used that and our backend that knew which tracked all library releases, did we see developers installing it and using it to fix dependency hell, specifically using that call graph to know which upgrades may case issues.

So if SCA was the tipping point that led to a security tool being adopted wide and fast, why have other DevSecOps tools not taken the same approach? I can’t figure it out. I think it's true that for the most part they would need to integrate back into the developer tools rather than add developer features to their security tools but it's the same thing.  

Let’s take VSCode. According to Statistica, via a ZDNet article, VSCode has 14 million users. The extensions marketplace is definitely not returning accurate results, I know some security plugs that are not showing up, but to illustrate the issues, search SAST and there are just 10 extensions. The search returns 11 but one is to record security notes during a code review, supporting importing SemGrep results, a truly brilliant idea. Synopsys has the highest downloads with 11k. I don’t know how this works, maybe you pull in the extension from a private server but if not that is 11,000 / 14,000,000,000  = 0.00078571428 % of developers.

All this while Prettier, the code formatter has 32 million downloads and even has a plugin interface. I have no idea if you could write a SAST plugin to Prettier but it parses all the code, presents developers and automatically fixes code format issues and so I am surprised Google doesn’t seem to know if someone has tried. 

Surely there are lots of opportunities. Cloud formation has 298 results, Git 1204 and Java has 4029. Maybe we will even see security plugins to ChatGPT plugins.