Cover image for Securing the Conda-Forge Supply Chain
Written on

Securing the Conda-Forge Supply Chain

Wolf Vollprecht
Wolf Vollprecht
Pavel Zwerschke
Pavel Zwerschke

The past weeks have shown that we need to take a more active stance to secure the conda-forge ecosystem. We’re happy to talk about added security measures for our ecosystem.

Dependency cooldown for Pixi

The biggest improvement we shipped in Pixi v0.67.0 is the ability to use relative time for the exclude-newer feature. This means you can now wait for packages to “mature” and security issues to be discovered in the ecosystem before upgrading your pixi lockfiles. Setting exclude-newer = “7d” will wait for seven days before pulling in new packages.

[workspace]
exclude-newer = "7d"

# you can also set an absolute date
# exclude-newer = "2025-01-01"

Pavel Zwerschke (our newest Pixi core maintainer from QuantCo) worked hard on this feature. We also made sure that exclude newer applies both to Conda and PyPI packages. Thanks to our deep integration with uv we could ensure this quite easily.

Channel and Package based cool-down

Lastly, there might be channels or packages that you fully control. For these cases it’s possible to override exclude-newer on a channel- and package level.

[workspace]
name = "my-workspace"
channels = [
  "conda-forge",
  # get most recent versions of packages you control
  { channel = "https://prefix.dev/my-internal-channel", exclude-newer = "0d" },
]
exclude-newer = "14d"
platforms = ["linux-64", "osx-arm64", "win-64"]

# Define the rest of your pixi.toml

[exclude-newer]
# CVE-XXXX-YYYY: allow the fresh fixed build immediately
python = "0d"
# CVE-XXXX-YYYY: allow the fresh fixed build immediately
openssl = "0d"

We also tested a large number of edge-cases: pixi-build, PyPI sdist builds, … - to make sure that excluding newer packages works reliably in all kinds of situation.

Read more in our documentation.

Other supply chain security features we shipped

Pixi already has a few security features:

  • Pixi does not execute post-install / pre-unlink scripts by default. They are usually "hidden" and can execute arbitrary code.

  • We implemented Trusted Publishing on prefix.dev and added Sigstore attestations with CEP-27 to follow best practices pioneered by PyPI and NPM.

  • From day 1 we used Bearer Tokens (Conda by default uses less secure tokens-in-the-url).

  • We're supporting Anaconda engineers to push a CEP for upload-timestamps (PyPI has the concept of upload-time that we are currently lacking in conda-forge for even better cooldown).

Taking a more active stance

We skirted by the biggest supply chain attacks in the conda-forge universe with a bit of luck (and an “automatic” cooldown that is inherent to the conda-forge model where packages are often repackaged from PyPI and other sources).

However, luck doesn’t cut it. This is why we are determined to take a more active stance for our conda-forge mirror. The first step is that we are implementing the ability to quarantine packages as soon as we hear about something fishy going on. This will allow us, at prefix, to make fast decisions about removing potentially dangerous packages from the index - better safe than sorry.

Acting on our own mirror is faster than going through conda-forge -> Anaconda -> the prefix.dev mirror. This does not mean that we would not simultaneously make the required changes in conda-forge to protect users everywhere.

If you spot any security issues on prefix.dev, please our contact form or the Report Issue knob in the user menu and we will take action asap.

Mapping out the CVEs in conda-forge

Today, it is possible to use tools like Grype to scan Pixi environments for CVEs. It's easy to install with pixi global install grype and to use. Running grype .pixi/envs will scan the (materialized) conda environments against the grype CVE database.

We've started work on a CVE mapping for our conda-forge mirror, so that we can continuously track which known CVEs affect packages in the ecosystem, surface that data in Pixi itself, and offer CVE alerting as a feature on our platform.

But CVE mapping shouldn't be a prefix.dev-only effort, and it shouldn't live behind any single vendor's walls. The conda-forge ecosystem underpins a huge amount of scientific computing, robotics, data science, and ML infrastructure and the mapping from conda-forge packages to upstream CVE identifiers (CPEs, PURLs, upstream project names, vendored dependencies) is genuinely hard, genuinely shared work. Every downstream tool like Pixi, mamba, conda, rattler, security scanners, and enterprise distributions benefit from the same underlying dataset.

That's why we are looking into forming a conda-forge security special interest group, with a first deliverable: an open, community-maintained CVE mapping for conda-forge. We want this SIG to bring together multiple stakeholders from across the ecosystem.

To make this sustainable, we're also planning to pursue funding from organizations that support open source security infrastructure like NumFOCUS and the Alpha-Omega project, and similar funders whose mission is exactly this kind of cross-cutting ecosystem work. A funded, open CVE mapping for conda-forge would be a meaningful step toward bringing more security to the ecosystem.

If you'd like to be part of this SIG as a contributor, a stakeholder, or a potential funding partner please reach out via our contact form. And if you spot any security issues on prefix.dev in the meantime, please use our contact form or the Report Issue button in the user menu; we'll act on it as fast as we can.