When security vulnerabilities are discussed, the term responsible disclosure often comes up. It is a rather perverse term, since responsible disclosure is based on the idea that software developers do not have to be responsible for security. With responsible disclosure, software developers can continually introduce security vulnerabilities in to their software. They are only being irresponsible if they don’t fix vulnerabilities once they are notified of them. Even that is overstating things, as software developers don’t face any long term consequences if they don’t do that. The party that does face potential consequences are those disclosing vulnerabilities if they haven’t done things to someone else’s satisfaction. It is impossible to avoid that because people have incompatible views of responsible disclosure is. For example, we had a developer criticize us for ever disclosing a vulnerability, saying responsible disclosure means only disclosing it to the developer. That runs directly against the disclosure part of responsible disclosure.

Software developer’s responsibilities are put on others in additional ways. We were recently contacted by someone wanting us to provide them with free help dealing with the aftereffects of their website being hacked caused by WordPress plugins from a major WordPress plugin developer. Or more accurately, their belief that the plugins were responsible for the hack. That was despite them paying the plugins’ developer a significant amount for support for those plugins.

They wanted us to confirm whether a vulnerability had been fixed in one of the plugins, which is what our customers pay to provide them with. And despite their being a proof of concept that they could test for themselves if they didn’t want to sign up for a free trial for our service.

They also wanted us to tell them how to prevent them from having security issues when using this plugin developer’s plugins. That is despite us having this warning in the post they were referencing when contacting us:

The developer of that plugin, StellarWP, has had a terrible security track record despite developing one of the most popular security plugins. Including failing to fix a vulnerability that their security plugin was warning about and failing to implement basic security in another plugin, leading to a zero-day.

If you are being warned by someone that the plugin developer has a terrible security track record, it is odd to want them to provide you with a way to keep secure instead of addressing the problem with the developer or finding a developer who has managed to avoid being that bad at security.

What the WordPress community really needs is for developers to be held responsible if they are failing to handle security well in ways that they could and should be doing. That isn’t happening for a variety of reasons, including that, as is the case with this plugin developer, developers cutting corners with security are also a security providers. It is the proverbial fox guarding the hen house. Other security providers are partnering with developers handling security bad instead of warning their customers and the community that the developer is putting websites at risk. Inside of WordPress, there doesn’t appear to be a properly functioning security team to the extent there even is one. So WordPress isn’t likely to play a role in something like this. Perhaps other parts of the community could come together to expand on the scope of existing efforts, like our Plugin Security Scorecard.