Default mistrust: this will change npm v12 to protect your supply chain

GitHub has announced important changes in npm that will arrive with version 12 and are designed to cut back the sabotage techniques in the supply chain that abuse the default behavior of npm install. In essence, what comes is a change of trust by omission to mistrust by omission: scripts and sources of dependencies that are now being executed or resolved will automatically become necessary explicit adoption the maintainer or the running environment.

The measures announced include: the pre-install, install and post-install units scripts shall not be run automatically unless explicitly approved; that the construction of native modules by node-gyp will be subject to the same rule; and that the units brought from Git repositories or from remote URL will no longer be resolved by default. GitHub explains that these changes close covert execution pathways used by attackers, such as the use of .npmrc files in Git dependencies to force malicious executables even when scripts are deactivated. More technical details and the official announcement are available at the GitHub changelog.

The practical impact is double: on the one hand, significantly increases resistance to supply chain attacks, since many recent campaigns were dependent on automatic execution of scripts or unregistered dependencies (e.g. incidents involving popular packages and waves of malicious packages in npm). On the other hand, projects and organizations that use legitimate flows based on Git dependencies, remote tarbals or preparation scripts will have to review and adapt their configuration before migrating to npm v12, because these flows will no longer function by default.

GitHub recommends to prepare already updating to npm 11.16.0 or more which introduces notices about the actions that will break with v12; that window allows to identify which packages or patterns of the code will need to be explicitly approved in the future. If you want to read reactions and proposals from the technical community, a Community discussion where experiences and solutions are being shared.

For equipment and security officials this involves running a practical review of the supply chain: generating or updating the SBOM, auditing the transitory units coming from Git or URL, and mapping the packages that run installation scripts or require native compilation. Third-party analysis tools and practices such as policy blocking in CI, use of verified lockfiles and setting of versions are now more relevant than ever. A good contextual reading on the nature and scope of the supply chain attacks is available in Snyk's article on the subject: what is an attack on the supply chain.

From the operational point of view, it is appropriate to test the CI pipelines in an environment that simulates the new restrictions before the v12 update. Configure white lists for the necessary sources, document authorisations for scripts and native buildings, and automate controlled approval in continuous integration systems will avoid surprises in deployments and releases. It is also time to consider the possibility of selling critical dependencies or to serve internal mirrors for libraries used in production, reducing dependence on dynamic external sources.

We must not lose sight of the implications for small open source projects: many bookstores or templates use installers and "prepare" scripts for packaging tasks or examples. Maintainers must inform their users how to migrate and, in some cases, provide alternative instructions (e.g., run scripts manually or adapt publishing processes to avoid Git or Tarbals dependencies). The cost of friction exists, but is offset by a much lower attack surface.

Finally, for organizations that want to tighten their position on emerging threats, the practical recommendation is to draw up a two-phase plan: first, run npm 11.16.0 in all development and CI environments to collect warnings and create a list of justified exceptions; second, implement automatic CI policies that default the resolution of unapproved external sources and require human review for their authorization. Taking these steps reduces the possibility that a malicious package will unadvertently run during an installation.

GitHub's movement towards a more restrictive model reflects the maturation of defense in mass package ecosystems: tools must assume that automatic installation is a risk vector. The teams that plan in advance and make these policies part of their development life cycle will gain security without sacrificing operational continuity.