Building Security Tools is the Wrong Approach

As a company, we are working on what is traditionally called finding ‘product market fit’, a stage in product management where you understand a critical ‘gunshot to the chest problem’ that people will pay you to solve, and then build a product that meets those needs.

After reviewing countless interviews, diving into ongoing feedback, and drinking my fair share of Belgian beers, I have become convinced that if you are building security tools then you are doing it wrong. I had previously thought this may not be the case but I was wrong.

We have historically had three phases of appsec tools. 

The first was when the tools were run by the security team. I did this, nursing overnight Fortify runs after weeks of trying to get code to compile so I was able to have that pleasure. Even in the age of waterfall development, there was no way you could get a development team to take on that burden, yet alone filter out 95% of crap findings. That is before we even mention that back then, many security teams acted like the police and sometimes didn’t even want developers to know about the holes in their own code. I faced that many times as a consultant in the mid 00’s.

During this period, looking at the big picture, we had almost no adoption of security tools, and as a result a negligible effect on the state of software security. 

As tools got more accurate and got faster, we moved into a second phase, where it was possible, still not the norm but possible, to put security tools in front of developers. The security champions in development teams sometimes took up the challenge, but in truth it was still few and far between, and as a result, still a small  incremental improvement on what we had seen before. Again, in the big picture we saw a relatively negligible effect on the overall state of software security. 

Things have looked up recently. It's not the shift left rhetoric which is based on myth, but the improvement in the speed and approach of modern SAST tools that allow them to be run inline of DevOps pipelines. 

Phase one was when there was so much friction you couldn't even give them to developers. Phase two was when you could give them to some developers but the friction was still unacceptable and phase three was when you didn't need to give them to developers because friction had reduced and they could, the key word being ‘could’, form part of the developer tool chain. 

Phase three has resulted in a meaningful effect on software security, but the reality is, especially when you consider the relative, previous levels of adoption, that we are still at a level when the effect on the big picture is relatively small,  so the question is what can we do about it.

Well we don’t need more bloody appsec tools for a start, but we can look at the adoption of SCA. For a long time, I have said that Github and probably AWS when they decide to run in the developer tools space, will become the dominant choice for security tools. When we look at SCA and particularly Dependabot, we see that the widespread adoption has been because it is mainly designed, deployed and positioned as a developer tool that automatically updates dependencies. It solves dependency hell and just so happens as a side effect to solve the vulnerable library security problem.

What this means is that if we are to get true mass adoption of tools that can significantly improve security, they will have to be tools that first and foremost solve a ‘gunshot to the chest’ problem for software developers, and then solve a ‘gunshot to the chest’ problem for security teams as a side effect as well. Just reducing friction is not enough.

This is of course far more complicated for security startups and far easier for developer tools companies who have many opportunities. We have tools like Playwright that are natural hosts for DAST, and tools like ESLint that are natural hosts for SAST. Check this out.  

I have had a personal revelation. If we want mass adoption of security technology and to have a truly meaningful impact on the state of software security, we have to stop building security tools and start building developer tools that have security features.