Why do Python wheels bundle shared libraries, and what does a scan see?

To make one wheel run on many Linux systems, packagers use auditwheel repair, which copies the external shared libraries a wheel needs into the wheel itself. That helps users, but those copied libraries are not listed as Python dependencies, so an inventory built from package metadata alone may not show them.

What auditwheel does

The project README describes two relevant commands. The show command lists external shared libraries a wheel depends on beyond those the manylinux policies allow, and checks extension modules for symbol versions that exceed the manylinux ABI. The repair command copies those external libraries into the wheel and edits the runtime search path entries so the bundled copies are found at runtime.

The README says this accomplishes a similar result to static linking without needing build system changes. It also carries a note that bundling, like static linking, may implicate copyright concerns for packagers.

The goal is compatibility. Wheels tagged for the manylinux standards are meant to work across a wide range of Linux distributions, and bundling is how a package that needs, say, a compression or crypto library gets there without asking the user to install it.

Why this matters for security work

A Python dependency list names Python packages. A bundled shared library is a different thing: a compiled library inside a Python package, with its own version and its own vulnerabilities.

Consider what each view tells you.

If a vulnerability is announced in a native library, your Python level inventory may show nothing named after it, while a copy sits inside a wheel. This is an inference from how bundling works, not a claim about any specific tool, so check what your own scanner reports for a wheel you know bundles libraries.

A practical check

1. Pick a compiled package from your dependency set.
2. Download its wheel, or find it in your cache, and list the contents. A wheel is a zip archive, so any unzip tool works.
3. Look for shared library files in a directory the packager added, and note their names and versions.
4. Compare that list to what your scanner and SBOM reported for the same package.

python -m pip download --no-deps --only-binary :all: somepackage -d wheels
unzip -l wheels/somepackage-*.whl | grep -E '\.so'

If the bundled libraries are missing from your reports, you have found a gap to document and plan around.

What to do about it

• Ask the packager. Mature projects often state which native libraries they bundle and how they track them.
• Track upstream releases. When a native library has a security release, check whether packages you use have rebuilt their wheels.
• Prefer recent releases of compiled packages. Rebuilt wheels pick up library fixes.
• Record the gap. If your inventory cannot see bundled libraries, say so in your risk register rather than implying full coverage.

Related reading: what is inside a sdist and a wheel and how to read a wheel filename and its tags.

Safeguard's SBOM generation and dependency scanning cover the Python packages in your projects, and reachability analysis helps decide which findings matter. For bundled native code, run the wheel contents check above and add what you find to your records. A free scan is available at gold.safeguard.sh/scan.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how checking whether vulnerable code is actually used changes the list you must act on.

Quick check

Sources

• auditwheel README

Last reviewed: 19 October 2026.