Security Self Assessment: [DEV-2] Verify vulnerability reporting process

[randomvariable]

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

[k8s-ci-robot]

@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.

[neolit123]

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?

[randomvariable]

Github handles are useless as there are no github dms?

Yes, I don't think we can use them really for private disclosure.

[vincepri]

/milestone Next

To discuss at SIG level as well + documentation changes and potential issue template

[k8s-triage-robot]

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/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was 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

[fabriziopandini]

/remove-lifecycle stale

[sbueringer]

/milestone v1.2

[PushkarJ]

/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)

[fabriziopandini]

/triage accepted

[k8s-triage-robot]

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/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was 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

[fabriziopandini]

/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

[sbueringer]

cc @aladewberry
(looks like there is a space too much in your mention)

[k8s-triage-robot]

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

[fabriziopandini]

/priority backlog

[fabriziopandini]

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]

/close

[k8s-ci-robot]

@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.