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

Weston’s notes:

• How is WordPress perceived in security?
  • Badly
  • Two camps: WordPress is insecure. From its roots its not scalable for enterprise. They run WP and their site got hacked. Could be due to insecure hosting, plugin vulnerabilities.
  • Is it due to poor user practices? Bad passwords?
  • Open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. aspect of WordPress contributes to the poor perception
  • PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. reputation as being insecure
  • We’ve grown a lot, and at our scale… 40% of all sites run WP, and with such a big footprint, the negative stories color everyone’s idea. We have the reputation as being insecure.
  • WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. has a pretty good reputation. It’s mostly plugins that are the problem, and especially paid plugins not on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/. But when sites are hacked, it’s not couched as a plugin being hacked. The scale is very high. We can control plugins on the directory, but we can’t do anything for commercial plugins.
  • Core and plugins are treated differently for security updates. There’s no standardized process for plugins to communicate security vulnerability fixes. How can plugin releases apply best practices?
  • Auto-updates were one step toward getting plugins security updates to be adopted similarly to core.
  • Auto-updates have done a lot for us. We’ve been pushing security updates for the past 10 years, and it has worked very well. Pushing security updates reaches 70% of sites in 3-4 days. The problem comes from when a smaller plugin author fixes a vulnerability themselves without alerting the core team, then the fix takes much longer to go out.
• How do we communicate security process to plugin developers?
• Best practices for plugin authors is not just fixing bugs but it’s also working with security team to get deployedDeploy Launching code from a local development environment to the production web server, so that it's available to visitors.. How much can the security team scale to accommodate all plugin security updates.
  • For any install count that is 20K+, it makes sense.
• We can’t control the plugin directory. It takes too much effort. Most plugins aren’t adding security vulnerabilities intentionally. Tell people what to do, show them how to do it, make it easier how to do it. People like to leave security up to someone else to take care of. It’s a lot of extra stuff for them to take care of. How can they be educated?
• There is a stigma with security, and nobody wants to see their plugin in the news. How can we make it easier to talk about security issues in plugins? We need to discourage burying the security fixes.
• Things to consider:
  • Communication: hosters discuss security in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., but not openly on Make. 
  • When you create a new WordPress plugin release, there could be a checkbox that the new release is security.
• Microsoft Windows took ownership of virus situation, and they built anti-virus. We are best equipped to solve the issue in the same way. 
• Community team sends out updates to organizers, so core team can have standard language in newsletters that go out. They can encourage automatic updates.
• People treat security as an add-on, so we should assume that a plugin is insecure by default. End users should not assume it is safe because it has a lot of installs. Plugins need to be vetted.
• How do we be mindful of end users using the software. Windows and browsers are good examples, as they alert for insecurities. How do we let end users know via static analysis that there is a security vulnerability, or that there is a security update.
• What about the plugins team? There is tooling for initial approval, but what about after? Is there tooling we can use to check plugins on an ongoing basis? Can we run checks on every release? Unescaped output notification, for example.
  • Tools like this have been tried, and the plugin team is writing tools to help with review and security review. 
  • Most of the time, any widely-known security flaw would not be caught.
