diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
new file mode 100644
index 0000000..bf83a47
--- /dev/null
+++ b/.github/CODEOWNERS
@@ -0,0 +1,2 @@
+# Default: Security TAG members review all changes
+* @cwperks @nibix @aparajita31pandey @kumargu @kkhatua @willyborankin @shikharj05 @jochen-kressin
diff --git a/.github/ISSUE_TEMPLATE/vulnerability-report.yml b/.github/ISSUE_TEMPLATE/vulnerability-report.yml
new file mode 100644
index 0000000..a65b9d4
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/vulnerability-report.yml
@@ -0,0 +1,57 @@
+name: Vulnerability Report
+description: Report a security vulnerability in an OpenSearch project. For private reports, use the Security tab instead.
+title: "[VULN] "
+labels: ["vulnerability", "triage"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        **⚠️ If this vulnerability has not been publicly disclosed, do NOT use this form.**
+        Instead, use one of these private channels:
+        - Email: security@opensearch.org
+        - GitHub Security tab → "Report a vulnerability" on the affected repository
+
+        This form is for tracking **already-public** vulnerabilities (e.g., CVEs in dependencies).
+
+  - type: input
+    id: repository
+    attributes:
+      label: Affected Repository
+      description: Which opensearch-project repository is affected?
+      placeholder: "e.g., opensearch-project/OpenSearch"
+    validations:
+      required: true
+
+  - type: input
+    id: versions
+    attributes:
+      label: Affected Versions
+      description: Which versions are affected?
+      placeholder: "e.g., 2.10.0–2.12.0"
+    validations:
+      required: true
+
+  - type: textarea
+    id: description
+    attributes:
+      label: Description
+      description: Describe the vulnerability and its impact.
+    validations:
+      required: true
+
+  - type: input
+    id: cve
+    attributes:
+      label: CVE ID
+      description: If a CVE has already been assigned, provide it here.
+      placeholder: "e.g., CVE-2026-XXXXX"
+    validations:
+      required: false
+
+  - type: textarea
+    id: references
+    attributes:
+      label: References
+      description: Links to public advisories, NVD entries, or upstream fixes.
+    validations:
+      required: false
diff --git a/.github/SECURITY.md b/.github/SECURITY.md
new file mode 100644
index 0000000..f74df07
--- /dev/null
+++ b/.github/SECURITY.md
@@ -0,0 +1,24 @@
+# Security
+
+If you discover a potential security issue in any OpenSearch project, please report it privately.
+
+## Reporting a Vulnerability
+
+- **Email**: security@opensearch.org
+- **GitHub**: Use the **Security** tab → **Report a vulnerability** on this or any `opensearch-project` repository.
+
+Please include the affected repository, affected versions, a description of the issue, and reproduction steps.
+
+**Do not** create a public GitHub issue for undisclosed vulnerabilities.
+
+## What to Expect
+
+- Acknowledgment within **48 hours**.
+- The [Security Response Team (SRT)](../README.md#security-response-team-srt) will triage, coordinate a fix, and work with you on a disclosure timeline.
+
+## More Information
+
+- [Intake Process](../INTAKE.md)
+- [Security Release Process](../SECURITY_RELEASE_PROCESS.md)
+- [Embargo Policy](../EMBARGO_POLICY.md)
+- [OpenSearch Security Policy](https://github.com/opensearch-project/.github/blob/main/SECURITY.md)
diff --git a/EMBARGO_POLICY.md b/EMBARGO_POLICY.md
new file mode 100644
index 0000000..aa9165a
--- /dev/null
+++ b/EMBARGO_POLICY.md
@@ -0,0 +1,80 @@
+# Embargo Policy
+
+This document describes the embargo process for security vulnerabilities in OpenSearch. It supplements the [Security Issue Response Process](https://github.com/opensearch-project/.github/blob/main/SECURITY.md) defined in the `.github` repository.
+
+## What Is an Embargo?
+
+An embargo is a period during which details of a vulnerability are kept confidential to allow time for a fix to be developed, tested, and released before the issue becomes public knowledge. During an embargo, only authorized parties (the SRT, the Fix Team, and the pre-disclosure list) have access to vulnerability details.
+
+## Embargo Timeline
+
+Embargo periods are negotiated on a case-by-case basis between the SRT and the reporter. The following are general guidelines:
+
+| Phase | Target Timeline |
+| --- | --- |
+| Advisory sent to pre-disclosure list | Within 2 weeks of confirmed report |
+| Public disclosure | Within 4 weeks of pre-disclosure advisory |
+
+### Adjustments
+
+- **Reporter requests a longer embargo**: The SRT will honor reasonable requests for extended timelines.
+- **Reporter requests accelerated disclosure**: If a reporter intends to disclose on a timeline shorter than the SRT would prefer, the SRT will work to have a fix or mitigation ready by that date. The SRT cannot prevent a reporter from disclosing independently.
+- **Active exploitation in the wild**: The SRT will disclose immediately and release patches as soon as possible.
+- **Severity-based**: Low severity issues (CVSS < 4.0) may follow a relaxed timeline aligned with the next [scheduled release](https://opensearch.org/releases/).
+
+## Obligations During Embargo
+
+All parties with access to embargoed information must maintain confidentiality until the embargo is lifted. Specifically, before the embargo date, recipients must **not** make available:
+
+- The OpenSearch advisory or their own advisory
+- The impact, scope, set of affected systems, or nature of the vulnerability
+- Commits, patches, or code changes that fix the issue
+- Patched software in any form (source or binary)
+
+Without prior SRT approval, recipients may share only:
+
+- The existence of an issue
+- The assigned advisory number
+- The planned disclosure date
+
+## Pre-Disclosure List
+
+The SRT maintains a pre-disclosure list of contributors, vendors, and operators who:
+
+1. Require significant work post-disclosure to remediate the issue across large deployments, or
+2. Can help develop and test fixes before public release.
+
+### What the List Receives
+
+- Advance copies of the advisory and patches, clearly marked with the embargo date, at least **7 days** before public disclosure.
+- Notification at least **24 hours** before a release containing security fixes, with the public messaging, date, and time of the announcement.
+
+### Sharing Between List Members
+
+Pre-disclosure list members may share fixes, analysis, and related materials with the SRT and security teams of other list members. Technical measures must be taken to prevent unauthorized access.
+
+### Deployment During Embargo
+
+List members may deploy fixed versions during the embargo **only** with explicit SRT permission. Any restrictions will be stated in the embargoed advisory. If deployment involves user-facing disruption (e.g., restarts), communications may mention that the disruption is to correct a security issue, referencing only the publicly shareable information listed above.
+
+### Joining the Pre-Disclosure List
+
+Organizations that meet the criteria above may apply by emailing security@opensearch.org with:
+
+- Organization name
+- How you use OpenSearch
+- Why you meet the criteria (user base size, remediation effort, ability to collaborate on fixes)
+- Your organization's security problem handling process and public contact information
+- Confirmation that you have read and agree to this policy
+- Email addresses to add to the list
+
+The SRT will review applications and respond with a decision.
+
+### Embargo Violations
+
+If a list member breaks embargo, the SRT will assess the impact and decide whether to accelerate disclosure. Repeated violations will result in removal from the pre-disclosure list.
+
+## References
+
+- [OpenSearch Security Issue Response Process](https://github.com/opensearch-project/.github/blob/main/SECURITY.md) — the org-wide security policy
+- [Security Release Process](SECURITY_RELEASE_PROCESS.md) — the full lifecycle in this repository
diff --git a/INTAKE.md b/INTAKE.md
new file mode 100644
index 0000000..aa1a2a1
--- /dev/null
+++ b/INTAKE.md
@@ -0,0 +1,68 @@
+# Vulnerability Intake Process
+
+This document describes how to report a security vulnerability in any [opensearch-project](https://github.com/opensearch-project) repository and how the SRT processes incoming reports.
+
+## How to Report
+
+There are two ways to report a vulnerability:
+
+### 1. Email (Preferred)
+
+Send an email to **security@opensearch.org** with:
+
+- **Affected repository** (e.g., `opensearch-project/OpenSearch`, `opensearch-project/security`)
+- **Affected versions** (if known)
+- **Description** of the vulnerability
+- **Reproduction steps** or proof of concept
+- **Impact assessment** (what can an adversary achieve?)
+- **Any suggested fix** (optional)
+
+The SRT monitors this inbox and will acknowledge your report within **48 hours**.
+
+### 2. GitHub Private Vulnerability Reporting
+
+You can also report directly through the **Security** tab on any `opensearch-project` repository:
+
+1. Navigate to the repository on GitHub.
+2. Click the **Security** tab.
+3. Click **Report a vulnerability**.
+4. Fill in the form and submit.
+
+This creates a Draft GHSA visible only to the repository maintainers and [`opensearch-admin`](https://github.com/orgs/opensearch-project/teams/opensearch-admin). The SRT will be notified and will follow up within **48 hours**.
+
+> **Note**: You can also use the Security tab on this repository ([opensearch-project/security-response](https://github.com/opensearch-project/security-response)) if you are unsure which repository is affected.
+
+## What Happens Next
+
+After your report is received:
+
+1. **Acknowledgment** (within 48 hours): An SRT member confirms receipt and may ask clarifying questions.
+2. **Triage**: The SRT validates the report, determines the affected component, and scores severity using [CVSS 3.1](https://www.first.org/cvss/v3.1/specification-document).
+3. **Draft GHSA**: If the report is confirmed, the SRT creates a Draft GHSA on the affected repository (if one was not already created via the Security tab).
+4. **CVE reservation**: The SRT reserves a CVE ID. GitHub's CNA will assign the CVE when the GHSA is published.
+5. **Embargo negotiation**: The SRT and reporter agree on an [embargo timeline](EMBARGO_POLICY.md).
+6. **Fix coordination**: The SRT assembles a Fix Team and begins the [private fix process](PRIVATE_FIX_GUIDELINES.md).
+7. **Tracking**: The issue is added to the [vulnerability tracking board](VULNERABILITY_TRACKING.md).
+
+## Requesting a GHSA or CVE for Your Repository
+
+If you are a maintainer of an `opensearch-project` repository and have identified a vulnerability in your own component:
+
+1. Email security@opensearch.org or message an SRT member on Slack.
+2. Provide the repository name, a description of the issue, and a list of GitHub usernames who should have access to the private fork.
+3. The SRT (via `opensearch-admin`) will create the Draft GHSA and temporary private fork on your repository.
+
+You do not need to be an SRT member to request this — any project maintainer can initiate the process.
+
+## Publicly Known Vulnerabilities
+
+If the vulnerability is already publicly known (e.g., a CVE in a third-party dependency), no embargo is needed. You may:
+
+- Open a public GitHub issue on the affected repository.
+- The SRT will still track the fix on the [vulnerability tracking board](VULNERABILITY_TRACKING.md).
+
+## Reporter Expectations
+
+- The SRT will keep you informed of progress throughout the process.
+- You will be credited in the published advisory unless you request otherwise.
+- If you have a preferred disclosure timeline, let the SRT know during the initial exchange. See the [Embargo Policy](EMBARGO_POLICY.md) for how timelines are negotiated.
diff --git a/LICENSE b/LICENSE
new file mode 100644
index 0000000..7e06c47
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,193 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to the Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by the Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding any notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   Copyright OpenSearch Contributors. See
+   https://github.com/opensearch-project/security-response/blob/main/NOTICE
+   for full contributor list.
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.
diff --git a/MAINTAINERS.md b/MAINTAINERS.md
new file mode 100644
index 0000000..c5578b9
--- /dev/null
+++ b/MAINTAINERS.md
@@ -0,0 +1,16 @@
+# Maintainers
+
+This document lists the maintainers of the [opensearch-project/security-response](https://github.com/opensearch-project/security-response) repository. Maintainers are responsible for reviewing and approving changes to the security response process documentation.
+
+All current [Security TAG members](ROLES.md#current-members-1) are maintainers of this repository.
+
+| Name | GitHub |
+| --- | --- |
+| Craig Perkins | [@cwperks](https://github.com/cwperks) |
+| Nils Bandener | [@nibix](https://github.com/nibix) |
+| Aparajita Pandey | [@aparajita31pandey](https://github.com/aparajita31pandey) |
+| Gulshan Kumar | [@kumargu](https://github.com/kumargu) |
+| Kunal Khatua | [@kkhatua](https://github.com/kkhatua) |
+| Andrey Pleskach | [@willyborankin](https://github.com/willyborankin) |
+| Shikhar Jain | [@shikharj05](https://github.com/shikharj05) |
+| Jochen Kressin | [@jochen-kressin](https://github.com/jochen-kressin) |
diff --git a/PRIVATE_FIX_GUIDELINES.md b/PRIVATE_FIX_GUIDELINES.md
new file mode 100644
index 0000000..67bb216
--- /dev/null
+++ b/PRIVATE_FIX_GUIDELINES.md
@@ -0,0 +1,83 @@
+# Private Fix Guidelines
+
+This document explains how to develop security fixes privately using GitHub Security Advisories and temporary private forks, and how to write commit messages that do not reveal the nature of the fix before disclosure.
+
+## Requesting a Draft GHSA and Private Fork
+
+Any maintainer or contributor who discovers or is assigned a security issue can request a Draft GHSA and temporary private fork. To do so:
+
+1. **Contact an [`opensearch-admin`](https://github.com/orgs/opensearch-project/teams/opensearch-admin) member** (via Slack DM or email to security@opensearch.org) with:
+   - The affected repository
+   - A brief description of the issue
+   - A list of GitHub usernames who need collaborator access to work on the fix (the "Fix Team")
+2. The admin will create a [Draft GitHub Security Advisory (GHSA)](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/creating-a-repository-security-advisory) on the affected repository.
+3. From the Draft GHSA, the admin will create a **temporary private fork** and add the Fix Team as collaborators.
+
+### What You Get
+
+- A private fork of the repository that is only visible to the Fix Team and `opensearch-admin`.
+- The ability to create branches, push commits, and open pull requests within the private fork — all invisible to the public.
+- The Draft GHSA serves as the central record for the vulnerability, including CVSS score, affected versions, and CVE ID.
+
+## Working in the Private Fork
+
+1. **Clone the private fork** using the URL provided in the Draft GHSA.
+2. **Create a feature branch** from the target release branch (e.g., `main` or a version branch).
+3. **Develop and test the fix** as you would in a normal PR.
+4. **Open a pull request within the private fork** for review by other Fix Team members.
+5. Once approved, **do not merge yet** — the merge is coordinated by the SRT to align with the release timeline.
+
+### Keeping the Fork Up to Date
+
+The private fork may fall behind the upstream repository. Periodically rebase or merge from upstream to avoid conflicts at merge time.
+
+## Commit Message Hygiene
+
+Commit messages in the private fork will become public when the fix is merged. To avoid drawing attention to the security nature of the fix before the advisory is published:
+
+### Do Not Use
+
+- "vulnerability", "exploit", "attack", "attacker", "CVE", "security fix", "security issue", "security bug"
+- "injection", "bypass", "privilege escalation", "denial of service" (or similar terms that describe the class of vulnerability)
+- Any CVE ID (e.g., `CVE-2026-XXXXX`)
+
+### Do Use
+
+- Neutral, descriptive language about what the code change does:
+  - ✅ "Validate input parameters in query handler"
+  - ✅ "Add bounds checking to buffer allocation"
+  - ✅ "Enforce permission check before resource access"
+  - ✅ "Update dependency X to version Y"
+  - ✅ "Fix edge case in authentication flow"
+- The same style and tone as any other bug fix or improvement.
+
+### PR Titles and Descriptions
+
+The same rules apply to PR titles and descriptions when the fix is merged into the public repository. Keep them factual and non-alarming.
+
+## Merging the Fix
+
+When the SRT gives the go-ahead (typically just before a release):
+
+1. The Fix Team merges the private fork PR into the target branch of the **public** repository.
+2. The merge should be timed to minimize the window between the commit appearing publicly and the patched release being available.
+3. After the patched release is published, the SRT publishes the Draft GHSA, which makes the advisory and CVE public.
+
+## After Disclosure
+
+Once the GHSA is published:
+
+- The temporary private fork is no longer needed and can be deleted by an `opensearch-admin` member.
+- The CVE ID and advisory link can be referenced freely in follow-up commits, release notes, and discussions.
+
+## Quick Reference
+
+| Step | Who | Action |
+| --- | --- | --- |
+| Request private fork | Any maintainer | Contact `opensearch-admin` with repo, description, and collaborator list |
+| Create Draft GHSA + fork | `opensearch-admin` | Set up GHSA, create private fork, add collaborators |
+| Develop fix | Fix Team | Work in private fork, follow commit message guidelines |
+| Review fix | Fix Team | PR review within private fork |
+| Merge fix | Fix Team + SRT | Merge to public repo, timed with release |
+| Publish advisory | SRT | Publish Draft GHSA after patched release is available |
+| Clean up | `opensearch-admin` | Delete temporary private fork |
diff --git a/README.md b/README.md
index 743b038..6613021 100644
--- a/README.md
+++ b/README.md
@@ -1,13 +1,49 @@
 # OpenSearch Security Response
 
-## Report a Vulnerability
-**Important:** Please `DO NOT` create any public GitHub issues.
-If you discover a potential security vulnerability in this project, you can report with two options:
+This repository documents the OpenSearch project's security vulnerability response process. It is the central reference for how security issues are reported, triaged, fixed, and disclosed across all [opensearch-project](https://github.com/opensearch-project) repositories.
 
-1. **Security Email**: [security@opensearch.org](mailto:security@opensearch.org)
+To report a vulnerability, email **security@opensearch.org** or use the **Security** tab on any `opensearch-project` repository to file a private vulnerability report.
 
-2. **GitHub PVR**: OpenSearch's [Private Vulnerability Reporting](https://github.com/opensearch-project/security-response/security) on GitHub
+## Documents
 
+| Document | Description |
+| --- | --- |
+| [Security Release Process](SECURITY_RELEASE_PROCESS.md) | End-to-end lifecycle from report intake through patch release and public disclosure |
+| [Intake Process](INTAKE.md) | How to request a Draft GHSA or CVE for any OpenSearch repository |
+| [Private Fix Guidelines](PRIVATE_FIX_GUIDELINES.md) | Working with Draft GHSAs, temporary private forks, and commit message hygiene |
+| [Embargo Policy](EMBARGO_POLICY.md) | Embargo terms, timelines, and pre-disclosure list |
+| [Vulnerability Tracking](VULNERABILITY_TRACKING.md) | Tracking board workflow and status definitions |
+| [Roles and Responsibilities](ROLES.md) | SRT and Security TAG charter, membership, and how they interact |
+| [Comms Templates](comms-templates/) | Email, Slack, and forum templates for each stage of the process |
 
-For more details, please refer to the security page on our website:
-* <https://opensearch.org/security-and-disclosure-information>
+## Security Response Team (SRT)
+
+The SRT is the operational arm — it handles triage, fix coordination, and disclosure. See [ROLES.md](ROLES.md) for full responsibilities and membership criteria.
+
+### Current Members
+
+| Name | GitHub | Affiliation |
+| --- | --- | --- |
+| Kunal Khatua | [@kkhatua](https://github.com/kkhatua) | Amazon |
+| Craig Perkins | [@cwperks](https://github.com/cwperks) | Amazon |
+| Nils Bandener | [@nibix](https://github.com/nibix) | Eliatra |
+
+## Security TAG
+
+The Security TAG is the advisory arm — it advises on severity, out-of-band release decisions, and policy changes, and makes recommendations to the [TSC](https://github.com/opensearch-project/technical-steering-committee). See [ROLES.md](ROLES.md) for full responsibilities and how the two groups work together.
+
+## Contact
+
+| Channel | Visibility | Use |
+| --- | --- | --- |
+| security@opensearch.org | Private | Report vulnerabilities. Monitored and triaged by the SRT. |
+| GitHub Security tab | Private | File a private vulnerability report on any `opensearch-project` repo. |
+| [OpenSearch Forum — Security](https://forum.opensearch.org/c/security/) | Public | General security discussion. |
+
+## Code of Conduct
+
+This project has adopted the [Contributor Covenant](https://www.contributor-covenant.org/) as its Code of Conduct. All community members are expected to adhere to it. See [CODE_OF_CONDUCT.md](https://github.com/opensearch-project/.github/blob/main/CODE_OF_CONDUCT.md) for details. This project is part of the [Linux Foundation](https://www.linuxfoundation.org/).
+
+## License
+
+This project is licensed under the [Apache License 2.0](LICENSE).
diff --git a/ROLES.md b/ROLES.md
new file mode 100644
index 0000000..668e461
--- /dev/null
+++ b/ROLES.md
@@ -0,0 +1,134 @@
+# Security Roles and Responsibilities
+
+This document describes the two security governance bodies in the OpenSearch project: the **Security Response Team (SRT)** and the **Security Technical Advisory Group (TAG)**. They serve distinct but complementary functions.
+
+## Security Response Team (SRT)
+
+The SRT is the **operational** arm of OpenSearch security. It handles the day-to-day work of receiving, triaging, and coordinating fixes for security vulnerabilities.
+
+### Responsibilities
+
+- Monitor security@opensearch.org and GitHub private vulnerability reports.
+- Acknowledge incoming reports within 48 hours.
+- Triage and validate reports, assign CVSS scores.
+- Create Draft GHSAs and reserve CVE IDs.
+- Assemble Fix Teams and coordinate private fix development.
+- Manage the vulnerability tracking board.
+- Negotiate embargo timelines with reporters.
+- Coordinate with release managers on patch timing.
+- Send pre-disclosure and public disclosure communications using the [comms templates](comms-templates/).
+- Maintain the pre-disclosure list.
+
+### Membership
+
+- New members are nominated by existing SRT members.
+- Members should have experience as maintainers in the OpenSearch project and familiarity with security concepts (CVSS scoring, responsible disclosure, CVE process).
+- To encourage diversity, no single organization should represent more than half of the SRT. If representation shifts due to job changes, the team should work to rebalance within 12 months.
+- The SRT has no fixed size cap but should remain small enough to act quickly (target: 5–8 members).
+
+### Stepping Down
+
+Members may step down at any time and are encouraged to nominate a replacement. Members who are unreachable for more than 2 months or are not fulfilling their responsibilities may be removed by consensus of the remaining members.
+
+### Current Members
+
+| Name | GitHub | Affiliation |
+| --- | --- | --- |
+| Kunal Khatua | [@kkhatua](https://github.com/kkhatua) | Amazon |
+| Craig Perkins | [@cwperks](https://github.com/cwperks) | Amazon |
+| Nils Bandener | [@nibix](https://github.com/nibix) | Eliatra |
+
+### Emeritus
+
+| Name | GitHub | Affiliation |
+| --- | --- | --- |
+| Shikhar Jain | [@shikharj05](https://github.com/shikharj05) | Amazon |
+| Gulshan Kumar | [@kumargu](https://github.com/kumargu) | Amazon |
+| Ryan Liang | [@RyanL1997](https://github.com/RyanL1997) | Amazon |
+| Varun Lodaya | [@varun-lodaya](https://github.com/varun-lodaya) | Amazon |
+| Andriy Redko | [@reta](https://github.com/reta) | Aiven |
+| Andrey Pleskach | [@willyborankin](https://github.com/willyborankin) | Aiven |
+
+## Security Technical Advisory Group (TAG)
+
+The Security TAG is the **advisory** arm. It champions the strategic direction and technical guidance for security across the OpenSearch ecosystem, and makes recommendations to the [TSC](https://github.com/opensearch-project/technical-steering-committee).
+
+The full TAG charter, including scope, non-goals, decision process, and membership rotation, is maintained in the [technical-steering repo](https://github.com/opensearch-project/technical-steering/tree/main/technical-advisory-groups/security-tag).
+
+### Responsibilities (as they relate to vulnerability response)
+
+- Review and advise on severity ratings for Critical and High issues.
+- Recommend out-of-band patch releases to the TSC.
+- Escalate high-impact security concerns (critical vulnerabilities, supply-chain risks) to the TSC and SRT.
+- Review and propose changes to security response policies (this repo's documentation).
+- Periodically review the vulnerability tracking board to ensure issues are progressing.
+- Participate in retrospectives for Critical and High severity incidents.
+
+The TAG's broader responsibilities — security architecture guidance, dependency management practices, plugin hardening, community education — are defined in the [charter](https://github.com/opensearch-project/technical-steering/blob/main/technical-advisory-groups/security-tag/charter.md).
+
+### Relationship to the TSC
+
+The Security TAG is advisory — it **recommends** but does not enforce. Final decision-making (e.g., out-of-band release approval, policy changes) rests with the TSC.
+
+### Current Members
+
+| Name | GitHub | Affiliation |
+| --- | --- | --- |
+| Craig Perkins | [@cwperks](https://github.com/cwperks) | Amazon |
+| Nils Bandener | [@nibix](https://github.com/nibix) | Eliatra |
+| Aparajita Pandey | [@aparajita31pandey](https://github.com/aparajita31pandey) | Uber |
+| Gulshan Kumar | [@kumargu](https://github.com/kumargu) | Amazon |
+| Kunal Khatua | [@kkhatua](https://github.com/kkhatua) | Amazon |
+| Andrey Pleskach | [@willyborankin](https://github.com/willyborankin) | Aiven |
+| Shikhar Jain | [@shikharj05](https://github.com/shikharj05) | Amazon |
+| Jochen Kressin | [@jochen-kressin](https://github.com/jochen-kressin) | Eliatra |
+
+Membership follows the guidelines in the [TAGs README](https://github.com/opensearch-project/technical-steering/tree/main/technical-advisory-groups).
+
+## How the SRT and TAG Work Together
+
+```
+┌──────────────────────────────────────────────────────────┐
+│                     Vulnerability Report                  │
+└──────────────────────┬───────────────────────────────────┘
+                       ▼
+              ┌─────────────────┐
+              │       SRT       │  Triage, CVSS, Draft GHSA,
+              │  (operational)  │  Fix Team, embargo, comms
+              └────────┬────────┘
+                       │
+          ┌────────────┼────────────────┐
+          ▼            ▼                ▼
+   Medium/Low    Critical/High    Policy questions
+   severity      severity
+          │            │                │
+          │            ▼                ▼
+          │   ┌─────────────────┐  ┌─────────────────┐
+          │   │  Security TAG   │  │  Security TAG   │
+          │   │  (advisory)     │  │  (advisory)     │
+          │   └────────┬────────┘  └────────┬────────┘
+          │            │                    │
+          │            ▼                    ▼
+          │   ┌─────────────────┐  ┌─────────────────┐
+          │   │      TSC        │  │      TSC        │
+          │   │ (out-of-band    │  │ (policy         │
+          │   │  release decision) │  approval)      │
+          │   └────────┬────────┘  └─────────────────┘
+          │            │
+          ▼            ▼
+   Next scheduled   Out-of-band
+   release          patch release
+```
+
+| Scenario | SRT | Security TAG | TSC |
+| --- | --- | --- | --- |
+| New vulnerability report | Triages, scores, creates GHSA | — | — |
+| Medium/Low severity fix | Coordinates fix, publishes on next release | Reviews if needed | — |
+| Critical severity fix | Coordinates fix, requests out-of-band release | Recommends out-of-band release | Approves out-of-band release |
+| High severity fix | Coordinates fix, consults TAG on release timing | Evaluates whether out-of-band is warranted | Approves if out-of-band recommended |
+| Policy change (e.g., embargo terms) | Proposes change | Reviews and advises | Approves |
+| Retrospective | Leads retrospective | Participates | — |
+
+## Joining
+
+If you are interested in joining the SRT or Security TAG, reach out to any current member or email security@opensearch.org. The best path to nomination is sustained contribution to security-related work in the OpenSearch project.
diff --git a/SECURITY_RELEASE_PROCESS.md b/SECURITY_RELEASE_PROCESS.md
new file mode 100644
index 0000000..396c443
--- /dev/null
+++ b/SECURITY_RELEASE_PROCESS.md
@@ -0,0 +1,186 @@
+# Security Release Process
+
+This document describes the end-to-end process for handling security vulnerabilities in OpenSearch, from initial report through patch release and public disclosure.
+
+## Overview
+
+```
+Report → Triage → Private Fix → Review → Patch Release → Public Disclosure
+```
+
+The [Security Response Team (SRT)](README.md#security-response-team-srt) coordinates each phase. The [Security TAG](README.md#security-tag) advises on severity and release decisions.
+
+## 1. Report Intake
+
+A vulnerability report arrives through one of two channels:
+
+- **Email**: security@opensearch.org
+- **GitHub Security tab**: Private vulnerability reporting on any `opensearch-project` repository
+
+See [INTAKE.md](INTAKE.md) for the full intake process.
+
+Within **48 hours** of receipt, an SRT member will:
+
+1. Acknowledge the report to the reporter.
+2. Create a tracking entry on the vulnerability tracking board with status **Triage**.
+3. Assess whether the report is valid and determine the affected repository/component.
+
+## 2. Triage
+
+The SRT evaluates the report and assigns a severity using [CVSS 3.1](https://www.first.org/cvss/v3.1/specification-document) via the [CVSS Calculator](https://www.first.org/cvss/calculator/3.1).
+
+| Severity | CVSS Score | Typical Response |
+| --- | --- | --- |
+| Critical | 9.0–10.0 | Out-of-band patch release |
+| High | 7.0–8.9 | Out-of-band if next release is >4 weeks away; otherwise next scheduled release |
+| Medium | 4.0–6.9 | Next scheduled release |
+| Low | 0.1–3.9 | Next scheduled release |
+
+For Critical issues, an out-of-band release is expected regardless of effort. For High issues, the Security TAG evaluates whether the time-to-next-release justifies the cost of an out-of-band patch. Factors include active exploitation, availability of mitigations, and the current [patching effort constraints](https://github.com/opensearch-project/opensearch-build/issues/5720).
+
+The SRT will:
+
+1. Confirm the vulnerability and its scope.
+2. Reserve a CVE ID if one has not already been assigned.
+3. Create a [Draft GitHub Security Advisory (GHSA)](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/creating-a-repository-security-advisory) on the affected repository.
+4. Negotiate an [embargo timeline](EMBARGO_POLICY.md) with the reporter.
+5. Update the tracking board status to **In Review**.
+
+## 3. Fix Development
+
+Once triage is complete, the SRT organizes a Fix Team:
+
+1. **Identify contributors**: The SRT identifies maintainers and contributors from the affected component who will develop the fix.
+2. **Request a temporary private fork**: An [`opensearch-admin`](https://github.com/orgs/opensearch-project/teams/opensearch-admin) member creates a temporary private fork from the Draft GHSA. The Fix Team members are added as collaborators. See [PRIVATE_FIX_GUIDELINES.md](PRIVATE_FIX_GUIDELINES.md).
+3. **Develop the fix**: The Fix Team works in the private fork. All commits must follow the [commit message guidelines](PRIVATE_FIX_GUIDELINES.md#commit-message-hygiene) — no security-signaling language.
+4. **Review**: The fix is reviewed by at least one other maintainer of the affected component within the private fork.
+5. Update the tracking board status to **Pending Release**.
+
+### Timeline Targets
+
+| Phase | Target |
+| --- | --- |
+| Triage complete | 7 days from report |
+| Fix developed and reviewed | 14 days from triage |
+| Patch released | Aligned with [release calendar](https://opensearch.org/releases/) or out-of-band |
+
+These are targets, not hard deadlines. The SRT adjusts based on severity and complexity.
+
+## 4. Release
+
+OpenSearch releases on a [regular cadence](https://opensearch.org/releases/). Security fixes are included in the next scheduled release when possible.
+
+### Disclosure Timing
+
+GHSAs and CVEs are published only after patched artifacts are available to users. This means:
+
+- The advisory is **not published when the fix is merged** — it is published when the release containing the fix is out.
+- If a fix lands in `main` but the next minor release is weeks away, the advisory remains in draft until that release ships.
+- Engineers and reporters should expect that disclosure is tied to the [release calendar](https://opensearch.org/releases/), not to when the code fix is ready.
+
+This policy exists to protect users: publishing an advisory before a patched version is available tells adversaries about the issue without giving users a way to protect themselves.
+
+### Patching Constraints
+
+Today, producing a patch release (e.g., `2.x.1`) across the full OpenSearch distribution requires significant coordination effort across all components. Historically, the project has only shipped a small number of patch releases (see [opensearch-build#5720](https://github.com/opensearch-project/opensearch-build/issues/5720) for ongoing discussion).
+
+This means that for Medium and Low severity issues, fixes typically ship in the next scheduled minor release rather than as an immediate patch.
+
+The project is working toward more flexible component-level patching — plugins carry a 4th digit in their semver (e.g., `2.19.0.1`) that could enable individual plugin patches without a full distribution release. As this capability matures, the SRT will update this process to take advantage of it.
+
+### Out-of-Band Releases
+
+For Critical severity issues, the Security TAG will recommend an out-of-band patch release to the [Technical Steering Committee (TSC)](https://github.com/opensearch-project/technical-steering-committee). An out-of-band release requires TSC sign-off.
+
+For High severity issues, the Security TAG evaluates whether an out-of-band release is warranted based on:
+
+- **Time to next release**: If the next scheduled release is more than 4 weeks away, an out-of-band release is strongly recommended.
+- **Active exploitation**: Evidence of exploitation in the wild triggers an immediate out-of-band release regardless of severity.
+- **Mitigation availability**: If a configuration change or workaround effectively neutralizes the risk, the fix may ride the next scheduled release.
+- **Patching effort**: Full distribution patch releases currently require [significant coordination](https://github.com/opensearch-project/opensearch-build/issues/5720). The TAG weighs this cost against the risk of waiting.
+
+### Release Day
+
+1. The Fix Team merges the private fork into the affected repository's release branch. Merges should be timed to minimize the window between merge and release.
+2. Release managers build and publish the patched version.
+3. The SRT updates the tracking board status to **Verified Fix**.
+4. Once the patched version is publicly available, the SRT updates the tracking board to **Ready for Publication**.
+
+## 5. Public Disclosure
+
+After patches are available, the SRT publishes the advisory:
+
+1. **Notify the pre-disclosure list** at least 24 hours before the public announcement ([template](comms-templates/release-day-headsup-email.md)).
+2. **Publish the GHSA**: The Draft GHSA is published on the affected repository, which automatically requests a CVE from GitHub's CNA.
+3. **Announce** via all public channels:
+   - [OpenSearch Forum — Security](https://forum.opensearch.org/c/security/) ([template](comms-templates/vulnerability-announcement-forum.md))
+   - The `#security` channel on [OpenSearch Slack](https://opensearch.org/slack.html) ([template](comms-templates/vulnerability-announcement-slack.md))
+   - Email announcement ([template](comms-templates/vulnerability-announcement-email.md))
+   - The project's release notes
+
+See the [comms-templates](comms-templates/) directory for all templates used throughout this process.
+
+## 6. Post-Disclosure
+
+- If new information emerges, the SRT updates the published GHSA.
+- The SRT conducts a brief retrospective for Critical and High severity issues to identify process improvements.
+- Lessons learned are shared with the Security TAG.
+
+## Publicly Known Vulnerabilities
+
+If a vulnerability is already publicly known (e.g., a CVE in a dependency), there is no need for an embargo. Anyone may open a public GitHub issue to discuss it. The SRT will still coordinate the fix and track it on the board.
+
+## Infrastructure and CI/CD Vulnerabilities
+
+Not all security issues affect the official released artifacts. Vulnerabilities in the project's CI/CD infrastructure, build pipelines, GitHub Actions workflows, or other tooling are handled through the same SRT process but disclosed differently:
+
+- **Product repos** (e.g., `OpenSearch`, `OpenSearch-Dashboards`, `security`): GHSAs and CVEs are published on the affected repo. This signals that the official artifacts for that repo are impacted and users should upgrade.
+- **Infrastructure issues**: GHSAs are published on the `security-response` repository (or another dedicated repo) since the released binaries are not directly affected. These advisories are still important for transparency and for anyone running similar infrastructure.
+
+The SRT will determine the appropriate repo for disclosure during triage based on whether end-user artifacts are impacted.
+
+## Summary Flowchart
+
+```
+┌─────────────┐
+│   Report     │  email or GitHub Security tab
+└──────┬──────┘
+       ▼
+┌─────────────┐
+│   Triage     │  SRT confirms, scores CVSS, reserves CVE, creates Draft GHSA
+└──────┬──────┘
+       ▼
+┌─────────────┐
+│  Private Fix │  temporary private fork, Fix Team develops and reviews
+└──────┬──────┘
+       ▼
+┌─────────────┐
+│   Release    │  merge fix, build and publish patched version
+└──────┬──────┘
+       ▼
+┌─────────────┐
+│  Disclosure  │  publish GHSA/CVE, announce on forum/Slack/release notes
+└─────────────┘
+```
+
+## FAQ
+
+### Why hasn't the GHSA/CVE been published yet if the fix is already merged?
+
+GHSAs and CVEs are published only after patched artifacts (official binaries) are available. Publishing an advisory before users can upgrade exposes the issue without giving them a way to protect themselves. If the fix is merged but the next release hasn't shipped yet, the advisory stays in draft.
+
+### Can we do a patch release just for a security fix?
+
+Out-of-band patch releases require a recommendation from the Security TAG and sign-off from the TSC. For Critical issues, an out-of-band release is expected. For High issues, the TAG evaluates whether the time-to-next-release, active exploitation, and mitigation availability justify the [patching effort](https://github.com/opensearch-project/opensearch-build/issues/5720). For Medium and Low, fixes ride the next scheduled release.
+
+### Can a single plugin ship a security patch independently?
+
+Plugins carry a 4th semver digit (e.g., `2.19.0.1`) that could enable this, but the project doesn't currently use it for independent patch releases. This is an area of active improvement. As component-level patching matures, the SRT will update this process.
+
+### I'm a reporter — when will I hear back?
+
+Within 48 hours of your report. See [INTAKE.md](INTAKE.md) for the full timeline.
+
+### Who decides if an issue warrants an out-of-band release?
+
+The Security TAG makes a recommendation to the TSC based on severity, active exploitation, and availability of mitigations. The TSC makes the final call.
diff --git a/comms-templates/non-vuln-response.md b/comms-templates/non-vuln-response.md
new file mode 100644
index 0000000..8b9535c
--- /dev/null
+++ b/comms-templates/non-vuln-response.md
@@ -0,0 +1,23 @@
+# Non-Vulnerability Response
+
+_Use this template when a report to security@opensearch.org is not a security vulnerability._
+
+TO: `$REPORTER_EMAIL`
+
+SUBJECT: `Re: $ORIGINAL_SUBJECT`
+
+---
+
+Thank you for your message.
+
+After review, this report does not appear to describe a security vulnerability. Consider one of these public channels instead:
+
+- OpenSearch Forum: https://forum.opensearch.org/
+- Open an issue: https://github.com/opensearch-project/OpenSearch/issues/new/choose
+- OpenSearch Slack: https://opensearch.org/slack.html
+
+If you believe we have made an error in this assessment, please reply to this email with additional details.
+
+Thank you,
+
+The OpenSearch Security Response Team
diff --git a/comms-templates/predisclosure-announcement-email.md b/comms-templates/predisclosure-announcement-email.md
new file mode 100644
index 0000000..a41f439
--- /dev/null
+++ b/comms-templates/predisclosure-announcement-email.md
@@ -0,0 +1,55 @@
+# Pre-Disclosure List Security Advisory Email
+
+_Use this template to notify pre-disclosure list members of upcoming security fixes before they become public. Pre-disclosure list members receive this advisory ahead of the official release so they can prepare their teams and environments._
+
+_This template is only used for private issues under embargo — not for publicly known 0-days._
+
+TO: `$PRE_DISCLOSURE_LIST`
+
+SUBJECT: `[EMBARGOED] OpenSearch Security Pre-Disclosure — $RELEASE_VERSIONS`
+
+---
+
+Hello,
+
+As part of the OpenSearch project's security pre-disclosure process, we are contacting you regarding an upcoming advisory as a courtesy before it becomes public in our next release(s).
+
+In the next few weeks, we will be releasing $RELEASE_VERSIONS_AND_DATES, which include a fix for $NUMBER_OF_ISSUES security issue(s). The accompanying advisory/advisories for these issues are enclosed below. Please be sure to notify your technical teams if you feel that your organization may be affected so that they can apply the fixes as soon as they become available.
+
+---
+
+<!-- Repeat this block for each advisory -->
+
+### ADVISORY: $ADVISORY_TITLE
+
+| | |
+| --- | --- |
+| **CVSS Score** | $CVSS_SCORE ($SEVERITY) |
+| **CVSS Vector** | $CVSS_VECTOR |
+| **CVE ID** | $CVE (if assigned) |
+| **Affected Versions** | $AFFECTED_VERSIONS |
+| **Patched Versions** | $PATCHED_VERSIONS |
+
+**Impact:**
+
+$IMPACT_DESCRIPTION
+
+**Mitigation:**
+
+$MITIGATION_DESCRIPTION
+
+---
+
+<!-- End repeating block -->
+
+### Embargo
+
+This information is under [embargo](https://github.com/opensearch-project/security-response/blob/main/EMBARGO_POLICY.md) until the public release date(s) listed above. Please do not share the details of these advisories outside of your organization's security and engineering teams until the embargo is lifted.
+
+### Questions
+
+If you have any questions or comments about this advisory, please contact the OpenSearch Security Response Team at security@opensearch.org. Please do **not** create a public GitHub issue.
+
+Thank you,
+
+$SRT_MEMBER on behalf of the OpenSearch Security Response Team
diff --git a/comms-templates/release-day-headsup-email.md b/comms-templates/release-day-headsup-email.md
new file mode 100644
index 0000000..eb0a341
--- /dev/null
+++ b/comms-templates/release-day-headsup-email.md
@@ -0,0 +1,25 @@
+# Release Day Heads-Up — Pre-Disclosure List
+
+_Send this to the pre-disclosure list at least 24 hours before the public announcement._
+
+TO: `$PRE_DISCLOSURE_LIST`
+
+SUBJECT: `[HEADS UP] Security release scheduled for $DATE`
+
+---
+
+Hello,
+
+This is a notification that OpenSearch will publish a security release on **$DATE** at approximately **$TIME UTC**.
+
+The release will include fixes for the following advisory/advisories:
+
+- **$CVE**: $SUMMARY ($SEVERITY)
+
+The public announcement will be posted to the [OpenSearch Forum](https://forum.opensearch.org/c/security/), [OpenSearch Slack](https://opensearch.org/slack.html) `#security`, and the affected repository's GHSA.
+
+The embargo will be lifted at the time of the public announcement.
+
+Thank you,
+
+$SRT_MEMBER on behalf of the OpenSearch Security Response Team
diff --git a/comms-templates/report-acknowledgment-email.md b/comms-templates/report-acknowledgment-email.md
new file mode 100644
index 0000000..558f917
--- /dev/null
+++ b/comms-templates/report-acknowledgment-email.md
@@ -0,0 +1,23 @@
+# Report Acknowledgment Email
+
+_Use this template to acknowledge receipt of a new vulnerability report._
+
+TO: `$REPORTER_EMAIL`
+
+SUBJECT: `Re: $ORIGINAL_SUBJECT`
+
+---
+
+Hello,
+
+Thank you for reporting this issue to the OpenSearch Security Response Team.
+
+We have received your report and will begin our assessment. You can expect an update from us within the next few business days with our initial findings.
+
+In the meantime, please let us know if you have any additional information, such as reproduction steps, affected versions, or a suggested fix.
+
+We will work with you to agree on a disclosure timeline per our [embargo policy](https://github.com/opensearch-project/security-response/blob/main/EMBARGO_POLICY.md).
+
+Thank you,
+
+$SRT_MEMBER on behalf of the OpenSearch Security Response Team
diff --git a/comms-templates/vulnerability-announcement-email.md b/comms-templates/vulnerability-announcement-email.md
new file mode 100644
index 0000000..61c346b
--- /dev/null
+++ b/comms-templates/vulnerability-announcement-email.md
@@ -0,0 +1,59 @@
+# Vulnerability Announcement Email
+
+_Use this template for publicly disclosing security vulnerabilities via email and the OpenSearch Forum._
+
+_The email should be concise and actionable. Assume the audience are OpenSearch operators, not developers. Technical details should be deferred to the GHSA._
+
+TO: `$ANNOUNCEMENT_LIST`
+
+SUBJECT: `[Security Advisory] $CVE: $SUMMARY`
+
+---
+
+Hello OpenSearch Community,
+
+A security issue was discovered in $COMPONENT that $SUMMARY.
+
+This issue has been rated **$SEVERITY** ([CVSS:3.1/$CVSS_VECTOR](https://www.first.org/cvss/calculator/3.1#$CVSS_VECTOR)), and assigned **$CVE**.
+
+### Am I affected?
+
+$HOW_TO_DETERMINE_IF_AFFECTED
+
+#### Affected Versions
+
+- $COMPONENT $VERSION_RANGE_1
+- $COMPONENT $VERSION_RANGE_2
+
+### How do I fix this?
+
+Upgrade to one of the following fixed versions:
+
+- $COMPONENT $FIXED_VERSION_1
+- $COMPONENT $FIXED_VERSION_2
+
+To upgrade, refer to the [OpenSearch documentation](https://opensearch.org/docs/latest/install-and-configure/upgrade-opensearch/index/).
+
+<!-- If additional steps are required after upgrade -->
+**ACTION REQUIRED:** After upgrading, the following steps must be taken: $STEPS
+
+<!-- If a mitigation is available before upgrading -->
+Prior to upgrading, this issue can be mitigated by $MITIGATION.
+
+### Detection
+
+$DETECTION_GUIDANCE
+
+If you find evidence that this issue has been exploited, please contact security@opensearch.org.
+
+### Additional Details
+
+See the full advisory: $GHSA_URL
+
+### Acknowledgments
+
+This issue was reported by $REPORTER.
+
+Thank you,
+
+$SRT_MEMBER on behalf of the OpenSearch Security Response Team
diff --git a/comms-templates/vulnerability-announcement-forum.md b/comms-templates/vulnerability-announcement-forum.md
new file mode 100644
index 0000000..c79ba87
--- /dev/null
+++ b/comms-templates/vulnerability-announcement-forum.md
@@ -0,0 +1,28 @@
+# Vulnerability Announcement — Forum Post
+
+_Post this to the [OpenSearch Forum — Security](https://forum.opensearch.org/c/security/) category._
+
+TITLE: `[Security Advisory] $CVE: $SUMMARY`
+
+---
+
+A security issue was discovered in **$COMPONENT** that $SUMMARY.
+
+| | |
+| --- | --- |
+| **Severity** | $SEVERITY |
+| **CVSS Score** | [$CVSS_VECTOR](https://www.first.org/cvss/calculator/3.1#$CVSS_VECTOR) |
+| **CVE** | $CVE |
+| **Affected Versions** | $VERSION_RANGE |
+| **Fixed Versions** | $FIXED_VERSIONS |
+
+### What should I do?
+
+Upgrade to a fixed version. See the full advisory for details: $GHSA_URL
+
+<!-- If a mitigation is available -->
+If you cannot upgrade immediately, you can mitigate this issue by $MITIGATION.
+
+### Acknowledgments
+
+This issue was reported by $REPORTER.
diff --git a/comms-templates/vulnerability-announcement-slack.md b/comms-templates/vulnerability-announcement-slack.md
new file mode 100644
index 0000000..b1c80b2
--- /dev/null
+++ b/comms-templates/vulnerability-announcement-slack.md
@@ -0,0 +1,13 @@
+# Vulnerability Announcement — Slack
+
+_Post this to the `#security` channel on [OpenSearch Slack](https://opensearch.org/slack.html)._
+
+---
+
+:rotating_light: **Security Advisory** — The Security Response Team has published an advisory for $COMPONENT that $SUMMARY. This issue has been rated **$SEVERITY** and assigned **$CVE**. Please see $GHSA_URL for details and upgrade instructions.
+
+---
+
+_Example:_
+
+:rotating_light: **Security Advisory** — The Security Response Team has published an advisory for OpenSearch that could allow unauthorized access to cluster state via a crafted API request. This issue has been rated **High** and assigned **CVE-2026-XXXXX**. Please see https://github.com/opensearch-project/OpenSearch/security/advisories/GHSA-xxxx-xxxx-xxxx for details and upgrade instructions.