In case you haven't heard yet, npm broke a significant chunk of the Internet yesterday. In a showdown over a trademark dispute regarding a small program called kik, lawyers for a company called Kik demanded that npm remove the kik module, published by open source software developer Azer Koçulu. Npm sided with Kik  in the dispute. In response, Koçulu unpublished all of his libraries on npm, including a small library called leftpad that happened to be a dependency for some of the biggest JavaScript libraries on the Internet. 

The effect was instantaneous. Hundreds of builds per minute were breaking, and npm took the unprecedented step of re-publishing the leftpad module to fix the problem. While the legal issues surrounding npm's decision are unclear at this time, we learned some very important lessons yesterday.

First, if you publish a library on npm that has external dependencies, you should consider forking the code for the external dependencies and publishing your own copy of the dependencies so you control your own destiny. Because of how npm works, you could even be at risk if a dependency once removed (a dependency of a library you are dependent on) is unpublished.

Second, npm is, as things stand, unsafe territory. See this Twitter comment from Maxwell Ogden:

There are at least three immediate issues with how npm works. First, a single developer, as we have just learned, can unpublish a single module and break a very large number of dependent projects. Second, and more insidious, a hacker could hack the install process for a module and inject a virus, as Ogden indicates.

Third, and perhaps worst of all, a maintainer of a module like leftpad, rather than unpublish the module during such a dispute, could change the module and create their own hacks against mass infrastructure. While ethical people would never do something so nefarious, it only takes a single unethical person to make it happen. And if you really want to be paranoid about it, consider that an agent for a third party like a government or corporation could publish something, wait until it becomes popular, and then infect it with malware. This kind of attack might be detected fairly quickly, but because of the scale of use, even a couple of days without detection could leave hundreds of thousands or millions of installations at risk of attack. 

Lastly, in case I haven't given you enough to worry about, consider the havoc someone could wreak if they could hack one of the major CDNs on the Internet. CDNs distribute assets over the Internet. Some CDNs are widely used to offload bandwidth usage for common scripts like jQuery and other popular JavaScript libraries. Now imagine that a hacker manages to penetrate one of the major CDNs and replaces a common script like jQuery or Backbone with a version infected with malware. Web browsers connecting to sites that reference the CDN for the infected scripts would immediately be infected. Again, because of scale, such an attack could affect millions of people within hours if not minutes. And while, once again, such attacks could be detected and then shut down, the damage would already be done.

What next?

Here are some immediate steps you can take:

1. Your web sites should be reviewed for dependencies on npm.
2. Any npm modules you publish should be reviewed for dependencies and such dependencies should be mitigated.
3. You should review reliance on CDNs and create fallback strategies if your CDN fails or is compromised.

There will be repercussions from yesterday's events for some time. Don't wait for npm to decide how they are going to deal with what happened, move now and protect your own assets.