What is the current state of signed packages?

I’d like to kick off a discussion of what the best practice currently is for updating dependencies “securely”, and what could be done to make the process more secure.

I’ve been reviewing the disparate threads around adding “security features” to Node.js. There seem to be two basic attack vectors they attempt to deal with:

1. From the network (the traditional attacks)
2. From dependent packages

The latter idea, that apps are vulnerable to malicious code in their dependent libraries, isn’t qualitatively different between node and any other language that has thirdparty dependencies/libraries, but the ease of use of npm install, the number of packages in npmjs.com, and the granularity (https://www.npmjs.com/package/left-pad) arguably make node+npm quantitatively more vulnerable to injection of code via dependencies.

The most obvious protection against dependency-poisoning is to freeze your package dependencies and check the package integrity at install time, something npm and yarn do by default with package locking.

However, this just forces dependency updating into an explicit process. The deps still have to be updated sometime, and when they are, how is a user to know the dependency is safe to update? Having to audit the contents of every single dependency as it is updated is pretty daunting, so that’s not much of a solution.

I’ve seen some comments to the affect that “signing npm packages” would solve this problem, but I don’t think that stands up to scrutiny. npm already checked the identity of the package publisher *, the problem is whether I trust that publisher.

* In theory. The theft of that eslint publisher’s credentials is an example of the check not working. 2FA might have helped there, and signing would have, but if a publisher has their identity stolen, they could have their gpg signing keys stolen, too.

I’ve been considering two ideas (I don’t claim credit for them, I think @rmg suggested at least one of them):

1. An npm install mode where deps do not get installed unless they were published with 2FA.
2. The ability to publish signed “attestations” (somewhere…), where the attestation could be “I state the license is correct” or “I state that I have audited this package version”, along with a tool that would report on unattested versions. It would be the responsibility of each user to decide who they trust as “attestors”.

So, to kick off the conversation:

Is either of those capabilities useful? What other suggestions does anybody have? Is there any ongoing work to help with the “secure dependency update” process? Is a good npm audit enough, even though its after the fact, and people should be more concerned with actively monitoring of their deployed apps for newly reported vulnerabilities? Is it even worth discussing updates to the npm client here, given that its controlled by npmjs.com?

And even if changes to npm install were useful, is there any practical way to achieve them? Maybe npm should just decline non-2FA publishes, so that 1 would go away?

[sam-github]

@mcollina You just mentioned npm exposing package metadata for whether a package was published with 2FA, see the issue description here, I also think it would be useful.

[mhdawson]

I’m less interested in packages being signed by the publisher, but a way for one or more third parties to sign modules after vetting them.