Recently, we have taken a renewed look at how to assess the security of WordPress plugins, as part of building up the capabilities of our new Plugin Security Scorecard tool. Right now, it is hard to easily assess the security of plugins and what has filled the gap is often useless advice that suggests checking on things that are easy to check on, but don’t have any correlation with the security of plugins. Our new tool tries to surface useful information to help assess if plugins are secure enough for usage on websites with varying degrees of security risk. Among other things, that includes warning about plugins still in the WordPress Plugin Directory despite being known to be vulnerable, warning about developers that have a track record of not handling security well, plugins that are not being supported anymore, and security code that is being misused. But there is more information that could be provided by developers, which we are hoping to help incentivize more common usage of by incorporating checking for their inclusion when calculating security grades.

Already, as part of the grading system, we check for inclusion of a security.txt file (or several equivalents) that provides information on how to contact the developers about security issues. Today we started checking for an additional piece of information in that file and next month we will add a check for another.

What we started checking for today is a Security-Review field that provides a link to the results of a security review of the plugin. A well-done security review is going to provide a good idea of how secure a plugin is at the time of the review. Most widely exploited vulnerabilities in WordPress plugins would have been caught by such a review, as they often involve well-known security weaknesses. The problem here is security reviews, whether well done or not, are rarely done. We seem to be the only ones that have really done reviews and released results of them. (We have an upcoming post on a security provider that is claiming to do reviews, but based on the how poor the results are, not really doing those reviews.)

Ahead of adding that to our grading system, we have done security reviews of all three of our own plugins that are under active development. We released the results of those, though there isn’t much to see, as none of the plugins had any vulnerabilities or lesser security issues identified. With our Plugin Vulnerabilities Firewall, we did identify several places where additional hardening could be done and we have already released an update to address those. So even for those that handle security well, a good security review can be of benefit.

Next month, we are going to be checking for a SBOM field, which provides the path to a software bill of materials (SBOM) file. That file provides information on the third-party software components that are included with a software package. That is something that has been getting a lot of attention in the security industry, as there have been high-profile vulnerabilities in components widely included in other software. Right now there isn’t an easy way to determine what components are in WordPress plugins and then determine if they are, say, known to be vulnerable. So more information from plugin developers could help to better address problems with insecure components.

There are various competing standards for SBOMs and the popular ones are rather complicated, which can make generating something that meets one of those standards difficult to do. For our plugins, so far, we have a simple text file with a link to a GitHub project for a third-party library we use to handle plugins updates. There are various tools out there that can be used to try to generate a more complex file (GitHub has a built-in solution for projects hosted with them).

While doing a security review and generating a SBOM are complicated, adding information to the security.txt file is easy. Here are the two lines added to that file for our Plugin Vulnerabilities Firewall:

Security-Review: https://www.pluginvulnerabilities.com/2024/07/26/wordpress-plugin-security-review-plugin-vulnerabilities-firewall/
SBOM: sbom.txt

(If a plugin doesn’t include any third-party components, the SBOM field can simply say “not applicable”.)