Abandonware is a silent security risk. With no developer or project lead to address bugs, especially security bugs, you are running code that has no support. If, or when, a security bug is found in an unsupported or abandoned project, then the users who rely on that project will be left with no recourse. They will have no ability to keep their sites safe and secure via an update.
This emphasizes the importance of choosing software wisely. The software you rely on, including open source components you build your projects and websites needs to be actively maintained. Software repositories such as the WordPress plugins and themes repositories share with you all the details you need to make an informed decision. In this post, I will share with you how to avoid using abandoned WordPress plugins and themes, and the risks if you don’t.
The following list of factors will help you choose active open source projects, and avoid abandoned ones. I will be focused on items found on the WordPress plugin and theme repositories because they provide all the data you need. This information could also be applied to any open source project or library, ideally, one distributed via a trustworthy repository and not one you found on the dark web.
Please feel free to fit these metrics to your needs. It will ultimately be up to you to decide the importance of each. This may vary from organization to organization or project to project, and there may be exceptions, so use this list as guidance for what to look for, not as absolutes.
An active community is a strong signal the project is active. The more attentive the developers are to their users’ needs, the better. This community could be a forum, mailing list, Slack/Discord/IRC channel, or support desk plus knowledge base (documentation). All you need to do is check it out to see how active it is. For the case of WordPress repositories, every theme and plugin is given a free support forum for the project (provided at no cost and moderated by a team of volunteers. Awesome stuff.)
Surprisingly, the last update only plays a small role. We should be mindful that different projects simply have different update frequencies. If the project has an active community, but no release in the last year, that may be fine! Maybe the project is in the middle of a big refactor of the code base.
It is important to know the software work on modern systems. “Tested up to” is WordPress repository specific phrasing, but you can look for any information that tells you what technology the project was built to run with.
WordPress core is known for being backward compatible. Many older plugins run perfectly well in newer versions of WordPress. This “Tested up to” update really tells you the last time the developer tested their project. It can be an indicator the project is actively maintained, or at least hasn’t been forgotten.
Active projects receive regular updates. These updates can be bi-weekly, monthly or quarterly, but don’t be surprised if you see daily or yearly updates in some cases.
This information needs a little digging to get to. You can see the frequency of updates in a project by looking at the changelog, or via the project’s git or SVN history. Projects in the WordPress repository, share every project’s changelog in the “Development” tab, this same tab also gives you access to the project’s SVN history via the “development log” link.
The next two tips are bonuses. They are not relevant to avoiding abandonware but will help you with other security and performance considerations.
Humility and transparency are important when communicating security. They are qualities you see in most mature projects. The truest way to know a project takes security seriously is through a history of patching security bugs and communicating it clearly to users.
Check the changelogs. Look for security releases, and how the developer communicates the reason for each release.
You may find it suspicious if there are no security releases. If you do, then you can search for that plugin in a trusted public vulnerability database (like the Patchstack Database) to be certain if a plugin has any security patches.
More is not always better. It is often tempting to choose projects with more bells and whistles, but the more complex a project gets the more issues that may cause. Simpler is sometimes better; fewer risks, more performant.
Sometimes leadership needs to change. Handing off ownership of an open source project happens, and can be a good thing to keep the project going. However, this can do wrong, especially when there is money involved.
Developers of semi-popular WordPress plugins have been targeted by malicious actors. This comes in the form of an email out-of-the-blue offering to “buy” the open source plugin from them. This sounds like a great deal to any struggling developer. It is a cash offer for a project they abandoned long ago, what could go wrong? Truth is, by the time the original developer has cashed the check, the new project owners could be pushing malware with the next release.
Auto-updates keep WordPress websites secure. They may not be a good fit for every website and some organizations prefer manually reviewing updates. But, auto-updates have their limitations.
You can not update if there is no update available. In 2021 the Patchstack Whitepaper showed that 9 WordPress plugins with one or more critical vulnerabilities in them had been abandoned, leaving sites vulnerable.
If you are looking for a safeguard to protect your website(s) then consider checking out the Patchstack App. The free app includes a security dashboard and real-time security alerts for WordPress websites. These alerts may come in handy if a security bug has no patch. Virtual patches (available on paid plans) can keep websites secure from attack and are especially useful for anyone who needs extra time to manually review their website during updates.
Practicing proper plugin hygiene means you should be verifying the software you use for your projects is being actively maintained and supported. This also may be a time to reflect on the fact that if we don’t support the open source projects, be them plugins, themes, or a whole CMS, then who is going to keep them from being abandoned?