[Doc] Create a vulnerability management team

[russellb]

If there is support for this proposal, we should name an initial group for the
vulnerability management team. I'm happy to serve in the role if the project
maintainers are interested, but I am of course happy to put any names here that
you see fit.

4d5bbcc [Doc] Propose a vulnerability management team

commit 4d5bbcc
Author: Russell Bryant [email protected]
Date: Fri Nov 1 16:46:48 2024 +0000

[Doc] Propose a vulnerability management team

The project has a policy for how vulnerabilties are reported, but
there is no specific indivudual(s) who has the responsibility for
ensuring that these reports are acted on in a timely manner. To
address this, I propose naming a "vulnerability management team" who
would have this responsibility.

The list of individuals that would seed this team is TBD.

Signed-off-by: Russell Bryant <[email protected]>

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.
Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which starts running only a small and essential subset of CI tests to quickly catch errors. You can run other CI tests on top of those by going to your fastcheck build on Buildkite UI (linked in the PR checks section) and unblock them. If you do not have permission to unblock, ping simon-mo or khluu to add you in our Buildkite org.

Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can do one of these:

• Add ready label to the PR
• Enable auto-merge.

🚀

[hmellor]

We could automate the discovery and reporting of such issues using Snyk's GitHub integration.

https://docs.snyk.io/scm-ide-and-ci-cd-integrations/snyk-scm-integrations/github

[russellb]

We could automate the discovery and reporting of such issues using Snyk's GitHub integration.

https://docs.snyk.io/scm-ide-and-ci-cd-integrations/snyk-scm-integrations/github

Indeed, though I'd prefer to keep that separate from clarifying the people and process for handling security issues.

[simon-mo]

I'm in favor. Is there a way to document the members of the team? (similar to CODEOWNERS)? And how do I give folks access to the current list of security advisories without giving admin rights?

Thank you for proposing this.

[russellb]

I'm in favor. Is there a way to document the members of the team? (similar to CODEOWNERS)? And how do I give folks access to the current list of security advisories without giving admin rights?

I left a spot in the proposed document to list the team members. That would provide the public view of the list.

GitHub also supports having a team for "security managers" in your GitHub organization. This would be done at the github.com/vllm-project level. Details here: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/managing-security-managers-in-your-organization

I think that's what you want -- a team that grants only the permissions necessary for viewing and editing security reports.

Thank you for proposing this.

Sure! Thanks for taking a look.

[simon-mo]

LGTM. I believe we can also mention corresponding channels in the vLLM Slack workspace.

[russellb]

LGTM. I believe we can also mention corresponding channels in the vLLM Slack workspace.

I pushed another commit to:

• add you and I as the initial VMT members
• point people to #security on Slack for security discussion (but not about private vulnerabilities)
• add a link to the vulnerability management doc from SECURITY.md.

This is ready to go now, IMO.