2026-06-09

152 Repositories, 60 Days, One Audit Trail: How the OpenSearch LTS Program Addresses Enterprise Compliance

How OpenSearch is evolving to meet the security and compliance demands of modern enterprises.

Reading time: 4 minutes

By Alannah Melly

152. That’s the number of OpenSearch repositories now being scanned to generate Software Bills of Materials under the new OpenSearch LTS program.

For most engineering teams, that number means little in isolation. For the security, compliance, and legal teams working alongside them, it represents something they have been asking for since OpenSearch first appeared in enterprise production environments: a formal, auditable record of what is actually running in the stack.

Why Compliance Has Been Difficult for OpenSearch Until Now

Open source software presents a structural challenge for enterprise compliance teams. The flexibility and community governance that make platforms like OpenSearch attractive are, from a compliance perspective, also sources of uncertainty. There is no vendor contract specifying a patch timeline. There is no single accountable entity for a vulnerability response. There is no standardised artefact to hand to an auditor proving the provenance and security posture of the software in production.

These gaps have become more consequential as regulatory frameworks have tightened. The EU’s Cyber Resilience Act (CRA) sets mandatory cybersecurity requirements for products with digital elements — including obligations to address vulnerabilities promptly and provide documentation of component provenance. For organisations using open source infrastructure in regulated environments, informal community governance structures are increasingly insufficient on their own.

The OpenSearch LTS program was designed in direct response to this pressure.

The Three Compliance Pillars of the LTS Program

SBOM Coverage Across the Full Repository Surface

The OpenSearch Software Foundation is scanning all 152 OpenSearch repositories to create a comprehensive library of Software Bills of Materials. An SBOM is a formal, machine-readable inventory of the components that make up a piece of software — every library, dependency, and sub-component, with version information and provenance. For organisations subject to the CRA or internal supply chain security requirements, SBOMs are increasingly a baseline expectation, not an optional extra. The LTS program makes them available across the entire OpenSearch codebase for the first time.

A Hard CVE Remediation SLA

The program establishes a 60-day maximum window for addressing medium and high-severity vulnerabilities from the point of public disclosure. This is a formal commitment, not a community aspiration. Accredited providers are also given early security vulnerability notifications — before CVEs are published — meaning that for customers working with an accredited provider like Eliatra, patching work can begin before the vulnerability is widely known.

This directly addresses one of the most common compliance blockers for open source infrastructure: the inability to commit to a vulnerability response timeline in a risk register or security contract.

Upstream-First Development

A condition of vendor accreditation is that all fixes and patches developed for an LTS version must be contributed back to the upstream open source project. This prevents the fragmentation that occurs when commercial vendors maintain private patched branches — a situation that makes auditing and supply chain verification significantly harder. Under the LTS program, there is one codebase, maintained in the open.

What This Looks Like in an Audit

Before the LTS program, organisations running OpenSearch in regulated environments often faced several compliance challenges:

copy

- No clearly accountable vendor responsible for patching

- No formal SLA for CVE remediation

- No comprehensive inventory of software components

- No guaranteed support lifecycle for deployed versions

- No formal vendor accreditation or accountability framework

With Eliatra LTS, organisations gain:

copy

- Support from a Foundation-accredited provider

- A maximum 60-day remediation window for medium and high-severity vulnerabilities

- Access to SBOMs covering all 152 OpenSearch repositories

- A minimum 18-month lifecycle for each LTS release

- Foundation vetting and accreditation for greater accountability and trust

Eliatra and Compliance-Ready LTS Support

As a Foundation-accredited LTS provider and founding member of the OpenSearch Software Foundation, Eliatra delivers support that directly maps to these compliance requirements. Our customers receive early vulnerability notifications, patching within the 60-day SLA, and access to SBOM artefacts for their OpenSearch deployments.

For organisations in regulated industries — financial services, healthcare, critical infrastructure, public sector — or those facing CRA obligations, this changes the conversation around OpenSearch from “can we use this?” to “here’s the documentation.”

OpenSearch 2.19 and 3.6 are the first designated LTS releases. If your organisation is planning a compliance review or upcoming audit and needs to formalise your OpenSearch support posture, now is the right time to engage.

“Our customers run OpenSearch in production environments where a surprise CVE or an unsupported version is not an option. This program gives that commitment a structure, and gives our customers something they can take to their security teams with confidence.”