The Enterprise Guide to AppSec Tech Stack Consolidation

There’s a big problem in the world of application security: enterprise organizations have taken on a multitude of AppSec testing tools, but they’re still shipping applications with known vulnerabilities.

In Enterprise Strategy Group’s 2020 survey of 378 IT, cybersecurity, and application development professionals in the US and Canada, more than 70 percent of respondents said their organization currently uses eleven or more individual AppSec tools. As a result, their DevSecOps teams deal with an overwhelming number of reports, alerts, and security processes—many of which are redundant. Prioritizing security issues in this environment is a nightmare, wrapped in a migraine, stuffed with a pain in the neck.

And as demand for software production increases, companies are more likely to ship code that they know contains exploitable vulnerabilities. Forty-eight percent of respondents admit that they “regularly” push code to production with known organic vulnerabilities—and an additional 31 percent say they do this occasionally. All too frequently, organizations are stuck choosing between security and meeting production deadlines. And they’re not always choosing security.

The bottom line: enterprise companies are paying for many application security tools without reaping the benefits. To fix this, DevSecOps leaders look for ways to strategically consolidate their AppSec tech stack.

AppSec Tech Stack consolidation should reduce complexity and increase efficiency

Any efforts to consolidate application security tools should improve the ROI of your AppSec tech stack while maintaining or improving the level of protection your software receives.

Most consolidation plans accomplish this by reducing complexity and increasing efficiency. By reducing complexity, you give your DevSecOps teams fewer tools to monitor, thus eliminating noise and allowing your developers to focus on prioritizing and fixing issues. This should, by nature, increase efficiency for both your tools and your people, enabling them to patch more issues while keeping up with your software production schedule.

And of course, if you can reduce your spend on AppSec tools while you’re at it, it’s an even bigger win.

The two main theories of consolidation

Organizations seeking to consolidate their application security testing tools have two very obvious levers to pull: work with fewer vendors and/or fewer tools. This has led to two popular theories of consolidation—either go with an AppSec suite from a single vendor or trim your stack to only include the best-in-breed point solutions.

In both cases, organizations should cover the bases in terms of AppSec testing tools. Every enterprise AppSec tech stack should include software composition analysis (SCA) to scan open-source libraries for known vulnerabilities, static application security testing (SAST) to scan your original code for vulnerabilities, and dynamic application security testing (DAST) to catch major vulnerabilities in your runtime application.

In some cases, you may want to incorporate an interactive security application testing (IAST) tool—which runs in tandem with your testers to find any vulnerabilities in the relevant functions of your application. Additionally, a consolidated tech stack should include application security posture management (ASPM) to orchestrate alerts from these different tools and provide managers with an accurate, comprehensive view of risk.

Reducing your AppSec testing toolset to these four types of tools solves the main problem DevSecOps shops experience: an overwhelming amount of reports coming from an overwhelming amount of tools. If you’re using more than 10 AppSec tools, your developers are dealing with an abundance of un-prioritizable, impenetrable reports. You already know that consolidation is the answer, but the approach you take will drastically influence the way this plays out.

There are two solutions to this problem—but the best approach is to use best-in-breed solutions.

Single-vendor AppSec consolidation: simple, but flawed

Relying on one vendor for your entire AppSec tech stack is a popular approach, and its benefits are apparent on the surface. We’ve been working within technological ecosystems since Microsoft Office, and big software security companies are eager to promote their comprehensive AppSec suites in kind. (And they have the marketing budget to do so!)

Synopsis is a notable proponent of the single-vendor approach. In their ebook Consolidate and Simplify: Streamline Application Security to Manage Software Risk, they lay out three major drivers of consolidation, the problems they cause, and how a single-vendor solution can make everything better. (If you don’t want to download the ebook, you can get the gist of it in this blog post.)

The argument is straightforward: collapsing your application security stack to a single vendor should reduce complexity, which gives you a cleaner view of your risk situation, which lets your team operate more efficiently—and you’ll realize cost efficiencies, too.

This comes with a few underlying assumptions:

1. Going with a single vendor reduces complexity by requiring fewer tools.
2. Going with a single vendor gives you a better view of risk.
3. Going with a single vendor’s integrated tool suite will increase efficiency.
4. Going with a single vendor reduces costs.

On the surface, this argument seems intuitive. But if you put it under the microscope, the single-vendor approach has several inherent flaws.

Fewer vendors ≠ fewer tools

Even if you’re working with a single vendor, your team will likely still need to deal with a suite of separate tools. They may pitch “one platform,” but that’s just the glue holding together their disparate point solutions.

