Security tools are a commodity. True Positives provided a great primer on the testing strategies. New tools are popping up regularly. Sites like Latio Tech have built a reputation on tracking them and splitting out their purpose. Trying to keep up with new tools, like keeping up with the latest developer frameworks, can be a full time job in and of itself.
While tools are popping up like weeds, they each still have a built in moat.
On the surface, security tools appear to have reached a state of commoditization. Vendors offer an array of products with overlapping features, all promising to catch the vulnerabilities lurking in your code. The devil, however, is in the details. Each one of these tools has their own unique blends of support, capabilities, and integrations.
It’s these complexities that create the moat—an ever-widening chasm between the tool you’re using and the tool you might consider using. Once a tool has been integrated into your Continuous Integration/Continuous Deployment (CI/CD) pipeline, it’s not just a piece of software; it’s a critical component of your entire development process.
Language and Framework Support
You can almost guarantee most tools will cover the main specific languages that are popular. And for the most part, most tools are pretty good at quickly adding newer language support — if there is enough demand for it. That said, though, there are cases where different frameworks in that language may not be supported by some tools. It also doesn’t have to be just language and framework. Even certain architectures can cause challenges. In the early days of web applications, DAST tools could easily crawl sites. Once Single Paged Applications (SPAs) became popular, some DAST tools struggled. Another example is authentication mechanisms. Some do better than others.
Vulnerability Classes and Recommendations
Identifying vulnerabilities and providing recommendations is the primary objective. All tools will have effectively the same capabilities here. Some will be better at identifying some vulnerabilities and not as effective at others. Some tools will offer the capability of custom rules. Migrating in and out of tools with custom rules overhauls the capabilities of a software security pipeline. Remediation guidance will also vary. Some will have more language examples than others. Some will provide specific guidance based on the language and frameworks used. While the variance may be slight, it is a key factor when selecting tools.
At their basic level, nearly all scanning tools are rules engines
Scanning Engines
At their basic level, nearly all scanning tools are rules engines that evaluates reviews the software in one of its states. It either is reviewing the code (custom code or dependencies), the memory, the runtime, or the interface to the consumer. The processor which does the reviews vary and the quality of the processor can be different. Two different SAST tools can understand the same languages and same frameworks while being able to search for the same vulnerabilities and yet have two different results. The reason for this is in the capabilities of how the tools are able to evaluate the code. The same goes for RASP, IAST, and DAST tools.
This difference makes switching between tools a challenge. There maybe some instances where one tool does better than the other.
Integrations
Once a security tool is purchased, the integrations start. Developers learn how to use the SAST capabilities in their IDE or their own workflow. In some cases they can be integrated into source code repositories like GitHub to prevent code being checked in. In other cases they are built into the CI/CD pipeline. In some cases there are scheduled processes that run externally. Or they can be built into the containers that are used to build the products. For DAST tools, there’s credentials that need to be managed in order to be maintained. And a lot of the security tools are connected into the company environment with ticketing systems or single sign on.
This is one reason you are seeing many more security tool platforms be successful. It’s easier to integrate one tool than many tools. Switching out these tools can be a major undertaking.
Results Management
Given how the tools run and the rules the run on, the findings between the tools can be significantly different. There’s a decision that has to be made. Is it worth the effort to try to keep the existing findings and manage them accordingly or does an organization start from scratch? What happens if there is a finding from the old tool but it isn’t found in the new one? Does that mean the old tool was wrong? If it isn’t wrong, how does the team go about validating the fix?
The Cost of Crossing the Moat
Switching software security tools may sound like a simple upgrade, but it’s akin to pulling out the foundation of a house to swap in a new one—while still living in it. The allure of shiny new features and better integrations is strong, but so is the grip of your current tool’s tendrils, deeply embedded in your CI/CD pipeline, workflows, and developer muscle memory. The moat around each tool isn’t just filled with the complexities of integration, but also with the time, effort, and risk associated with migrating.
In the end, the question isn’t whether you can cross the moat, but whether the cost of doing so is worth the promised greener pastures on the other side. Because while security tools may pop up like weeds, swapping them out might just make you wish you’d never stepped foot in the garden. It’s also why the cost of tools has yet to really come down.