project/security.md: howe we combat backdoors

Closes #499

project/security.md

@@ -26,3 +26,49 @@ chart](https://curl.se/docs/vulnerabilities.html) showing how all
 vulnerabilities affect which curl versions and we have this complete list of
 all known security problems since the birth of this project.
 
+## Backdoors and supply chain risks
+
+With libcurl being installed and running in billions of installations all over
+the world and in countless different environments, we recognize that it is an
+ideal target for someone who wants a backdoor somewhere.
+
+A new or old maintainer might at any point propose a change that sounds
+innocent and well-meaning but has a disguised malicious intent.
+
+To mitigate such risks, we apply established procedures and techniques:
+
+- **2FA required**. We require all maintainers with push access to git to have
+ two-factor authentication enabled, to reduce the risk that attackers can
+ impersonate them and use their credentials to push source code changes.
+- **Reviews**. Every contribution that are proposed for inclusion in the
+ project is reviewed by a maintainer. It is also automatically checked,
+ tested and scanned by numerous tools.
+- **Readable code**. We believe in readable code that follows our code style.
+ Easy to read makes it easy to debug. If code is hard to read it should be
+ improved until it gets easy to read. With easy to read code, smuggling
+ malicious payloads or hiding nefarious functionality is excruciatingly hard.
+- **Tests**. We have a large test suite that is always growing and we do not
+ accept changes that break existing tests and new functionality need to bring
+ new tests for the new functionality. We run *several hundred thousands*
+ tests on each proposed changed to make sure existing functionality remains.
+ This includes fuzzers, static code analyzers, fault injectors and more.
+- **No binary blobs**. All files stored in version control, in the git
+ repository is readable or is otherwise small and documented. There is no
+ place anywhere for any hidden encrypted payload.
+- **Reproducible builds**. curl releases are shipped as tarballs that are
+ hosted on the curl website. We provide documentation, docker setups and
+ setups etc that allows anyone wanting to easily reproduce our release builds
+ to generate identical images - proving that what we ship is only contents
+ taken from the git repository plus other correct and properly generated
+ contents.
+- **Signed commits**. Some - not all - of the committers sign commits to help
+ prove provenance.
+- **Signed releases**. Every release, every uploaded tarball, is signed by
+ Daniel. This helps to prove that the files have not been tampered with since
+ they were produced.
+- **Fix all vulnerabilities quickly**. Whenever we receive a security
+ vulnerability report, we create and ship a fix in the next pending release.
+ Sometimes sooner than previously planned. With every fixed security
+ vulnerability we release a detailed description of the flaw including exact
+ commit that introduced the problem, recommendations for users and more.
+ Further, the security advisories get announced to the world.

wordlist.txt

@@ -23,6 +23,8 @@ autobuild
 autobuilds
 Autotools
 autotools
+Backdoor
+Backdoors
 backend
 backends
 backoff
@@ -169,6 +171,7 @@ FreeBSD
 Frexx
 fseek
 FTPing
+fuzzers
 fwrite
 gcc
 gdb
@@ -221,6 +224,7 @@ http
 HTTPAUTH
 httpget
 HttpGet
+HTTPHEADER
 HTTPS
 https
 Huawei
@@ -583,7 +587,6 @@ wolfSSL
 WS
 WSS
 www
-HTTPHEADER
 xdigit
 Xilinx
 XYZ