This is the case with Synopsys, who doesn’t offer an all-in-one AppSec solution, but instead a lineup of distinct SAST, DAST, SCA, and IAST tools. If you choose to move forward with a single vendor, you’re not necessarily consolidating tools—you’re consolidating invoices. It may relieve some of the complexity for your billing department and simplify customer support processes, but that’s not changing much for DevSecOps.

Switching is time-consuming, disruptive, and expensive

A good single-vendor option will provide you with tools that integrate well with each other—but that doesn’t mean everything fits with your current development environment. Your developers don’t need your AppSec tools to work with each other as much as they need these tools to work with the tools they’re already using to build and ship your applications.

Consolidating to a single vendor’s suite means you will need to uproot every established process with every other vendor’s tools you use. This can be catastrophic for your DevSecOps team

A single vendor locks you into the quality level of their tools

Although a single vendor may offer all the kinds of tools you need, it doesn’t mean that these tools will provide you with the level of quality you need. Consolidating your invoices to one vendor can easily stick your developers with a more confused view of risk and less guidance for managing it.

And even if your team currently enjoys using a certain tool from a potential single vendor, it doesn’t mean they’ll like the rest of the suite. A vendor might have a dynamite SAST tool, but that’s no guarantee that their SCA will serve you better than your current solution.

With Synopsys, this is the sad reality. If an organization were to move all their AppSec testing to Synopsys tools, their developers would need to use Black Duck, their software composition analysis tool. And Black Duck is notorious in the SCA space for wasting developers’ time with false positives while delivering almost no guidance for patching vulnerabilities.

The single-vendor argument ignores the larger picture

But perhaps the biggest issue with choosing a single-vendor approach to consolidation is that it cuts you off from all the other levers you can pull to reduce complexity, get a better view of risk, and improve efficiency.

Investing in fewer tools, better orchestration, improved accuracy, and advanced developer guidance can all move you closer to the end goal of consolidation, and you can realize these without moving to a single vendor. (And choosing a single vendor isn’t the same as investing in these consolidation efforts.)

You want better ROI on your AppSec spend, and a more effective DevSecOps shop, and there are several avenues you can take to get there. Going with a single vendor locks you into one—so consider all your options carefully before making that decision.

The argument for best-in-breed AppSec consolidation

Now let’s look at the other approach to consolidating AppSec tools: trimming your tech stack down to a few key best-in-breed tools from multiple vendors. This approach assumes that you will reduce your AppSec tools to a set including: SCA, SAST, DAST, and IAST.

There’s no use being shy about it: this is the approach we recommend. Choosing a small collection of high-accuracy tools with advanced developer guidance sets up your DevSecOps team with a clear and comprehensive view of risk—and gives your developers the direction they need to prioritize and implement fixes.

This is because choosing best-in-breed solutions allows you to isolate the problems that are driving you to consolidate in the first place and fix them with the best possible solutions. A vendor that rates well overall in the category of application security testing may not be the strongest when compared to a combination of vendors who specialize in SCA, SAST, DAST, and IAST.

Best-in-breed lets you keep the tools that work best for you

When consolidating your AppSec tech stack, you don’t want to remove tools that already integrate well with your environment and earn their keep with your developers. If you’re using the best-in-breed approach, you can retain these tools and build your new, smaller stack around them.

However, a single-vendor approach might require you to say goodbye to tools that are currently working well for you. The argument you’ll hear is that all their tools integrate well with each other—but this isn’t really what your developers want. Your developers want tools that integrate well with your established development environment! Otherwise, you’re creating more hassle for them—which is the very problem your consolidation efforts are trying to fix.

Let’s say you’re using a terrific SAST (say, SonarQube) that works well with your development environment and helps your team produce stellar, secure code. Moving to a single-vendor solution would require you to abandon that tool—even though it’s helped your developers ship excellent code—for whatever SAST offering the single-vendor solution offers. Your developers won’t be happy, and in the long run, neither will you.

The best-in-breed approach allows you to talk to your developers about which tools are already working well, isolate those tools, and build your AppSec tech stack around them. Which solutions work well with the tools and processes your team already loves?

Best-in-breed reduces tools and maintains coverage

If you’re trying to reduce your stack of eleven or more tools, going with the Core Four will immediately eliminate the majority of the reports your developers have to sift through today. Your developers will still be able to check their code for quality and security with your SAST tool.

You will still have protection against threats in your runtime application with your DAST tool. And with an SCA, your application will still remain protected from the most imposing threat of all: known vulnerabilities in your open-source code.

Of course, needs will vary from organization to organization, but for most, these three will cover the most high-risk threats.

