mirror of https://github.com/docker/buildx.git
touch-up security policy
Touch-up the security policy to make the OpenSSF scorecard slightly happier; https://securityscorecards.dev/viewer/?uri=github.com/docker/buildx Warn: One or no descriptive hints of disclosure, vulnerability, and/or timelines in security policy Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit is contained in:
parent
d353f5f6ba
commit
1ce3e6a221
|
@ -1,12 +1,44 @@
|
||||||
# Reporting security issues
|
# Security Policy
|
||||||
|
|
||||||
The project maintainers take security seriously. If you discover a security
|
The maintainers of Docker Buildx take security seriously. If you discover
|
||||||
issue, please bring it to their attention right away!
|
a security issue, please bring it to their attention right away!
|
||||||
|
|
||||||
**Please _DO NOT_ file a public issue**, instead send your report privately to
|
## Reporting a Vulnerability
|
||||||
[security@docker.com](mailto:security@docker.com).
|
|
||||||
|
|
||||||
Security reports are greatly appreciated, and we will publicly thank you for it.
|
Please **DO NOT** file a public issue, instead send your report privately
|
||||||
We also like to send gifts—if you're into schwag, make sure to let
|
to [security@docker.com](mailto:security@docker.com).
|
||||||
us know. We currently do not offer a paid security bounty program, but are not
|
|
||||||
ruling it out in the future.
|
Reporter(s) can expect a response within 72 hours, acknowledging the issue was
|
||||||
|
received.
|
||||||
|
|
||||||
|
## Review Process
|
||||||
|
|
||||||
|
After receiving the report, an initial triage and technical analysis is
|
||||||
|
performed to confirm the report and determine its scope. We may request
|
||||||
|
additional information in this stage of the process.
|
||||||
|
|
||||||
|
Once a reviewer has confirmed the relevance of the report, a draft security
|
||||||
|
advisory will be created on GitHub. The draft advisory will be used to discuss
|
||||||
|
the issue with maintainers, the reporter(s), and where applicable, other
|
||||||
|
affected parties under embargo.
|
||||||
|
|
||||||
|
If the vulnerability is accepted, a timeline for developing a patch, public
|
||||||
|
disclosure, and patch release will be determined. If there is an embargo period
|
||||||
|
on public disclosure before the patch release, the reporter(s) are expected to
|
||||||
|
participate in the discussion of the timeline and abide by agreed upon dates
|
||||||
|
for public disclosure.
|
||||||
|
|
||||||
|
## Accreditation
|
||||||
|
|
||||||
|
Security reports are greatly appreciated and we will publicly thank you,
|
||||||
|
although we will keep your name confidential if you request it. We also like to
|
||||||
|
send gifts - if you're into swag, make sure to let us know. We do not currently
|
||||||
|
offer a paid security bounty program at this time.
|
||||||
|
|
||||||
|
## Supported Versions
|
||||||
|
|
||||||
|
Once a new feature release is cut, support for the previous feature release is
|
||||||
|
discontinued. An exception may be made for urgent security releases that occur
|
||||||
|
shortly after a new feature release. Buildx does not offer LTS (Long-Term Support)
|
||||||
|
releases. Refer to the [Support Policy](https://github.com/docker/buildx/blob/master/PROJECT.md#support-policy)
|
||||||
|
for further details.
|
||||||
|
|
Loading…
Reference in New Issue