[nginx] Updated security policy to include disclosure details.

[noreply at nginx.com]

details:   https://github.com/nginx/nginx/commit/f45c2707ea1bf6fde3bd0c045cc4a63cdc4a966a
branches:  master
commit:    f45c2707ea1bf6fde3bd0c045cc4a63cdc4a966a
user:      jzebor-at-f5 <144731595+jzebor-at-f5 at users.noreply.github.com>
date:      Fri, 11 Oct 2024 09:48:53 -0700
description:
Updated security policy to include disclosure details.


---
 SECURITY.md | 94 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 89 insertions(+), 5 deletions(-)

diff --git a/SECURITY.md b/SECURITY.md
index 2b48e47e3..f5cfcd788 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -1,8 +1,8 @@
 # Security Policy
 
-## Latest Versions
-
-We advise users to run the most recent mainline or stable release of nginx.
+This document provides an overview of security concerns related to nginx
+deployments, focusing on confidentiality, integrity, availability, and the
+implications of configurations and misconfigurations.
 
 ## Reporting a Vulnerability
 
@@ -10,11 +10,95 @@ Please report any vulnerabilities via one of the following methods
 (in order of preference):
 
 1. [Report a vulnerability](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability)
-within this repository. We are using the Github workflow that allows us to
-manage vulnerabilities in a private manner and to interact with reporters
+within this repository. We are using the GitHub workflow that allows us to
+manage vulnerabilities in a private manner and interact with reporters
 securely.
 
 2. [Report directly to F5](https://www.f5.com/services/support/report-a-vulnerability).
 
 3. Report via email to security-alert at nginx.org.
 This method will be deprecated in the future.
+
+### Vulnerability Disclosure and Fix Process
+
+The nginx team expects that all suspected vulnerabilities be reported
+privately via the
+[Reporting a Vulnerability](SECURITY.md#reporting-a-vulnerability) guidelines.
+If a publicly released vulnerability is reported, we
+may request to handle it according to the private disclosure process.
+If the reporter agrees, we will follow the private disclosure process.
+
+Security fixes will be applied to all supported stable releases, as well
+as the mainline version, as applicable. We recommend using the most recent
+mainline or stable release of nginx. Fixes are created and tested by the core
+team using a GitHub private fork for security. If necessary, the reporter
+may be invited to contribute to the fork and assist with the solution.
+
+The nginx team is committed to responsible information disclosure with
+sufficient detail, such as the CVSS score and vector. Privately disclosed
+vulnerabilities are embargoed by default until the fix is released.
+Communications and fixes remain private until made public. As nginx is
+supported by F5, we generally follow the
+[F5 security vulnerability response policy](https://my.f5.com/manage/s/article/K4602).
+
+### Vulnerability Disclosure and Fix Service Level Objectives
+
+- We will acknowledge all vulnerability reports within 1 to 3 days.
+- Fixes will be developed and released within 90 days from the date of
+disclosure. If an extension is needed, we will work with the disclosing person.
+- Publicly disclosed (i.e., Zero-Day vulnerabilities) will be addressed ASAP.
+
+## Confidentiality, Integrity, and Availability
+
+### Confidentiality and Integrity
+
+Vulnerabilities compromising data confidentiality or integrity are considered
+the highest priority. Any issue leading to unauthorized data access, leaks, or
+manipulation will trigger the security release process.
+
+### Availability
+
+Availability issues must meet the following criteria to trigger the security
+release process:
+- Is present in a standard module included with nginx.
+- Arises from traffic that the module is designed to handle.
+- Resource exhaustion issues are not mitigated by existing timeout, rate
+limiting, or buffer size configurations, or applying changes is impractical.
+- Results in highly asymmetric, extreme resource consumption.
+
+Availability issues excluded from the security release process:
+- Local file content or upstream response content resulting only in worker
+process termination.
+- Issues with experimental features which result only in worker process
+termination.
+
+## Trusted Configurations and Misconfigurations
+
+In nginx, configuration files, modules, certificate/key pairs, nginx JavaScript,
+and local file content are considered trusted sources. Issues arising from
+loading or execution of these trusted components are not considered
+vulnerabilities. Operators are responsible for securing and maintaining the
+integrity of these sources. Misconfigurations can create vulnerabilities, and
+operators should implement configurations according to best practices, review
+them regularly, and apply security updates.
+
+## Data Plane vs. Control Plane
+
+The data plane handles traffic through nginx, directly interacting with user
+data. nginx inherently trusts the content and instructions from upstream
+servers. The control plane governs configuration, management, and orchestration.
+Misconfigurations or vulnerabilities in the control plane can cause improper
+behavior in the data plane.
+
+## Modules Under Scope
+
+The policy applies to all nginx modules included in this repository. Security
+considerations and attack vectors for each module will be identified, with
+recommended configurations to mitigate risks.
+
+## Debug Logging and Core Files
+
+Debug logs and core files produced by nginx may contain un-sanitized data,
+including sensitive information like client requests, server configurations,
+and private key material. These artifacts must be handled carefully to avoid
+exposing confidential data.