add security triaging to core repo GOVERNANCE.md and/or charter?

[Trott]

Refs: #1097 (comment)

Security triaging is not mentioned in the charter or in the core repo GOVERNANCE.md. Should it be? (I vote yes and will be happy to come up with some wording for GOVERNANCE.md. I don't think it needs to be enshrined in the charter, at least not initially. We can always add it to the charter once we've done a test-drive with having it in GOVERNANCE.md for a while.)

I'm also interested in discussing (again, as we had the conversation recently) how to spread the triaging workload a little bit more. Matteo is doing almost all of it these days. Some of that is because the reports tend to be in http and related modules, where he has more expertise than most (all?) current TSC members. But the act of making sure reports are responded to in a timely fashion and so on doesn't have to fall to him solely, I imagine. If we can establish a rotation of four or five people, I'd be happy to be "on call" for checking H1 a few times a day and making sure we're not about to go over a SLA time commitment or anything, and responding with general questions to reporters and so on.

[mcollina]

All the above is documented in https://github.com/nodejs/TSC/blob/main/Security-Team.md, however it does not have much participation by other TSC members.

I agree in making it one of the fundamental responsibilities of the TSC.

[mhdawson]

+1 on the rotation side of things, did you have something in mind for the time somebody is on rotation (week ?).

[Trott]

+1 on the rotation side of things, did you have something in mind for the time somebody is on rotation (week ?).

I was thinking more like a day at a time, but we can talk about longer time frames like a week at a time if we think that is better.

I guess my initial spitball idea would be five slots per week:

1. Sunday/Monday
2. Tuesday
3. Wednesday
4. Thursday
5. Friday/Saturday

We'd have to carefully spell out that time zone, such as "midnight to 11:59pm UTC" for each "day". With five (or more) people and with people being willing to sometimes take two (or more) slots in a row to cover for people on vacation or in crunch time at work or whatever, that seems like it could work.

Another possibility might be two slots, but I find this more daunting:

1. Friday/Saturday/Sunday/Monday
2. Tuesday/Wednesday/Thursday

[Trott]

Also, if there's a group of five or more people committed to triaging, perhaps there could be a one hour meeting every other week where whoever can attend goes over (as a group) anything that's stuck or about to miss a deadline or something like that.

It's tempting to suggest that ought to happen at a TSC meeting, but at least in the short term, I think that will make things worse because all the time will be spent catching people up who haven't been paying close attention to the HackerOne queue. So better, at least initially, if it's a core group of people that at least read everything that comes in.

Here's a list of initial folks who might be willing/able to do this work if we can spread it around enough and not burn out one person subjected to doing it all. (I'm looking in Matteo's direction.)

1. Matteo
2. Vladimir
3. Michael Dawson
4. Rich
5. ONE MORE PERSON (@ChALkeR perhaps?)

[Trott]

@nodejs/tsc

[mcollina]

I think a better rotation is weekly or biweekly. Daily seems too complex and there are weekends which are problematic for most people.

[Trott]

I think a better rotation is weekly or biweekly. Daily seems too complex and there are weekends which are problematic for most people.

Sure. Let's flesh this out a bit. First, by "biweekly", you mean a rotation that lasts two full weeks? Or one that lasts half of a week? I gather from context that you mean two full weeks, but let's confirm anyway.

What would be the number of people we'd need to make this workable in your opinion? Four? Six?

[mhdawson]

+1 on daily being too complex.

I also don't think we have to commit to an SLA that says we respond immediately. If it takes a day or two I don't think that should be a problem. I also don't think we need to commit to responding on the weekends. Realistically it can take weeks/months for a patch even when we think it is important. I think if we set expectations, no weekends and within a day or two should be reasonable for a open source project. We should check what we say in terms of our H1 site though and if we need to update them to be consistent with what we choose.

I would go for 6 to make it workable. We have 22+ people on the TSC, we should push to have more support/involvement from the larger group if we can.

[mcollina]

Sure. Let's flesh this out a bit. First, by "biweekly", you mean a rotation that lasts two full weeks? Or one that lasts half of a week? I gather from context that you mean two full weeks, but let's confirm anyway.

Two full weeks.

What would be the number of people we'd need to make this workable in your opinion? Four? Six?

Four people at minimum, Six ideal, Eight would be perfect.

[Trott]

@vdeturckheim @danielleadams @ronag

[Trott]

Following up on this, the relevant text to start with is in https://github.com/nodejs/TSC/blob/main/Security-Team.md#nodejs-security-team-membership-policy:

1. All members of @nodejs/TSC have access to private security reports and private patches.
2. Members of the @nodejs/releasers team have access to private security patches in order to produce releases.
3. On a case-by-case basis, individuals outside the Technical Steering Committee are invited by the TSC to have access to private security reports or private patches so that their expertise can be applied to an issue or patch. This access may be temporary or permanent, as decided by the TSC.

The first item means that all Node.js TSC members have access to nodejs-private and to HackerOne. That makes sense to me but also highlights our need to be better about removing inactive folks from the TSC.

The second point means that Releasers have access to nodejs-private but not HackerOne. This makes sense to me as well but likewise highlights a need to frequently audit members of that list for inactivity too. (As of this writing, there is only one person on the Releasers team who is not also on TSC. Their last release was in late March.)

The third point is worth reviewing in some detail. I'll start an email thread with TSC on this.