doc: add binary generation threat

Author: RafaelGSS

MAINTAINERS_THREAT_MODEL.md

@@ -99,3 +99,59 @@ or inderictly (builds process/testing)
 | **Social media accounts**    | -     | N\A |
 | **Email** (nodejs-sec)       | -     | N\A |
 | **Email** (io.js aliases)    | -     | N\A |
+
+### Malicious release binary generation in Node.js release/build processes
+
+In this scenario we asume that a malicious actor will include a malicios code
+(malware, malicious dependencies, polluted binaries...) in the release binaries
+available through the Nodejs.org downloads.
+
+**Vectors:**
+
+* Use priviledge access to GitHub in order to add/modify/pollute the Git History
+for the tooling/build repositories (like ansible scripts, etc..)
+* Pollute directly machines that are part of the CI/release inventory used by
+Jenkins/GH Actions
+* Manipulate the CI/release pipelines in Jenkins or GH Actions (add/modify custom
+scripts, pollute plugins, overwrite configuration...)  
+* Swaping out release binaries where they are hosted on nodejs.org web server
+* Modifying the cloudflare configuration to change were binaries are served from
+* Modifying the vercel website configation
+
+**Related CWEs:**
+
+* [CWE-94: Improper Control of Generation of Code ('Code Injection')](https://cwe.mitre.org/data/definitions/94.html)
+* [CWE-73: External Control of File Name or Path](https://cwe.mitre.org/data/definitions/73.html)
+* [CWE-829: Inclusion of Functionality from Untrusted Control Sphere](https://cwe.mitre.org/data/definitions/829.html)
+* [CWE-353: Missing Support for Integrity Check](https://cwe.mitre.org/data/definitions/353.html)
+* [CWE-506: Embedded Malicious Code](https://cwe.mitre.org/data/definitions/506.html)
+
+| Resource | Minimum Access    | Description |
+|-         |-                  |-            |
+| **HackerOne**                | - | N\A |
+| **MITRE**                    | - | N\A |
+| **private/node-private**     | - | N\A |
+| **private/security-release** | - | N\A |
+| **private/secrets**          | r | read access to secrets grants access to key resources |
+| **nodejs/node**              | - | N\A |
+| **nodejs/deps¹**             | - | N\A |
+| **nodejs/build** (GH)        | w | write access would allow key scripts, infra to be modified |
+| **nodejs/docker-node**       | - | - |
+| **nodejs/node-core-utils**   | - | N\A |
+| **npm account**              | - | N\A |
+| **Jenkins CI - test**        | - | N\A |
+| **Jenkins CI - release**     | w | access to jenkins used for build would allow swapping published binaries |
+| **Infra - test**             | - | N/A |
+| **Infra - release**          | w | access to machines used for build would allow swapping published binaries |
+| **Build infra**              | w | access to machines used for build would allow swapping published binaries |
+| **Website Infra**            | w | access to machines used for build would allow swapping published binaries |
+| **Youtube**                  | - | N\A |
+| **Zoom**                     | - | N\A |
+| **1Password**                | r | read access to secrets grants access to key resources |
+| **Social media accounts**    | - | N\A |
+| **Email** (nodejs-sec)       | - | N\A |
+| **Email** (io.js aliases)    | - | N\A |
+
+Notes:
+
+* Orka infra is shared, so any orka admin can modify test/relese machines