Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
1 task
schalkneethling opened this issue Nov 29, 2018 · 8 comments
Assignees

Comments

@schalkneethling
Copy link

schalkneethling commented Nov 29, 2018

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.
@jwhitlock jwhitlock added this to the Diana Ross (Q4 S4 2018) milestone Nov 29, 2018
@schalkneethling
Copy link
Author

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:

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
Copy link
Author

@jwhitlock r? ^^

@jwhitlock
Copy link
Contributor

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
Copy link
Author

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

@jwhitlock
Copy link
Contributor

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

@jmswisher
Copy link

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

@jmswisher jmswisher removed this from the Diana Ross (Q4 S4 2018) milestone Jan 23, 2019
jwhitlock added a commit that referenced this issue Jan 28, 2019

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
…rity-vulnerability-response-steps

Issue #45, add doc describing security vulnerability response steps
@jwhitlock
Copy link
Contributor

With the document merged, this issue is closed.

@bsmth
Copy link
Member

bsmth commented May 9, 2025

This is being sunset from content. I'm posting here so the information is visible to anyone dropping by to the former page (which now redirects here):

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:

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.

We then copied all of the usernames for these users and pinged them on the above issue, for example by commenting in it.

This was very effective, judging from the responses the issue received, 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. Here is an example of our answer.

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, we tweeted from our official Twitter account to raise awareness of the issue.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants