Marak Squires is the maintainer of the ‘colors’ and ‘faker’ libraries. The two projects accumulate ~23 million weekly downloads and support ~23,000 projects. In January of 2022, he intentionally introduced an infinite loop that bricked every project relying on either one of these libraries.
Consequently, GitHub suspended the developer’s account.
The justification provided by the developer is one of retaliation to “Fortune 500s (and other smaller sized companies)” who extensively rely on cost-free and community-driven software but do not give back to the community. His actions are in line with an ultimatum he provided in November when stating that users of the project must ‘pay me or fork’ the project.
Responses to Marak’s actions have been mixed. Some members of the Open-source software (OSS) community have praised the developer’s actions. While others are unsympathetic and critical. From the actions, however, two things have become undeniable:
- It is abundantly clear, the Open-source community is divided on what ‘Open-source’ represents, fundamentally; and
- Developers, start-ups, small-businesses and corporations who leverage OSS must implement strict controls to protect themselves, their business and their customers.
Learning from Recent OSS Compromises
It should go without saying, but this recent corruption has underscored the need to emphasise key technical and security practices for working with OSS libraries.
None of this is new. At the start of 2020, the code-js project had 25 million weekly downloads, was critical to countless projects, and maintained by a single developer who is infamous for advertising that they are looking for a job every time the project is installed in CI.
The market rate for a developer who would maintain a project like this in a private enterprise is between $200,000 and $300,000/yr. Understandably, when working for free, developers in this position spend their time working on changes that are of most interest to them. You are unlikely to find them maintaining high quality controls.
This – entirely predictable – reality has been recognised broadly and governments are introducing legislation to ensure organizations act accordingly. Still in the inception phase, the maturity of this legislative agenda will ensure that in the coming months and years it will no longer be reasonable for a developer or business to shirk responsibility for vulnerabilities introduced by OSS. The earlier that developers recognize this regulatory shift, the better prepared they – and their employers – will be for the transition to more regulated OSS implementation practices.
Rules of Engagement for OSS Implementation
When you evaluate this most recent incident in the context of broader DevSecOps issues that OSS introduces – for instance, Log4j, coa/rc, and ua-parsers-js as recent notable examples – it is apparent that stricter controls must be introduced. The number one priority for any entity implementing OSS libraries is an OSS policy. Below I have mapped out essential controls for OSS policies entities must enforce when implementing OSS.
- Stop all automated updating of OSS source and binary updates: While an obvious control, the recent NPM issue has highlighted the need to reiterate; Don’t automate updates for foreign code. It’s as straightforward as telling your Finance team not to download files from @microsòft.com email addresses.
- Pentest each OSS component prior to acceptance: The quantity of library downloads does not evidence quality control. It is no longer reasonable to assume OSS components are secure. OSS components do not pass the same quality standards checks as proprietary code. In most instances, they receive only a cursory glance. It is easy to incorporate code containing vulnerabilities.
- Embed automated OSS controls in your CI/CD pipeline: An integrated development environment (IDE) software suite will warn developers if their code will potentially introduce a vulnerability and provides remediation advice. These tools are critical for the introduction and management of OSS components in your stack.
- Maintain continuous visibility of OSS components: Comprehensive visibility of OSS components is critical to securing the testing, development and production of applications. Like a parts list in a manufacturing company, it provides an inventory and mapping for potentially vulnerable components when necessary.
- Remediate and contribute: Open-source software is an opportunity to develop in a decentralised and collaborative way. The underlying ethos is community production. Despite this, the log4j debacle exposed how few are willing to contribute. It is in the interest of every developer, small-business and large corporation to contribute fixes to OSS projects when they are identified.
Would You Like to Know More?
The advancement of technology beyond the bounds of the law as a catalyst for introducing compliance and regulation requirements is evident through history and increasingly common. For several years the public sector has been experimenting with, and implementing, assessment standardisation practices. Ensuring the entities tasked with evaluating organisations are consistent and meet government thresholds.
