SECURITY-PROCESS: extended

Also clarify BUG-BOUNTY.md with IBB details.

Closes #8754

docs/BUG-BOUNTY.md

@@ -11,14 +11,8 @@ HackerOne program](https://hackerone.com/curl).
 
 After you have reported a security issue, it has been deemed credible, and a
 patch and advisory has been made public, you may be eligible for a bounty from
-this program.
+this program. See the [SECURITY-PROCESS](SECURITY-PROCESS.md) document for how
-
+we work with security issues.
-See all details at [https://hackerone.com/curl](https://hackerone.com/curl)
-
-This bounty is relying on funds from sponsors. If you use curl professionally,
-consider helping fund this! See
-[https://opencollective.com/curl](https://opencollective.com/curl) for
-details.
 
 # What are the reward amounts?
 
@@ -26,11 +20,10 @@ The curl project offers 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* a certain amount per severity. The curl security
+Since 2021, the Bug Bounty is managed in association with the Internet Bug
-team determines the severity of each reported flaw on a case by case basis and
+Bounty and they will set the reward amounts. If it would turn out that they
-the exact amount rewarded to the reporter is then decided.
+set amounts that are way lower than we can accept, the curl project intends to
-
+"top up" rewards.
-Check out the current award amounts at [https://hackerone.com/curl](https://hackerone.com/curl)
 
 # Who is eligible for a reward?
 
@@ -43,6 +36,9 @@ experimental are not eligible for a reward.
 The vulnerability has to be fixed and publicly announced (by the curl project)
 before a bug bounty will be considered.
 
+Once the vulnerability has been published by curl, the researcher can request
+their bounty from the [Internet Bug Bounty](https://hackerone.com/ibb).
+
 Bounties need to be requested within twelve months from the publication of the
 vulnerability.
 
@@ -50,7 +46,8 @@ vulnerability.
 
 This 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, websites, or other infrastructure.
+include curl documentation, curl websites, or other curl related
+infrastructure.
 
 The curl security team is the sole arbiter if a reported flaw is subject to a
 bounty or not.
@@ -68,16 +65,9 @@ above, and based on that level we set an amount depending on the specifics of
 the individual case. Other sponsors of the program might also get involved and
 can raise the amounts depending on the particular issue.
 
-# 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 ends 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
+In the event that the individual receiving a bug bounty needs to pay taxes on
-taxes on the reward money, the responsibility lies with the receiver. The
+the reward money, the responsibility lies with the receiver. The curl project
-curl project or its security team never actually receive any of this money,
+or its security team never actually receive any of this money, hold the money,
-hold the money, or pay out the money.
+or pay out the money.

docs/SECURITY-PROCESS.md

@@ -1,11 +1,9 @@
-curl security process
+# curl security process
-=====================
 
 This document describes how security vulnerabilities should be handled in the
 curl project.
 
-Publishing Information
+## Publishing Information
-----------------------
 
 All known and public curl or libcurl related vulnerabilities are listed on
 [the curl website security page](https://curl.se/docs/security.html).
@@ -13,8 +11,7 @@ All known and public curl or libcurl related vulnerabilities are listed on
 Security vulnerabilities **should not** be entered in the project's public bug
 tracker.
 
-Vulnerability Handling
+## Vulnerability Handling
-----------------------
 
 The typical process for handling a new security vulnerability is as follows.
 
@@ -38,7 +35,8 @@ announcement.
   that a human has seen the report.
 
 - The security team investigates the report and either rejects it or accepts
-  it.
+  it. See below for examples of problems that are not considered
+  vulnerabilities.
 
 - If the report is rejected, the team writes to the reporter to explain why.
 
@@ -92,8 +90,7 @@ announcement.
 - The security web page on the website should get the new vulnerability
   mentioned.
 
-security (at curl dot se)
+## security (at curl dot se)
-------------------------------
 
 This is a private mailing list for discussions on and about curl security
 issues.
@@ -108,8 +105,7 @@ have no plans of vanishing in the near future.
 We do not make the list of participants public mostly because it tends to vary
 somewhat over time and a list somewhere will only risk getting outdated.
 
-Publishing Security Advisories
+## Publishing Security Advisories
-------------------------------
 
 1. Write up the security advisory, using markdown syntax. Use the same
    subtitles as last time to maintain consistency.
@@ -119,23 +115,76 @@ Publishing Security Advisories
 3. Add a line on the top of the array in `curl-www/docs/vuln.pm'.
 
 4. Put the new advisory markdown file in the curl-www/docs/ directory. Add it
-   to the git repo.
+   to the git repository.
 
 5. Run `make` in your local web checkout and verify that things look fine.
 
 6. On security advisory release day, push the changes on the curl-www
    repository's remote master branch.
 
-Hackerone
+## Hackerone
----------
 
 Request the issue to be disclosed. If there are sensitive details present in
 the report and discussion, those should be redacted from the disclosure. The
 default policy is to disclose as much as possible as soon as the vulnerability
 has been published.
 
-Bug Bounty
+## Bug Bounty
-----------
 
 See [BUG-BOUNTY](https://curl.se/docs/bugbounty.html) for details on the
 bug bounty program.
+
+# Not security issues
+
+This is an incomplete list of issues that are not considered vulnerabilities.
+
+## Small memory leaks
+
+We do not consider a small memory leak a security problem; even if the amount
+of allocated memory grows by a small amount every now and then. Long-living
+applications and services already need to have counter-measures and deal with
+growing memory usage, be it leaks or just increased use. A small memory or
+resource leak is then expected to *not* cause a security problem.
+
+Of course there can be a discussion if a leak is small or not. A large leak
+can be considered a security problem due to the DOS risk. If leaked memory
+contains sensitive data it might also qualify as a security problem.
+
+## Never-ending transfers
+
+We do not consider flaws that cause a transfer to never end to be a security
+problem. There are already several benign and likely reasons for transfers to
+stall and never end, so applications that cannot deal with never-ending
+transfers already need to have counter-measures established.
+
+If the problem avoids the regular counter-measures when it causes a never-
+ending transfer, it might very well be a security problem.
+
+## Not practically possible
+
+If the flaw or vulnerability cannot practically get executed on existing
+hardware it is not a security problem.
+
+## API misuse
+
+If a reported issue only triggers by an application using the API in a way
+that is not documented to work or even documented to not work, it is probably
+not going to be considered a security problem. We only guarantee secure and
+proper functionality when the APIs are used as expected and documented.
+
+There can be a discussion about what the documentation actually means and how
+to interpret the text, which might end up with us still agreeing that it is a
+security problem.
+
+## Local attackers already present
+
+When an issue can only be attacked or misused by an attacker present on the
+local system or network, the bar is raised. If a local user wrongfully has
+elevated rights on your system enough to attack curl, they can probably
+already do much worse harm and the problem is not really in curl.
+
+## Experiments
+
+Vulnerabilities in features which are off by default (in the build) and
+documented as experimental, are not eligible for a reward and we do not
+consider them security problems.