Polyglot dependency hygiene: seven myths and what the docs say

Several comfortable beliefs about dependencies fail when you read each tool's own documentation. A lockfile does not make an install safe. A matching hash does not make a package honest. A clean audit in one language says little about another. Here are seven myths, each checked against official docs.

Myth 1: A lockfile means builds are reproducible

Fact: A lock helps, but only if CI installs from it. npm's clean install requires a lock and fails on mismatch, while an ordinary install is a different command. NuGet notes the .NET SDK can add implicit packages whose versions change with the SDK, which can break locked restores. Pin the SDK too.

Myth 2: Every package manager verifies what it downloads

Fact: Not the same way. Go verifies against go.sum and a checksum database. pip verifies only after you supply hashes, and then requires them for every dependency. See integrity by language.

Myth 3: A matching hash means the package is safe

Fact: A hash proves the file is the one that was published. pip's docs frame hash checking as protection against remote tampering and network corruption. A malicious package published with its own valid hash passes.

Myth 4: Installing a dependency only downloads files

Fact: In some ecosystems it runs code. npm's lifecycle scripts run on install, and Cargo runs a build script just before building a package. The npm ignore-scripts setting turns scripts off, though commands that run a named script still run it.

Myth 5: Libraries and apps should treat lockfiles the same

Fact: The docs differ. Cargo's FAQ says the lockfile does not affect consumers of your package. Composer says libraries do not need to commit it. NuGet says a library you do not ship should not check it in.

Myth 6: If one audit tool says clean, we are clean

Fact: Audit tools answer different questions. npm audit sends your dependency tree to the registry for advisories. govulncheck reports whether your code calls vulnerable functions. A clean result from one scope does not carry over to another.

Myth 7: The manifest lists everything that ships

Fact: Manifests list declared packages. Build scripts can compile bundled C libraries, per the Cargo reference, and packages can ship native assets. Scan built artifacts as well as manifests.

Using the list

Take these as prompts for review, not accusations. In each repo, ask which myth the team currently acts on. A common pattern: "we have a lockfile" is true, but CI runs the ordinary install, so the lock has no force.

What to do first

1. Switch CI to locked install modes.
2. Turn on integrity checks where available.
3. Decide a policy for install scripts.
4. Scan artifacts, not only manifests.

Safeguard can help here: it scans dependencies and generates SBOMs, applies reachability analysis so you can sort findings by what your code can actually call, and enforces policies and gates on pull requests. You can try a free scan on a repository to see what it finds.

Quick check

Sources

• npm ci
• NuGet PackageReference
• Go modules reference
• pip secure installs
• npm scripts
• npm config
• Cargo FAQ
• Cargo build scripts
• Composer basic usage
• npm audit
• Go govulncheck tutorial

Last reviewed: 19 October 2026.