Initial commit adding Security TAG policies

.github/CODEOWNERS

@@ -0,0 +1,2 @@
+# Default: Security TAG members review all changes
+* @cwperks @nibix @aparajita31pandey @kumargu @kkhatua @willyborankin @shikharj05 @jochen-kressin

.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

.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)

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

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.