Closed randomvariable closed 4 months ago
@randomvariable: The label(s) area/security
cannot be applied, because the repository doesn't have them.
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
/milestone v1.2
/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)
/triage accepted
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
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
cc @aladewberry (looks like there is a space too much in your mention)
This issue has not been updated in over 1 year, and should be re-triaged.
You can:
/triage accepted
(org members only)/close
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/
/remove-triage accepted
/priority backlog
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
/close
@fabriziopandini: Closing this issue.
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