Zero Trust's Blind Spot: The Unmanaged Package Manager

How R and Python package installs create software supply chain risk

Your security team spent years rolling out Zero Trust. Identity verified. Devices hardened. Network segmented. Conditional access policies tuned.

Then, a senior developer ran pip install reqeusts (note the typo), and none of that mattered. Zero Trust verified the person. It verified the machine. It verified the access path. It did not verify the code that person just downloaded and executed.

Whether your analysts pull from CRAN, PyPI or an internal mirror like Posit Package Manager, the package ecosystem is one of the most prolific software supply chains in most organizations. Without governance, it operates in the open: analysts installing packages several times a day with no review, no approval and no audit trail beyond "it worked".

The good news is that this is fixable. Tools like Posit Package Manager can bring these risks under control, but only if they are configured with governance in mind.

The Attack Surface Is Vast

Typosquatting is the obvious attack vector. Someone means to install requests, mistypes the name and installs something else. If that package is malicious, the attacker does not need to defeat your identity provider. The user installs the payload for them.

But typos are only the start.

Aikido recently documented a related problem in the npm ecosystem that applies more broadly to package governance. Their team claimed 128 package names that were referenced by documentation or package metadata but had not actually been registered. Over seven months, those package names received more than 120,000 downloads. That is package-name confusion, stale documentation and developer habit turning into arbitrary code execution.

Legitimate packages get compromised too. Microsoft Threat Intelligence recently flagged a compromised version of the official mistralai PyPI package. The injected code executed on import, downloaded a second-stage payload and launched it on Linux systems. It also included geo-fenced logic: a 1-in-6 chance of executing `rm -rf` when the system appeared to be in Israel or Iran. The compromised package passed every check until someone happened to notice the malicious code.

Typosquatting and package compromise are only part of the problem. Transitive dependencies drift silently. You install a package you trust, and that package pulls in dependencies you have never reviewed. Those dependencies update. Their dependencies update. Six months later, your environment includes code that did not exist when you first set things up.

That is normal in modern software. It is also a supply chain.

Why the Usual Answers Fall Short

Endpoint Detection and Response (EDR) tools watch for suspicious process behavior, but pip install and install.packages() look exactly like normal work. Because they are normal work. By the time EDR might flag something, credentials may already be exfiltrated.

Manual review does not scale either. A typical data science project pulls in dozens of packages and hundreds of transitive dependencies. Reviewing each one before every analyst can use it would create bottlenecks that teams simply route around. 

Shadow IT wins when the secure path is slower than the work.

This is why package governance has to live in the workflow itself. A policy document is not enough. A quarterly reminder is not enough. The package manager is too close to the day-to-day work.

How To Remediate

The pattern that works is a governed internal mirror, frozen snapshots, vulnerability blocking and project-level lockfiles.

Posit Package Manager does this well for both R and Python. Instead of letting every user pull directly from public repositories, you route installs through a governed package source. That gives the organization one place to apply policy.

You configure a snapshot date so every install.packages() or pip install pulls from a known point in time. You enable vulnerability checks against packages and block anything above your risk threshold. When a new vulnerability surfaces, you know which snapshots are affected and which teams need to move.

That matters. Without snapshots, you are asking, “what did this environment install at some unknown point in the past?” With snapshots, the question gets much cleaner: “which projects used the affected package state?”

The second piece is locking environments on the analyst side.

For R, renv captures exact versions and restores them reliably. For Python, uv provides cross-platform lockfiles and repeatable installs. The internal mirror governs what packages are available upstream. The lockfile records what a project actually uses downstream.

Together, that gives you reproducibility and security without making every analyst manually inspect a dependency graph.

The Unavoidable Friction

Analysts push back on this; developers too. They want the latest packages. They want to experiment freely. They do not want to file a ticket every time they need a dependency. Governance feels like bureaucracy until you catch something and the perceived paranoia is validated.

That is why the process matters. The goal should be a default safe path with visible exceptions, rather than a process that freezes everyone in place.

If someone needs a new package or a newer version, there should be a clear review path. Not a mystery install from a production box. Not a one-off workaround. Not a Slack message that becomes the approval record.

A useful first step is simple: pull your proxy logs.

Count how many unique packages were installed last quarter. Include transitive dependencies. Cross-reference against known typosquatting campaigns and vulnerability databases. Calculate how many of those packages you could actually trace to a project, an approval or a review.

The numbers tend to be uncomfortable. That is the point. You cannot govern what you cannot see.

This Belongs in Zero Trust

The package manager is too prolific to ignore and too risky to leave unmanaged.

Zero Trust assumes access should be continuously verified. For data science and engineering teams, package installation belongs in that same conversation because it is an execution path. A trusted user on a trusted device can still install untrusted code into an environment with access to credentials, data, APIs and internal systems.

The answer is not to stop using open source packages. R and Python are useful because of their ecosystems. The answer is to govern how those ecosystems enter the organization.

A governed mirror with frozen snapshots, vulnerability blocking and locked project environments is not exotic infrastructure. It is table stakes for any organization that takes Zero Trust seriously.

How Lander Can Help

At Lander Analytics, we help data teams put this control layer in place.

That includes configuring Posit Package Manager with the right snapshot policies, vulnerability thresholds and allowlists for your environment. It includes setting up renv and uv workflows so analysts get reproducibility without unnecessary friction. It also includes training teams on the why behind the guardrails, because governance only works if people understand what it is protecting.

If your R and Python package managers are still pointing directly at public mirrors, let's talk.

Travis Knoche Senior Data Scientist

Lander Analytics

---

Subscribe to our Substack and below to our monthly emails for practical AI strategies for your organization: what to build, what to avoid, and how to make systems reliable in the real world.

Work with us: If you want help identifying the right first workflow, building a permissioned knowledge base, or training your team to ship responsibly, reach out at info@landeranalytics.com.

About the author: Travis Knoche is a Senior Data Scientist at Lander Analytics, where he designs, deploys, and maintains data science infrastructure in a wide variety of environments and constraints, and bridges the gap between backend infrastructure and frontend data science development work.