Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add security policy of Kurator #459

Merged
merged 1 commit into from
Nov 22, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 52 additions & 0 deletions community/security/SECURITY.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
# Security Policy

## Report a vulnerability
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This document describes an overall process from reporting a security breach to dealing with it, so there will be some duplication of report-a-vulnerability.md


We sincerely request you to keep the vulnerability information confidential and responsibly disclose the vulnerabilities.

To report a vulnerability, please contact the Security Team: [kurator-security@googlegroups.com](mailto:kurator-security@googlegroups.com). You can email the Security Team with the security details and the details expected for [Kurator vulnerability reports](./comms-templates/vulnerability-report-template.md).

The information of the Security Team members is described in [here](security-groups.md).

### E-mail Response

The team will help diagnose the severity of the issue and determine how to address the issue. The reporter(s) can expect a response within 2 business day acknowledging the issue was received. If a response is not received within 2 business day, please reach out to any Security Team member directly to confirm receipt of the issue. We’ll try to keep you informed about our progress throughout the process.

### When Should I Report a Vulnerability?

- You think you discovered a potential security vulnerability in Kurator
- You are unsure how a vulnerability affects Kurator

### When Should I NOT Report a Vulnerability?

- You need help tuning Kurator components for security
- You need help applying security related updates
- Your issue is not security related

If you think you discovered a vulnerability in another project that Kurator depends on, and that project has their own vulnerability reporting and disclosure process, please report it directly there.

## Security release process

The Kurator community will strictly handle the reporting vulnerability according to this [procedure](security-release-process.md). The following flowchart shows the vulnerability handling process.

<img src="./images/vulnerability-handling-process.PNG">

## Relative Mailing lists

- [kurator-security@googlegroups.com](mailto:kurator-security@googlegroups.com), is for reporting security concerns to the Kurator Security Team, who uses the list to privately discuss security issues and fixes prior to disclosure.

- [kurator-security@googlegroups.com](mailto:kurator-security@googlegroups.com), is for advance private information and vulnerability disclosure.

More details of group membership is managed [here](security-groups.md).

See the [private-distributors-list](private-distributors-list.md) for information on how Kurator distributors or vendors can apply to join this list.

## Supported versions

Kurator versions are expressed as x.y.z, where x is the major version, y is the minor version, and z is the patch version, following [Semantic Versioning](https://semver.org/) terminology.

The Kurator project maintains release branches for the most recent three minor releases. Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility.

Our typical patch release cadence is every 3 months. Critical bug fixes may cause a more immediate release outside of the normal cadence. We also aim to not make releases during major holiday periods.

See the [Kurator releases page](https://github.com/kurator-dev/kurator/releases) for information on supported versions of Kurator.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading