How the OpenSearch LTS Program Works: A Technical Look at Lifecycles, Patching, and Accreditation

The OpenSearch Software Foundation’s LTS program is well documented at the announcement level. What gets less coverage is how it actually operates — how versions are selected for LTS designation, what the patching workflow looks like from vulnerability disclosure to release, how the SBOM pipeline is structured, and what the accreditation process requires of providers. This post covers the mechanics.

OpenSearch follows semantic versioning. Minor versions are released approximately every eight weeks and include all features and fixes that have cleared the exit criteria at the point the release window opens. Major versions are released when breaking changes are unavoidable. The LTS program sits on top of this cadence rather than replacing it.

The Foundation designates at least one minor version per major release as an LTS version. The selection criteria prioritise stability over feature density — an LTS release is one that has cleared a higher bar for quality and compatibility testing than a standard minor release. The first designated LTS versions are 2.19 (from the 2.x line, released February 2025) and 3.6 (from the 3.x line, released April 2026). The designation is made by the Foundation, not by individual accredited providers, which is what gives it vendor-neutral standing.

Once a version is designated LTS, it enters a support window of at least 18 months. During this window it continues to receive bug fixes and security patches. It does not receive new features — that distinction matters for operators who want a stable target without the churn of a moving feature surface.

The security workflow under the LTS program is more structured than the standard community disclosure process, and the difference is meaningful for enterprise operators.

When a vulnerability is identified that affects an LTS version, accredited providers receive notification before it is publicly disclosed. This is a pre-disclosure window — not just an early heads-up, but an active period during which providers can begin assessment and patch development before the CVE is publicly known. The length of the pre-disclosure window varies depending on severity and coordination requirements, but the intent is that accredited providers have a working patch either complete or well underway by the time a vulnerability becomes public knowledge.

For medium and high-severity vulnerabilities, the LTS program sets a hard 60-day window from public disclosure to the availability of a fix in a supported LTS release. This is an SLA on the Foundation’s accredited provider ecosystem, not on the community release process, which remains best-effort. The SLA applies from the date of public CVE disclosure, not from the date of internal notification — which means the pre-disclosure period effectively extends the time available to prepare a fix before the clock formally starts.

All security fixes developed for an LTS version must be contributed back to the upstream OpenSearch project before or simultaneously with their release to LTS customers. This is enforced as a condition of accreditation. In practice it means patches go through the standard OpenSearch pull request and review process, not through a private patching pipeline. The result is that the security work done under the LTS program is visible to and reviewable by the full OpenSearch community, and the fixes land in the main codebase where they benefit non-LTS users too.

Software Bills of Materials under the LTS program are generated through systematic scanning of OpenSearch’s repository surface. The Foundation is scanning all 152 OpenSearch repositories to produce SBOMs in standard machine-readable formats. This is not a one-time snapshot — the scanning is tied to the release process so that each LTS release is accompanied by a current SBOM reflecting the components in that specific build.

The practical implication for operators is that for each LTS release they run, they can obtain an SBOM that enumerates every library, dependency, and sub-component with version information and provenance. This is the artefact that answers supply chain audit questions and satisfies the component documentation requirements of frameworks like the EU’s Cyber Resilience Act. It is also the artefact that security tooling can ingest to automatically flag when a component in a running deployment has a known vulnerability — which changes vulnerability management from a reactive to a proactive posture.

The accreditation model is how the Foundation vets providers who want to offer commercial LTS support. It is worth understanding what accreditation actually requires, because it is more substantive than a formal registration.

Accredited providers must be members of the OpenSearch Software Foundation. This is not a passive relationship — Foundation members participate in governance, contribute to project direction, and are accountable to the Foundation’s standards. Membership is a precondition, not a consequence, of accreditation.

Providers must demonstrate the capability to deliver against the program’s SLAs — specifically the 60-day CVE remediation window and the upstream-first development requirement. This involves assessment of the provider’s security engineering capacity, their history of contributions to the OpenSearch project, and their ability to participate in the pre-disclosure notification process responsibly. Providers without prior meaningful involvement in the OpenSearch codebase are unlikely to meet this bar.

The no-fork requirement is a continuing obligation of accreditation, not a one-time commitment. Accredited providers must contribute all fixes developed for LTS versions back upstream. The Foundation monitors compliance as part of ongoing accreditation status. A provider who develops private patches and does not contribute them upstream risks losing accreditation. This is what makes the vendor-neutral framing genuine rather than aspirational — the mechanism that enforces it is built into the accreditation terms.

The three founding accredited providers are BigData Boutique, Eliatra, and Resolve Technology. All three were involved in shaping the program structure and have committed to its requirements from the outset. Eliatra’s engineers maintain the Security and Operator repositories for OpenSearch, which is directly relevant to the security patching obligations the accreditation entails. Additional providers can apply for accreditation through the Foundation at opensearch.org/long-term-support.

For operators making a versioning decision today, the practical question is whether to target 2.19 or 3.6. Both carry LTS designation and the same support guarantees. The meaningful differences are:

OpenSearch 2.19 is the stable choice for teams on the 2.x line who cannot yet take a major version upgrade. Its LTS window runs from February 2025, giving it a longer remaining support horizon if you are starting the process now.

OpenSearch 3.6 is the right target for new deployments or teams already planning a 3.x move. It carries the full 3.x feature set including the Observability Stack and the vector search improvements introduced in 3.x, alongside its LTS designation.

There is no requirement to use an accredited provider to benefit from the LTS lifecycle designations — the version support windows are a Foundation commitment. Commercial LTS support from an accredited provider adds the SLA guarantees, pre-disclosure notifications, and SBOM access on top of the baseline lifecycle.

The mechanics described here reflect the program as launched at OpenSearchCon Europe in April 2026. The Foundation publishes full program details at opensearch.org/long-term-support.

Eliatra is a founding accredited provider under the OpenSearch Software Foundation’s LTS program. If you’d like to discuss how the LTS patching workflow or SBOM pipeline applies to your deployment, get in touch today.