N.B.: If you’re able to afford and manage a host of AppSec tools, then a full toolset may be best for you—but it’s worth examining your toolset to see if it’s providing your team with findings that you can effectively manage and process. If not, consolidating to a smaller array of best-in-breeds may be even more effective for you.

Best-in-breed gives you a better view of risk with a specialized ASPM

The problem of a fragmented view of risk is one of the key forces driving AppSec consolidation. This can be dealt with via better orchestration, i.e., giving your team a clear, comprehensive picture of their risk exposure and helping them prioritize issues to address.

An application security posture management (ASPM) tool helps you do this. If you choose a top-tier ASPM, it will compile reports from your SCA, SAST, and DAST. Furthermore, if you choose to incorporate other AppSec tools (e.g., IAST, MAST, RASP, etc.), an ASPM will help you triage reports from all of these—saving your dev team valuable time.

Best-in-breed lets you select for accuracy

It’s a shared understanding in the AppSec community: false positives are productivity killers. They waste your team’s time, and the false alarms damage relationships between your security team and your other developers. Improving accuracy of your tools improves your DevSecOps shop efficiency—it helps ensure your developers are alerted to real problems, and eliminates the time drain that chasing down false positives causes.

Selecting best-in-breed vendors from each category helps you mitigate this. By building your AppSec tech stack around accuracy, you give your developers more reliable reports, which allows them to spend their time taking actions that matter.

Best-in-breed lets you select for developer guidance

In a 2021 IBM Security™ study, 59% of respondents cited delays associated with patching vulnerabilities as a reason their organizations hadn’t become more resilient to cyber threats. These vulnerabilities were known, but the patches just weren’t applied. A major reason why patches get delayed is that developers lack guidance—the tools tell them that there’s an issue but leave it to the developer to figure out how to fix it.

Catching vulnerabilities is an important function of AppSec tools, but this should only be the beginning. While top-of-the-line application security testing tools will give your developers guidance in terms of prioritizing and implementing issues, not all tools are created equal in this regard. Some tools will patch some fixes automatically. Some will provide information on various available patch versions, their popularity, and their compatibility with your application. But others will only refer you to the latest available patch—or give no developer guidance at all.

If you choose the single-vendor route, you’re locked into using whatever tools that vendor offers. And unfortunately, the major single-vendor candidates don’t offer as much developer guidance as some best-in-breed players can. (For example, we compared three major AppSec vendors’ SCA tool developer guidance against ours—and none provide the level of time-saving, risk-mitigating guidance we do.)

How to start consolidating your AppSec stack

If you’re ready to begin consolidating the tools you use to secure your applications, you’ll need to make sure you have your bases covered:

• Software composition analysis (SCA): this helps you spot the known vulnerabilities in your third-party libraries—which is the biggest threat to your application’s security.
• Static application security testing (SAST): this scans your original code for vulnerabilities before it’s pushed live.
• Dynamic application security testing (DAST): this scans your runtime application for threats, which you can use to inform update priorities.
• Interactive application security testing (IAST): this scans your application while you’re testing it, analyzing relevant functions to see where you’re vulnerable to known threats.
• Application security posture management (ASPM): this helps you orchestrate reports and prioritize issues across the other three tools (and any more that you choose to keep), giving you a clear, comprehensive view of risk.

You likely already have one or more of these tools in place. So as you begin the consolidation process, talk to your DevSecOps team about how each tool contributes to their efforts. If you’re already using one of these categories, examine the value and challenges that each tool presents you with.

Find out how well each tool integrates with the development environment—and be sure to ask about false positives and developer guidance. If a tool you’re currently using doesn’t integrate well, generates a great deal of false positives, or doesn’t provide much guidance for developers, consider dropping it and replacing it with a better alternative.

If you’re not currently using one of these tools, begin working to find a way to acquire and implement them one at a time. (We recommend doing so in the order listed above.)

In the end, you should have a small set of tools that do their jobs well and play nicely with your development environment. This will empower your developers to spend less time sifting through reports and focus their energy on the issues that matter.

And that’s how you finally overcome the problem that started your consolidation journey in the first place: you’ll be paying for fewer tools, and enjoying the full benefits of all of them!

Start consolidating with a best-in-breed SCA: MergeBase

Software composition analysis is the foundation of application security. Most of the threats your application faces come from known vulnerabilities in your third-party code libraries. If hackers know about these vulnerabilities, you should too.

If you’re looking to consolidate your AppSec tech stack, consider MergeBase as your SCA player. We integrate with leading ASPMs, and companies switch to us for our low false positives rate and advanced developer guidance.

If you’d like to see how MergeBase can secure your application from known vulnerabilities in your open-source code, we’d love to help. Start your free trial today!