Security Review Process
As a mod for the WordPress forum at Webmaster World I started a thread about WordPress security – or the lack there of. Largely because I’m tired of the beating WP takes and I wanted to see if anyone could actually prove there were security issues. What has come out of the thread so far is lot of accusations about how there is no dedicated security team or process for handing issues. SO I’m here to ask, what is there for a security team or security review process/protocol for code and issues when they’re uncovered?
Ha. That’s a good one. Give this a read for a good response to that.
tl;dr is that WordPress core is secure. But there are a lot of problem plugins, themes and shared servers running other exploitable code and that results in all the apps on that server getting compromised.
Thanks for the reply Jan. That’s a helpful post. Do you know of a formal review process for security issues/exploits in place? It’s all well and fine to say it’s secure but part of the issue is a lack of transparency about what WP does to review it’s code and ensure the core is tight and secure.
It’s all well and fine to say it’s secure but part of the issue is a lack of transparency about what WP does to review it’s code and ensure the core is tight and secure.
Lack of transparency? How? Have you visited the developers’ blog? The entire development effort is open and you can alway browse the source.
I’m not sure exactly what you are referring to but security is taken very seriously and everything about WordPress is open and transparent.
There’s the Hardening WordPress Codex link.
Which has a section on reporting security issues.
Which also links to the FAQ Security.
To me this is the critical part of that FAQ.
- For a WordPress plugin security issue, email plugins [at] wordpress.org with as much detail as you can. You should also contact the plugin developer either via email (if it’s listed in the plugin source code), or by posting in the support forum on their plugin page asking how best to send them details.
- For a security issue with the self-hosted version of WordPress, email security [at] wordpress.org with as much detail as you can.
In all cases, you should never publish details of a security vulnerability. Doing so is irresponsible and unprofessional.
See that last part? I happen to agree completely with that last statement. The important thing about an identified vulnerability is to fix it. It’s not for providing a road map on how to exploit older versions.
The problem with talking about security and WordPress is that the topic becomes a dog whistle. Too many folks just respond to the whistle and start with a mistaken premise.
Security should be talked about but without the preconceived notion that WordPress is insecure. When a vulnerability or exploit is determined (or even a POC) it get’s a patch and an update is rolled out. That doesn’t make WordPress insecure or lack transparency.
I’m sorry but i wasn’t clear enough. By lack of transparency I meant with the security review process and if there’s a dedicated security team. I can’t find a clear indication of either. It would help with the credibility of the claim that WordPress is secure if there’s a clear protocol for testing, reviewing, and resolving security issues by a dedicated team. I have visited the developers blog. I see sections for the Core, Community, Themes, etc but not Security. Which also leads people to the question of why not?
I assume there is some form of review process – the FAQs and resources you list (which I have read through) all indicate there is (plus I know issues DO get resolved) but there’s no indication of what happens when an issue is discovered. I’m in agreement with not posting the details of a security vulnerability and that’s not what this is about. I’m trying to uncover how the WordPress team approaches security.
In thinking about how to articulate this better I think the issue is a matter of perception and public awareness.
Coders care and they can read through the development blog posts – if they care to. Joe & Sue Public aren’t going to and even if they did, wouldn’t understand 99% of it. What WordPress is missing is a few confidence builders – akin to the “Protected by Verisign” logos on eCommerce sites. Something that clearly indicates the WordPress team has an organized approach to security.
Example: Drupal – https://drupal.org/security-team
That the Joomla and Drupal communities have organized clear security teams with clear objectives has a powerful impact on public and community perception/confidence – even if it’s no different than what the WordPress community has. It’s just that they packaged it into an easy to understand black box, with a clear label and outcomes.
Again, please don’t get me wrong. I’m not questioning if WordPress is secure or not. I’m trying to help erase the myth that it’s not.
It’s referenced in security releases – i.e.
Ah, thank you WPyogi. So there is a team. Perhaps they prefer to lay low.
I have copied a few lines from the Drupal link:
Goals of the security team
Resolve reported security issues in a Security Advisory
I would assume WordPress has a place for users to report security issues, and maybe WPyogi or Jan or someone else can post the link.
Provide assistance for contributed module maintainers in resolving security issues
Here at WordPress, I would assume that would translate into assisting plugin authors trying to help users who have reported security issues.
Provide documentation on how to write secure code
Writing any code at all is beyond my own ability, but surely WordPress has that kind of documentation available.
Provide documentation on securing your site
Help the infrastructure team to keep the…infrastructure secure
As far as I know, that would not be applicable here since WordPress.org is not running in WordPress.
Members of the security team sometimes perform analysis of core or contributed project code…but in general the team does not review core nor contributed code.
Maybe trying to educate more WordPress users about the difference there would be helpful. The internet can be like an alligator-infested swamp, and the folks who work on security are dealing only with the ‘gators, not supervising the improvements on the swamp.
I would assume WordPress has a place for users to report security issues
Maybe trying to educate more WordPress users about the difference there would be helpful.
How? There are already resources in the Codex on security (as mentioned above) but we cannot force users to read them.
Threads such as this can help people see the difference between the Security Team and the Development Team, and my metaphor was intended to help increase the overall awareness and understanding of the presence, commitment, tasks, chores and successes of the Security Team.
Right. We’re talking about perception here – the perception of insecurity that could be significantly reduced if not erased by including more visibility of the security team itself.
In what way? And bearing mind that the work of a security group, almost by definition, needs to be “behind closed doors”?
It might also help if there was some clarification as to which “security group” is being discussed. In theory, there are 4 distinct groups dealing with core, themes, plugins and wordpress.com.
the perception of insecurity that could be significantly reduced if not erased by including more visibility of the security team itself.
Yes, and esmi knows:
there are 4 distinct groups dealing with core, themes, plugins and wordpress.com.
>> In what way?
It could be as simple as a one pager that acknowledges there IS a security team, it’s objectives, and the general process it uses proactively as well as reactively. I know this may seem silly and redundant but users like convenient, easy to understand packages of information. That they have to visit several pages to get the answers isn’t working and leads to misunderstanding.
- The topic ‘Security Review Process’ is closed to new replies.