# Mitigating Supply Chain Security Risks in Data Science > A Posit whitepaper on securing the open-source package supply chain for Python and R. It maps the threat landscape across PyPI, CRAN, Bioconductor, and the Open VSX extension registry, then details the layered controls in Posit Package Manager that mitigate those threats: curated repositories, vulnerability and license blocking, Posit-built binaries, package cooldown, unified private/public repositories, and Open VSX extension mirroring. Published August 2026. The full PDF is available behind a short form. Publisher: Posit Software, PBC (formerly RStudio, PBC) Audience: IT leaders, security and platform teams, data science leaders in regulated industries Product: Posit Package Manager Landing page: https://posit.co/[FINAL-URL-TBD] Format: Whitepaper, 13 pages, gated PDF ## Core premise Data science runs on open-source packages, and so do the attackers targeting it. The same openness that lets the Python and R ecosystems thrive makes them a target. There is no single perfect control for every environment; a defensible posture comes from combining strategies into layers that balance risk, cost, and compatibility. ## The four public registries, and two different models of trust - **PyPI** — Permissive. A service of the Python Software Foundation and the largest public Python repository, with over 800,000 projects. Anyone can publish instantly. Maximum collaboration, higher inherent security risk. - **CRAN** — Reviewed. Maintained by the R Foundation. A small team reviews every submission against automated validation checks and CRAN policies. Not a security audit, but meaningful oversight that PyPI lacks. - **Bioconductor** — Peer reviewed. R packages for genomic analysis, using a review methodology similar to CRAN's with peer review and stringent submission standards. - **Open VSX** — Permissive. Maintained by the Eclipse Foundation, the primary open-source extension registry for VS Code-compatible editors including Positron and Posit Workbench. No formal review, so risk comparable to PyPI. Review is oversight, not a guarantee: review teams are small relative to submission volume, and determined adversaries have circumvented them. ## Threats covered - **Vulnerabilities in compiled code** — Many Python and R packages ship C, Java, or Fortran code. Once compiled, vulnerabilities are far harder to identify, and they need not be malicious: compiling against outdated libraries or a compromised toolchain has the same effect. Recent exploits have targeted build infrastructure directly, so even a low-risk package can be compromised during packaging. - **Compromised package updates** — Attacks that target maintainers rather than infrastructure. Stolen credentials or a malicious contributor accepted through social engineering can put harmful code in a legitimate package with years of established reputation, defeating reputation-based evaluation. Abandoned packages compound this: unlike CRAN, PyPI does not proactively flag inactive maintainers, making dormant accounts on widely depended-upon packages high-value targets. The XZ Utils backdoor (CVE-2024-3094) is the most documented case, where an actor spent roughly two years earning maintainer trust before inserting a backdoor into a build process. - **Package confusion** — Exploits the delivery infrastructure rather than an individual package. Typosquatting publishes a malicious package under a name similar to a popular one. Dependency confusion publishes a public package matching the name of an organization's internal package, expecting some users to install the public one by mistake. - **Extension-level risk** — Open VSX extensions share the same threat model as packages, but execute with IDE-level privileges on the developer's machine rather than inside a data pipeline, arguably making them higher risk. ## What determines whether a package can be trusted Six factors: download volume and reverse dependencies; dependency count and depth (a trustworthy package can pull in a compromised indirect dependency, a risk compounding with each layer); author reputation; documentation quality; revision history; and the presence of a validation test suite. The R Validation Hub's `riskmetric` package and the newer `val.meter` package automate evaluation against these criteria, but final suitability still requires human review against an accepted level of risk. ## Posit Package Manager mitigations - **The Posit Package Service** — Posit Package Manager does not fetch from PyPI or CRAN directly. Packages, metadata, and vulnerability data come from the Posit Package Service, a Posit-operated CDN that evaluates upstream repositories each business day and publishes new snapshots when changes are detected. Installations need no direct network access to public repositories, which eliminates a class of man-in-the-middle paths and simplifies network policy in restricted and air-gapped environments. Each snapshot is a fixed, immutable state of the upstream repository identified by a `YYYY-MM-DD` alias, which underpins both reproducibility and configurable sync delay. - **Curated repositories** — The most risk-averse strategy: block public repositories entirely and evaluate every package before it reaches an internal server. Administrators include only approved packages from public repositories and internal sources, so users never need direct access to public servers. - **Posit-built binaries** — CRAN supplies team-built binaries for Windows and macOS; Posit extends this to Windows, macOS, and nearly a dozen Linux distributions. Every build runs from scratch in a clean, ephemeral environment with updated build tools and dependencies from trusted sources. Roughly 200,000 package builds per month, 12+ platforms and Linux distros, 5 R releases supported. - **Vulnerability blocking** — Expose an entire public repository while blocking harmful packages. Posit aggregates five advisory sources into OSV format, refreshed several times a day and delivered over the same CDN: the Python Packaging Advisory Database (PyPA), the RConsortium Advisory Database (developed by Posit with the R Consortium), the OpenSSF Malicious Packages Database, the GitHub Advisory Database (including packages installed from GitHub via pip), and NIST's National Vulnerability Database. - **License-type blocking** — Restrict packages by declared open-source license, or allow only approved licenses. Not a security control in the traditional sense, but part of risk management. - **Custom blocking rules** — Deny packages by name or specific version. Rules can be prioritized, reordered, and given exceptions, either globally or scoped to designated repositories. - **Package cooldown** — Most suspicious packages are identified and removed from PyPI within the first week, often within hours. A cooldown sets a minimum age a version must reach before users can install it, letting community detection work first. Two implementations: a repository-wide sync delay that serves only snapshots older than a set number of days, creating a rolling quarantine; and a rule-based `--min-age` blocking rule that gates individual package versions. The rule-based approach composes with exceptions, per-source or per-repository scoping, and stacking with vulnerability, license, and custom rules. Both can run together where repositories need different policies. - **Unified private and public repositories** — Eliminates dependency confusion by serving internal packages first from a single repository URL, while retaining access to the full public repository. Protection holds even if someone later publishes a public package matching an internal name. - **Open VSX extension mirroring** — Extensions are mirrored through the same Posit Package Service CDN used for CRAN and PyPI, with the same OSV-based vulnerability detection and blocking. Organizations can make Posit Package Manager the sole extension source, preventing direct registry access and extending dependency confusion protection to the editor; internal extensions are served ahead of public ones. One difference: Open VSX snapshots filter on extension published timestamps rather than the deterministic historical snapshot model, so a snapshot reflects extensions published on or before a date that remain in the registry today, not a fully immutable historical record. Rarely significant for security posture, but relevant under strict reproducibility requirements. ## Two strategies, and the trade-off between them - **Bottom-up (lowest risk)** — Start with an empty repository and layer in trusted packages approved through manual and rule-based evaluation. Lowest risk, but many organizations lack the resources to run a request/approval process or the expertise to evaluate package risk. - **Top-down (most flexible)** — Start with a full mirror of a public repository and block packages deemed high-risk against any number of criteria. Broader compatibility for exploratory work, often preferred where regulatory requirements are less stringent. ## New in this edition The Posit Package Service CDN architecture, package cooldown and minimum-age rules, VS Code extension governance via Open VSX, and expanded blocking by vulnerability, license, and custom criteria. ## Get the whitepaper - [Mitigating Supply Chain Security Risks in Data Science (gated PDF)](https://posit.co/[FINAL-URL-TBD]): Full 13-page whitepaper with architecture diagrams. Requires a short form. ## Related Posit resources - [Posit Package Manager](https://posit.co/products/enterprise/package-manager): Distribute and manage secure, scalable package repositories for Python and R. - [Public Package Manager](https://posit.co/products/enterprise/public-package-manager): Discover and install Python and R packages from CRAN, PyPI, and Bioconductor. - [Posit Package Manager documentation](https://docs.posit.co/rspm/admin/): Administrator guide, including blocking rules and snapshot configuration. - [Solutions for IT Leaders](https://posit.co/solutions/it-leaders): Governance, security, and platform management for data science environments. - [Posit Trust Center](https://trust.posit.co/): Security, compliance, and privacy documentation. - [Talk to us about your environment](https://posit.co/schedule-a-call): Schedule a call with the Posit team. ## Citation Posit Software, PBC. "Mitigating Supply Chain Security Risks in Data Science: Layered defenses for open source packages with Posit Package Manager." August 2026.