mirror of
https://github.com/moparisthebest/curl
synced 2024-11-17 06:55:02 -05:00
db1338474c
Retract the previous approach as the sponsors will be the ones to set the final amounts. Closes #3152 [ci skip]
77 lines
3.0 KiB
Markdown
77 lines
3.0 KiB
Markdown
# The curl bug bounty
|
|
|
|
The curl project runs a bug bounty program in association with
|
|
bountygraph.com.
|
|
|
|
After you have reported a security issue to the curl project, it has been
|
|
deemed credible and a patch and advisory has been made public you can be
|
|
eligible for a bounty from this program.
|
|
|
|
See all details at https://bountygraph.com/programs/curl
|
|
|
|
This bounty is relying on funds from sponsors. If you use curl professionally,
|
|
consider help funding this!
|
|
|
|
## How much money is the bounty at
|
|
|
|
The curl projects offer monetary compensation for reported and published
|
|
security vulnerabilities. The amount of money that is rewarded depends on how
|
|
serious the flaw is determined to be.
|
|
|
|
We offer reward money *up to* the total amount of the fund. The curl security
|
|
team determines the severity of each reported flaw on a case by case basis
|
|
and the exact amount rewarded to the reporter is then decided by the sponsor.
|
|
|
|
## Who's eligible for a reward
|
|
|
|
Everyone and anyone who reports a security problem in a released curl version
|
|
that hasn't already been reported can ask for a bounty.
|
|
|
|
The vulnerability has to be fixed and publicly announced (by the curl
|
|
project) before a bug bounty will be considered.
|
|
|
|
Bounties need to be requested within twelve months from the publication of
|
|
the vulnerability.
|
|
|
|
The vulnerabilities must not have been made public before August 1st, 2018.
|
|
We do not retroactively pay for old, already known and published security
|
|
problems.
|
|
|
|
## Product vulnerabilities only
|
|
|
|
The bug bounty only concerns the curl and libcurl products and thus their
|
|
respective source codes - when running on existing hardware. It does not
|
|
include documentation, web sites or other infrastructure.
|
|
|
|
The curl security team will be the sole arbiter if a reported flaw can be
|
|
subject to a bounty or not.
|
|
|
|
## How are vulnerabilities graded
|
|
|
|
The grading of each reported vulnerability that makes a reward claim will be
|
|
performed by the curl security team. The grading will be based on the CVSS
|
|
(Common Vulnerability Scoring System) 3.0.
|
|
|
|
## How are reward amounts determined
|
|
|
|
The curl security team first gives the vulnerability a score, as mentioned
|
|
above, and based on that level the sponsor sets the bounty amount depending
|
|
on the specifics of the individual case.
|
|
|
|
The bounty fund sponsor is the arbiter of the bounty amount.
|
|
|
|
## What happens if the bounty fund is drained
|
|
|
|
The bounty fund depends on sponsors. If we pay out more bounties than we add,
|
|
the fund will eventually drain. If that end up happening, we will simply not
|
|
be able to pay out as high bounties as we would like and hope that we can
|
|
convince new sponsors to help us top up the fund again.
|
|
|
|
## Regarding taxes etc on the bounties
|
|
|
|
In the event that the individual receiving a curl bug bounty needs to pay
|
|
taxes on the reward money, that's something for the receiver (and
|
|
bountygraph.com?) to work out and handle. The curl project or its security
|
|
team never actually receive any of this money, hold the money or pay out the
|
|
money.
|