Are your vulnerability management practices actually reducing risk, or are they quietly disrupting your ability to deliver software? 

That is the main question behind this year’s research. 

Most organizations now have some kind of process for detecting and responding to vulnerabilities in open-source dependencies. They have scanners, alerts, dashboards, dependency update PRs, security policies, and remediation workflows. 

To explore this, we spent more than 100 hours reviewing industry reports, surveyed 500 qualified IT and software professionals, and conducted follow-up interviews to better understand how teams manage open-source dependency vulnerabilities in practice.

What the 2026 Survey Revealed

This year’s research found that common vulnerability management practices are helpful, but incomplete. They are useful for detecting known vulnerabilities, but they still leave major gaps—and can create serious side effects for development teams.

1. Unknown Exposure to Risky Dependencies

We found strong evidence that many teams may still be exposed to risky dependencies, even when they have vulnerability scanners in place. Scanners cannot detect unknown vulnerabilities until those issues are discovered and added to advisory databases. They are also not designed to fully prevent malicious packages from entering the software supply chain.

On top of that, security policy can also become unusable in practice. When rules are too strict, alerts are too noisy, or workflows do not match how developers actually work, teams create informal workarounds. That is how governance lapses: the policy still exists, but the real process becomes inconsistent.

2. Regression Risk from Security-Driven Upgrades

Many teams respond to vulnerability alerts by upgrading dependencies. But security-driven upgrades often happen under pressure, with less review than planned maintenance work.

That creates regression risk. A dependency upgrade can change behavior, introduce compatibility issues, or break edge cases. When that happens, the “security fix” creates new engineering work.

3. Delayed Release of Valuable Features and Updates

Vulnerability work is not always a rare emergency. It often arrives through PRs, CI/CD checks, issue trackers, dashboards, email, chat, and developer tools.

Even small alerts add up. Teams investigate, review, upgrade, test, suppress, document, and coordinate. Over time, vulnerability management becomes recurring unplanned work that slows the delivery of valuable features and updates.

Request the Whitepaper

The full 2026 Software Supply Chain Security whitepaper explains these three findings in detail.

It examines why teams still have unknown exposure to risky dependencies, how security-driven upgrades create regression risk, and why recurring vulnerability work can quietly delay valuable software delivery.

Based on 500 qualified respondents, follow-up interviews, and analysis of common vulnerability management practices, the report also serves as a practical benchmark for how organizations actually handle vulnerability alerts, dependency upgrades, remediation decisions, and process breakdowns.