• User confidence in the update process. We need to give users a better sense when it is important to update a plugin. People are afraid to do any plugin updates. We need to build that confidence.
• Does WordPress even own the conversation for plugin security? Googling plugin security shows a WordPress.org result as the 5th and it is very stale. Should core be re-thinking APIs that it provides? Can there be a set of APIs that are more secure by default. For example, no use of echo and no direct access of globals. If only using safe functions, then static analysis could be used and a checkmark could be shown on the plugin directory. Such plugins could automatically get plugin updates.
• Secure APIs are helpful, but core needs to own the problem. For example, ZIP file malware scanner, some part of core should be scanning plugins.  Plugin authors have no idea how to examine source code of a plugin whether it is insecure. Core should scan installed plugins to alert users.
• Security plugins (e.g. WPScan) own the database of security vulnerabilities. People need to know if a plugin is secure. There is a plugin that incorporates this information into the directory. What if every time a CVE was opened, a plugin vulnerability could be noted?
• In plugin review team, they only have capacity to review brand new plugins, not updates to existing plugins. The Tide project could be the solution to reviewing new releases. 
• Who owns the security documentation? There is no one place where all security documentation is located?
• Tide is good, but it doesn’t address commercial plugins since they aren’t on WordPress.org.
• Windows Defender has improved reputation of Windows, but it is still less than MacOS. If there was a notification in the WP admin of a plugin vulnerability, it may improve WP’s perceived reputation. In the future, could there be untrusted plugins by default with sandboxed APIs?
• Is there a need to have improved security documentation with howtos on security? Who owns it?
• Writing documentation can be uncomfortable due to differences in English proficiency, but docs team can help with copy review.
• Documentation is passive. The problem we have is active. We have to actively market that WP is safe. 
• It’s not wise for software to be marketed as safe. There’s a lot of danger to brand something as being really secure. You don’t want something to be maligned as being insecure when it isn’t. Instead of saying something is really secure, we should instead communicate that everything is insecure. There’s the risk of false confidence.
• Weighing marketing vs security, we need to document how plugin authors talk about security. What is non-existent is what to do when there is a security flaw, how to communicate to the security team.
• Perception of WP from outside and inside, these are interlinked. If we have a strong message about security, about how X, Y Z are done. Plugin authors could do the same. We don’t have a clear story for how plugin security updates are handled. It needs to be both active and passive.
• We’re the largest attack vector since we’re the biggest. We’re not going to solve the problem with a scanner, as even the biggest plugins have security updates. Who owns the conversation? Form a plan for what security issues are handled by core. What happens when a site gets hacked? There should be a playbook, and core should have a “hacked mode”. Auto-updates should be the default for plugins; users don’t change the defaults.
• Security vulnerabilities are going to happen; what matters is how people reactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. to them. WordPress core has vulnerabilities, but it has a good reputation because they are addressed routinely. Plugins will also have vulnerabilities, and what matters is how we react to them. Fine line between user experience and security. Usernames are not considered private, and that’s a UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. decision. We have to balance all of that.
• Hacked mode in WP would be target of plugins to prevent it from happening.
• Hacked mode would have to be enabled in 3rd party sense, like adding a PHP file to check the integrity of every file, listing users, checking for links to malware sites, scripts in post content, etc.
• Security handbook is stale. The developer part should be separated from the user part. Bottleneck from getting security team to approve documentation updates.
• There can be set approved-upon language that plugin authors can use for security updates.
• What are the next steps?
  • Refining tooling for developers
  • Security team members to work with docs team
• Refining tooling: Static analysis can give a false sense of security.
• How do we feel about unmaintained plugins? Should they be retired?
  • Plugins don’t show up in search results if not tested up to.
• WordPress has made a choice to allow plugins; we could have disallowed plugins to have perfect security. We have a responsibility for security by offering a plugins APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. We have the power to change security via the plugins API.
• There could be a program for getting code review from community members. The docs could have info on how to get paired up with someone else to get code review. It could reduce friction.
• Learn.WordPress.org just started their first cohort course. There could be a cohort course for code review, paired programming.
• There’s a lot of great ideas, and all of it takes time. Activity doesn’t equate to impact. How do we gain insight on what improvements will have the biggest impact. Is it a research project to identify where the problems and what the solutions could be?
• With the end user being a first time plugin developer, it’s nice to have an onramp for someone to create a Hello Dolly plugin. If there’s a lot of hoops and hurdles to get into the plugin repo, we could hurt the end user. 
• What we have to keep in mind is the perception of WordPress being insecure. The best way to combat that is to make widely known that activities are happening, so the word gets out. This will improve WordPress’s perception. In one way, it doesn’t mean whether an activity moves the needle, if it improves the perception.
• If a user has to go through some check in the admin to approve a potentially insecure plugin, it would help improve perception since the plugin insecurity would be the focus.
• We should improve end user experience and provide tools to developers. WordPress core could include in the dashboard that a plugin is vulnerable and to enable auto-updates by default. Plugin developers don’t have a way to release multiple plugin versions with backported versions, to only publish security updates? Does this require the security team? 
• Lowest hanging fruit is improving SEO of WP security docs, getting word out via WordPress publications, and also to have communication between security and docs teams.
• We need to make it more widely known the process for updating a plugin security. Someone needs to draft an SOP.
• How much effort would it be to allow the plugin update system to release old patched versions? It’s a manual process, but it’s simple. Security updates only update a patch version. Currently it requires security team involvement.
• Plugin authors don’t understand version updates, and if they had the ability to push out an update, they would abuse it.
• We have documentation for how to write secure code, but do we have docs on security procedures? It’s all documented in blog posts, so it should be moved to a new page in the plugin developer handbook.
• There should also be security procedure guidelines for commercial plugins to be more secure and what to do when vulnerability happens.
• We don’t have any stats on plugins that we don’t control.

