suggest that security reports handled using a tool other than github's issue tracker

[sam-github]

Some concerns have been raised with the current tools used to track security reports for Node.js:

• Who should have access to the security repo ?  CTC#96 points to ongoing concern about how many people have pre-release access to security reports (27+)
• can we improve the security reporting process for node security-wg#17 points to ongoing concern about the opaqueness of the security report process to external reporters

In the August 8th Security WG meeting we got a demo by @reedloden of HackerOne, and it appeared to me that it addressed many of the concerns about the current github issue-tracker based system. I suggest that the TSC / @nodejs/security consider using it as a tool to track, discuss, triage, etc. security issues. From above, this is how I think it would be useful:

The thing they might find most compelling for use with node core relates to permissions, since the Response team size has been described as too large recently. Use of HackerOne will allow:

• Web or email submission of vulnerabilities, with the submitter being allowed to view and discuss the submission directly using the web UI.
• The conversation history to be made public when a vulnerability is publicized: ATM all conversations about vulnerabilities are private for ever, unnecessarily.
• A triage team of 3 or 4 people who can see every submission, and either reject it as not a vulnerability, or assign it to the correct people to work on it further (those people would get access to only the one specific pre-release vulnerabilty). This would allow, for example, HTTP experts who are not on the Response team to be brought into the discussion of an HTTP issue. It would also allow the setup of a team to further triage npmjs.org package vulnerability reports, so the response team can re-assign non-node core vulnerabilities.

[sam-github]

/cc @nodejs/security-wg

[gibfahn]

Sounds like it has some useful features, agreed that using a custom tool probably makes more sense for this.

Questions:

• Is there a good way to migrate existing issues over there?
• Is there a way to make discussions public after fixes are released?

[reedloden]

- Is there a good way to migrate existing issues over there?

Yes, existing issues can be imported. We (HackerOne) would be happy to help with that.

- Is there a way to make discussions public after fixes are released?

Yes, we support multiple forms of public disclosure. Check out https://support.hackerone.com/hc/en-us/articles/205269479 for some more details about how disclosure works, or just take a look at https://hackerone.com/hacktivity for some recently disclosed issues.

[mhdawson]

I think it looks like a good option, input from those currently triaging would be good. @rvagg, @bnoordhuis comments ?

[rvagg]

Without looking into the details on HackerOne or giving a firm opinion here (I'm actually pretty happy to have the security-wg push on policy here, that's healthy I think). My general thoughts on the state of play is this:

• The "triage" team is essentially 6 people, they receive the security@ emails, as listed here: https://github.com/nodejs/email/blob/master/iojs.org/aliases.json#L51-L56 - in terms of actually triaging it's been mostly myself and @bnoordhuis with a bit of @jasnell IIRC. A bunch of traffic is just ignored as spam, some is responded with "this is not the right place to get help, go to ..." and others are actually triaged. Many of the valid ones end up as issues with verbose text pasted in the private security repo.
• I don't think our triage process is bad, but it could certainly be considered somewhat ad-hoc, we don't have a consistent process defined and it's really just evolved. In fact depending on who does the responding you'll get a different set of steps followed. So I'd be happy to see more process developed around this to make sure that reports flow through the process properly and nothing slips through the cracks (including keeping the reporter informed of progress, we've had a number of occasions where reporters have become antsy with our slow progress or lack of reporting to them on what we're up to).
• Regarding who has access to nodejs/security, I actually don't think we have too many people, what we have is not enough active people who can help come up with fixes. When I've had to shepherd fixes through the process it's been very frustrating to get enough engagement to come up with quality fixes and we've had more than one release that has required subsequent patching because the quality was low. It makes me yearn for the process on nodejs/node where you have lots of eyes. If you trim the list down of people who have access then it'd have to be from people who don't give any input, and there are plenty of those, but I'd also like to see more active and trusted people brought in that can help come up with solid fixes to security bugs, even if it's just reviewing and testing. I wouldn't mind the security-wg coming up with some kind of proposal for generating a list of people that can help in that process and can be trusted with the responsibility and aren't just there to see what's going on, that's no help at all.

Does that help?

[sam-github]

membership scope also being discussed here: #358

[jasnell]

This discussion has largely been taken over by the @nodejs/security-wg. As there does not appear to be anything further to discuss in this thread, closing.