3 ways that security tool sprawl can hurt application security testing

Tool sprawl is a problem in all walks of the technology industry but can hit especially hard in cybersecurity. Losing track of the security toolset in your organization introduces inefficiencies that can hurt not only your security operations and incident response but also your application development and overall company performance.

There are many examples of tool sprawl in the wide world of IT security, with a common scenario related to endpoint protection involving adding ever more security software to end-user devices. Without careful planning, testing, oversight, and reevaluation, this can have a serious performance impact, compromise usability, or even require more powerful and expensive hardware without necessarily improving security.

For this post, we’ll focus specifically on how tool sprawl can affect application security testing. While most examples will come from Invicti’s area of expertise, namely dynamic application security testing (DAST), many of the same challenges apply in other areas of cybersecurity. 

Sprawling problem #1: Workflow inefficiencies and security gaps

Wherever you have multiple point solutions used in isolation, the lack of integration and automation can result in inefficient manual processes and needlessly duplicated functionality. This is especially true with subpar quality results and false positives in the mix, with each tool consuming additional time and effort every time it runs.

Taking a fairly typical example from the DAST world, engineering might be using a basic vulnerability scanner that was bundled with their SAST tool. At the same time, the application security team might be using a commercial DAST to run vulnerability scans in QA, and the corporate IT security team might be paying an external provider to run periodic vulnerability scans on the production environment. That means three DAST tool processes to maintain, operate, and finance.

Running multiple disjointed and uncoordinated security testing tools is inefficient and can slow down all processes that rely on them, including development pipelines. It can also give a false sense of security by leaving gaps and gray areas in your overall security posture—which neatly brings us to problems with visibility.

Sprawling problem #2: Lack of centralized visibility and control

To repeat a well-worn truth, attackers only need one gap, but defenders have to close them all. Tool sprawl can lead to data silos that hinder visibility and make it harder to see the big picture, including any weak spots. If they don’t know about all the security tools used in the organization and its many environments, CISOs can’t get the most out of the data they generate nor ensure that they’re the best tools for the job. Crucially, sprawling security tools are tough to integrate and automate, making it that much harder to quickly react to security threats.

Continuing with the sprawling DAST example, it’s possible to have the same vulnerability in an existing application being found three times by three different tools at different stages of the DevOps process. The DAST-lite used by engineering might flag the issue but be ignored because most of its reports for this vulnerability type are not actionable. The security team running a dedicated scanner in QA might find the issue and submit a developer ticket to get it fixed in the next release. And finally, the external scanning provider might find the same flaw in production and include it in their report to IT security, who then need to decide whether to block it on the web application firewall (WAF).

In effect, you could have three teams independently and manually evaluating three vulnerabilities without knowing they are the same underlying issue. And that’s only a simplified example that doesn’t consider the complexity of development and deployment in cloud environments, where you also have to factor in a mix of provider-operated security measures and any cybersecurity tools you run on your own. Centralized visibility is a must for effective application security, both preventive and reactive—and tool sprawl obscures that picture.

Sprawling problem #3: Zombie tooling

Tools don’t run and maintain themselves, so a common consequence of sprawl is zombie security tools and workflows that have been completely abandoned or relegated to a meaningless checkbox. Especially with open-source or bundled tools, it can be tempting to just add a new process because you don’t need separate purchasing approval.

In our sprawling DAST scenario, the engineering team has a lightweight vulnerability scanner that was added to the pipeline mostly because it came bundled with their SAST. The scanner doesn’t find much, and what it finds is mostly ignored, but it’s not costing us extra, so why not use it, right? Such lip-service tooling clutters up workflows and gives a false sense of security because it ticks a box without really making a difference. It can also give security tools a bad name, strengthening the developer misconception that application security is mostly meaningless bureaucracy.

With no upfront cost, it’s easy enough to add and forget a tool—but the same thing can happen with commercial products. All too often, point solutions are bought without looking at the wider security picture or considering factors like setup and maintenance requirements, integration, or vendor support. Teams might then realize that nobody has time to configure, run, and maintain the new tool, and a new full-time role is not on the cards. The product is then written off as a waste of time and money, leaving the organization with zero, if not negative, ROI on their security solution.

Dealing with tool sprawl in application security testing

Security doesn’t happen in a vacuum but is a cross-cutting concern that touches all areas of an organization, so centralized control and visibility is a must. Application security, in particular, is deeply woven into the wider cybersecurity picture, and relying on ad-hoc point solutions is never a good long-term strategy. To reduce tool sprawl and see real security improvements and ROI in application security, follow these overarching principles: 

• Tool consolidation and integration: Aim to minimize the number of tools overall and ensure that everything you use is integrated into your overall security strategy and makes a difference to your organization’s security posture.
• Centralized visibility: Ensure you’re always looking at the big picture by centralizing as much security reporting and monitoring as possible, which may include consolidating or eliminating isolated security products and workflows.
• Automation and efficiency: Automate everything you can based on accurate data to speed up security response and optimize costs by minimizing manual work and duplication of effort.

Invicti provides one answer to inefficiencies in application security testing, taking a DAST-first approach to cracking down on tool sprawl for web application and API security. Building on the foundation of a mature DAST engine with evidence-based verification, the Invicti platform also incorporates IAST, dynamic SCA, tech stack version checking, and web discovery, with a wide choice of out-of-the-box and custom workflow integrations. Invicti customers also get onboarding services and technical support to ensure they’re getting the most out of their investment—and seeing solid security improvements from day one.

Learn more about the differences between DAST, SAST, and IAST