How to Protect Your Projects from the Risks of Deprecated npm Packages

Continuing on in our series covering various indicators of software supply chain risk, today we’re zooming in on the risks of using deprecated open source packages.

In many cases, you may not be aware that the package has been silently deprecated without a formal notice, or is simply no longer maintained. This is exceedingly common and poses a multitude of risks:

• Security vulnerabilities due to not receiving any security updates or patches
• Lack of active support
• Reduced performance
• Compatibility issues with other packages
• Increased maintenance burden
• Compliance and reputation risks

In the most ideal scenario, when using packages from the npm repository, maintainers will officially designate a package or a version of a package as deprecated. This adds a deprecation message to the package page:

The vast majority of package maintainers do not go through this process and will simply add big bright text to the readme file, or, in the worst case, abandon the package with no intention to update anyone about its maintenance.

More than 21% of the top 50K npm packages may be deprecated or abandoned#

In a recent analysis of the top 50,000 most-downloaded npm packages, researchers at Aqua Nautilus found that 8.2% are officially deprecated:

Due to inconsistent practices in handling package dependencies, the real number is much larger, closer to 21.2%. Moreover, some package maintainers, when confronted with security flaws, deprecate their packages instead of reporting them, getting a CVE assigned or remediating the vulnerabilities. These gaps can leave developers unaware that they are using unmaintained, vulnerable packages, and create opportunities for attackers to take over unmaintained code that continues to be used.

While researching deprecated packages, Aqua reported some vulnerabilities to maintainers, and some responded by archiving their GitHub repositories instead of fixing the issues and officially deprecating their packages.

When Aqua expanded the definition of deprecated to include archived repositories, the rate of deprecation among the top 50K npm packages jumps to 12.8%. Including instances where there is no GitHub repository available, it’s 15%. Aqua researchers arrived at 21% when including packages that are not actively maintained, have no visible repository, commit history, issue tracking, or linked repository.

These packages are downloaded an estimated 2.1 billion times per week, which means there are a lot of popular, deprecated packages that are still in play.

Mitigate Risks of Deprecated Packages with Socket’s Alerts#

Using open source software comes with numerous advantages, such as cost savings, flexibility, and community support, but also carries a few notable risks, including unpredictable package maintenance leading to potential security issues.

Socket has several checks that will automatically detect the majority of these packages and alert developers to a potential risk. These include the following:

• Deprecated - The maintainer of the package marked it as deprecated. This could indicate that a single version should not be used, or that the package is no longer maintained and any new vulnerabilities will not be fixed.
• No Repository - Package does not have a linked source code repository. Without this field, a package will have no reference to the location of the source code use to generate the package.
• Unmaintained - Package has not been updated in more than a year and may be unmaintained. Problems with the package may go unaddressed.

These checks run automatically with every GitHub PR when using the free app, and will also appear in the Socket dashboard’s Alerts table. Developers can sort by alert type and see if the deprecated packages are direct or transitive dependencies.

These alerts also appear on package pages, in case you want to manually search a package or delve deeper, with more information than the official npm package registry provides:

Clicking on the package page inside the alert offers a better understanding of why the package was deprecated and what the maintainer suggests as an alternative. Scrolling down you will also find AI-powered suggestions for alternative packages with similar capabilities:

Things change rapidly in the Node ecosystem and dealing with deprecated dependencies is inevitable. Not everyone is fastidious about updating packages - there’s a whole spectrum of approaches to updates, and in many cases swapping out deprecated dependencies is not a trivial undertaking. Drop-in replacements are not always guaranteed to be readily available.

One commenter on reddit shared a common scenario in response to a discussion on project maintainers struggling with numerous deprecated packages:

I inherited a system that was in production supporting one of my company’s major income streams, and it was out of date by at least a year in every way. It took a full year to upgrade everything. It’s like replacing a car’s engine while it’s driving on the highway.

Anyway, yeah, it happens a lot. The node ecosystem moves so fast you can’t fall behind or it will overwhelm you.

Plan time monthly to do package updates.

Getting a handle on technical debt and deprecated packages can become more urgent if security is paramount to the success of your organization or if you have compliance requirements that you need to meet regularly.

Socket’s alerts make it easy see at a glance which packages in your repositories are deprecated and in need of attention. Install the free GitHub app to protect your repositories. You will get actionable insights as part of your workflow, project health reports, and more security information about your dependencies inside the Socket dashboard.

These tools will help you identify deprecated dependencies and get a broad overview of the health of your project, enabling quicker decisions when evaluating alternative packages.