Developer intentionally corrupts npm libraries, exposing weaknesses in OSS supply chain security

How developer activity analysis is crucial to detecting rogue developers and repository abuse

Fourteen months after declaring “Respectfully, I am no longer going to support Fortune 500s (and other smaller sized companies ) with my free work,” developer Marak Squires introduced corrupt updates to the colors.js and faker.js libraries, resulting in an infinite loop that prevented thousands of applications from functioning.

While many people in the open source community might be familiar with the sentiment, this action by Squires to sabotage his own code base was really something out-of-the-ordinary.

Background

colors.js is a very useful and highly-rated NPM package that enables developers to easily control console output text and background colors. It is downloaded 22.4 million times per week. Faker.js, which is downloaded 2.5 million times weekly, generates fake data for demos.

Squires inserted an infinite loop that sends an artistic interpretation of a console-based American flag and  anUncle Sam-like character onto the screen, causing the systems using it to halt. This resulted in a Denial-of-Service attack on applications that consumed the affected version of the package. 

Commit contents shown below:

We used Apiiro to analyze the colors.js repository and out of 259 commits, only one was flagged as an anomaly: the malicious commit “074a0f8” from Jan 9.

Top 3 Tips to Detect Software Supply Chain Threats

As an industry, we need to use this incident as an opportunity to rethink how we secure our Software Development Lifecycle, from custom code to open source dependencies. Specifically, here are a few recommendations:

1. Detect Malicious Commits. We must continuously screen for anomalous commits. There were a few red flags about the commit:
   • It wasn’t coherent with normal cadence of releases
   • In general the repository had a very slow release cycle and was long-dormant
   • The change was conducted on a very crucial code segment of the package
2. Flag Abnormal Developer Activities. In this particular case, the legitimate developer inserted malicious code into the library but a similar attack could be performed using a compromised account. Any indications of out-of-the-ordinary behavior should be flagged and investigated.
3. Identify Significant Changes. Understanding which changes are “material” or may have a significant impact on the application as a whole requires a deep understanding of context across the SDLC, from the code being committed to the settings on the API Gateway.