Python Dependency Security

It's easy to think of a dependency as 'just some code that provides a function I call' — but the reality is more consequential: once pip install-ed and imported, a dependency's code runs with *exactly* the same permissions as your own code, with no default sandboxing, no restricted filesystem access, no restricted network access, nothing preventing it from doing anything your own code could do. A dependency can read your environment variables (including any secrets stored there, tying directly back to the Secrets Management lesson), read arbitrary files on disk, make outbound network requests to anywhere, or execute arbitrary further code — all without your own application code needing to explicitly grant any of that access.

This is precisely why a real, well-documented and increasingly common attack vector targets the software supply chain rather than your own code directly: compromising a popular package (through a maintainer account takeover, a malicious update slipped past review, or a deliberately similarly-named 'typosquatting' package) gives an attacker the exact same broad access your own application has, distributed automatically to every downstream project that installs it — a single compromise reaching potentially thousands of systems, rather than needing to attack each one individually.

This doesn't mean dependencies should be avoided — the entire modern software ecosystem depends on reusing well-tested, community-maintained code rather than reimplementing everything from scratch. It means the trust extended to every dependency (and every one of *its* dependencies, recursively, down the full tree) is a genuine, real security consideration, not merely a correctness or licensing one — and the depth of the dependency tree doesn't reduce that responsibility: a vulnerability three levels deep in a transitive dependency you never directly named is still fully your production risk.

pip-audit (and similar tools — safety, and uv's own increasingly integrated scanning capabilities) checks your actual, currently-installed dependency versions against a maintained, continuously-updated database of *known*, publicly-disclosed vulnerabilities (sourced from advisories like GitHub's Security Advisory database, referenced by the GHSA-... identifiers in its output). This is a direct, mechanical, and genuinely actionable check — not a guess or a heuristic, but a lookup against documented, real vulnerabilities specific to the exact package and version you have installed.

The output's specificity is what makes it genuinely useful rather than merely alarming: it names the exact affected package and its currently-installed version, references the specific vulnerability by its tracked identifier (letting you read the actual advisory for details on severity and exploitability), and — critically — states the exact fixed version to upgrade to, turning a vague 'you might have a security problem' into a concrete, actionable 'upgrade requests from 2.25.0 to 2.31.0 or later.'

Running this kind of scan regularly — as part of CI, ideally on every dependency change and on a scheduled basis independent of code changes (since a package that was safe when installed can have a new vulnerability discovered and disclosed *after* installation, with no code change on your end at all) — closes the loop on dependency risk: knowing about a vulnerability the moment it's disclosed and publicly tracked, rather than discovering it only when it's actually exploited.

The Dependency Management lesson covered lock file hashes primarily through the lens of *reproducibility* — guaranteeing the exact same bytes install on every machine, every time. There's a second, distinctly security-focused reason those hashes matter: they defend against a compromised package registry (or a compromised connection to it) silently serving different bytes than what was originally resolved and verified, for what claims to be the same package name and version.

Without hash verification, pip install package==1.0.0 trusts that whatever bytes the registry currently serves for "package" version "1.0.0" are genuinely the same bytes that existed when that version was first published and reviewed — an assumption that a compromised registry, a compromised CDN in front of it, or a man-in-the-middle attacker on an insecure connection could violate, serving malicious, tampered content under a legitimate, trusted-sounding package name and version number. pip install --require-hashes (and uv sync's default, built-in behavior) verifies the downloaded bytes' cryptographic hash against what's recorded in the lock file *before* installing, refusing to proceed if they don't match exactly — catching this specific tampering scenario regardless of how convincing the tampered package's name and version claim to be.

This is a genuine defense-in-depth measure, distinct from and complementary to vulnerability scanning: scanning catches *known*, already-disclosed vulnerabilities in legitimate package versions; hash verification catches *tampering* — a package claiming to be a specific, previously-verified version but actually containing different, unverified, potentially malicious content. Both matter, and neither substitutes for the other.

A dependency's own dependency's own dependency having a known vulnerability is still YOUR production incident — the depth of the tree doesn't reduce the responsibility.

Every installed dependency runs with your code's FULL permissions -- reading files, making network calls, anything your own code could do.

Checkpoint: Does a Python dependency run in any kind of restricted, sandboxed environment by default?

• →No — an installed dependency runs with your code's full permissions, with no default sandboxing or restriction
• →Yes — pip automatically sandboxes installed packages, restricting their filesystem and network access

pip-audit (or uv's built-in equivalent) scans your installed dependencies against a database of KNOWN vulnerabilities -- a direct, actionable check.

Checkpoint: What does pip-audit's output actually tell you, beyond just "there is a vulnerability somewhere"?

• →The specific package, its currently-installed version, the specific vulnerability ID, AND the exact version that fixes it
• →Only a generic warning that "some dependency" might have an issue, without further detail

Lock file hash verification (from the Dependency Management lesson) also defends against a compromised package registry silently serving different bytes than what you originally resolved.

That completes Python Security — secrets, safe file handling, secure serialization, pickle-specific risks, and now dependency security. Next, Python Developer Tools covers the tooling ecosystem that helps enforce all of this automatically.

Confirm Real Dependency Permissions. Finish dependency_is_sandboxed_by_default(): every installed dependency runs with full permissions.