The “Non-Existent Author” Alert: How to Safeguard Against the Dangers of Abandoned npm Packages

Today we’re taking another deep dive into Socket’s alerts in our series on various indicators of software supply chain risk, exploring the implications of the Non-existent Author alert. It’s one of the fastest ways to determine if a package may be abandoned.

The Non-existent Author alert flags packages that were published by an npm account that no longer exists. It is a high severity alert and is currently only supported for the JavaScript ecosystem.

In an ideal world, your code base should only be using packages that have active and identified authors. This ensures that any issues, which will inevitably pop up, can be promptly addressed, and that the package remains secure and reliable.

When a maintainer’s account is deleted, there is no longer a responsible party for updating the package, addressing security issues, or managing potential bug fixes. This leaves the package vulnerable to exploitation and increases the risk for projects depending on it. Very old packages that are not maintained will frequently have critical CVEs and many supply chain risks.

Instead of assigning a timeframe since last update as the trigger for a generic “abandoned” alert, Socket checks if the author no longer exists. The frequency of updates to npm packages varies widely—some authors update their packages every few days, while others do so only once every two years. In some cases, there may be no new features to add because the package has reached a mature state.

npm Retains Packages for Historical Reasons, Even When the Author’s Account No Longer Exists#

In 2022, when the notion of opening up unmaintained packages to other developers came up in npm feedback discussions, npm product manager Monish Chandra Mohan responded to clarify the registry’s policy.

“npm being a public registry, we do not remove abandoned packages for historical value,” Mohan said. “If you wish to maintain an abandoned project or willing to take over the name please write to our support.”

At that time the npm registry had a 3+ month long backlog of name disputes and recommended authors consider scoping their packages to retain a desired name.

How npm Handles Requests to Remove Abandoned Packages#

npm has a highly opinionated approach to abandoned packages, which has evolved over the past few years. In 2020, Josh Bressers asked if npm has a policy for unresponsive maintainers of popular packages who do not appear to be merging any PRs in the package’s repo, even for security issues.

At that time, npm Director of Product Management Myles Borins referred to the registry’s documented process for disputes which included the request to adopt an "abandoned" package as a reason one might go through the process. These types of disputes were handled on a case by case basis in 2020. This policy changed in 2021.

“We opted to move towards not allowing adoption of abandoned packages as it was an attack vector for folks could use for a supply chain attack,” Borins said in an update.

This decision was controversial, as some saw the solution to be worse than the problem, contending that npm “traded the potential for a supply chain attack for guaranteed vulnerabilities/attacks on everyone using abandoned packages.”

In 2023, Boris further clarified npm’s approach to abandoned/unmaintained packages:

Our current stance is that unmaintained packages will remain unmaintained. As stewards of the registry it is not in our purview to maintain packages created by others nor should we be making a decision regarding a future maintainer.

The registry does entertain requests regarding names through its naming dispute policy and accepts trademark disputes as per GitHub's trademark policy.

How to Use the Non-Existent Author Alert to Prevent Use of Abandoned Packages#

Searching amongst abandoned packages is a reality of using the npm registry, so Socket’s Non-existent Author alert is helpful in weeding some of them out when you are vetting your dependencies.

This alert is triggered if the npm account that published the package has been deleted. This can happen either because the author chose to delete their account or due to an npm policy violation. Either of these reasons are serious enough considerations to encourage developers to seek out an alternative package.

This alert helps identify packages that might be vulnerable to being hijacked or republished by malicious actors, as there is no longer an active, accountable maintainer.

What To Do When You Receive The Non-Existent Author Alert:

• Evaluate Package Usage: Assess whether the package is critical to your project. If it is not essential, consider finding an alternative with an active maintainer.
• Check for Recent Activity: Look at the package’s repository to see if there has been any recent activity or community involvement that suggests ongoing maintenance by others.
• Contact the Community: Engage with the community to see if there are plans to adopt or maintain the package.
• Fork the Package: If the package is essential, consider forking it and maintaining your own version, ensuring that any security updates and necessary changes are applied promptly.
• Version Pinning: Consider pinning the version of the package you are currently using to ensure that your project continues to use a known good version. This should be a temporary measure while you are actively seeking out a replacement in instances where replacing the library isn’t trivial, since version pinning can make package management and maintenance more cumbersome. It can also keep you from receiving necessary security updates.

The most ideal scenario is to seek out dependencies that are actively maintained by people and organizations that are easy to reach in the event of an issue. Regularly auditing your dependencies and removing or replacing packages flagged by the Non-existent Author alert can significantly improve your project’s security posture.

Install the Socket for GitHub app for free to scan your dependencies for non-existent npm authors and 70+ other supply chain risks.