cluster-api
cluster-api copied to clipboard
kubernetes-sigs
Security Self Assessment: [DEV-2] Verify vulnerability reporting process
Detailed Description
As part of the security self-assessment, (#4446) am reviewing our software development practices.
We have a SECURITY_CONTACTS and we have vulnerability reporting (via an org template?) that can be invoked hitting New Issue.
Do we know if this process is valid for subprojects? In addition, the SECURITY_CONTACTS file is outdated, and needs updating.
(I would also like to volunteer to be on that list)
/kind feature /area security
@randomvariable: The label(s) area/security cannot be applied, because the repository doesn't have them.
In response to this:
Detailed Description
As part of the security self-assessment, am reviewing our software development practices.
We have a SECURITY_CONTACTS and we have vulnerability reporting (via an org template?) that can be invoked hitting New Issue.
Do we know if this process is valid for subprojects? In addition, the SECURITY_CONTACTS file is outdated, and needs updating.
(I would also like to volunteer to be on that list)
/kind feature /area security
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.
The process of batch removing these files went stale. But they are pretty much pending deletion in all repos...I'd probably delete the file and keep email / contacts in the main readme.
Girhub handles are useless as there are no github dms?
Github handles are useless as there are no github dms?
Yes, I don't think we can use them really for private disclosure.
/milestone Next
To discuss at SIG level as well + documentation changes and potential issue template
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/retitle Security Self Assessment: [DEV-2] Verify vulnerability reporting process /sig security /area security
(This topic is being discussed in the community right now across SIG Security, Contribex and SRC. Cluster API sub-project may end up benefitting from the structural changes that this discussion creates)
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/lifecycle frozen This has been discussed at KubeCon Detroit during a postmortem of the security assessment.
TL;DR; The CAPI subproject doesn't have the critical mass to own its own vulnerability reporting process; in the issue templates, under "Report a security vulnerability" we are referring to the Kubernetes process described in https://github.com/kubernetes-sigs/cluster-api/security/policy, but the Kubernetes security response team should be staffed/define its own processes about how to engage sub-projects. cc @PushkarJ @ aladewberry
This issue has not been updated in over 1 year, and should be re-triaged.
You can:
- Confirm that this issue is still relevant with
/triage accepted(org members only) - Close this issue with
/close
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/
/remove-triage accepted
The Cluster API project currently lacks enough contributors to adequately respond to all issues and PRs.
As discussed with SIG security folks back in detroit when we did a retrospective on this security assessment (@aladewberry), given different staffing/size of projects, the only viable way for subprojects to handle vulnerability reporting process is to rely on the K8s process
@fabriziopandini: Closing this issue.
In response to this:
/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.