Let's start the charter ✨ by UlisesGascon · Pull Request #1 · webpack/security-wg

Let's start the charter ✨ by UlisesGascon · Pull Request #1 · webpack/security-wg

This is an initial proposal, feel free to add comments/changes/suggestions until we are all aligned!

		- Recommend security improvements for the project and the packages in scope
		- Support the TSC team on security triage as needed
		- Support initiatives from the [OpenJS Foundation Security Collab Space](https://github.com/openjs-foundation/security-collab-space).
		- Support initiatives from the OpenSSF [Best Practices for Open Source Developers Working Group](https://github.com/ossf/wg-best-practices-os-developers).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can skip this one, as we try to bring the initiatives first to the Collab Space


		### Responsibilities

		- Define the Security triage role

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably this can be also a good next initiative, define how the triage work is done in much more detail


		The Security Working Group is composed of two groups of members: the Security Triage Team and the Regular members. The regular members are responsible for the public facing activity of the group, while the Security Triage Team is responsible for the security triage process.

		### Security Triage Team @webpack/security-triage

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assumed that we want to list them here

Comment on lines +24 to +26

		\|------------\|----------\|--------\|-------\|
		\| Kick off the WG \| [@UlisesGascon](https://github.com/UlisesGascon) \| In progress \| _none_ \|
		\| Incident Response Plan \| [@RafaelGSS](https://github.com/rafaelgss) \| In progress \| [PR #19841](https://github.com/webpack/webpack/pull/19841)\|

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was an example, feel free to suggest/remove 👍


		## Members

		The Security Working Group is composed of two groups of members: the Security Triage Team and the Regular members. The regular members are responsible for the public facing activity of the group, while the Security Triage Team is responsible for the security triage process.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assumed that this repo and the group work will be potentially public in the future. The triage part will be private (to prevent early disclosure) as we do in Node/Express.

Comment on lines +36 to +45

		### Lead Members @webpack/security-wg-leads

		_TBA_

		### Team Members @webpack/security-wg

		- [Claudio Wunder](https://github.com/ovflowd)
		- [Even Stensberg](https://github.com/evenstensberg)
		- [Rafael Gonzaga](https://github.com/RafaelGSS)
		- [Ulises Gascón](https://github.com/UlisesGascon)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel free to update roles and members


		## Meetings

		The Security Working Group meets on an ad hoc basis. The meeting is open to the public. The agenda and meeting notes are published in this repository. You can find the calendar entries in the [OpenJS Foundation calendar](https://openjsf.org/collaboration).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assumed that we want to do only ad-hoc meetings (as in Express) but we can go for regular meetings as we do in Node.js if makes sense. But probably this is something that we can figure out in the future.

		@@ -0,0 +1,23 @@

		\| Name \| Github Repository \| npm

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did an initial scoping by ignoring deprecated, achieved, etc... but I might missed some packages/repos. Ideally we focus only on repos that are code related