Refocusing the Ecosystem Security WG on OpenJS Foundation projects

[MarcinHoppe]

Background

In the last few months we have experienced some stagnation in our ability to resolve vulnerability reports (#654) and have developed quite a significant backlog (183 high priority and 83 low priority triaged findings sitting in the queue at the moment of publication). We discussed improving our how triage works by improving thresholds for high and low priority buckets (#604). Unfortunately this has not resulted in any meaningful action.

Opportunity

I personally think that keeping the program open for submissions for the entire JavaScript ecosystem is not sustainable. To make matters worse, the openness of the program leaves an impression that we can handle and address all reports. The most recent experience shows that we are not able to do it.

It is also not clear if we should: focusing on niche packages with low number of downloads benefits very few users. At times we spend a lot of time chasing maintainers only to learn the project has been abandoned or not hear anything from maintainers at all. I think it has already been acknowledged that focusing on packages with high number of users and active maintainers committed to fixing security issues would allow the WG to better serve the community.

The OpenJS Foundation is currently home to several very popular JavaScript projects (e.g. jQuery, Electron, and Node.js itself). Not all of those projects have robust and mature security reporting, triage, and disclosure capabilities.

Those projects, however, have large user base and active, committed maintainers. I think refocusing the WG on OpenJS Foundation projects and incentivizing researchers to focus on those projects would allow this WG to have greater overall impact on the security of the JavaScript ecosystem as a whole.

Questions

• Should we narrow down the scope of this WG and the associated HackerOne program to OpenJS Foundation projects?

• Alternatively: to stay true to the original mission of this WG, should we only accept reports for packages where maintainers have agreed to participate in the program and are able to provide timely patches?

[sam-github]

I think the WG set off on a voyage across a landscape that has fundamentally changed since it set out, and maybe the voyage needs reevaluation.

At the time nsp donated the DB, and the foundation started maintenance: snyk existed, nsp existed, but neither npmjs.com nor github offered support for accepting security advisories, and npm audit did not exist.

The foundation DB was an attempt at a vendor neutral vuln DB that would enable innovation in the community about how to use the vuln data.

Since then, snyk continues to develop, npmjs.com now has a built-in way to report vulns, github.com now has a built-in advisory support, and then github bought npm...

Its a different world, is there really value in continuing to accept vulnerabilities on any set of npmjs.com packages if those packages don't have a relationship with the js foundation, or at least, an agreement with this group that it will triage their vulnerabilities with or for them?

To be clear, I am not saying there is no value, just that if there is, I'm just not sure who the beneficiaries are. The people who find the DB really useful to them and will miss it if its not maintained should please step up!

Wrt Marcin's suggestion, the idea of reforming the wg as a triage and response team specifically for jsfoundation projects sounds great to me. It has a clear goal. Its not something, from his description, that sounds like its being done now (so its not duplicate work). Its probably achievable with the volunteer resources available.

[MarcinHoppe]

@sam-github Thanks for this opinion. You bring a very good point about the evolution of the vendor landscape for Node.js package security.

@nodejs/security-wg I'd love to get your thoughts about this.

[mcollina]

I deeply support this refocus.

[sam-github]

And to be even more explicit:

1. I would support either (or both) of the approaches @MarcinHoppe mentioned (under "Questions").
2. I feel strongly that the people volunteering to do the work should have a great deal of say on what work is done. I'm not involved in ecosystem triage, so while I express an opinion, I'd give more weight to the opinions of those comitting their time.

[vdeturckheim]

I would be more inclined to the first proposal and refocus on the foundation.
However, if some project outside of the foundation wish to be part of this initiative, I would be happy to find a way to associate them with it. Kind of an open door policy to help any project who requires it.

[MarcinHoppe]

I now realized I started the discussion without stating my preference: I am also in favor of focusing on OpenJSF projects with leaving open door for other projects to opt-in without explicitly joining OpenJSF.

[esarafianou]

I think focusing on OpenJSF projects while allowing other projects to opt-in is the right direction but I'd change the wording a little bit.

In my mind, we're moving in working with a whitelist of projects and the OpenJSF projects are the ones to be added as starters in this list. Any other project can be added (maybe we need some thresholds here?) as long as its maintainers want to and commit to collaborate with us on any findings.

I think it's important that the message is clear: It's not that we're focusing only on OpenJSF projects. We want to start working on a specific - but expandable - list of projects. Welcoming maintainers to be part of this and include their projects in the list should be highlighted in our message.

[mhdawson]

I agree with @sam-github comment.

I think the WG set off on a voyage across a landscape that has fundamentally changed since it set out, and maybe the voyage needs reevaluation.

There are other options for reporting vulnerabilities now, and its a good to time revisit what adds value going forward. I see a few questions:

1. Database: Does the "neutral" database adds enough value to keep it going. I think most most of the comments are on the "no" side and that people would be comfortable with other existing alternatives for vulnerability databases.

2. Triage: Even if the WG stopped maintaining database it could still help with triage/management of reported vulnerabilities. From the discussion/experience it's clear that we can't keep up with triaging for all packages and there needs to be a tighter focus. I think a refocus on "helping" key projects/packages makes sense, and starting with those in the OpenJS Foundation is a good first step. I think it would be good if the WG would work on a number of programs that projects could opt into. For example bug bounties, triage support etc. I think the WG could focus more on getting those programs up and running, and helping to find/keep engaged volunteers to then help specific projects. For example instead of being on the hook to triage incoming vulnerabilities I'd see the group help find/co-ordinate volunteers who are willing to help one or more projects. In this context the projects who opt in would still need to "own" the triage but would have help from volunteers, common processes set up by the WG etc, access to expertise from the WG etc.

3. Should the WG remain as a Node.js WG or possibly move to be a OpenJS WG? It's probably a good time to answer that as well.

[lirantal]

+1 on the refocus for the umbrella projects in OpenJS and allowing for other projects to pro-actively opt-in (which we'll need to create a process for).

+1 on expiring the vulnerability database in this repo. It's a cumbersome process for us triage team to always sync it and I don't see any other purpose that it serves that others can't get from H1. The reports are open and available there too.

[MarcinHoppe]

I would like to add a few things to @mhdawson points:

1. Database: Does the "neutral" database adds enough value to keep it going. I think most most of the comments are on the "no" side and that people would be comfortable with other existing alternatives for vulnerability databases.

Increasingly, the value of a vulnerability database will come from intelligent tooling that can be built on top of it. The databases will have to be constantly embellished with new data about existing and new vulnerabilities. For example: we should probably be capturing the vulnerable entry point for each vulnerability in the ecosystem DB so SCA tools built on top of it could provide more accurate information about impact of a vulnerability.

I don't think this WG has means or incentives to constantly evolve a growing body of vulnerability metadata.

2. Triage: Even if the WG stopped maintaining database it could still help with triage/management of reported vulnerabilities.

💯 that. We have a lot of expertise in coordinated disclosure, working with multiple parties, navigating conflict situations. I think this is what we can also contribute to OpenJSF.

3. Should the WG remain as a Node.js WG or possibly move to be a OpenJS WG? It's probably a good time to answer that as well.

If we are branching outside of Node.js, my vote would go to become an OpenJSF body. I know this is an extra step to go through, but observing how OpenJSF works, it would be very beneficial to operate there.

[lirantal]

Wrong button :-)