Ryan’s notes:

• Extend to plugin + theme security
• Few people here on WordPress core security team
• How WordPress security is perceived?
  • Badly
  • Two camps:
    • WordPress is insecure from its roots
    • Ran WordPress and site got hacked
      • Insecure hosting and vulnerabilities
      • Both platform and just things outside of WP control (insecure passwords)
  • Can’t do something at scale because it’ll get hacked
  • Transparency can scare people
    • Don’t know the difference between WP and plugins
  • PHP as a language can be considered insecure
  • Scale makes problem worse – raw number makes it more visible
  • Reputation is insecure, regardless of accuracy
  • Core has a decent reputation, people do see the difference
    • Can be plugins outside of control
  • To what degree are people distinguishing between core and plugins?
    • Could we have best practices for plugins?
    • Added autoupdates to tackle some of that
      • Not sure on statistics for that
      • 70%-ish reach within 3 days
      • Don’t always hear from plugin authors to use forced autoupdate process
• Best practices and procedures to show we take security seriously
  • Resources for plugin developers to learn about things
  • Best practises are not just fixing vulnerabilities, but also reaching out to plugins team to roll things out
    • Is that actually scalable for every developer?
    • Could do for >20k installs
  • Talking about “control” but can’t really do so on the repository
  • What can be done organisationally?
  • Fear of (capital S) “Security”
    • Perception of security being a lot more work to do
    • Stigma around security issues
      • Don’t want to see plugin on Google when looking for “plugin security issues”
  • Communication
    • Core is openly discussed and explained
    • In hosting team, explain security things, but don’t talk about that publicly
    • Plugins have ability to “approve” upload
      • Add a security flag when uploading new release
  • Education is important, but not full solution
    • eg Windows analogy – core has responsibility and it’s our issue to solve
  • Newsletters get sent out for organisers, core team could have standard language
  • Security has perception that it’s an add-on thing, can do later
    • Ability to run checks by assuming things are insecure by default
  • How do we mindful of users?
    • Operating systems and browsers have built these things in
    • How do we let users know when a plugin may have a vulnerability?
  • Tooling used when plugin is first uploaded, could more tooling be provided for plugin authors?
    • Tide project was tackling this
    • Raise awareness of issues
    • Plugin review team is exploring more tooling
    • Most security issues
  • Convincing users it’s safe, desirable, worthwhile
    • Give them a sense that it’s safe to update
  • WordPress doesn’t own WordPress security
    • Need to own the conversation in the public sense
    • Core should be rethinking APIs
      • Filtering down to “safe” APIs (e.g. only uses specific secure functions)
  • Idea of zip scanner
    • Giving users a stronger sense of security
  • Who owns security information?
    • Patchstack, WPScan, WordFence “own” conversation about ecosystem
    • Created open vulnerability database to expose more information
    • Information is siloed within each company currently
  • Plugins team only focussing on new plugins, not existing ones
    • Tide project was working towards this, but project is somewhat dead
  • Who owns security documentation?
    • Docs for core, plugin, theme, hosting, but not one place where everything is collected
  • Windows even with anti-virus still percevied as insecure
    • Other systems like iOSiOS The operating system used on iPhones and iPads. and Android have opt-in APIs and sandboxing
