Security: published npm package has floating transitive dependencies

[Squixx]

Summary

When users install Renovate via npx renovate or npm install -g renovate, npm resolves
transitive dependency versions at install time using the semver ranges declared by Renovate's
direct and indirect dependencies. This means the installed dependency tree is not
deterministic — npm may download package versions that were never tested, audited, or even
known at the time Renovate was published.

Renovate uses pnpm internally with a pnpm-lock.yaml that pins the full tree. That lockfile
is not shipped in the npm tarball and is not respected by npm. Consumers get floating
resolution instead.

Affected install methods

• npx renovate
• npm install -g renovate
• npm install renovate (as a direct dependency)
• Any Docker image that runs npm install renovate at build time without a lockfile

Concrete example

renovate depends on protobufjs@8.2.0. However, @opentelemetry/otlp-transformer (a
transitive dependency) declares "protobufjs": "8.0.1" as a direct dependency with a
separate older version. protobufjs@8.0.1 in turn depends on @protobufjs/fetch and
@protobufjs/inquire using caret ranges (^1.1.0). These are resolved at install time to
whatever version npm finds in the registry — including packages published after Renovate
itself was released.

This has already triggered blocks in security-hardened environments (e.g. Safe-chain
minimum package age policy):

blocked 2 direct package download request(s) due to minimum package age:
 - @protobufjs/fetch@1.1.1
 - @protobufjs/inquire@1.1.2

Those versions are known-good and tested in our lockfile. But because npm re-resolves them
at install time, they appear as "new" unknown packages from the registry.

Real-world supply chain attacks on transitive npm packages

This class of issue is not theoretical. Multiple supply chain attacks have exploited the gap
between a package's declared direct dependencies and what actually gets installed transiently:

• event-stream (2018) — a transitive dependency of thousands of packages was hijacked
  after the original author transferred ownership. A malicious version was published targeting
  a specific Bitcoin wallet. Downstream consumers received the malicious version because they
  had floating transitive resolution.

• ua-parser-js (2021) — the package was briefly taken over and malicious versions
  (0.7.29, 0.8.0, 1.0.0) were published. Any project with ua-parser-js as a
  transitive dependency (including Facebook's create-react-app) received the malware on
  next install because versions were floating.

• colors / faker (2022) — the maintainer intentionally published breaking/malicious
  versions. Projects with ^ ranges on these packages automatically pulled in the new
  versions.

• axios (2023) — a protestware/malicious version was briefly published. Projects
  floating on ^1.x resolved the new version before it was removed.

• node-ipc (2022) — a widely-used transitive dependency was deliberately sabotaged with
  geopolitically-targeted destructive code. Any project floating on the affected semver range
  received it.

In each case, pinned lockfiles at the consuming project would have prevented automatic
uptake. But for CLI tools like Renovate that are installed directly from npm without a
project-level lockfile, the only protection is publishing a lockfile with the package itself.

Impact

• Users installing Renovate receive a non-deterministic dependency tree
• Security tools (Safe-chain, Socket, Snyk) flag unknown transitive versions
• A malicious or compromised transitive package could be silently included between a
  Renovate release and a user's install
• Renovate, by its nature, has broad access to source code repositories and CI/CD secrets —
  a compromised install could have severe blast radius

Expected behavior

Users installing Renovate via npm/npx should receive exactly the dependency versions that
were resolved in pnpm-lock.yaml at publish time — the same versions CI tested.

References

• npm shrinkwrap documentation: https://docs.npmjs.com/cli/v10/commands/npm-shrinkwrap
• pnpm lockfile specification: https://github.com/pnpm/spec
• Supply chain risk: https://owasp.org/www-project-software-component-verification-standard/

[Squixx]

Possible direction for a solution #43436