|
| 1 | +# Node.js maintainers: Threat Model |
| 2 | + |
| 3 | +This document serves as a comprehensive overview of access levels for specific |
| 4 | +resources related to the Node.js project. The purpose is to provide clarity on |
| 5 | +who has access to each resource, the extent of that access, and any notable |
| 6 | +distinctions within groups or subgroups. By documenting these access controls, |
| 7 | +we aim to promote transparency, accountability, and better resource management. |
| 8 | + |
| 9 | +> [!NOTE] |
| 10 | +> This document is still under development. |
| 11 | +
|
| 12 | +## Access per Group |
| 13 | + |
| 14 | +The Access per Group table below outlines the permissions granted to different |
| 15 | +teams and individuals, categorized by resource and access level. The levels are |
| 16 | +inspired by standard UNIX permission notations, defined as follows: |
| 17 | + |
| 18 | +* `-`: No access |
| 19 | +* `r`: Read-only access |
| 20 | +* `w`: Write access |
| 21 | +* `a`: Admin/Owner access |
| 22 | + |
| 23 | +**Additional notes:** |
| 24 | +- While some teams can have access to a resource, like the `secrets`, they |
| 25 | +might have different access level internally based on sub-groups. |
| 26 | +- Some individuals and team have access such write in different GitHub |
| 27 | +repositories in the org, like Working groups or subteams. |
| 28 | + |
| 29 | +> [!NOTE] |
| 30 | +> ¹ - All repositories with code that get published or has some impact on nodejs/core |
| 31 | +> ² - Releasers has access to run CI during CI Embargo (Security Release) |
| 32 | +
|
| 33 | +| Resource | External people | Contributors - Core/Triagers/WG | Build - Test/Infra/Admin | Admin - TSC/Releasers/Moderation | Security Stewards/Triagers/External | GitHub - Actions/Plugins | |
| 34 | +|- |- |- |- |- |- |- | |
| 35 | +| **HackerOne** | - | -\-\- | -\-\- | aw- | www | -\- | |
| 36 | +| **MITRE** | - | -\-\- | -\-\- | a-\- | w-\- | -\- | |
| 37 | +| **private/node-private** | - | -\-\- | www | aw- | w-w | -\- | |
| 38 | +| **private/security-release** | - | -\-\- | -\-\- | a-\- | ww- | -\- | |
| 39 | +| **private/secrets** | - | -\-\- | www | a-\- | -\-\- | -\- | |
| 40 | +| **nodejs/node** | r | wrr | rrw | awa | rrr | wr | |
| 41 | +| **nodejs/deps¹** | r | rrr | rrw | arr | rrr | wr | |
| 42 | +| **nodejs/build** (GH) | r | rrr | rrw | awa | rrr | wr | |
| 43 | +| **nodejs/node-core-utils** | r | rrr | rrw | awa | rrr | wr | |
| 44 | +| **npm account** | - | - | -a- | a-\- | -\-\- | -\- | |
| 45 | +| **Jenkins CI - test** | r | ww- | wwa | -w²- | -\-\- | ww | |
| 46 | +| **Jenkins CI - release** | - | -\-\- | -ww | -w- | -\-\- | -\- | |
| 47 | +| **Infra - test** | - | w-\- | aaa | ww- | -w- | ww | |
| 48 | +| **Infra - release** | - | -\-\- | -ww | -w- | -\-\- | -\- | |
| 49 | +| **Build infra** | - | -\-\- | -a- | -\-\-| -\-\- | -\- | |
| 50 | +| **Website Infra** | - | -\-\- | -a- | a-\- | -\-\- | -\- | |
| 51 | +| **Youtube** | - | -\-w | -\-\- | a-\- | -\-\- | -\- | |
| 52 | +| **Zoom** | r | rrw | -\-\- | a-\- | -\-\- | -\- | |
| 53 | +| **1Password** | - | -\-r | -\-\- | a-\- | -\-\- | -\- | |
| 54 | +| **Social media accounts** | - | -\-\- | -\-\- | -\-\-| -\-\- | -\- | |
| 55 | +| **Email** (nodejs-sec) | r | rrr | rrr | awr | wrr | rr | |
| 56 | +| **Email** (io.js aliases) | r | -\-\- | -a- | w-\- | -\-\- | -\- | |
| 57 | + |
| 58 | +Repos under nodejs which do not include code, are not covered as they cannot lead to the threats listed. |
| 59 | +pkgjs.org is excluded as it does not include code/repos that make it into Node.js binaries |
| 60 | + |
| 61 | +## Threats |
| 62 | + |
| 63 | +### Malicious code in Node.js codebase |
| 64 | + |
| 65 | +In this scenario we asume that a malicios actor will include a malicious code |
| 66 | +(malware, malicious dependencies, polluted binaries...) in the codebase (GitHub repository) |
| 67 | + |
| 68 | +**Vectors:** |
| 69 | +* Use priviledge access to GitHub in order to add/modify/pollute the Git History |
| 70 | +* Pollute a dependency that is used by the project directly (v8, livub, openSSL, undici...) |
| 71 | +or inderictly (builds process/testing) |
| 72 | + |
| 73 | +**Related CWEs:** |
| 74 | +* [CWE-94: Improper Control of Generation of Code ('Code Injection')](https://cwe.mitre.org/data/definitions/94.html) |
| 75 | +* [CWE-1395: Dependency on Vulnerable Third-Party Component](https://cwe.mitre.org/data/definitions/1395.html) |
| 76 | +* [CWE-506: Embedded Malicious Code](https://cwe.mitre.org/data/definitions/506.html) |
| 77 | + |
| 78 | +| Resource | Minimum Access | Description | |
| 79 | +|-|-|-| |
| 80 | +| **HackerOne** | - | N\A | |
| 81 | +| **MITRE** | - | N\A | |
| 82 | +| **private/node-private** | Write | - | |
| 83 | +| **private/security-release** | - | N\A | |
| 84 | +| **private/secrets** | Read | You must have a GPG key to decrypt the keys | |
| 85 | +| **nodejs/node** | Write | - | |
| 86 | +| **nodejs/deps¹** | Write | If you have write access to Node.js dependencies you can hide malicious code and publish a new version, eventually the automation will create a PR to sync to nodejs/core and this code might pass without supervision | |
| 87 | +| **nodejs/build** (GH) | - | N\A | |
| 88 | +| **nodejs/node-core-utils** | Write | User must have _Write_ access to nodejs/node to open a attack vector| |
| 89 | +| **npm account** | Write | Because you can change the node-core-utils/branch-diff code to inject malicious code | |
| 90 | +| **Jenkins CI - test** | - | N\A | |
| 91 | +| **Jenkins CI - release** | - | N\A | |
| 92 | +| **Infra - test** | ? | Check if the CI runs with push permissions to Node.js | |
| 93 | +| **Infra - release** | - | N\A | |
| 94 | +| **Build infra** | - | N\A | |
| 95 | +| ~~Website Infra~~ | - | N\A | |
| 96 | +| **Youtube** | - | N\A | |
| 97 | +| **Zoom** | - | N\A | |
| 98 | +| **1Password** | - | N\A | |
| 99 | +| **Social media accounts** | - | N\A | |
| 100 | +| **Email** (nodejs-sec) | - | N\A | |
| 101 | +| **Email** (io.js aliases) | - | N\A | |
0 commit comments