Supply chain security: Why tool consolidation doesn’t always mean progress

New research from open source security platform JFrog shows that security tool consolidation is well underway: the share of organisations using seven or more application security tools fell from 73% to 35% year on year.

Fewer tools can mean cleaner workflows and lower operational drag – and a better chance that developers actually use the products that security teams buy.

But consolidation doesn’t automatically equal progress. Because the remaining tools have to cover the risks that are important right now – and in supply chain security, consolidation could be moving the blind spots upstream. 

Why are the blind spots moving? 

JFrog’s report suggests that while the tool stack is shrinking, the attack surface is spreading. 

Malicious package detection is used by only 40% of respondents – that’s almost unchanged from 41% the previous year. Secrets detection is even lower, at 28%.

That would be worrying in any year. In 2025, it looked particularly thin. JFrog detected 171,592 unique malicious npm packages, up 451% from 2024. It also found 495 malicious Hugging Face models and 969 malicious AI agent skills, showing that attackers are not stopping at traditional package registries.

The supply chain isn’t just the library a developer imports anymore. It includes the IDE extension they install, the CI/CD workflow they trust, the model they pull, the MCP server they connect to, and the AI agent skill they allow into a development environment.

That’s where the idea that fewer tools is better gets a little more complicated. A consolidated platform might be stronger than a messy pile of point products – or it may just leave fewer places to notice the next attack.

Platform-native security needs depth

JFrog found that 38% of organisations now rely primarily on security capabilities in their existing DevOps platform. Dedicated software supply chain security platforms were the main reliance for only 7%.

And that’s not automatically bad. Security embedded into developer workflows is usually better than security bolted on at the end. But it raises the question: are those platform features built for modern supply chain attacks, or are they checkbox controls wrapped around old assumptions?

A 2026 supply chain report from Black Kite makes the timing problem clear. More than 48,000 CVEs were published in 2025, but only 58 met its ‘Code Red’ threshold for genuine supply chain threat. Meanwhile, attackers exploited vulnerabilities an average of seven days before public disclosure.

That combination changes the job. Instead of just needing more scanning, security teams need faster, more precise signals about what is exploitable, exposed and present inside their ecosystem.

The good news is focus

But there is progress here. Tool sprawl is being challenged, and platform-native controls are moving into the mainstream. Teams are starting to realise that vulnerability volume is not the same thing as risk.

But the weak spots have moved from the edge of the problem to the very heart of it. They now exist inside the developer workflow: secrets, malicious packages, AI models, extensions, CI/CD permissions and agentic tooling.

So if you’re consolidating, then do it carefully. Fewer tools only really help if coverage improves. Treat IDEs, MCP servers and model registries like supply chain infrastructure. And measure risk by exploitability and exposure, not raw CVE or package counts.

Supply chain security is improving where teams are reducing noise. But it’s still failing where controls stop at outdated perimeters.