Potential stagnation of open issues on h1 bounty program

[phra]

Hello,

I've recently open few issues on the 3rd party modules h1 bounty program and I'm noticing a bit of delay in responses from the team, e.g. a bug that was fixed two months ago after I contacted the developer myself is still in triaged status without any response but h1 staff ones.

I understand the amount of effort involving managing the program itself but leaving open issues for a long time without any interaction can damage the whole initiative, especially when the only party not actively participating in the resolution are the program managers themselves.

Do you have any thoughts on how we can improve the bug hunters' experience by providing a smoother resolution and achieve more prompt reactions?

I maybe have a couple of suggestions already, that are:

1. predefining a standard flow/timeline that the staff can follow in order to contact the maintainer for a fix and/or disclosure of (un)patched issues in a reasonable amount of time? (like google project zero)
2. increase the number of people actively collaborating to the bounty program

I will be happy to hear from you what are your thoughts on this particular topic.

PS: I can eventually be available to help with the program in my spare time.

EDIT: regarding 1., I noticed that a process is already defined here.

[sam-github]

@phra Conversation is ongoing in #604 thta you may find relevant.

[phra]

thanks @sam-github

[lirantal]

I apologies for that @phra. We are way behind on many reports and have taken actionable steps previously too to ensure we prioritize correctly with the limited time folks here have but that's still hard.

We are welcoming others to join and have recently added a couple more but that's still not scalable with the amount of reports we're getting. I'm happy to hear any ideas you have on #604 as Sam mentioned.

[phra]

i have commented on #604

[mcollina]

I would let you know that the number of issues in the bounty program is too big and the situation is becoming untenable. There are weeks of full time work to exhaust that pipeline and no one who is going to do them.

[MarcinHoppe]

Should we stop accepting new reports until we decide on the new direction and act on that decision? I think we probably should.

[MarcinHoppe]

@nodejs/security-wg I'd love your opinion ☝️.

[mcollina]

Should we stop accepting new reports until we decide on the new direction and act on that decision? I think we probably should.

I think we should keep accepting them for projects/organizations that opted in.

[MarcinHoppe]

Fair point, I agree with that.

[DanielRuf]

I think we should keep accepting them for projects/organizations that opted in.

I agree with this.

Many of the current reports are probably the same findings in different packages and so far most maintainers did not react / answer after I have informed them (so far mostly the low priority bucket ones) so in my opinion this would be helpful to accept these which opted in.

[esarafianou]

I think we should keep accepting them for projects/organizations that opted in.

Where is a list of projects/organizations that opted in?

[phra]

Where is a list of projects/organizations that opted in?

@esarafianou i think they are referring to the repo/orgs list shown on Node.js third-party modules h1 page.

[MarcinHoppe]

We add assets for every new package we have a report for. This list does not represent packages where maintainers opted in to be part of the program.

[phra]

@MarcinHoppe ok, so is this list available to be reviewed? 😄

a question regarding packages that instead were removed from the list (i have reports for packages that were in the list but aren't anymore): does it mean that the maintainers opted out or something else?

[MarcinHoppe]

The best link I think there is is this one:

https://github.com/nodejs/security-wg/blob/master/processes/bug_bounty_criteria.md#modules-list

@lirantal @vdeturckheim is this the correct list of packages that have the maintainer opt-in?

[lirantal]

This one that have confirmed: https://github.com/nodejs/security-wg/blob/master/processes/bug_bounty_criteria.md#confirmed

[esarafianou]

This list seems to be a year old. If we are to allow packages whose maintainers have opted-in, I think it's valuable to reach out to the maintainers once again to verify that they still wish to be in the program.

[mcollina]

I think the situation of the H1 program is getting severe. I've tagged this as tsc-agenda.

I strongly recommend to shut the program down.

[MarcinHoppe]

I agree, I think the fact that it is open sets the expectations we are currently not able to meet.

[MarcinHoppe]

@mcollina any feedback from the TSC?

[mhdawson]

Sorry meant to post this to the issue, from the minutes:

• Discussion, general support from those in the meeting that TSC members
  support shutting down the program.
• Myles can check if they have a replacement at GitHub for places people
  can report vulnerabilities.
• @Trott will reach out to some involved parties on the team to discuss winding it down.

[adam-nygate]

Hi all,

We'd be happy to support the program over at www.huntr.dev.

We're rebuilding our disclosure process at the moment, including support for private disclosure and incentivising security researchers and maintainers for securing open source code.

Perhaps I could introduce myself and what we're building at a future meeting?

[mhdawson]

@adam-nygate +1 to doing an introduction.

One question in advance. From the part on the web site on disclosing a vulnerability, it seems to say to open a pull request. Does that mean the vulnerability is immediately public?

[adam-nygate]

@adam-nygate +1 to doing an introduction.

Great @mhdawson, could you let me know where I can register to attend the next meeting?

One question in advance. From the part on the web site on disclosing a vulnerability, it seems to say to open a pull request. Does that mean the vulnerability is immediately public?

Yes, we built our current disclosure process pretty quickly and around GitHub Issues (which are public by default), we were hoping for GitHub to bring out private issues or to expand the functionality of their security advisory feature, but now our plans are to build out a new disclosure process that supports both full and coordinated disclosure, allowing the Maintainer of a project to choose.

[MarcinHoppe]

How does this compare to HackerOne?

[lirantal]

@mhdawson 9:30 would work.
Can you put me on a calendar invite and I'll forward that internally to the folks?

[mhdawson]

Invite sent

[lirantal]

Thanks! Confirmed I got it and sent internally for folks to join.

[mhdawson]

I'm going to close this one out. From what I understand all triage issues have been closed as outlined in: https://nodejs.medium.com/node-js-ecosystem-vulnerability-reporting-program-winding-down-591d9a8cd2c7

@lirantal mentioned that there are a small number of issues that need to be "triaged" then close in a similar manner but he is planning to do that this week.

[lirantal]

@mhdawson et all - I now finished reviewing all the pending reports too and the HackerOne inbox for the ecosystem security working group is now clear.