Community Summit Discussion Notes
Title of Session: Building trust in WordPress CMS and pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party security
Facilitator: Peter Wilson
Notetaker 1: Ryan McCue
Notetaker 2: Weston Ruter
Notetaker 3: Jason Coleman
Key Points
- Communication of security practices:
- Organization
- The security page on WordPress.org needs to be refreshed with a clearer message – this will benefit WordPress from an external perspective, and can be a jumping off point internally too
- This can point out to the various handbooks (security, plugin, theme, hosting)
- The whitepaper is also heavily out-of-date and needs refreshing
- WordPress as a project should be “owning” the security conversation, rather than leaving to third-parties
- Documentation can be improved, but is “passive” – active communication (i.e. marketing) must also take place. Other teams (docs and marketing) are able and willing to help if the raw communication is available, and can share some of this communication burden.
- Organization
- Responsibility and ecosystem:
- WordPress decided to provide plugin functionality, so must take responsibility for the security of it – we cannot say that this is the ecosystem’s problem alone to solve
- The ecosystem is broader than just the .org repository, so security cannot be “controlled” through the repository alone
- Tools such as scanners could potentially be built into WordPress itself, mirroring operating system virus scanners eg
- A “safe mode” could be added to disable all plugins (eg), but this is often one of the first things to be bypassed – external tools (such as those operated by hosts) are likely to be a safer way to achieve this
- Tools are available to the ecosystem (autoupdates via the plugin team, eg) but awareness of these is low. These are available for authors of non-trivial usage plugins (e.g. something like 20k+ installs would be a workable threshold)
- Documentation exists around how to write secure code, but there isn’t sufficient or sufficiently-known documentation on procedure of how to deal with vulnerabilities, how to issue security releases, and how to communicate
- Make it clear to ecosystem authors that vulnerabilities will happen, and destigmatize the process
- A “what to do if your plugin has a vulnerability” guide could bring this information together
- Documentation needs to be clearly findable and approachable for the ecosystem, and can tie in to the refreshed page
Action Items/Next Steps:
- Refresh the .org security page
- Refresh the security whitepaper
- Write documentation on procedure for dealing with vulnerabilities
Raw Notes
Continue reading