Update Security Policies and Procedures

[UlisesGascon]

Currently, we provide this Security.md as the reference for researchers.

There are somethings that we might want to change, for example the way of reporting:

Report security bugs by emailing the lead maintainer in the Readme.md file.

I will suggest to use a plain email reference or even better an alias so the security triage team can get notify and not individuals. I think that we should provide a way to send secure messages (PGP?).

The lead maintainer will acknowledge your email within 48 hours, and will send a more detailed response within 48 hours indicating the next steps in handling your report.

Maybe we can change this a bit to mimic the Node.js policy:

Normally your report will be acknowledged within 5 days, and you'll receive a more detailed response to your report within 10 days indicating the next steps in handling your submission. These timelines may extend when our triage volunteers are away on holiday, particularly at the end of the year.

By checking the Node.js Security policy I noticed two interesting things:

1. They relay in an external bug bounty platform: https://hackerone.com/nodejs/hacktivity and not emails
2. They provide security updates using the blog and google groups: https://github.com/nodejs/node/blob/main/SECURITY.md#receiving-security-updates

[wesleytodd]

even better an alias so the security triage team

We can get this setup with the foundation. Honestly I thought we had done that but then we apparently had decided only on a tc email we planned to use for this. If you are good with express-security@lists.openjsf.org then I can put in the request and get us added. I am sure I will need everyones emails for that, maybe we should also make a private email list somewhere for folks the project because I keep on having to ask for them or rely on Ben to find them in the foundation records.

[UlisesGascon]

@ruddermann it is working on it at foundation level and there is a proposal on going, so I will check that out and create a PR soon with the changes :)

[UlisesGascon]

If you are good with express-security@lists.openjsf.org then I can put in the request and get us added. I am sure I will need everyones emails for that, maybe we should also make a private email list somewhere for folks the project because I keep on having to ask for them or rely on Ben to find them in the foundation records.

I think that is a good idea, we can add an issue in the private repo and ask for the emails. Also we will need to include this step in the onboarding process once is completed 👍

[ruddermann]

Excuse my ignorance if there is value in using a mail distro, but is there any particular value over using a dedicated tool like Private Vulnerability Reporting in Github instead? There's also potential for you to get an open source H1 account if that was interesting to you.

It's generally a good idea to only accept bugs by one channel, so it's common for programs to only accept bugs through a platform and not accept via email anymore. One of the reasons for this is that there is some recourse for bad behavior by researchers thanks to platform T&Cs and having standardized, in-platform processes instead of ad hoc ones based on custom scripts and humans remembering stuff.

On using Google Groups to announce security updates, this seems like something better served by something more modern like Github Advisories and/or updates to the website itself. Is the use of Google Groups like this common in open source? I ask because this is pretty non-standard in other places.

Having an email distro for folks to ask questions makes sense if you want, but also unnecessary if you have a platform, since legitimate questions that aren't answered by the Disclosure Policy often turn into vuln reports anyway (and via platform they can be formally accepted or rejected). The Policy itself should be the place to answer common questions that do come up along the way.

[ruddermann]

Since y'all are starting from scratch on this program, you can build an approach that provides a more consistent and transparent experience for researchers vs ad hoc processes. Express already has a lot of good structure for this (dedicated security reporting page that includes contributor guidance), so it's really the reporting channel and advisory release process that needs to be fleshed out. In general, when building vuln disclosure programs, it's generally a good idea to use common processes and patterns.

I don't know if y'all have had any discussion on this yet, but absent that, my initial suggestion is:

1. Get a HackerOne open source license or use Github Private Vulnerability Reporting (PVR). Using PVR would mean enabling it on all repos in the Github org.
2. Accepting questions via an email is fine, but does offer room for genuine and malicious confusion by researchers who are generally no longer communicating bugs via email and are trained to use a platform-based experience. Building a runbook around PVR/H1 will be easier and reduce manual human steps.
3. The actual vulnerability policy in each repo points to a centralized policy displayed on the Express website and maintained within Github.
4. Advisories are published using Github Security Advisories and thus are visible under the Security tab for each repo.
5. A central list of all security advisories should be visible on the website separate from other release announcements, and this file can be maintained within Github. You already have this here.
6. Get CVEs issued automatically via PVR as part of the built-in Advisory publication process. If you're on H1, I wouldn't wouldn't use H1 as the place the official advisory announcements, but you can use it for reserving CVEs in a transparent, researcher-friendly way.

[UlisesGascon]

Thanks for all the feedback @ruddermann. It is clear for me that email reporting is not the way but maybe valuable for announce security updates (we still need to map out better our dependants), also it is harder to track for us AFAIK. Between PVR and H1, I will love to go more in detail for our case, so I will probably discuss this with you directly in slack.

[wesleytodd]

Excuse my ignorance if there is value in using a mail distro, but is there any particular value over using a dedicated tool like Private Vulnerability Reporting in Github instead? There's also potential for you to get an open source H1 account if that was interesting to you.

I think we may even have one? I thought we had used H1 to triage something in the past. That said, I am not at all opposed to using GH tools either. Honestly whatever you recommend is what we will do! :P

[ruddermann]

@wesleytodd I'm happy to reach out to H1 and find out the status of a license you may have already. If there isn't one, H1 has a request/approval process the project would have to go through with H1, since they offer these licenses on a case-by-case basis. So we'd need to see what they consider when doing this.

@UlisesGascon From a process perspective, the only downside doing it an email distro in addition to a more normalized security advisory/bulletin like GH's is additional process complexity and if updates to the advisory are needed after they're published. Otherwise it's not a huge thing, I'm not sure if it's the best way to exclusively do it.

[ctcpip]

Excuse my ignorance if there is value in using a mail distro, but is there any particular value over using a dedicated tool like Private Vulnerability Reporting in Github instead?

Email should always be provided at least as one option. Per the OpenSSF Guide to implementing a coordinated vulnerability disclosure process for open source projects:

The vulnerability reporter is doing you a favor; don't add more steps than absolutely necessary. In the spirit of this balance, our recommendation is that using email for intake is okay, and should at least be provided as an alternative.

Things like GH PVR are great but they also require folks to create an account.

[wesleytodd]

Things like GH PVR are great but they also require folks to create an account.

I personally am comfortable with that requirement. If we prevent low quality reports by not allowing an email report and also require a GH account I think that is actually a good thing.

[ctcpip]

If we prevent low quality reports by not allowing an email report and also require a GH account I think that is actually a good thing.

shouldn't assume that by doing this you are preventing low quality reports. and you may also be preventing high quality reports.

[ctcpip]

also, if you don't provide a dedicated security email, people will email maintainers directly

[wesleytodd]

That already happens, ok you sold me. I think we should have both, a list express-security and either H1 or GHPVR.