Checkmarx this week released a report detailing a package distributed via the NPM registry that cripples any machine that is used to download it.
Dubbed the “Everything” package, a user known as PatrickJS, also known as gdi2290, uploaded a package that has more than 3,000 sub-packages. Each sub-package is designed to split dependencies into chunks and to depend on all publicly available NPM registry packages, resulting in transitive dependencies that disrupt pipelines and exhaust storage space.
Following significant effort, The Everything package has since been removed from the registry, but the perpetrators did create a domain where they showcase their handiwork. Whether the Everything package was created as a joke to be played on developers or has some other malicious vandalistic intent is unclear.
Jossef Harush Kadouri, head of software supply chain security for Checkmarx, said these types of incidents are likely to happen from time to time because there is no process for reviewing packages prior to them being loaded into a registry. In fact, a similar incident previously occurred when a “no-one-left-behind” package by Zalastax that was dependent on every publicly available npm package was uploaded in the registry.
It’s only when an issue is identified that the maintainers of the NPM registry will remove a package. Those maintainers simply lack the resources and tools that would be required to scan every package, noted Harush Kadouri.
Heading into 2024, it will be incidents like these, along with vulnerabilities found in NPM packages, that will serve as an impetus for reviewing the workflows that make up an organization’s software supply chain. For well over a decade, developers have been downloading software components from various repositories with little to no regard for vulnerabilities. As more of those vulnerabilities are exploited, organizations that rely on that software are now requiring providers of applications to provide visibility into the provenance of the components used to construct it. The overall goal is to make it simpler to remediate applications, especially when a zero-day vulnerability is discovered.
In the meantime, organizations would be well-advised to curate a repository of software components that have been vetted. Developers can still readily access those components to build applications, but there should be fewer downstream application security issues if the components residing in that registry have been scanned. If developers are allowed to directly download packages and components from a public registry, it’s only a matter of time before an application security issue is going to arise.
Hopefully, as organizations adopt DevSecOps best practices, the number of application security issues encountered will steadily decline. Each organization will need to determine how far left to shift responsibility for application security toward developers, but one way or another, software supply chains need to be better protected.
Of course, the issue will ultimately be forced by regulations that are becoming increasingly more stringent. Once the first fines are levied, it won’t be long before just about every organization that builds and deploys software will quickly move to limit their liability as much as possible. The challenge and the opportunity now is to proactively secure software supply chains today before any remedy that might be imposed on an organization disrupts application development workflows tomorrow.
