Investing in Open Source Security – ASW #180

This isn't a story about NPM even though it's inspired by NPM. Twice.

The maintainer of the "colors" NPM library intentionally changed the library's behavior from its expected functionality to printing garbage messages. The library was exhibiting the type of malicious activity that typically comes from a compromised package. Only this time users of the library, which easily number in the thousands, discovered this was sabotage by the package maintainer himself.

This opens up a broader discussion on supply chain security than just provenance. How do we ensure open source tools receive the investments they need -- security or otherwise? For that matter, how do we ensure internal tools receive the investments they need? Log4j was just one recent example of seeing old code appear in surprising places.

Segment resources

• https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/
• https://www.zdnet.com/article/when-open-source-developers-go-bad/
• https://www.zdnet.com/article/log4j-after-white-house-meeting-google-calls-for-list-of-critical-open-source-projects/
• https://www.theregister.com/2022/01/17/opensourceclosedwalletsbig/
• https://blog.google/technology/safety-security/making-open-source-software-safer-and-more-secure/
• https://docs.linuxfoundation.org/lfx/security/onboarding-your-project
• https://arstechnica.com/information-technology/2016/03/rage-quit-coder-unpublished-17-lines-of-javascript-and-broke-the-internet/