Document process to follow when security vulnerability are announced and 1 or more of our repos are affected.

[schalkneethling]

Recently there was a security vulnerability found in a NPM package that interactive examples and BoB indirectly depended on. The required quick action, including notifying users, contributors and forks of these projects.

We need to document the process that followed as it seemed to have been very effective. This will take away some of the guesswork should this scenario happen again in future.

Acceptance Criteria

• A document describing this process exists in mdn/mdn and has been reviewed by 1 knowledgeable stakeholder.

[schalkneethling]

A little history

On ~27 November 2018 an NPM security vulnerability was announced for all users that depend, either directly or indirectly, on the event-stream package. It was a very targeted attack, that only activated if the Copay bitcoin wallet was installed, whereupon it tried to steal the contents.

Two of our projects, namely interactive-examples and BoB, depend on an NPM package called npm-run-all, which in turn depended on the event-stream package.

This meant that not only was staff at risk, but people who have forked either of these repositories might have been affected as well. Thankfully the maintainers of the affected package reacted swiftly and released an update to address the issue. Because we have the Renovate bot running against these repositories, there was a pull request ready to merge.

This only resolved one part of the problem though. Our users still needed to be notified.

Steps taken

The community for especially the interactive-examples project was rather large, and not everyone active, but we still needed a way to reach out to everyone. The first step was then to open an issue against each of the repositories detailing the problem:

• interactive-examples
• bob

That by itself is not enough as users do not necessarily actively monitor issues. We therefore, needed to look at all of the forks of the project, for example: https://github.com/mdn/interactive-examples/network/members

We then copied all of the usernames for these users and pinged them on the above issue, for example: mdn/interactive-examples#1242 (comment)

This was very effective from the response we received in the issue, but we could not leave it there. The next step was to post a comment on each of the open pull requests informing the user of the problem, and what their next steps should be:
mdn/interactive-examples#1144

With this, we felt rather confident that between us reaching out, and coverage of the issue online by NPM and other channels, would ensure that we ensured our users are safe.

As a final step, @schalkneethling posted a message on Twitter which was in turn retweeted by the MDN Web Docs Twitter account.

In closing

Hopefully, these types of incidents will be few and far between. Should this happen again however, the above provides a solid guideline on how to respond.

[schalkneethling]

@jwhitlock r? ^^

[jwhitlock]

This is a great summary, @schalkneethling, thank you.

I'm concerned that if we close this issue, then we'll lose this information. It would have a more permanent home as a markdown file in the repo. At the same time, these incidents are few and far between, so maybe it can wait for the next one to formalize.

Do you think it should be added as a file to the repo, or close the ticket and rely on search and memory?

[schalkneethling]

@jwhitlock I reckon adding this as a markdown file makes sense. Perhaps something like security-vulnerability-response-steps.md?

[jwhitlock]

@schalkneethling I like the idea of a document. Please mark me as the reviewer on the PR to this repo.

[jmswisher]

Marking this as "Not done - continue later" in the tracking spreadsheet.

[jwhitlock]

With the document merged, this issue is closed.