Community Summit Discussion Notes: Building trust in WordPress CMS and plugin security

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.
  • 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

#security, #summit, #summit-2023, #wpscan