Bug Bounty program

Bug Bounty program

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 2441 bytes --]

Recently we (the Xen security team) have been invited by HackerOne
to join the Internet Bug Bounty https://hackerone.com/ibb (citing the
original mail):

 > The Internet Bug Bounty <https://hackerone.com/ibb> was created with
 > the goal of helping to secure critical open source infrastructure.
 > After almost $1M paid out for vulnerabilities in open source, we are
 > expanding the program's scope with more OSS Projects, and I’m reaching
 > out to you today because Xen Hypervisor was specifically requested by
 > multiple partners.
 >
 > - Partners contribute funds to a shared pool, and nominate projects
 >   for inclusion
 > - Projects opt-in for inclusion in the program
 > - Vulnerabilities are reported directly to project maintainers by your
 >   preferred process
 > - After a public advisory is released, the Finder submits a bounty
 >   claim to the IBB
 > - Bounty is split 80% for finder and 20% to the project

This is something we as the security team don't want to decide without
discussing it in the open. We've brought that topic up in today's (Nov
2nd) community call. As maybe not everyone wanting to bring something
up was in that call, I volunteered to write this mail to xen-devel.

There are a few things we already discussed:

- As a large quantity of security bugs is actually detected by the
   security team while looking at other security bugs, we feel that the
   members of the security team should not be claiming bug bounties for
   issues they find in the code.

- We are aware of the possibility that someone (being a contributor or
   a maintainer) might try to sneak in a patch introducing a security
   bug, in order to claim a bounty for it later. OTOH setting up rules
   for a (hopefully) never occurring case feels like overkill, and we
   don't want to drive away potential new contributors or maintainers by
   excluding them at least partially from the bounty program. So right
   now we are inclined to not setup further exclusion rules for claiming
   any bounties.

- General consensus seems to be to let the bug bounty program only cover
   our coding. Any vulnerabilities reported against the Xen project's
   infrastructure (web sites, ...) should not qualify for claiming a bug
   bounty.

Are there any further topics we need to discuss, or is there any concern
with above statements?


Juergen, on behalf of the Xen security team

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 491 bytes --]

Re: Bug Bounty program

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 3341 bytes --]

On 02.11.21 17:10, Juergen Gross wrote:
> Recently we (the Xen security team) have been invited by HackerOne
> to join the Internet Bug Bounty https://hackerone.com/ibb (citing the
> original mail):
> 
>  > The Internet Bug Bounty <https://hackerone.com/ibb> was created with
>  > the goal of helping to secure critical open source infrastructure.
>  > After almost $1M paid out for vulnerabilities in open source, we are
>  > expanding the program's scope with more OSS Projects, and I’m reaching
>  > out to you today because Xen Hypervisor was specifically requested by
>  > multiple partners.
>  >
>  > - Partners contribute funds to a shared pool, and nominate projects
>  >   for inclusion
>  > - Projects opt-in for inclusion in the program
>  > - Vulnerabilities are reported directly to project maintainers by your
>  >   preferred process
>  > - After a public advisory is released, the Finder submits a bounty
>  >   claim to the IBB
>  > - Bounty is split 80% for finder and 20% to the project
> 
> This is something we as the security team don't want to decide without
> discussing it in the open. We've brought that topic up in today's (Nov
> 2nd) community call. As maybe not everyone wanting to bring something
> up was in that call, I volunteered to write this mail to xen-devel.
> 
> There are a few things we already discussed:
> 
> - As a large quantity of security bugs is actually detected by the
>    security team while looking at other security bugs, we feel that the
>    members of the security team should not be claiming bug bounties for
>    issues they find in the code.
> 
> - We are aware of the possibility that someone (being a contributor or
>    a maintainer) might try to sneak in a patch introducing a security
>    bug, in order to claim a bounty for it later. OTOH setting up rules
>    for a (hopefully) never occurring case feels like overkill, and we
>    don't want to drive away potential new contributors or maintainers by
>    excluding them at least partially from the bounty program. So right
>    now we are inclined to not setup further exclusion rules for claiming
>    any bounties.
> 
> - General consensus seems to be to let the bug bounty program only cover
>    our coding. Any vulnerabilities reported against the Xen project's
>    infrastructure (web sites, ...) should not qualify for claiming a bug
>    bounty.
> 
> Are there any further topics we need to discuss, or is there any concern
> with above statements?

Seems as if there is no specific need for further discussion, given that
2 weeks have passed without any response to this mail.

As the advisory board is fine with us joining the Internet Bug Bounty,
we'll do that.

The following restrictions apply:

- Members of the security team can't claim bounties.

- Nobody should claim a bounty for a vulnerability introduced by a
   patch for which he/she has given any of a "Signed-off-by:",
   "Acked-by:" or "Reviewed-by:" tag. In case someone thinks that
   a special case needs an exception from that rule, it is always
   possible to request that from the community manager or the security
   team (before claiming the bounty).

- Only security issues in our code base are covered by the Bug Bounty
   program.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]