Define more clearly SRC bug bounty scope

[aojea]

The SRC bug bounty scope is unclear for most of the kubernetes community members.

It was announced in 2020 claiming to be targeting the core projects https://kubernetes.io/blog/2020/01/14/kubernetes-bug-bounty-announcement/#what-s-in-scope

The bug bounty scope covers code from the main Kubernetes organizations on GitHub, as well as continuous integration, release, and documentation artifacts. Basically, most content you’d think of as ‘core’ Kubernetes, included at https://github.com/kubernetes, is in scope

However, the definition in the hackerone page is larger than that and with a wider scope https://hackerone.com/kubernetes?type=team

It does not feel right that a Kubernetes project program so important , that impacts its subprojects and SIG is not documented within the community, or at least I could not find it in:

• https://github.com/kubernetes/community/tree/master/committee-security-response
• https://github.com/kubernetes/committee-security-response/

Let's try to discuss how to better document this and how to make this decisions more open so the rest of the community or at least steering has visibility on such important decisions.

[pohly]

See also the proposal to maintain the NVIDIA DRA driver as a SIG Node subproject. @enj pointed out that it then will fall under the bug bounty program (https://groups.google.com/a/kubernetes.io/g/sig-node/c/vy-zhDXIsCc/m/GimmiuU5CQAJ).

[aojea]

Indeed that comment is the trigger of the discussion.

The kubernetes-sigs does not show up as eligible for the bounty program, am I looking at the wrong place?

IMHO that is a change on the existing policies that are not documented on the project donation rules https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md#rules-for-donated-repositories , so if we want to put that criteria we need to update our community process first.

I do not feel personally that a security audit per kuberneetes-sigs project will scale, we already have 201 repositories there https://github.com/kubernetes-sigs . Also, SRC was trying to go in the other direction, and remove scope per proposal from last yaer to steering , https://docs.google.com/document/d/1LJ8lDLGyvSfbdn3kkM4L1O65WS9hALWIYChpzBodAMo/edit?usp=sharing and be opt-in for projects.

[ritazh]

To clarify, not eligible for bounty does not mean we do not still review it for CVEs. SRC currently handles CVE reports and patches for many subprojects under k-sigs.

That blog is old, not the source of truth for what is in scope.

The latest documented scope is here as reporters look there for guidance:
https://hackerone.com/kubernetes?type=team

Snippets relating to k-sigs:

Supply Chain: (excluding social engineering attacks against maintainers)Unauthorized code commit to any Kubernetes org repositoryIncluding: github.com/kubernetes{,-client,-csi,-incubator,-retired,-security,-sigs}/*…

Tier 2 includes:GA & Beta features of non-core GA components (e.g. CSI drivers, k8s.io/dashboard, kube-adm)..

[aojea]

The latest documented scope is here as reporters look there for guidance:
https://hackerone.com/kubernetes?type=team

I think we should have the source of truth within the project and not in an external page ... and also have a voting process like we have in steering that makes this process of defining the scope more transparent to the community https://github.com/kubernetes/steering/blob/main/charter.md#voting

[aojea]

I don't think we need to make big changes here. I think that having the source of truth just inside the committee's repository will immediately offer all the benefits of GitHub for traceability, visibility, and open discussion.

It also allows projects to send a PR to opt out (like Windows, etcd, and CoreDNS do today, for example). This offloads work for the SRC, allowing the committee to move to a more reactive mode instead of proactively having to chase down subprojects.

To implement this, we could simply:

• Take the currently documented scope from HackerOne and commit it as bug-bounty-scope.md in the kubernetes/committee-security-response repo.

• Let the SRC define standard GitHub approval rules for future changes (e.g., requiring 2 approvers and lazy consensus).

This way, the changes are open and auditable, and we no longer have to rely on a third-party private platform for our own policy governance.

Sent kubernetes/committee-security-response#221 as POC