How to consolidate your security testing stack without the lock-in

Every new tool promises to save you time. Then you spend that time reconciling reports, learning one more interface, and sitting through one more sales call about pricing.

Dragos Sandu, our Product Manager, joined our host Jan Pedersen for an Office Hours session on tool sprawl. They worked through what consolidation means in practice and how to do it without trading sprawl for lock-in. 

Here's what they covered, and a checklist for your team.

Start with the bucket test

Jan's rule from an earlier session is simple: consolidate tools that fit in one bucket, and keep tools from different realms separate. 

But how do you know which tools share a bucket? That's the hard part, Dragos said, because vendors give similar tools very different names.

His test is:

If someone on your team keeps comparing the results of two tools to see if they found the same problem, then those tools are part of the same bucket, at least for your team. - Dragos Sandu, Product Manager, Pentest-Tools.com

Two meanings practitioners assign to consolidation

Jan split the word "consolidation" in two:

• some teams want one place for all their findings 

• others want fewer tools and fewer vendors doing the work

Each needs a different answer.

One place for all security testing findings

Dragos started from the goal of the security program. 

Most teams now run a loop: find the weak spots, pick the important ones, make sure they're real, and fix them. People call this loop continuous threat exposure management (CTEM). Two kinds of tools support it: 

• Unified vulnerability management platforms which gather findings from many tools into one list and turn them into tasks. 

• Exposure assessment platforms (EAPs) continuously discover exposures across the attack surface and prioritize them, typically by severity and threat intelligence context.

Dragos said one step often goes missing: checking that a finding is real before an engineer spends a day on it. 

That's our spot in the loop: proving which findings are exploitable. Those platforms hold the list, and we send them data and proof.

Fewer tools and vendors

Customers want the same work done with fewer tools. But they don't want to swap five small tools for one giant vendor with 10 modules and 10 licenses:

...where you need to have three sales calls just to understand the pricing, because this just moves complexity somewhere else. - Dragos Sandu, Product Manager, Pentest-Tools.com

They also want a vendor who will still be around next year, which matters with so many new AI startups.

Then comes a cost that never shows up on an invoice: time. 

Dragos shared an example from an MSP customer. After a few scans with different tools on the same target, they have to collect every report, merge them, remove the duplicates, and generate a report for their own client.

Jan added the other side of the budget: time to value. 

At a very large company he worked at before, customers implemented less than a third of the package they bought within a year. How long a purchase takes to pay back matters as much as how long it takes to buy.

What security leaders told us in London

During the session, Dragos also talked about attending the IT Security Analyst and CISO Forum in London, in April. A few things stood out, because most attending CISOs agreed on them:

• CISOs use only a fraction of the tools they buy

• They pick the tool that's easiest to use in their workflow over the best one on the market

• Before buying anything new, they check what they already own, since an existing tool usually covers the same ground and nobody has had time to find out what it can do

• The strongest point: CISOs don't need more findings. They need fewer, well-explained findings with high criticality, so a small engineering team can fix what matters

What goes in the security testing bucket

Dragos's answer: everything that answers one question. 

How deeply does a system need testing right now?

The answer changes from system to system. A small marketing site that hasn't changed in months may need only a regular automated scan. A payment app after a big release needs more than a scan, so someone or something has to thoroughly test every critical flow.

So the bucket holds every depth of testing, from quick checks to a manual pentest. It leaves out protection tools like EDR and antivirus. Jan added that testing and defense are different jobs for different people, so they deserve different tool sets.

Three depths of offensive security testing

Different targets need different testing cadence and depth. A quarterly scan won't investigate a complex web app before launch, and a manual pentest won't cover 200 assets. Dragos walked through the three depths Pentest-Tools.com covers:

Vulnerability scanning and deterministic validation

Accurate results you can act on. It scans web apps, networks, and cloud with daily detection updates, then safely exploits what it finds where supported, so you get solid evidence for remediation. Recurring scans surface what's new and what changed through scan diff notifications, and you control what to test, how, and when.

AI Pentests 

Autonomous web app investigation on demand. You define the scope, and Specter, our autonomous AI pentesting agent, runs a full web app pentest and delivers a report of validated results in hours, with an auditable activity log. Every finding includes the steps to reproduce its exploitability.

Offensive security services 

Expert judgment where automation falls short. Certified offensive security practitioners step in when business logic, data sensitivity, or compliance context needs a real human's judgment. They explore complex attack paths manually and write reports tailored to your business.

Buying all three separately usually means three vendors, three contracts, and three report formats. Say a scan flags something worth digging into. Dragos said moving that system to a deeper test is just a change of scope, with no need to explain your environment all over again. You pick the depth each target needs without changing vendors or breaking your workflow, and the findings and reports come back in the same structure.

How to avoid vendor lock-in

Jan came back to a question from his earlier session: how do you protect yourself from a vendor who gains pricing power once you've consolidated? He asked Dragos the same question about us, and Dragos named three checks:

Define clear limits

We do offensive security testing. We don't do endpoint protection, antivirus, or EDR, and we don't want to. That focus lets us build a team of certified practitioners, with GSE, OSCP, and GXPN among their credentials.

Check how easily you can take your data out

Interoperability is essential for companies who've been burnt by data migration issues. That's why, with Pentest-Tools.com, you can export results as CSV and JSON, use the API, or send findings to tools such as Jira, Vanta, and Nucleus Security. 

On data portability, Dragos was direct:

If a vendor makes it hard for you to get data out, for me, it's a warning sign. - Dragos Sandu, Product Manager, Pentest-Tools.com

Jan asked it this way: is it really your data, or is it the vendor's data about you? 

That's why it pays to ask any vendor for how long it keeps your data and when it deletes it, and audits make that detail matter more. Also check whether results move into your other tools, such as opening a finding in Burp Suite. For us, the answers are in the security and privacy section of our FAQ.

Evaluate each type of security testing on its own

If our vulnerability scanning works for you but AI Pentests, our autonomous web app pentesting agent, doesn't fit your system, you can skip it. Using one doesn't force you to buy the other.

Does AI mean fewer tools or more sprawl?

Dragos's take: 

I think it can do both. It really depends on how you adopt it. - Dragos Sandu, Product Manager, Pentest-Tools.com

"Right now, every week there is a new AI security tool," he said, "and people inside companies use AI tools the security team doesn't even know about… and it's like shadow IT all over again." The CISOs he spoke to in London worried less about what AI finds than about what it quietly ignores.

Our AI pentesting survey shows what that looks like. Practitioners named business logic as the limitation they mention most often. As one respondent described it, AI tools can find SQL injections but won't understand that a discount coupon works once per customer, or that "adding negative quantities to the cart is equal to free money." Nothing errors and nothing alerts, because the application does exactly what it was built to do.

The survey also shows the other side of the worry: nearly 88% of practitioners who use AI to generate findings said the results needed significant manual validation.

The CISOs' advice: 

• Start from a real problem

• Decide how you'll measure success

• Test the AI tool on that problem like an experiment

Taken step by step, AI can reduce your tools. Without that discipline, it becomes one more tool nobody uses properly.

Your consolidation checklist

1. Run the bucket test on your tool list. Which two tools do you keep comparing?

2. Before you buy, check what you already own that covers the same ground.

3. Match testing depth to each asset, and revisit it after a big release.

4. Ask every vendor, us included, to pass the three lock-in checks.

5. Start any AI adoption from a real problem, treat it as an experiment, and assign it a measure of success.

Watch the session

Here's the full session:

Every Office Hours session lives on our YouTube playlist, so catch up on any you missed.