mirror of
https://github.com/opentofu/opentofu.git
synced 2024-12-22 15:13:29 -06:00
63 lines
3.2 KiB
Markdown
63 lines
3.2 KiB
Markdown
|
# Security Reporting Process
|
||
|
|
|
||
|
|
Please report any security issue via
|
||
|
|
[Private Vulnerability Reporting](https://github.com/opentofu/opentofu/security/advisories/new) where the issue will be triaged appropriately.
|
||
|
|
Thank you in advance for helping to keep OpenTofu secure.
|
||
|
|
|
||
|
|
# Security Release Process
|
||
|
|
|
||
|
|
OpenTofu is a large growing community of volunteers, users, and vendors. The OpenTofu community has
|
||
|
|
adopted this security disclosure and response policy to ensure we responsibly handle critical
|
||
|
|
issues.
|
||
|
|
|
||
|
|
## Product Security Team (PST)
|
||
|
|
|
||
|
|
Security vulnerabilities should be handled quickly and sometimes privately. The primary goal of this
|
||
|
|
process is to reduce the total time users are vulnerable to publicly known exploits.
|
||
|
|
|
||
|
|
The Product Security Team (PST) is responsible for organizing the entire response including internal
|
||
|
|
communication and external disclosure but will need help from relevant developers to successfully
|
||
|
|
run this process.
|
||
|
|
|
||
|
|
The initial Product Security Team will consist of members of Steering Committee and Core Development Team. In the future we may
|
||
|
|
decide to have a subset of maintainers work on security response given that this process is time
|
||
|
|
consuming.
|
||
|
|
|
||
|
|
## Disclosures
|
||
|
|
|
||
|
|
### Private Disclosure Processes
|
||
|
|
|
||
|
|
The OpenTofu community asks that all suspected vulnerabilities be privately and responsibly disclosed
|
||
|
|
via the [reporting policy](README.md#reporting-security-vulnerabilities).
|
||
|
|
|
||
|
|
### Public Disclosure Processes
|
||
|
|
|
||
|
|
If you know of a publicly disclosed security vulnerability please IMMEDIATELY submit a report via
|
||
|
|
[Private Vulnerability Reporting](https://github.com/opentofu/opentofu/security/advisories/new) to inform the Product
|
||
|
|
Security Team (PST) about the vulnerability so they may start the patch, release, and communication
|
||
|
|
process.
|
||
|
|
|
||
|
|
If possible the PST will ask the person making the public report if the issue can be handled via a
|
||
|
|
private disclosure process (for example if the full exploit details have not yet been published). If
|
||
|
|
the reporter denies the request for private disclosure, the PST will move swiftly with the fix and
|
||
|
|
release process. In extreme cases GitHub can be asked to delete the issue but this generally isn't
|
||
|
|
necessary and is unlikely to make a public disclosure less damaging.
|
||
|
|
|
||
|
|
## Patch, Release, and Public Communication
|
||
|
|
|
||
|
|
For each vulnerability a member of the PST will volunteer to lead coordination with the "Fix Team"
|
||
|
|
and is responsible for sending disclosure emails to the rest of the community. This lead will be
|
||
|
|
referred to as the "Fix Lead."
|
||
|
|
|
||
|
|
The role of Fix Lead should rotate round-robin across the PST.
|
||
|
|
|
||
|
|
Note that given the current size of the OpenTofu community it is likely that the PST is the same as
|
||
|
|
the "Fix team." (I.e., all maintainers). The PST may decide to bring in additional contributors
|
||
|
|
for added expertise depending on the area of the code that contains the vulnerability.
|
||
|
|
|
||
|
|
The Fix Lead drives the schedule using their best judgment based on severity and development time. If the Fix Lead is
|
||
|
|
dealing with a public disclosure all timelines become ASAP (assuming the vulnerability has a CVSS
|
||
|
|
score >= 4). If the fix relies on another upstream project's disclosure timeline, that
|
||
|
|
will adjust the process as well. We will work with the upstream project to fit their timeline and
|
||
|
|
best protect our users.
|