NPM Shrinkwrap - Alert

Information

npm shrinkwrap was introduced as an important tool in the early days of Node.js development to address the challenge of dependency management, but it had some significant drawbacks that were later addressed with the release of package-lock.json in npm 5. The two locking mechanisms have several distinctions:

npm-shrinkwrap.json is useful if you want your module's dependencies to be locked down for anyone who installs it. This file ensures that everyone who installs your module gets the exact same versions of the dependencies.
package-lock.json is used to lock down dependencies for your own development environment and is meant to be checked into your source control, but it doesn't get published with your module.

The package-lock.json file is automatically generated and maintained by npm, whereas npm shrinkwrap requires a manual command to create or update the shrinkwrap file. As a result, npm shrinkwrap became less commonly used, as package-lock.json provided an easier and more streamlined approach to locking dependencies.

In most modern development projects it is preferable to use package-lock.json

npm's docs have a narrow scope of recommended uses:

The recommended use-case for npm-shrinkwrap.json is applications deployed through the publishing process on the registry: for example, daemons and command-line tools intended as global installs or devDependencies. It's strongly discouraged for library authors to publish this file, since that would prevent end users from having control over transitive dependency updates.

While the shrinkwrap file wasn’t created with bad intentions, it essentially lets you completely bypass all normal dependency installation rules. It’s also not caught by most SCA tools. Shrinkwrapping allows a package to install any unsigned code from any host and also override any transitive dependency in your tree.

Some developers might not realize that shrinkwrap files can be included in packages, not just within their own applications. If a package is using this tool, it’s going to raise some red flags and should be investigated. Shrinkwrapped packages require just as much manual auditing as any Node package that has a native / binary module or arbitrary C++ code in it.

Due to these issues, there are some who think it should probably be deprecated. There was a time when it had reasonable use, but most modern software projects will opt for using package-lock.json.

Some of the supply chain risks associated with using npm shrinkwrap include the following:

Risk of Outdated Dependencies

npm shrinkwrap tightly locks down the versions of dependencies and their sub-dependencies, ensuring consistency across environments. However, if the shrinkwrap file is not regularly updated, this can lead to the use of outdated or potentially insecure versions of packages, increasing the risk of security vulnerabilities.

Manual Maintenance

Shrinkwrap files require manual updates and maintenance. If the file is neglected or not updated properly, it can lock the project into using dependencies with known vulnerabilities, thus exposing the application to security risks.

Complexity in Auditing

Shrinkwrap files can complicate the auditing process. Security tools might have difficulty traversing the locked dependency tree effectively, making it harder to identify and address vulnerabilities. This could potentially hide security issues from being flagged during automated scans.

Security Misconfigurations

In some cases, the use of npm shrinkwrap can introduce misconfigurations or conflicts that might be exploited. This can create openings for attackers if not managed carefully.

In 2016, npm warned that npm shrinkwrap allows remote code execution if it contains a HTTP registry URL. This makes it possible to for a local network attacker (MITM) to execute malicious code on your machine. This is highly unlikely but the risk isn’t zero, and the impact would be severe.

Recommended actions

Review the Shrinkwrap File

Start by reviewing the npm-shrinkwrap.json file to understand why it was created and what dependencies it locks. Check for any outdated or potentially vulnerable packages that might be included.

Consider Using package-lock.json Instead

If you don't need the exact version locking provided by npm shrinkwrap, consider replacing the npm-shrinkwrap.json file with a package-lock.json file. The package-lock.json file serves a similar purpose but is generally more suitable for most projects, as it does not get published with the package, reducing the risk of stale dependencies.

Manual Dependency Audit

Perform a manual audit of the locked dependencies to ensure there are no security vulnerabilities. If you find any issues, consider updating or replacing those dependencies with more secure alternatives.

Engage with the Dependency's Maintainers

If the shrinkwrap file is part of a third-party package, consider reaching out to the maintainers to discuss the security implications. They may provide guidance on whether the shrinkwrap file is necessary and how to safely update or remove it.

Configuring Your Security Policy

Socket users may want to set the npm Shrinkwrap alert to Warn, in order to catch these packages and investigate them before incorporating them into your projects.

Examples

Here's an example of a package flagged with this alert:

Clicking on the alert will take you to the file that caused it to be flagged. For this type of alert, the offending file is npm-shrinkwrap.json.

Detection Method

Socket flags npm packages that contain an npm-shrinkwrap.json file. (This alert only applies to the JavaScript ecosystem.)

Additional resources

Understanding the Security Concerns of npm Shrinkwrap

npm docs on shrinkwrap.json

npm docs for package-lock.json

Avoid HTTP URLs in shrinkwrap files

npm shrinkwrap allows remote code execution

Managing Node.js Dependencies with Shrinkwrap