Earlier this year, Endor Labs surveyed 605 IT professionals across North America, Europe, and India about their programs, controls, and experiences with malicious open source software. The headline numbers from that survey are already published. 

But some of the more interesting findings come from looking at what predicts organizational behavior. Not just what people say they do, but what correlates with actually finding and responding to malware. The patterns that emerge are more structural than most security conversations give them credit for.

Getting hit doesn't reliably unlock investment

Experiencing an incident is often a trigger for change. But a significant survey finding really surprised us: among organizations that had a confirmed malicious package in 2025, one-in-three still expects a flat security budget in 2026.

This isn't a failure of awareness. These are organizations that already lived through an incident. They know what it costs. And a meaningful fraction of them are still not translating that experience into investment. The broader survey shows an 81% top-priority rate for malicious OSS alongside only 48% expecting budget growth. But the confirmed-incident cohort makes that gap harder to explain away as an awareness problem. Something else is going on.

Part of the answer is probably that security leaders are making a case to people who weren't in the room when the incident happened. Or it may come down to practitioners lacking the skills to adequately sell increased program investment. To overcome this delta, security leaders need to connect supply chain investment to business outcomes in language that survives the budget conversation. Incident experience alone doesn't do that job automatically.

Your org structure is shaping your threat model, whether you designed it that way or not

The survey asked respondents how responsibility for software supply chain security is structured in their organization. Five ownership models emerged in roughly equal distribution:

• Centrally led by security
• Shared between engineering and security
• Shared between platform and AppSec
• Platform-led
• No consistent model at all.

When you cross that question against malware detection outcomes, you get a picture that most program recommendations don't account for. 

AppSec-led organizations had the highest rate of any malware detection at 65%. But 43% of those findings were ultimately ruled out, meaning a significant portion of their investigation activity was false positives. Platform-led organizations, by contrast, had the highest confirmed malware rate at 18%, with less noise. Organizations with no consistent ownership model had the lowest confirmed rate at under 9% and the highest 'no malware' rate at 43%.

The instinct is to read that last number as evidence that inconsistent ownership is somehow protective. It isn't. Organizations without a clear ownership structure aren't finding malware because they're not looking hard enough to find it. 

The more useful read is that different ownership structures produce different capability profiles, and those profiles have real consequences. AppSec-led teams own tools that generate findings, which is good, but the data suggests they’re also generating more noise. This doesn’t come as a surprise to us, as noise reduction is a top reason teams use Endor Labs.

Platform-led teams find fewer things but confirm more of what they find. And organizations with fragmented ownership are the slowest to respond: only 19.6% of them triage within hours, compared to a survey average around 30%.

The response speed gap is where inconsistent ownership actually shows up as a risk, not in detection rate. When something goes wrong and the team responsible for responding doesn't know where the controls live, time passes. And with malware, it’s almost always a speed game.

Dependency hygiene isn't just about reducing the attack surface. It's a detection multiplier.

The survey asked respondents to characterize their organization's current state of dependency hygiene: whether they actively remove unused and outdated dependencies, consolidate redundant libraries, and maintain clean dependency estates. The hygiene question was included as a signal of program maturity. What it turns out to predict is something more specific.

Organizations with proactive and ongoing dependency hygiene practices had a confirmed malware rate of 18.8%. Organizations with minimal hygiene effort: 6.6%. That's nearly a 3x gap. On response speed, the difference is larger still: 44% of proactive hygiene organizations triaged within hours, compared to 18% of minimal hygiene organizations.

This gap is too large to be explained by differential targeting. Attackers aren't systematically avoiding organizations with messy dependency estates. The more credible explanation is that organizations with well-maintained dependency graphs are better equipped to find malicious packages. When your estate is bloated with redundant packages, dozens of unused transitive dependencies, and libraries that haven't been touched in two years, the signal-to-noise ratio on any detection effort gets worse. You might have excellent scanning tools, but you're pointing them at a much harder problem.

Hygiene also speeds response. When malware is confirmed, the questions that take the most time — where does this package appear, what pulls it in, which systems are affected — are much faster to answer when someone actually understands the dependency landscape. Proactive hygiene organizations are nearly 2.5x more likely to contain an incident within hours than their minimal-hygiene counterparts, and that difference is almost certainly downstream of the visibility advantage that clean estates provide.

This reframes what dependency hygiene investment is actually buying. It's not just attack surface reduction, though it does that too. It's infrastructure for detection and response, which is a more defensible argument to make internally when competing against feature work for engineering time.

The common thread

None of these gaps are primarily about tooling. Every organization in this survey had access to security tools, and most had at least some controls in place. The patterns that predict better outcomes (confirmed malware discovery, faster response, stronger investment alignment) are organizational ones: who owns the problem and how clean the environment is.

The organizations that are doing better on malicious OSS aren't necessarily running better scanners, though don’t get us wrong- that matters a lot! They're the ones that have made supply chain security a legible program with clear ownership, maintained the dependency estate well enough to reason about it, and ensured that the people who respond know where to start looking.

The full data and methodology behind these findings is in the Endor Labs Open Source Malware Gap report, published March 2026.