Transitioning Security Team Members on Project Deprecation
| HIP | Title | Author(s) | Created | Type | Status |
|---|---|---|---|---|---|
| 9 | Transitioning Security Team Members on Project Deprecation | Matt Butcher matt.butcher@microsoft.com | 2020-09-24 | process | draft |
Abstract
Helm maintains a security team composed of interested maintainers from Helm projects. This proposal clarifies that to be a member of the security team, one must be a maintainer of an active (non-deprecated) project.
Motivation
The existing security team documentation does not cover cases where a Helm project is marked deprecated. However, because the security team discusses sensitive and potentially damaging issues, the Helm project requires clarity on this point.
Rationale
This HIP suggests that security team members must be maintainers on active Helm projects.
Specification
According to the current documentation in SECURITY.md, the only requirements for security team members are as follows:
- Members MUST be active project maintainers as defined in the governance
- Members SHOULD engage in each reported vulnerability, at a minimum to make sure it is being handled
- Members MUST keep the vulnerability details private and only share on a need to know basis
This proposal suggests that the first requirement be amended to read:
Members MUST be active project maintainers for an active project as defined in [the governance]
Further, the SECURITY.md document should be updated to indicate that a security team member will be automatically removed if they are no longer affiliated with any active (non-deprecated) projects.
Backwards compatibility
N/A
Security implications
The primary reason for this change is that we view it as a compromise of our security posture to have vulnerability disclosures sent to non-maintainers. Making this change improves our security posture.
How to teach this
The change will be documented in SECURITY.md
Reference implementation
The change will be made in SECURITY.md
Rejected ideas
One might claim that security team members should be entitled to stay because of their past experience. While we do not want to downplay the role of experience, we do want to point out that it is unwise to allow unaffiliated individuals to have access to vulnerability disclosures.
Open issues
None currently.