Establish processes for security issue reporting, evaluation, fix release

[guydc]

Description:
Projects like Envoy proxy have a robust processe for vulnerability management, outlined here. OSS control planes like Istio have similar processes in place.

Envoy Gateway should establish similar processes, communication channels, responsibilities, SLOs, etc.

More concretely, the following should be done:

• Create a public vulnerability reporting and disclosure process:
  • Create an email for Envoy Gateway vulnerability reporting
  • Establish a security team responsible for monitoring vulnerability reports and determine criteria for membership
• Define a security assessment and fix process:
  • Determine how a security team member(s) is appointed to determine the severity of a reported issue and/or develop s fix (e.g. release manager for upstream envoy patches, security team member on duty for EG-specific issues, code owner, ad-hoc decision by the security team... )
  • Where is the fix developed (private GH repo?)
  • What are the SLAs for the fix the be available (time to determine severity since disclosure, time to fix from severity determination based on severity level)
• Create process for early disclosure
  • Establish criteria for membership in early disclosure group
  • Determine when a vulnerability is disclosed with the early disclosure group
  • Create an early disclosure reporting email for Envoy Gateway
  • Define an embargo policy
• Create a public vulnerability disclosure process for Envoy Gateway:
  • Decide on a medium for vulnerability disclosure (EG Site, Slack Announcement)
  • Define how fixes relate to the release process in terms of release responsibility, announcement, etc.

Additionally, Envoy Gateway security representatives should strive to join the Envoy Proxy private distributor list, to ensure early disclosure of vulnerabilities and proper preparation for fix releases.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.