diff --git a/pages/security-charter.ftl b/pages/security-charter.ftl new file mode 100644 index 00000000..49564d9e --- /dev/null +++ b/pages/security-charter.ftl @@ -0,0 +1,119 @@ +<#import "/templates/template.ftl" as tmpl> + +<@tmpl.page current="charter" title="Security Charter"> + +
+ +

Security Charter

+ +

Mission

+

The Keycloak Security Taskforce is committed to enhancing the security of the Keycloak project through continuous improvement of documentation, code, and processes. Our core responsibilities include:

+ + +

Teams

+

Keycloak Security Response Team

+

A dedicated subset of maintainers actively involved in triaging new issues and coordinating with Resolution Teams. The Response Team has full access to all CVEs reported to the project and can add or remove members from Resolution Teams as necessary.

+ +

Member Nomination Process

+ + +

Responsibilities

+ + +

Scope

+ + +

Rotating Shifts

+ + +

Keycloak Security Resolution Team

+

Dynamic teams formed by individuals actively involved in triaging or resolving open CVEs. Members are added when they engage with a vulnerability and removed once their involvement concludes.

+ +

Scope

+ + +

Access

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ResourceResponse TeamResolution Team
Mailing listFull accessAdded in CC to specific threads
Private GitHub repositoryFull accessTemporary access
Security advisories and alertsFull accessNo access
Slack channel (#alerts-keycloak-cve)Full accessTemporary access
+ +

Coordinating a Security Vulnerability Fix

+ + +

Process Overview

+
    +
  1. A new vulnerability is reported to the Keycloak security mailing list.
  2. +
  3. The vulnerability report is triaged.
  4. +
  5. A CVE ID is assigned.
  6. +
  7. The Response Team identifies the responsible group (e.g., Team A with members Noah and Emma).
  8. +
  9. Team A submits the fix to the private repository and includes domain experts for review.
  10. +
  11. Team A informs QE and releases coordinators about the forthcoming patch.
  12. +
  13. The pull request is merged, and a new release is issued along with official advisories.
  14. +
+

In the absence of CVEs to fix, all team members will have their access revoked to security-sensitive channels except for the Keycloak Security Response Team.

+ +

This charter outlines the approach the Keycloak project takes to manage and mitigate security vulnerabilities, ensuring the integrity and reliability of the project for all users.

+ +
+ + diff --git a/pages/security.ftl b/pages/security.ftl index 0ab08547..2c957f6c 100644 --- a/pages/security.ftl +++ b/pages/security.ftl @@ -1,31 +1,44 @@ <#import "/templates/template.ftl" as tmpl> -<@tmpl.page current="security" title="Security"> +<@tmpl.page current="security" title="Security Policy">

Security Policy

+

This policy is based on the CISA vulnerability disclosure policy template

+ +

Introduction

+

The Keycloak team believes that everyone, everywhere, is entitled to the access and quality information needed to mitigate security and privacy risks. We strive to protect communities of users, contributors, and partners from digital security threats. We believe an open approach to vulnerability management is the best way to achieve this.

+

This policy supports our open approach and is intended to give security researchers clear guidelines for submitting and coordinating discovered vulnerabilities with us. In complying with this policy, you authorize CNCF to work with you to understand and resolve the issue quickly. For more details about our processes, please read the security charter.

+ +

Guidelines

+ +

Violation of these guidelines may result in the individual, or vendor, being added to a denied coordination list.

+ +

Scope

+

This policy applies to all Keycloak components and projects. Research disclosed to the project will be limited to Response Team members; however, we will assist in coordinating the disclosure of research with upstream open-source communities as needed and requested.

+ +

Reporting a Suspected Vulnerability

+

Suspected vulnerabilities should be disclosed responsibly and not made public until after analysis and a fix are available. We will acknowledge your report within 7 business days and work with you to confirm the vulnerability's existence and impact. Our goal is to maintain open dialogue during the assessment and remediation process.

+ +

Supported Versions

+

Depending on the severity of a vulnerability the issue may be fixed in the current major.minor release of Keycloak, or for lower severity vulnerabilities or hardening in the following major.minor release. Refer to https://www.keycloak.org/downloads to find the latest release.

+

If you are unable to regularly upgrade Keycloak we encourage you to consider Red Hat build of Keycloak, which offers long term support of specific versions of Keycloak.

-

The Keycloak team takes security very seriously, and aim to resolve issues as quickly as possible. Building secure software is a continuous process, and can always be improved. As such we welcome reports on potential security vulnerabilities, as well as suggestions around hardening the software and our process.

- -

Reporting a suspected vulnerability

- -

It is important that suspected vulnerabilities are disclosed in a responsible way, and are not publicly disclosed until after they have been analysed and a fix is available.

- -

To report a security vulnerability in the Keycloak codebase, send an email to keycloak-security@googlegroups.com. Please test against the latest version of Keycloak and include the version affected in your report, provide detailed instructions on how to reproduce the issue with a minimal an reproducible example, and include your contact information for acknowledgements. If you are reporting known CVEs related to third-party libraries used in Keycloak, please create a new GitHub issue.

- -

If you would like to work with us on a fix for the security vulnerability, please include your GitHub username in the above email, and we will provide you access to a temporary private fork where we can collaborate on a fix without it being disclosed publicly.

- -

Do not open a public issue, send a pull request, or disclose any information about the suspected vulnerability publicly. If you discover any publicly disclosed security vulnerabilities, please notify us immediately through keycloak-security@googlegroups.com.

+

Coordinated Vulnerability Disclosure

+

To report a security vulnerability in the Keycloak codebase, send an email to keycloak-security@googlegroups.com. Please test against the latest version of Keycloak, include the affected version in your report, provide detailed instructions on how to reproduce the issue with a minimal and reproducible example, and include your contact information for acknowledgements. If you are reporting known CVEs related to third-party libraries used in Keycloak, please create a new GitHub issue.

+

If you would like to collaborate on a fix for the security vulnerability, please include your GitHub username in the email, and we will provide you access to a temporary private fork where we can work together.

+

If you discover any publicly disclosed security vulnerabilities, please notify us immediately through keycloak-security@googlegroups.com.

Security Scanners

- -

Reports from automated security scanners will not be accepted. These tools often report false positives, and can be disruptive to the project maintainers as it takes a long time to analyse these reports. If you believe you have found a security vulnerability using a security scanner, it is your responsiblity to provide a clear example of the vulnerability and how it could be exploited specifically for Keycloak as outlined above.

- -

Supported Versions

- -

Depending on the severity of a vulnerability the issue may be fixed in the current major.minor release of Keycloak, or for lower severity vulnerabilities or hardening in the following major.minor release. Refer to https://www.keycloak.org/downloads to find the latest release.

- -

If you are unable to regularly upgrade Keycloak we encourage you to consider Red Hat build of Keycloak, which offers long term support of specific versions of Keycloak.

+

Reports from automated security scanners will not be accepted. These tools often report false positives, and can be disruptive to the project maintainers as it takes a long time to analyze these reports. If you believe you have found a security vulnerability using a security scanner, it is your responsibility to provide a clear example of the vulnerability and how it could be exploited specifically for Keycloak as outlined above.