Deprecated npm packages that appear active present open-source risk
Security researchers warn that many npm packages are being deprecated and abandoned by their maintainers without a clear warning to users. Such packages can accumulate serious vulnerabilities over time and sometimes their maintainers even abandon them particularly because they don’t have the time or interest to fix reported security issues.
Out of the top 50,000 most downloaded packages on the npm registry, around 8% are “officially” deprecated or have a direct dependency that is deprecated. This means their authors flagged those packages as deprecated and posted a warning to users. However, researchers from software supply chain security firm Aqua Security found that by expanding the search with other criteria that could indicate “deceptive” or non-explicit deprecation, the rate rises to 21% of packages.
The problem is probably much worse because Aqua only checked direct dependencies, not transient ones as well — the dependencies of dependencies. The dependency chain for npm packages can go many levels deep and not accounting for this is a common reason why vulnerable code might make it into projects undetected.
“This situation becomes critical when maintainers, instead of addressing security flaws with patches or CVE assignments, opt to deprecate affected packages,” the Aqua researchers said in their report. “What makes this particularly concerning is that, at times, these maintainers do not officially mark the package as deprecated on npm, leaving a security gap for users who may remain unaware of potential threats.”
To help organizations Aqua Security released an open-source tool called the Dependency Deprecation Checker that can take a project’s package.json and iterate through its dependency tree in order to find packages that match the deprecation criteria chosen by the user.
Official versus practical deprecation
In practical terms, software code can be considered deprecated when its author takes the decision to no longer update the code or to fix issues found within it, security-related or otherwise. This can happen because they no longer have time to maintain it — most open-source development is volunteer work — and they haven’t found someone else to take over the job, because someone else created a better alternative, they originally created it for themselves and have since moved on to other things, or simply because they became annoyed with the community’s response.
When it comes to open source, making that choice is perfectly fine because the code doesn’t come with a support contract attached and it’s available for anyone to take, modify, and improve if they want to keep using it. The author doesn’t have to announce their decision, either, and it’s up to the users to figure out when the code quality no longer satisfies their expectations.
