[Doc] Add SECURITY.md with vulnerability reporting policy

[arijitroy003]

Summary

Adds SECURITY.md for responsible vulnerability disclosure. 2.5k-star repo currently has no security reporting path.

Changes

• Add SECURITY.md based on upstream vllm project template
• Adapted threat model for production-stack (deployment/orchestration focus)
• Documents severity levels and fix disclosure policy
• Links to vLLM vulnerability management team for coordination

Testing

Verified by grep — documentation only change.

[gemini-code-assist]

Code Review

This pull request introduces a new SECURITY.md file outlining the security policy, threat model, severity levels, and disclosure/prenotification policies for the project. The review feedback suggests rephrasing a sentence fragment in the CRITICAL severity description for better consistency and grammar, as well as updating list bullet points from asterisks to hyphens to maintain consistent Markdown formatting throughout the document.

[gemini-code-assist]

The second sentence in this paragraph is a fragment ("Generally those issues which are rated as CVSS ≥ 9.0.") and is inconsistent with the phrasing used in the subsequent severity sections (e.g., "These issues typically have CVSS scores..."). Let's rephrase it for grammatical correctness and consistency.

Suggested change

	Vulnerabilities that allow remote attackers to execute arbitrary code, take full control of the system, or significantly compromise confidentiality, integrity, or availability without any interaction or privileges needed. Generally those issues which are rated as CVSS ≥ 9.0.
	Vulnerabilities that allow remote attackers to execute arbitrary code, take full control of the system, or significantly compromise confidentiality, integrity, or availability without any interaction or privileges needed. These issues typically have CVSS scores of 9.0 or higher.

[gemini-code-assist]

To maintain consistent Markdown formatting throughout the document, please use hyphens (-) instead of asterisks (*) for list items, matching the style used in the 'Threat model' section.

Suggested change

	* **CRITICAL and HIGH severity**: Fixes are developed in a private security fork and coordinated with the prenotification group before public disclosure.
	* **MODERATE and LOW severity**: Fixes are developed and submitted as public pull requests. These issues do not require embargo since they do not enable arbitrary code execution or significant data breach, and public visibility accelerates community review and adoption of the fix.
	- **CRITICAL and HIGH severity**: Fixes are developed in a private security fork and coordinated with the prenotification group before public disclosure.
	- **MODERATE and LOW severity**: Fixes are developed and submitted as public pull requests. These issues do not require embargo since they do not enable arbitrary code execution or significant data breach, and public visibility accelerates community review and adoption of the fix.

[gemini-code-assist]

To maintain consistent Markdown formatting throughout the document, please use hyphens (-) instead of asterisks (*) for list items, matching the style used in the 'Threat model' section.

Suggested change

	* This prenotification will be in the form of a private email notification. It may also include adding security contacts to the GitHub security advisory, typically a few days before release.
	* If you wish to be added to the prenotification group, please send an email to the members of the [vLLM vulnerability management team](https://docs.vllm.ai/en/latest/contributing/vulnerability_management.html).
	- This prenotification will be in the form of a private email notification. It may also include adding security contacts to the GitHub security advisory, typically a few days before release.
	- If you wish to be added to the prenotification group, please send an email to the members of the [vLLM vulnerability management team](https://docs.vllm.ai/en/latest/contributing/vulnerability_management.html).