- 4 mins
The number of tools for performing various application security tests is increasing at a very rapid rate. We’ve gone from the big players: Fortify, Checkmarx, AppScan, Burp Suite, NTO/Rapid 7 to many more such as SemGrep, Invicti, Snyk, Oxeye, BLST, APISec, etc. etc. etc.
The list is really growing and growing very rapidly. And that doesn’t even include WhiteHat, Veracode, and numerous open-source tools that can be leveraged. There are similar increases in the software composition analysis (SCA) space or the interactive application security testing (IAST) space.
More Choices Don’t Lead to Better Pricing
Supply and demand tells us that more choices results in better prices. At least, that’s the theory. The challenge with application security (and most security products) is that vendor lock-in tends to happen. While there are options like Defect Dojo and leveraging JIRA for managing findings, there are complications when switching tools because there is no simple import and export.
This lack of importing and exporting means there is work analyzing the differences between the scans. It is highly likely that any new tool will have different scanning capabilities and will need training. It is necessary to run both products for a time and analyze these differences. It will also be necessary to rework any automation and integrations that were done.
Most vendors focus on the enterprise business and price their services accordingly. Those in the small to mid-size market tend to get priced out or there are limitations on licensing that make it harder to integrate.
Scanners Aren’t Created Equally
Scanners have different strengths and weaknesses. The capabilities for discovering (both in coverage of the application scanned and types of findings) will be different. Some scan different languages better. Some handle different architectures better. Some have better incremental capabilities. Some are better at full scans. There are going to be tradeoffs based on architecture, performance, and a significant number of other variables. These variables don’t even take into account pipeline configurations, custom code management, and the on-premise vs Software as a Service (Saas) solutions.
Tool Selection as A Barrier
Selecting the right tool isn’t easy. There are the obvious variables at play - technologies supported, ease of use, configuration capabilities, and price. There’s also the not-so-subtle ones like integrations, reporting capabilities, data exporting, performance, and collaboration features.
It would be one thing to manage to test these in a small tool bake off, but as the toolset increases, the number of tests and time to complete the bake-off increases. For organizations without enough engineering support, this almost becomes a “pick and cross your fingers for success” method. Or, let’s just get something good enough.
Licensing Confusion
Most of the tools out there now are offering three-tiered licensing models. There is a free version, a team version, and an enterprise version. The theory is that some new software company will use the “free” version. A small business will use the “team” version, and of course, the larger enterprise will call in work with a salesperson and get the complete solution.
While there are more tools offering multiple testing technologies and being a single platform, most are still really only strong at one type. This means that to support an application security program, a company needs to manage licenses for different tools, and this can get costly even for that middle option of “teams” license.
The Real Cost
Imagine a company that has 50 developers. The company has a static analysis testing tool, a source composition analysis tool, and a dynamic scanner. Hypothetically, say the “teams” model of tool in each testing technology is chosen provides the necessary features for $25/month per developer. $45,000 a year.
That $45,000 doesn’t sound too bad. Except, there’s still engineering costs. The costs of figuring out the best tool, managing the tools, configuring pipelines, the scans, and reviewing the results all. Of course, that is better than not doing scans or ignoring results.
The next question is who is doing that work? In a small company, architects and senior developers can pitch in, which takes away from the actual product development. Or, this company can hire an application security architect to manage the program and set up a security champion program. The average salary for an application security architect is $150,000 (not including any benefits, bonus, stock, etc.). And that number is probably on the very lower end based on what we have seen in the market.
Where Do We Go from Here?
For some companies, managing the application security assurance platform in house makes sense. The amount of dollars spent on tooling and people to manage the platform is small in comparison to the revenue dollars. For other companies, that math might not make sense.
What can those companies do? One option would be to rely on independent industry leaders to provide technology analysis of the tool vendors. What works best for what technology. They need to be able to leverage external resources to recommend tools to the software security pipeline, assist in negotiations for purchase of tools, and potentially even own the pipeline.
If you would like to find out how True Positives can help your company solve this complex juggling act, please contact us to get a free 1-1 appsec consultation.
