There is such a thing as too much of a good thing. Or too many good things.
And that has become a problem in a digital world where the need to manage application security risk at enterprise scale and at unprecedented speed has never been greater.
To meet that demand, many organizations have added to their existing set of application security testing (AST) tools. The perception, apparently, is that if some tools improve your security, more will improve it even more and even faster. The Enterprise Strategy Group recently reported that 70% of enterprise organizations are using 10 or more AST tools.
But “tool sprawl” is likely to result in the opposite outcome. Instead of enabling faster development, it leads to teams struggling to manage large, complex, heterogenous AST environments with hundreds of applications being tested by dozens of tools, often across multiple teams. And when teams are bombarded with constant notifications, they start ignoring the “noise.”
Yes, AST tools are necessary. They are crucial to building security into software at the speed modern development demands. But too many of them? Not so good, especially if you have several designed to do the same thing. In this case, redundancy makes you weaker.
Another problem with simply adding tools is that it makes it nearly impossible to measure the success or failure of a security program. Having all those tools moves the focus to collecting data with endless scans, rather than on deciding what success and return on investment look like, and making sure you can measure them.
The solution is a modern-day version of Henry David Thoreau’s iconic mantra to “simplify, simplify.” In the case of software tools, it should be “consolidate, consolidate.”
To eliminate tool sprawl, start with a rigorous inventory. Know what tools you have and what they’re supposed to do. Make sure they’re all up-to-date. Then evaluate: Are they all effective? Necessary? Is one doing the same thing that another, perhaps better, tool is doing?
If tools are inferior or redundant, they’re creating security clutter, so get rid of them.
Second, make sure your tools can work together. It doesn’t matter if one is considered best-in-class if it can’t play nice with the others. You need ease of integration to embed security into development from start to finish.
Next, set policies that will help you measure success. That starts with another inventory: Document your existing software assets and applications. Then assign them a risk ranking based on things like which of them are behind a firewall (i.e., not facing the internet and therefore not exploitable), which are business-critical, and which are most vulnerable to attack.
That will then hep you set success metrics. These should be limited—things like vulnerability density, time to triage, or time to remediate—but they should align with the specific business objectives of the organization, which means they won’t be the same for everybody.
Those metrics can then guide the policies that determine how to configure AST tools. And tools that are correctly configured give organizations the ability to measure the performance of their security program as it relates to their priorities, without cluttering the view with piles of irrelevant data. Tool policy helps answer questions like: Where is all my software? How secure is it? Are we getting better? Are we spending time and resources on the right areas?
The right combination of tools—the essential three AST tools are static analysis, dynamic analysis, and software composition analysis for open source software—configured to adhere to your priorities throughout the software development life cycle (SDLC), can bring that elusive goal of software risk management at enterprise scale within reach—with the help of one more tool.
The best way to get control of security policy implementation, testing results, and defect remediation is to use an application security posture management (ASPM) tool, which provides the visibility that security teams need to manage findings. It gives them a consolidated view of security and risk status across the entire development environment.
Among its multiple benefits is orchestration—doing the right test at the right time with the right tool throughout the SDLC.
A good ASPM solution will correlate and analyze data from a variety of sources, allow you to administer and orchestrate security tools, and automate your security policies. And since most are tool-agnostic, they provide visibility into which of your current tools are most effective.
And that is another way to measure success.
