Endor Labs recently surveyed 605 IT professionals across the US, UK, Germany, and the Netherlands about how their organizations are defending against malicious open source software. The full findings are published today in Malware in Open Source Ecosystems: Everyone's Problem, Nobody's Program. 

At the end of the survey, we asked an optional open-ended question: When you think about malicious OSS dependencies, what's the scenario you're most worried about in your environment, and why?

About one in four respondents answered it. This post is about what they said.

The structured survey questions tell you what people do and what they report experiencing. Open-ended responses tell you something different: what keeps them up at night, in their own words, without answer choices to anchor them.

141 usable responses came back across seven distinct fear categories. What follows is each one, in the words of the people who live with these risks.

Credential and secrets theft

The single most common fear, appearing in roughly 23% of comments, is not disruption or downtime. It is quiet, targeted theft of credentials, API keys, and customer data. Practitioners understand that for many malicious packages, exfiltration is the point. The package gets removed from the registry within days; what it took does not come back. Exfiltrated secrets become the initial access vector for whatever comes after.

"Leak of secrets which will lead to bigger compromise in the future. For example trufflehog deployed as part of the shai hulud 1/2 npm compromise was a real headache — we had to rotate a lot of secrets. From SecOps perspective and knowing that compromised credentials/secrets are one of the most common initial breach vector, this makes me and my team paranoid."
— Individual Contributor, Security Operations/Detection & Response/Incident Response, Scotland

"Malicious packages making their way into software that is deployed into production and stealing credentials or exfiltrating customer data. These situations can lead to breach level events that destroy trust in an organization and can severely hurt business."
— Senior Director, Product Security, United States

CI/CD pipeline propagation

At 21% of comments, “pipeline propagation” is the fear that a malicious package enters an automated build system and spreads across services before any human has the opportunity to review it. The build pipeline is not just a delivery mechanism, it is an amplifier. A package that reaches your build environment can reach everything downstream, automatically, at machine speed.

"I'm most worried about a bad open-source package getting into our build system, because the build system has access to important secrets and automatically sends code into production. If a malicious dependency gets in there, it could spread to every service before anyone notices."
— Senior Manager, Security Engineering, United States

"I think the biggest worry would be a supply chain attack becoming automated: one where a bad package gets injected into our CI/build pipeline... the code may be automatically pushed into production before any manual review can detect the threat."
— Manager, Security Engineering, Germany

This fear connects directly to one of the sharpest disconnects in the broader survey: 88% of respondents agree that the first days after a new package release are the highest-risk window, yet only 21% enforce a cooldown period before adopting newly released versions. Awareness of the risk and protection against it are not the same thing.

Visibility and detection failure

Also at 21%, detection failure is distinct from the other fears in an important way: it is not a fear about what the malware does. It is a fear about never knowing it was there. Practitioners in this category are not describing a response problem, but rather they’re describing a blindspot.

"That we do not find out a dependency is malicious."
— C-level Executive, Security Operations/Detection & Response/Incident Response, The Netherlands

"The lack of control makes it impossible to be sure that internal dev teams, but also external applications are secure. This makes it possible to overlook something and have a long-running risk and possible breach."
— Individual Contributor, Security Operations/Detection & Response/Incident Response, The Netherlands

"Concern is delayed detection of malicious dependencies due to incomplete visibility into transitive dependencies and legacy components, which can slow confident remediation."
— Individual Contributor, Security Engineering, India

The broader survey data gives this fear a structural foundation: 24% of respondents report little to no centralized visibility over where their dependencies come from or how they change, and 41% of individuals say they have little to no visibility into their organization's dependency intake controls. When detection does happen, it is spread across developer machines, CI/CD pipelines, artifact repositories, and production environments.

Account takeovers (ATOs)

Perhaps the biggest surprise given the prominence of ATOs in 2025 is that just ~11% of comments center on a specific betrayal of trust: a legitimate, reputable, widely-used package being compromised and weaponized. The threat actor inherits the reputation the maintainer built. Every downstream consumer who trusts that package inherits the risk.

"Previously safe and reputable OSS being compromised and taking too long for community to notice."
— Senior Manager, Software Engineering, United States

"I'm most worried about a legitimate package being taken over and used for malicious purposes. The impact can be hard to track down."
— Senior Vice President, DevOps/Platform Engineering, United States

"This is a risk because smaller orgs tend to trust well-known libraries and don't have security teams monitoring every update. One malicious update could steal credentials, expose customer data, or open a backdoor and it could go unnoticed for a long time."
— Senior Manager, Software Engineering, India

Of the 1,011 npm account takeover advisories ever recorded in OSV, 930 were filed in 2025 alone — a roughly 12x year-over-year increase. Attackers are not going after obscure packages: among 2025 npm ATO victims, 38% had more than 1,000 monthly downloads and 11% had more than 100,000.

Governance, process, and the human factor

Also at 11%, this category is different in character from the others. It is not a fear about a specific attack technique, instead it’s a fear about organizational failure creating the conditions for attackw to succeed. Controls that exist on paper but are not followed. Dependencies installed without review. Leaders who do not treat the problem as urgent.

