Cover image for Introducing the Pixi Audit Beta
Written on

Introducing the Pixi Audit Beta

Pixi
Tim de Jager
Tim de Jager

We are releasing a beta version of pixi audit: a tool similar in the vein of pip audit, npm audit, or many of the other ecosystem-specific auditing tools out there.

Why?

conda-forge is special when compared to other ecosystems: it rebuilds from different ecosystems like PyPI, npm and others. But it also sometimes builds directly from source like we do for cmake. Up until now there was not really a vulnerability database for conda-forge. So we decided to start building one, details will be below: spoiler alert it is called Basilisk. But first let me give you a quick tour of pixi audit.

A tour of pixi audit

You can Install the beta from our prefix-labs channel:

pixi global install \
  --channel https://prefix.dev/prefix-dev/prefix-labs \
  pixi-audit

Then, from a pixi workspace you want to check, run:

pixi audit

Pixi discovers the installed pixi-audit executable as an extension. You can also pass a the path to a lock file.

pixi audit path/to/pixi.lock

For a workspace with several environments or platforms, you can narrow the audit. For example, if your lock file contains a production environment for linux-64:

pixi audit --environment production --platform linux-64

The results looks something like:

 ✔ Audited /Users/tdejager/development/pixi/examples/pybind11/pixi.lock [110 packages audited]
 ✔ Scanned for vulnerabilities       [260 vulnerability matches]
   ├── by severity: 9 critical, 89 high, 101 medium, 26 low, 35 unknown
   └── by status:   120 fixed, 140 not-fixed, 0 ignored, 20 unbounded

    Name                    Version  Fixed in                        Vulnerability               Severity  EPSS          Risk   Environments
 C  libsqlite               3.46.1   3.50.2                          CVE-2025-6965               High      72.5% (99th)  55.1   build, default
 C  libssh2                 1.11.0   1.11.1                          CVE-2023-48795              Medium    93.3% (99th)  50.9   build
 C  openssl                 3.3.2    3.6.1                           CVE-2025-15467              Critical  48.2% (98th)  44.1   build, default
 C  libnghttp2              1.58.0   upstream: 1.61.0                CVE-2024-28182              Medium    85.0% (99th)  43.8   build
 C  openssl                 3.3.2    3.3.3                           CVE-2024-9143               Medium    5.8% (92nd)   2.7    build, default
 C  krb5                    1.21.3                                   CVE-2007-5894 (unbounded)   High      2.7% (85th)   2.3    build
 C  openssl                 3.3.2    3.4.1                           CVE-2024-12797              Medium    2.5% (84th)   1.4    build, default
 C  libxml2                 2.12.7   2.13.9                          CVE-2025-49796              Critical  1.6% (74th)   1.4    build
 C  python                  3.11.10  upstream: 3.13.4                CVE-2025-4517               Critical  1.4% (71st)   1.3    build, default
 C  openssl                 3.3.2    3.5.4                           CVE-2025-9231               Medium    2.2% (82nd)   1.3    build, default

You also get a report overview and a list of next steps:

 Assessment
   • Highest finding prioritization score:  55.1 / 100
   • CISA KEV matches:                      0 CVEs
   • Critical/high findings:                98
   • Fix available in audited ecosystem:    120 of 260 vulnerabilities across 17 audited packages
   • Fix only upstream:                     35 vulnerabilities
   • No known fix:                          105 vulnerabilities

 Next steps
   • Re-run this audit with `--fix` to ask pixi to update 15 package names. Fixed releases in the audited ecosystem are available for 120 vulnerabilities.
   • 35 vulnerabilities have fixes only upstream. `--fix` cannot install them. Wait for an ecosystem build or change dependency source.
   • 105 vulnerabilities have no known fix. Remove, replace, or mitigate the affected dependencies. Use `pixi audit ignore <ID> --until-fixed` only after accepting the risk.

Don't know what any of this means? pixi audit --explain explains and links some common terminology used in these reports.

Fix automatically

To ask pixi audit to update dependencies with known fixes, run:

pixi audit --fix

This can change your manifest and lock file. The process:

  1. First it raises versions, matching direct dependency constraints to the lowest known compatible fixed version, preserves existing upper bounds,

  2. runs pixi update, and pixi audit again. It leaves transitive dependency constraints and unversioned Git, path, or URL dependencies alone.

You can add ignore rules for packages or specific CVE's either by adding these to the manifest, or using the CLI to add these automatically.

Use it in CI

You can use pixi audit in CI, the following changes the point at which it returns a 1 exit code:

pixi audit --severity high

JSON and SARIF output are available for tooling that expect such.

What the beta covers

The current audit covers conda-forge and PyPI packages, and does certain simple fixes.

Basilisk and the purl-associator

To power pixi audit and potentially other security features in the future, we decide to start a conda-forge vulnerability database and automated mapping system called Basilisk.

Because, conda-forge repackages or takes sources that have been represented in other vulnerability databases like osv (Open Source Vulnerability DB) or the nvd (National Vulnerability Database). We need to establish the link, or what we call the identity between a conda-forge package and another packaging ecosystem (we use PURL), or a software distribution (we use CPE).

Anyone can help us establish identity for conda-forge packages today! Please do so, this way we can identify and audit more vulnerabilities. We are looking into ways to include this mapping information directly in conda-forge in the future, but a good baseline (meaning a mapping to identities) helps us to hit the ground running.

Whats next?

We have more ideas to make this great, the next things we want to look into are:

  • While a lot of the mapping is automated we want the ability of being able to say that a specific vulnerability does not apply to our ecosystem. For this, we are looking into adding support for OpenVEX directly, allowing us to note if a vulnerability applies or is irrelevant for conda-forge.

  • Conda-forge also ships Rust binaries, or other binaries that bundle dependencies statically linked into a final executable. These may pull in more vulnerabilities while this information is not in the lock file. We want to utilize Software Bill of Material (sbom's) per package for a more extensive audit.

How can you help?

We'd like you to try pixi audit on a real workspace and tell us where it falls short. Reports of incorrect matches, missed advisories, and confusing output are especially useful. We're also interested in how the findings fit into your team's update and CI workflows.

Share feedback or any problem on Discord.

Security as a Product

We are taking security more serious for conda-forge, both in the light of LLM's finding vulnerabilities at record pace - but also as regarding upcoming regulation like the Cyber Resilliency Act (CRA). If you are interested in this as well we'd love to talk! Or take a look at some of our security product page.

Thanks for reading as well, shoot us a message on Discord, or contact us directly.