mirror of
https://github.com/nginx/nginx.git
synced 2024-11-21 00:24:32 -06:00
Updated security policy to include disclosure details.
This commit is contained in:
parent
b394d44cfa
commit
f45c2707ea
94
SECURITY.md
94
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@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.
|
||||
|
Loading…
Reference in New Issue
Block a user