This past week’s spike in npm attacks should be a turning point for how enterprises think about open source (OSS). These aren’t isolated incidents, they’re symptoms of a broader shift in how software is built and attacked.

It’s time we extend Zero Trust principles to OSS consumption. Assume nothing is safe and verify everything. This post outlines what Zero Trust for OSS looks like, why it’s necessary, and how teams can practically implement it.

Why Zero Trust must extend to open source

Modern applications are built on OSS. Roughly 80% of the average codebase comes from external packages, and increasingly those packages aren’t even hand-picked by humans, they’re introduced by AI coding assistants.

That scale creates new attack vectors. Package managers like npm and PyPI have become high-value targets for malicious actors. We’ve seen attackers weaponize malicious uploads, typosquatting, and dependency confusion to deliver malware directly into enterprise build pipelines.

The problem: most AppSec and software development programs treat OSS as safe by default. If it passes scans for CVEs, it’s assumed to be trustworthy. Zero Trust principles say the opposite, never trust, always verify. 

That has to include the OSS code running inside your business.

What Zero Trust for open source looks like

When applied to OSS, this philosophy challenges a dangerous default assumption—that if a package is available in a public registry, it must be safe enough to use. The reality is that registries like npm and PyPI are uncurated, adversary-friendly ecosystems. To bring Zero Trust to OSS, enterprises need to adapt familiar principles:

• Default Deny: Just as Zero Trust network models block inbound traffic until explicitly allowed, no OSS package should be pulled into a build without prior review and approval. This baseline prevents accidental or malicious additions from flowing unchecked into production systems.
  
  
• Continuous Verification: In identity security, a user’s trust is reevaluated each time they request access. The same must be true for OSS: every dependency, direct and transitive, should be continuously monitored against evolving risks—new vulnerabilities, maintainer compromise, or package takedowns.
  
  
• Least Privilege: Minimizing access is a cornerstone of Zero Trust. In the OSS context, this means using only the dependencies you actually need. Remove unused libraries, avoid bloated frameworks, and scrutinize over-permissive packages that introduce unnecessary risk.
  
  
• Assume Compromise: A mature Zero Trust architecture prepares for breach by containing blast radius and enabling rapid recovery. For OSS, this translates into having predefined remediation paths: knowing how to patch, roll back, or replace dependencies when they are inevitably compromised.
  
  
• Visibility and Provenance: Zero Trust emphasizes complete visibility into users, devices, and data flows. Applied to OSS, enterprises need transparency into what packages are in use, where they came from, and who maintains them. Without that visibility, you can’t enforce policy or respond effectively.

Together, these principles define a new security model for consuming OSS. But principles alone aren’t enough, enterprises need practical, enforceable controls to put Zero Trust into practice. That’s where tactical safeguards come in.

Tactical controls to enable open source trust

Principles set the direction, but controls make them real. Extending Zero Trust to OSS means converting principles to concrete guardrails inside your pipelines and developer workflows. The goal isn’t to slow engineers down, it’s to make secure practices the default.

Pin all dependencies

One of the simplest and most effective safeguards. By pinning dependencies to exact versions, you prevent unexpected updates, whether from maintainers publishing a new release, mirrors serving a different file, or attackers hijacking a package name. This enforces the Zero Trust principle of default deny at the version level.

Delay adoption of new packages and versions

Newly-published packages and versions are disproportionately risky: attackers know the window before discovery is short, so they aim to strike fast. Enforcing a mandatory “cool down” period, where new packages are briefly quarantined before use, allows time to observe for malicious indicators, sudden removals from registries, or maintainer anomalies. This embodies assume compromise: act as if every new dependency could be hostile until proven otherwise.

Use health and risk scoring tools

Not all packages are created equal. A Zero Trust approach requires continuous verification, assessing not just CVE counts, but maintainer reputation, build pipeline security, repository activity, and function-level reachability in your code. Risk scoring tools (such as Endor Labs) bring context to these evaluations, helping security teams focus on the packages that truly matter.

Enforce SBOM & provenance verification

Visibility is non-negotiable. Generating a Software Bill of Materials (SBOM) for every build lets you know exactly what’s running in production. Provenance checks and attestations (VEX, SLSA) verify that the code came from a trusted source. These measures reinforce visibility and provenance, a core Zero Trust adaptation for OSS.

Plan for remediation

When things go wrong, and they will—remediation needs to be fast, precise, and minimally disruptive. Evidence-based tools provide clear guidance: whether a vulnerable function is reachable, what the safest upgrade path looks like, or whether a backported patch is available. This keeps the Zero Trust cycle sustainable, ensuring teams can respond quickly without breaking builds.

Continuously validate code at the source

Most security checks sit downstream from where developers write code, scanning builds or repos after code is committed. Security-focused MCP servers (like the one from Endor Labs) enforce Zero Trust for code and dependencies at the point of creation by validating every dependency and AI-suggested snippet inside the development environment. This helps prevent unverified, untrusted code from entering repositories and CI pipelines.

Endor Labs is built to enable Zero Trust for open source

The tactical controls above outline what Zero Trust for OSS looks like in practice. But implementing them at enterprise scale requires automation, deep analysis, and tools that fit naturally into developer workflows. This is where Endor Labs provides the missing layer: turning Zero Trust from a checklist of controls into a dynamic system.

High-fidelity code scanning and inventory

Endor Labs builds a complete graph of your application to understand exactly how your code calls into your direct and transitive dependencies, and helps us identify phantom dependencies missing from your package.json or requirements.txt files. As a result we have a more accurate inventory and can pinpoint whether or not CVEs are reachable in your application. 

We also scan for malicious code in dependencies and suspicious behavior like typosquatting or hidden install scripts. Ultimately this precision prevents wasted cycles on irrelevant alerts and ensures teams focus only on exploitable risks.

OSS risk intelligence and scoring

Endor Labs tracks more than 150 risk factors for every OSS package covering security, activity, popularity, and operational risks. This makes it easier to detect likely targets like end-of-life projects, or malware ridden dependencies.

Flexible policy engine

Security teams can define requirements, such as “require pinned dependencies” or “block packages below a risk score threshold”, and Endor Labs enforces them across pull requests and pipelines. This is a straightforward way to embed the concepts of default deny and least privilege into development workflows without unduly slowing engineering teams down.

But our real strength lies in our policy engine built on the Open Policy Agent (OPA) and the Rego language. In addition to our pre-built policies that can help you enforce the use of pinned dependencies and lockfiles, mandatory “cooling off” periods for new versions, or low risk scores, you can write any custom policy you want using the risk scoring data in our platform, today over 1B data points for more than 4.5 million open source packages and AI models.

Evidence-based remediation

Endor Labs helps teams get clarity on what to fix, when to fix it, and how to do so without breaking builds. This starts by giving security teams and developers evidence to make prioritization decisions. This starts from whether a risk is reachable at the function-level in code, and extends into impact (will upgrading break my code?) and effort (if it breaks my code, it will take more work to fix). And we offer backported security patches to fix end-of-life or hard-to-upgrade packages. 

Together, these capabilities operationalize OSS Zero Trust, making it possible for enterprises to defend against supply chain threats while keeping developers productive.

The Zero Trust mandate for open source

It’s time security leaders recognize that OSS security isn’t just a nice to have, it’s the new baseline for application security. Our team identified this reality years ago which is why we helped create the OWASP Top 10 Risks for Open Source Software.

Forward-looking security and engineering organizations trust our team to help them implement Zero Trust principles for OSS so they can keep developers building and pipelines while maintaining security across the organization.