Yes, often. A Python library installed with the operating system package manager is tracked by that manager, not by your requirements file, so a scan of pip manifests never lists it. An image or host level scan that reads the OS package database does see it.
Two package managers, two records
When you run apt install python3-requests, the library lands in the system Python directories and is recorded in the OS package database. Your requirements.txt says nothing about it. A scanner that parses Python manifests sees only what the file lists.
PEP 668 explains why the split exists. It defines a way to mark a Python base environment as externally managed, so that installers like pip refuse to modify packages the OS manager owns, avoiding conflicts such as externally installed packages being deleted. It recommends guiding users toward virtual environments. The result is two worlds: the system environment managed by the distribution, and project environments managed by pip.
Why it matters for scanning
| Where the library came from | Recorded in | Seen by pip manifest scan | Seen by image or host scan |
|---|---|---|---|
| requirements.txt install | Manifest and site packages | Yes | Often |
| Virtual environment | Lockfile if you keep one | Yes | Sometimes |
| OS package | OS package database | No | Yes |
If your app, or a tool in the same image, imports a system library, an advisory against it will not appear in your Python results. It may appear instead as an OS package advisory, under a different package name such as the distribution's own python3- prefix, which complicates matching.
How to check your own images
- Open a shell in the built image.
- List OS packages with names starting with
python3-, using your distribution's package listing command. - List pip installed packages from the interpreter your app uses.
- Compare. Anything in the first list and not the second is invisible to a manifest scan.
- Decide whether the app actually imports it.
Reducing the gap
- Use a virtual environment for application dependencies, and keep a lockfile.
- Avoid installing Python libraries through the OS manager in application images, unless the distribution's tested version is deliberately wanted.
- Always run an image level scan as well as a manifest scan. See scan conda and pip environments for known vulnerabilities.
- When an advisory names a Python library, search both lists.
Which one is patched by whom
OS packages are patched by the distribution through updates to the image. Pip packages are patched by you, through the lockfile. Knowing the source tells you who fixes it. See does the scanner cover containers and base images.
Safeguard offers SBOM and dependency scanning and a free scan at gold.safeguard.sh/scan. Use both manifest and image views for Python workloads.
Quick check
Does PEP 668 stop pip from touching system packages?
It lets distributions mark the environment as externally managed, so pip warns or refuses by default. Details depend on the distribution.
Which scan should I trust for a Python container?
Use both. The manifest scan sees your pinned libraries, and the image scan sees OS level ones.
Sources
Last reviewed: 19 October 2026.
