5 New Critical Issue Alerts

Today we are enabling 5 new critical pull request issue types in our GitHub app:#

- Git dependency: A dependency that is being added or updated contains a dependency that references a mutable git address
- HTTP dependency: A dependency that is being added or updated contains a dependency that references a mutable http address
- Non-existent author: The author of a dependency no longer exists for some reason. (UPDATE: This issue has been temporarily disabled by default while we tune sensitivity)
- Invalid package.json: A dependency in your tree has an invalid package.json and will cause install problems.
- Unresolved require: A dependency is importing a package that it cannot resolve.

UPDATE 2022-11-07: We disabled the non-existent author notification while we tune issue sensitivity as it was creating too many alerts.

Mutable specifiers#

Dependencies that are specified with git or http urls are sometimes a necessary part of developing with dependencies. Perhaps you are waiting for upstream to merge a change. Perhaps you need to float a longer term patch over a dependency and you don't want to fully commit to forking and maintaining a dependency. (In these cases we, recommend npm overrides or patch-pacakge)

Whatever the reason, using a git (or less often, http) dependency specifier in place of an official semver number can sometime be necessary. Issues can arise when this feature sneaks into your dependency tree when a transitive dependency utilizes this feature. Besides slowing down install times, these dependencies end up losing various security guarantees that packages published to npm have such as immutability or publishing policies around malware. This means that the mutable transitive dependency could selectively inject different package code depending on who is making the request, or the host is slow or unresponsive to requests to remove malware.

Just plain broken#

If a dependency version has a invalid package.json or has imports that are broken, hopefully your CI tests will pick up the issue in the pull request when the broken version is added to your project. Either way, the Invalid package.json and Unresolved require alerts will help you diagnose why and where you might find broken dependencies in your pull requests. npm has some failsafes in place to prevent these kinds of things from getting published, however they do make it into the registry from time to time, and can be annoying to debug. We hope this info can help save you some time when you do come across them.

Abandoned#

Here is a scenario: you start a new project, and you install some of your long time favorite dependencies. You are using the dependency but notice an error. You decide to be a good open source citizen and debug the issue and upstream a patch. You go through the work of writing that patch. When you go to submit it, the upstream repo/author account is no longer there! It turns out, your favorite dependency has been abandoned. If you had gotten a Non-existent author alert in your pull request when adding the dependency, you could have found this out sooner, and discovered that there are now 3 community forks of this dependency where the bug is fixed already. You could have saved hours of debugging time if you had just gotten this information sooner. In addition to a number of other implications around packages with non-existant authors, we hope that this alert will assist in dealing with this unfortunate situation.

Onward and upward!#

These issues themselves are usually not signs of a supply chain attack, but can cause issues if merged into your project and would typically require a lot of manual labor to locate from just a git diff on a package.json file.

We hope these new issues continue to surface interesting (smelly?) dependency mutations in your pull requests!