Establish audit process for information access
tallclair opened this issue · comments
We now have a lot of different places that include sensitive vulnerability information, including:
- Email lists: security@kubernetes.io, security-discuss-private@kubernetes.io, distributors-announce@kubernetes.io, release-managers-private@kubernetes.io
- HackerOne
- github.com/kubernetes-security repos
- (maybe) private slack channel
- Private docs (CNA, others?)
We should:
- Record everywhere that includes sensitive information (a more permanent version of the above list). We may want to keep this list private (maybe in https://github.com/kubernetes-security/security-disclosures)
- Establish a process for periodically reviewing the access to all these resources.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
.
Mark the issue as fresh with /remove-lifecycle rotten
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen
.
Mark the issue as fresh with/remove-lifecycle rotten
.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.