Security tool sprawl has made many teams so overwhelmed by security alerts that they can’t respond to them. Here’s how to deal with security tool overload.

Perhaps the “Too many cooks can spoil the stew” cliché needs a corollary in the IT world.

Because too many security tools can spoil your software development—and even undermine your security.

No, this doesn’t mean all security testing tools are bad, or that only one tool is good.

The reality is that it takes the integration of multiple tools to build security in during the software development life cycle (SDLC). Those tools should include, at a minimum, static, dynamic, and interactive analysis security testing, software composition analysis (SCA) for open source components, and penetration testing at the end of the cycle before an app goes into production.

But there is such a thing as too much of a good thing, or too many good things.

What is security tool sprawl?

The Enterprise Strategy Group (ESG) reported more than a year ago that organizations, on average, run 25 to 49 security tools from up to 10 different vendors.

Some of these are monitoring tools for IT infrastructure, such as network, endpoint, wireless, identities, and so on. But it applies to software development as well.

Analysts like Forrester and 451 Research have reported on security tool sprawl in the past year, noting that as many as 40% of organizations admit that their development teams are so overwhelmed by security alerts that they can’t respond to at least 25% of them. Indeed, when security alerts are so constant, they become background noise and are ignored—the exact opposite of the intent.

Larry Ponemon, president of the Ponemon Group, said of tool sprawl that “so many things are generating reports [and alerts] … you are in a state of information overload pretty quickly.”

And as Tech Radar put it recently, security tool overload can “end up creating chaos and inefficiencies,” leading to “reduced productivity, inefficient workflows and higher overall costs.” These are the very things a good mix of security tools should help development teams avoid.

How to deal with security tool overload

It shouldn’t be this way. The right combination of tools that run the right tests at the right time can help security keep pace with development, which has moved into hyperdrive over the last few years.

Still, there is a persistent perception that if some tools improve your security, more will improve it even more. Unfortunately, it could be just the opposite. If you pile too many tools on your development team, especially if you can’t coordinate them on a single platform, your developers are more likely to ignore critical alerts.

Too many tools can even expand your attack surface. A post in Dark Reading noted that “hackers often exploit vulnerabilities in tools that do not communicate securely or are not regularly updated.”

Beyond that, any organization that has dozens of security tools almost certainly has multiples intended to do the same thing. Security tooling is an area where redundancy makes you weaker, not stronger. An overload of tools just adds to the noise without improving anything.

1. Take an inventory of your security tools

The first thing to do to eliminate security tool sprawl is to take a rigorous inventory and evaluate it. Know what you have and what it is supposed to do. Make sure all your tools are properly configured, deployed, and up to date. And then evaluate: Are they doing what they are supposed to do? Is any tool doing the same thing that another tool might be doing better?

If a security tool is inferior or redundant, get rid of it. Security clutter is the last thing you want.

2. Make sure your tools complement one another

Second, make sure your tools can work together. It doesn’t matter that a single tool is considered best in class if it can’t play nice with all the others. Your tools need to integrate with one other and into your workflow, which makes it easier to embed security into the SDLC from start to finish.

As the experts say, the best way to encourage developers to add “Sec” to DevOps is to make the secure way the easier way.

3. Integrate your tools into your workflow

That leads to Step 3: The way to make security easier, and combat security tool overload in the process, is to integrate your security tools into a single platform, with a dashboard that flags bugs and other potential defects as you go. It’s far better than forcing developers to return to code they wrote weeks ago to deal with problems you discovered today.

At Synopsys, we offer the Polaris Software Integrity Platform. It integrates and automates our security tools with the tools developers are already using, so they can address security defects in their code as they write it, without switching tools. Its integrations cover the DevOps landscape, from the developer IDE and build systems to container orchestration and cloud deployment platforms.

It even offers some real-time coaching in the form of detailed remediation guidance and context-sensitive eLearning, helping developers fix problems now and avoid them in the future.

But the bottom line is that rather than suffer from security tool overload, you can have the right tools at the right time that will let security keep pace with the velocity of development.

Which lets you reach your goal of building secure, high-quality software faster.

Learn more about the Polaris platform