"Devs using OSS dependencies without proper approvals from security teams."
— Individual Contributor, Security Engineering, India

"Dev installs a new dependency without any oversight."
— Senior Manager, Software Engineering, Canada

"That leaders don't always see the problem as urgent as getting other work done."
— Manager, Software Engineering, Canada

One response captures the organizational inertia that sits behind the concern-to-investment gap documented in the full report, and perhaps illustrates a lack of understanding about how malware differs from CVEs:

"I'm not worried, everybody knows we're vulnerable to that and nobody wants to fix it, because it's running fine so why bother."
— Manager, Software Engineering, Germany

That response is a minority view, but it is a real one. And the conditions it describes are not unusual.

Deeply embedded malware

At 10% of responses, this fear is about remediation more than detection. The malicious package is found, but is so deeply embedded in the codebase, so foundational to how the application is built, that removing it is not a quick fix. It is an architectural project.

"Almost certainly vulnerabilities being found in older legacy packages that underpin the majority of our environments and would require large architectural changes to remediate."
— Vice President, Software Engineering, Northern Ireland

"Something that affects our core dependencies is the worst case scenario. Dependencies that can't be hot-swapped with a small code change."
— Manager, Software Engineering, England

"There is a legacy dependency that will break with no workaround and will shut down production and need to be significantly rewritten. We may not have the staff retained with the knowledge base to work on it."
— Senior Manager, Security Operations/Detection & Response/Incident Response, United States

The broader survey puts a number to this: 17% of respondents cite deeply embedded dependencies as a top barrier to faster incident response. Once something foundational is compromised, the options narrow fast.

Transitive Dependencies

At 9% of comments, transitive dependency fear is specifically about invisible attack surface. Dependencies nobody explicitly chose, pulled in by the packages that were chosen, which pull in more. Direct dependencies get reviewed; transitive ones largely don’t because poor visibility and high volume makes comprehensive review impractical.

"The scenario that worries me the most is a quiet, widely-used transitive dependency getting compromised and exfiltrating secrets at build or runtime and doing it just subtly enough that it blends into normal behavior."
— Senior Manager, Software Engineering, The Netherlands

"We're most concerned about a compromised transitive dependency being introduced through a routine update and propagating through CI before it's detected, especially if it's widely used and difficult to replace quickly."
— Individual Contributor, DevOps/Platform Engineering, United States

"A malicious dependency being introduced through a trusted transitive package shortly after release, before community signals or advisories are available. This is concerning because it can bypass initial trust assumptions and impact build pipelines or developer environments before detection."
— Individual Contributor, Security Operations/Detection & Response/Incident Response, India

Engineering and security are worried about the same things

There is a common assumption that security concerns live in security teams, and that engineering teams “don’t care.” The comment data does not support that. 

When responses are split between engineering roles (Software Engineering, DevOps/Platform Engineering, SRE, DevSecOps) and security roles (AppSec, Security Engineering, SecOps/IR, Product Security), the theme distribution is nearly identical. Credential theft and pipeline propagation are top concerns for both groups at comparable rates.

The difference is not what they worry about, it’s how they describe it. 

Engineering respondents tend to frame risk operationally: what happens to the pipeline, the build, the deployment. 

Security respondents tend to frame the same risk organizationally: who would know, who is accountable, whether the controls that exist on paper are actually working. That framing gap may itself be part of why ownership of malicious OSS risk remains fragmented.

Seniority shapes what feels most urgent

The most consistent pattern in the data is seniority-based:

• Individual contributors are the most likely to name governance and process friction as a concern, which tracks: they are the people navigating approval workflows and making daily dependency decisions with incomplete tooling. 
• Managers and Senior Managers concentrate on pipeline propagation and credential theft — the blast radius of something getting through the systems they are accountable for. 
• Directors and above (n=19, directional) shift toward detection and visibility as the primary fear, and toward embedded legacy dependencies as a secondary one. 
• Senior leaders are describing organizational blindspots. The worry at that level is not how an attack works. It is whether they would know it happened.

Research Methodology

The findings in this post are drawn from responses to a single optional open-ended question in a broader survey of 605 IT professionals conducted January 26 to February 10, 2026, across the US, UK, Germany, and the Netherlands. Respondents held roles spanning Software Engineering, DevOps/Platform Engineering, Site Reliability Engineering, DevSecOps, Application Security, Security Engineering, Product Security, and Security Operations/Detection and Response/Incident Response.

141 of 605 respondents (23%) left a substantive response to the open-ended question. Participation rates were consistent across roles, ranging from 20% to 24% for most functions. Security Engineers were the exception at 33%, suggesting stronger motivation to articulate specific concerns.

Responses were coded thematically. Because many responses addressed more than one concern, theme percentages sum to more than 100%. Seniority-band analysis at Director level and above covers 19 respondents and should be treated as directional rather than statistically definitive. The full survey methodology, including confidence intervals and margin of error, is available in the full report.