Security: Comprehensive security assessment and documentation

SECURITY.md

@@ -0,0 +1,137 @@
+# Security
+
+## Reporting a security bug in Node.js Release Cloudflare Worker
+
+Report security bugs in the Node.js Release Cloudflare Worker via [HackerOne](https://hackerone.com/nodejs) or by contacting the [Node.js Security Working Group](mailto:security@nodejs.org).
+
+Normally, your report will be acknowledged within 5 days, and you'll receive
+a more detailed response to your report within 10 days indicating the
+next steps in handling your submission. These timelines may extend when
+our triage volunteers are away on holiday, particularly at the end of the
+year.
+
+After the initial reply to your report, the security team will endeavor to keep
+you informed of the progress being made towards a fix and full announcement,
+and may ask for additional information or guidance surrounding the reported
+issue.
+
+## Node.js bug bounty program
+
+The Node.js project engages in an official bug bounty program for security
+researchers and responsible public disclosures. The program is managed through
+the HackerOne platform and covers this repository. See <https://hackerone.com/nodejs> for further details.
+
+## Disclosure policy
+
+This repository follows the Node.js security disclosure policy:
+
+* The security report is received and is assigned a primary handler. This
+  person will coordinate the fix and release process. The problem is validated
+  and confirmed. Code is audited to find any potential similar problems. 
+  Fixes are prepared for the affected worker deployment. These fixes are not 
+  committed to the public repository but rather held locally pending the announcement.
+
+* A suggested embargo date for this vulnerability is chosen and a CVE (Common
+  Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.
+
+* On the embargo date, a copy of the announcement is sent to the Node.js
+  security mailing list. The changes are pushed to the public repository and the
+  worker is deployed with the security fix. Within 6 hours of the mailing list being
+  notified, a copy of the advisory will be published on the Node.js blog.
+
+* Typically, the embargo date will be set 72 hours from the time the CVE is
+  issued. However, this may vary depending on the severity of the bug or
+  difficulty in applying a fix.
+
+## Code of Conduct and Vulnerability Reporting Guidelines
+
+When reporting security vulnerabilities, reporters must adhere to the following guidelines:
+
+1. **Code of Conduct Compliance**: All security reports must comply with the
+   [Node.js Code of Conduct](https://github.com/nodejs/node/blob/main/CODE_OF_CONDUCT.md). 
+   Reports that violate the code of conduct will not be considered and may result 
+   in being banned from future participation.
+
+2. **No Harmful Actions**: Security research and vulnerability reporting must not:
+   * Cause damage to the dist.nodejs.org infrastructure or production environments.
+   * Disrupt Node.js distribution services or affect end users.
+   * Attempt to access or modify Node.js release binaries or distribution files.
+   * Include actual exploits that could harm the Node.js ecosystem.
+   * Involve social engineering or phishing attempts against maintainers.
+
+3. **Responsible Testing**: When testing potential vulnerabilities:
+   * Use controlled, isolated test environments when possible.
+   * Do not test against the production dist.nodejs.org infrastructure without prior authorization.
+   * Do not attempt to access internal Cloudflare Worker logs or configuration.
+   * Immediately stop testing if unauthorized access is gained accidentally.
+
+4. **Report Quality**
+   * Provide clear, detailed steps to reproduce the vulnerability.
+   * Include only the minimum proof of concept required to demonstrate the issue.
+   * Remove any malicious payloads or components that could cause harm.
+
+## The Node.js Release Worker Threat Model
+
+The Node.js Release Cloudflare Worker serves all Node.js binaries, documentation, 
+and release assets via https://dist.nodejs.org. This critical infrastructure component
+is trusted by the entire Node.js ecosystem.
+
+### In Scope
+
+Vulnerabilities that could lead to:
+
+* **Supply Chain Attacks**: Serving modified or malicious Node.js binaries or release assets
+* **Data Integrity Issues**: Corruption or manipulation of served files
+* **Service Availability**: Denial of service attacks against the distribution infrastructure
+* **Information Disclosure**: Exposure of internal infrastructure details or sensitive configuration
+* **Cache Poisoning**: Manipulation of cached responses to serve incorrect content
+* **Path Traversal**: Unauthorized access to files outside intended directory structure
+
+### Trusted Elements
+
+The worker trusts:
+
+* The underlying Cloudflare Workers platform and infrastructure
+* The R2 bucket storage containing official Node.js releases
+* The origin server (origin.nodejs.org) used as a fallback
+* The CI/CD pipeline and deployment process
+* Collaborators with appropriate repository access
+
+### Examples of Vulnerabilities
+
+#### Supply Chain Manipulation (Critical)
+* Serving modified Node.js binaries through cache poisoning or path manipulation
+* Bypassing integrity checks to serve unauthorized content
+
+#### Service Disruption (High)
+* Resource exhaustion attacks causing worker failures
+* Cache manipulation leading to widespread service degradation
+
+#### Information Disclosure (Medium-High)
+* Exposure of internal worker configuration or error details
+* Leaking information about infrastructure or storage backend
+
+### Examples of Non-Vulnerabilities
+
+#### Expected Behavior
+* Serving publicly available Node.js releases and documentation
+* Directory listings for public release directories
+* Standard HTTP cache headers and responses
+
+#### Out of Scope
+* Issues requiring compromise of trusted infrastructure (Cloudflare, GitHub Actions)
+* Vulnerabilities in Node.js itself (report to main Node.js repository)
+* General availability issues not caused by security vulnerabilities
+
+## Incident Response
+
+In the event of a security incident, please refer to the 
+[Node.js Security Incident Response Plan](https://github.com/nodejs/security-wg/blob/main/INCIDENT_RESPONSE_PLAN.md).
+
+For immediate security incidents affecting dist.nodejs.org availability or integrity,
+also contact the [@nodejs/web-infra](https://github.com/orgs/nodejs/teams/web-infra) team.
+
+## Comments on this policy
+
+If you have suggestions on how this process could be improved, please visit
+the [nodejs/security-wg](https://github.com/nodejs/security-wg) repository.