• Documentation
  • Takeaway: documentation improvements and coordination
  • Making time for people to write up issues
    • Can end up with not enough time on your hands to write up everything
    • Not everyone is comfortable writing things up
      • Feeling more comfortable about getting things out, and having docs team help with formatting
      • Documentation is passive, active is the problem we have (marketing)
  • Not always wise to market things as secure
    • Danger to branding things as secure
    • Want to make users somewhat skeptical of assuming things are secure, don’t create false confidence
  • Haven’t worked out ourselves exactly what our positioning is
    • Technical parts of docs are OK, but information about how to communicate is somewhat non-existent
  • Having information facing externally and internally, both reinforce each other
  • Biggest project, so biggest vector
    • Perception of insecurity feeds back in to problem, plugin authors stop caring
    • Tools in core to handle what happens when your site is hacked
  • Changing defaults to make plugin autoupdates the default
  • Security vulnerabilities are going to happen, it’s about how we react to it
    • Core has vulnerabilities, but perception is strong because core stays on top of it
    • Making it clear to ecosystem authors that their code will be vulnerable, and they should know how to deal with it
  • Balance of user experience vs security
    • eg usernames not considered private
  • “Safe mode” sounds good in theory, but may require external tools since gets disabled immediately
    • Some tools exist already
    • Troubleshooting mode in the health check could be used for this
  • Some parts of the security documentation are in the [?] handbook
    • Trying to separate developer part from the hosting side
    • Security team says they need to review everything on security
  • Crisis communication process
    • Who can work out least alarming way to phrase things
• Need to work out next steps
  • Refining tooling for plugin developers
  • Custom scripting for finding vulnerabilities
  • Unmaintained plugins?
    • Eventually retiring things
  • We’ve made the choice to offer plugin functionality for user experience, so we have responsibility to make sure that’s secure
    • Important takeaway to recognise this
  • Peer code review to enable learning across the community
    • Offer “standard” way for developers to get review
    • Learn recently started first code course and a lot of people moving through at once
      • Cohort can review as a group
  • Decide on biggest areas we can make impact
  • Talked a lot about end user – who is that?
    • Plugin developer in many case
    • Could be first time developers
  • Main topic is perception
    • Need to disseminate this information
    • Push that messaging out
    • Part of that perception is users’ experience within WordPress itself
  • Work towards improving experience for end users
    • Having public vulnerability database
    • Ensuring plugin developers have same tools
    • Plugin developers don’t really have way to update multiple versions
  • Lowest hanging fruit is SEO for plugin security docs
  • Publicising this and having conversation with docs team
  • Making it known that you can coordinate security updates and backports with plugins team
    • Write up a standard operating procedure for what to do
    • Current process is manual and requires plugins team
    • Controlled in the plugins repository side, can’t be done by plugin authors
    • Processes documented on the make/plugins blog, can look at moving into the documentation
  • Guidelines for paid and third-party plugins

Jason’s Raw Notes

And themes.

Q: Do people have any thoughts about how WP is perceived at the moment in terms of security?

* Badyly.

* Two camps. (1) Insecure. Not scalable for enterprise. (2) I rean WP and my site got hacked. (It comes from the hosting side.)

* Transparency in open source scares the average person.

* PHP has a perception as an insecure language.

* We’ve grown a lot and so even a normal distribution of issues seems worse because the raw numbers (40% of the internet) are high.

* Some think that WP core is secure, but plugins are the issue. Worse yet, it’s paid plugins that aren’t even in the repository. It’s hard to exert control over paid themes and plugins.

Autoupdates helps to make sure plugins are up to date with security fixes. That’s both regular updates and also security updates that get pushed out from .org. When a security update is pushed it gets to 70% of sites within 3 days.

When plugin authors update security patches, the plugin team doesn’t hear about it.

Scaling a process to push security patches might require some extra personnel. “It’s easier than you might think.”

Can education help. “No one writes insecure code out of malice.” It’s because they didn’t know better.

Q: What could we do better to reduce the fear as a topic area and make it easier to follow?

Can we reduce the stigma around plugin authors admitting to security issues.

A PHP 8.0 security issue was communicated via Slack, but could we have done better?

Microsoft takes ownership of antivirus even though the attack vector is zips in emails. Similarlly WP core should take ownership of security issues even though the attack vector is plugins and hosts.

