How can pnpm mitigate supply chain attacks better

[zkochan]

I have asked this on Twitter (https://x.com/pnpmjs/status/2054276951641129054) and this is a summery of the replies.

🛡️ Security & Configuration Defaults

• Minimum Release Age: Bump the default minimumReleaseAge to >1 day (or make the current setting stricter/more prominent).
• Version Pinning: Change savePrefix default to "" (removing ^ or ~) so package.json pins exact versions by default.
• Strict Builds: Make allowBuilds (or equivalent) more rigorous—e.g., require a specific version or a detailed explanation for the allowance.
• CI Enforcement: Treat any non-frozen install (pnpm install without --frozen-lockfile) as a security event, specifically within CI environments.

---

🔍 Dependency Review & Scanning Tools

• Built-in Diffing: Add commands to easily review changes in node_modules (similar to npm diff).
• Secrets Scanner: Optional built-in credential scanner that runs before installation and fails loudly if secrets are detected.
• Dry-Run Mode: A --dry-run mode that generates full diffs, formatted for easy pasting into an LLM with a security prompt.
• LLM-Powered CI: Feed package.json changes to an LLM during CI to analyze what the new code actually requests or does.
• Security Proxies: Proxy installs through services like Socket Security (via integration or partnership).

---

📦 Lockfile & Reproducibility

• Vendoring: Encourage or simplify the vendoring of dependencies into source control to eliminate the need for install in CI.
• Frozen Lockfiles: Stronger emphasis on --frozen-lockfile; pnpm could warn or block standard installs in sensitive contexts.
• Smart Bumping: A "Pin by Default" system that only auto-bumps minor/patch versions when a known security update is available.

---

🏗️ Sandbox & Isolation

• Sandboxed Execution: Implement pnpm install --sandbox and/or pnpm run --sandbox.
• Environment Isolation: Isolate node_modules or post-install scripts entirely from the host system.
• Unsafe Dependency Detection: Detect and block (or warn against) "unsafe" dependencies, such as direct GitHub URLs.

---

💡 Other Notable Suggestions

• Threshold Installation: Add an opt-in flag for minimumReleaseAge that installs the newest version older than the threshold rather than failing with an error.
• Update Channels: Implement staggered or "unstable" package update channels for tiered testing.
• Hardened Mode: Adopt a "hardened mode" (similar to Yarn) that auto-enables for publish workflows.
• Best Practices: Follow community standards like the npm security best practices repository.
• Ecosystem Limits: Acknowledgment that some fixes must be ecosystem-wide (registry practices, post-mortems) rather than just client-side tools.

[darcyrush]

• Version Pinning: Change savePrefix default to "" (removing ^ or ~) so package.json pins exact versions by default.
• Strict Builds: Make allowBuilds (or equivalent) more rigorous—e.g., require a specific version or a detailed explanation for the allowance.
• CI Enforcement: Treat any non-frozen install (pnpm install without --frozen-lockfile) as a security event, specifically within CI environments.

All three of these would be huge improvements.

We have created scripts to parse package.json files to check for any semver range modifiers and to fail if any are found. Along with --frozen-lockfile (now pnpm ci) this works fine. Would be great if there was a setting in pnpm to enforce this somehow failOnSemverRange: true

[zkochan]

I don't like this solution because if we would all switch to exact versions then that would cause a lot of duplicated packages in node_modules. With ranges we can install one version that satisfies many ranges.

[darcyrush]

Fair point. We follow this advice currently because NodeJS list it as a security best practice even though it indirectly references npm. Its a quick win however and beats trying to educate half of the development team on the nuances of package lock-files.

I guess we should reevaluate this once we fully migrate to a pnpm solution.

[wereHamster]

CI Enforcement: Treat any non-frozen install (pnpm install without --frozen-lockfile) as a security event, specifically within CI environments.

Isn't --frozen-lockfile default when pnpm detects it's running within a CI/CD env?

[kweij]

Yep, that's right (https://pnpm.io/cli/install#--frozen-lockfile), but it never hurts to be specific. Since v11 you can also use pnpm ci as a shorter alias for using the flag

[kweij]

I don't see a mention of ignoreScripts. I have two questions about this:

• Is setting it to false redundant because all scripts of (transitive) dependencies are ignored unless explicitly added to allowBuild?
• Is setting it to true to be able to use the postinstall in my project's package.json (for adding a pre-commit hook) a security risk?

I'm looking for a configuration that BLOCKS all scripts from (transitive) dependencies, but ALLOWS my own postinstall hook.