Communication is important. 

In education, security needs to be stressed as a requirement vs something that is done at the end.

Can we build tools similar to browsers warning RE sites, where we do static analysis and warn users RE potential issues.

Plugins team has tooling to approve plugins and do security reviews. Can we provide that same tooling to plugin authors. Continuous integration testing? There is the Tide project.

Oftentimes the kinds of issues that lead to hacks aren’t caught by scanners.

Make sure we talk about the non technical parts too.

User confidence in the udpate process. Is this safe to do, desirable, and worth while. Note security releases somehow? Or someway to know how likely a specific update is to break your site.

Does WordPress even own the conversation around WP security? If you google “wordpress security” the top 4 results are not .org. The first .org result is around WP version 4.x or something else out of date.

Should core rethink APIs to make them more secure by default. It’s only part of making things more secure, but could give us more confidence.

Who “owns” the information around security issues. #wpscan and WordFence have databases. There is a wpvulnerability open database. (This one? https://wordpress.org/plugins/wpvulnerability/)

The plugin team can only focus on new plugins. They can’t review every single update. Is Tide the solution to the review issues?

Q: Who owns the security documentation in the community?

Even with good tooling (a la Windwos Defender) there is still a perception of insecurity. How does flagging issues affect that? Would it make people feel more or less secure.

Could plugins be untrusted by default? And have some way to opt into a trusted list.

Documentation is an issue in general.

There is a marketing issue too around marketing that WordPress is safe.

Is it even advisable to market WordPress as being safe? We need users to take ownership of security too. Risk of false confidence. Security theatre. (Note taker’s note: Reminds me of issues around AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) too.)

Can we publish an SOP RE how to handle security issues?

How is WP perceived from outside the ecosystem and how is it perceieved from inside the system. The 2 are interlinked. If we own the conversation about security, that helps with perception. The lack of messaging is seen as an indication that security is not important. We need a clear coherant story RE security updates, e.g. making sure a security update includes only the security issue to make it easier to update.

Reminder our scale means we will get hacked a lot.

Is there a difference between directory installs vs upload installs? At the same time, even big companies are having security issues.

+1 Who owns the conversation. The way to get ahead of that is to form a plan of the security topics we are going to address.

We don’t do signed distribution of our code. (Chuckles in the audience.)

“Hacked mode”? Similar to how fatal errors are handled. Can core help hacked sites get back to a safe place?

– Hacks will learn to disable this first.

– Could we isolate the checker code so it’s not tamperable via vulnerabilities. (Note taker’s note: or a service on different servers.)

Can auto updates be a default ever? Can plugins opt out of auto updates?

Core has a better reputation than plugins for security because they address the issues methodically. Can we get plugins to do the same?

There is a fine balance between user experience and security.

Need help updating security in the plugin handbook.

Often when we try to update things about security, the security team stops it because it needs to be reviewed.

If we had preapproved standarsd language around security issues, it would make it easier and possible for the documentation team/etc to communicate when issues happen.

Q: How do we feel about deprecating old plugins that haven’t been updated in a while?

“The thing that has helped me most personally around security is code review from peers.” Can we help plugin authors to find peers to do code review. Or a “code review club” instead of a formal review from a plugins team volunteer.

learn.wordpress.org just started “cohort” courses where people are going through together. A cohort would be a good way to find those folks to help review.

The more hoops we give plugin developers to jump through, the fewer folks we will “onramp” into plugin devs.

Technically could we have an “only apply security updates” system that also accounts for hot fixes of old versions.

Take aways:

* If we offer a plugins API in core, we have a responsibility to make sure plugins are secure.

* Whatever we do, publicizing it is an important step in helping the perception of how WP handles security.

Next Steps:

* Refining tooling for developers.

* Security team and docs team figuring things out.

* Plan to “own” the “WordPress security” documentation. Is an official vulnerability DB part of this?

* Could a research project help us to figure out which of the options discussed would have the biggest impact?

* Draft SOP of what a plugin developer should do when they have a vulnerability and/or vulnerability update. (There is content in old make blog posts.) (Also version for how non-org plugins should handle the same situation.)

#security, #summit, #summit-2023