OpenEoX

OpenEoX

Speakers: Shamusaf Roguski (Rogue), Principal Security Engineer, Red Hat

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=4Xg1EwFNC14

Overview

The "OpenEoX" talk, presented by Shamusaf Roguski (known as Rogue), a Principal Security Engineer at Red Hat, introduces a nascent project aimed at standardizing and exchanging product lifecycle data in a machine-readable format. At its core, OpenEoX seeks to address the pervasive problem of ambiguous, inconsistent, and often human-readable product lifecycle information, which currently hinders efficient security, compliance, and product management processes across the software industry.

This initiative is particularly vital in today's complex software supply chain landscape, where understanding the support status of components and products is as critical as identifying vulnerabilities. By providing a clear, automated mechanism for communicating lifecycle phases—from initial release to end-of-life, including nuanced support scopes—OpenEoX promises to enhance transparency, improve risk management, and streamline decision-making for various stakeholders, from security analysts to sales teams. The project endeavors to integrate seamlessly with existing security data standards like SBOMs (Software Bill of Materials) and CSAF (Common Security Advisory Framework) to offer a holistic view of a product's security posture and longevity.

Background

▶ Watch: Introduction to OpenEoX project and agenda (0:00)

The genesis of the OpenEoX project stems from fundamental challenges in how the software industry defines, identifies, and manages its products and their lifecycles. Rogue highlighted that even the basic definition of a "product" is highly contextual and inconsistent across different teams and organizations within a single company like Red Hat. A product might be perceived as a single license, a specific offering with a support model, an upstream repository, a complex bundle of components, or even just a marketing name. This ambiguity creates a significant barrier to effective communication and automated data processing.

While existing methods for product identification, such as CPEs (Common Platform Enumerations), PURLs (Package URLs), SWID tags (Software Identification Tags), and Software Heritage IDs, offer ways to uniquely name software, the critical missing piece is a standardized, machine-readable representation of its lifecycle. Rogue emphasized the paramount importance of product versioning in this context, as it precisely logs the state of software at a particular point in time, including all correlated requirements and dependencies. Red Hat, for instance, adheres to an XYZ semantic versioning model: X for major, backward-incompatible versions; Y for minor, backward-compatible product streams (often multiple supported concurrently); and Z for asynchronous patches within a Y stream. An example given was Red Hat OpenShift Container Platform 4.18.5, where '4' is the major version, '18' is the supported stream, and '5' is the fifth update. Each supported stream is associated with unique CPE IDs.

The core problem OpenEoX aims to solve is the complex and often fragmented nature of product lifecycle data. A product lifecycle is defined as the combination of product versioning and its associated product support model, which comprises vendor-defined maintenance rules from the product's General Availability (GA) date until its End of Life (EOL). This maintenance scope can significantly change over time, encompassing various lifecycle phases such as maintenance support, vulnerability support, or migration support. These phases can be consecutive (where the end of one phase marks the beginning of the next) or overlapping, adding further layers of complexity. The most significant challenge is that this critical lifecycle data is predominantly available in human-readable formats, often buried in web pages or PDF documents, making automated consumption and integration incredibly difficult. Furthermore, different vendors can offer vastly different lifecycles for functionally identical components, or even support a component long after its upstream maintainer has declared it EOL, creating a labyrinth of support statuses that current tools cannot easily navigate.

Key Findings

▶ Watch: Importance of precise product versioning (3:40)

The central finding that underpins the OpenEoX project is the critical need for a standardized, machine-readable format for exchanging product lifecycle data. The current landscape, characterized by diverse interpretations of what constitutes a "product" and lifecycle information primarily confined to human-readable documents, presents significant operational and security challenges. OpenEoX emerges as a proposed solution to this widespread data problem.

Initially conceived to cover only End of Life (EOL) and End of Support (EOS) phases, the project quickly recognized the broader utility and necessity of encompassing a wider array of lifecycle phases. A key objective is to ensure that OpenEoX data can seamlessly integrate and work in conjunction with other security data standards, such as SBOMs (Software Bill of Materials), CSAF (Common Security Advisory Framework), and VEX (Vulnerability Exploitability eXchange). This interoperability is crucial for building a comprehensive understanding of a product's security posture. By linking through common identifiers like CPEs and PURLs, users can leverage an SBOM to see a product's components, a VEX file for its vulnerability status, and OpenEoX data for its current support phase and expected longevity.

This integrated approach offers tangible benefits across various organizational functions:

• Security Teams gain immediate clarity on support status for vulnerable components.
• Support Teams can precisely communicate expected service levels.
• Compliance Teams can automate checks for adherence to support policies.
• Product Planning and Management can make informed decisions about future development and resource allocation.
• Sales and Marketing Teams can accurately convey product longevity and value propositions.

Rogue illustrated the real-world complexity with Red Hat OpenShift Container Platform, which simultaneously supports six different product streams. Each stream exists in a different support level or phase, with distinct end dates, making it an arduous task for an end-user to programmatically ascertain the current status of a particular stream. OpenEoX aims to represent this intricate information in an "easy and precise way," transforming manual data collection into a fast and automated process, thereby providing a clear, unambiguous source of truth for product lifecycle information.

Technical Deep Dive

▶ Watch: Defining product life cycle and support model (6:10)

The OpenEoX project proposes a structured, machine-readable format to encapsulate complex product lifecycle data. While no specific format (like JSON or XML schema) was formally presented, the talk outlined the essential elements and their relationships within an OpenEoX document, providing a conceptual blueprint for its data structure.

A core OpenEoX data representation for a product would include:

• Product Identifier: A unique identifier (UID) for the product.
• Product Type: Categorization of the product (e.g., "cloud product," "business unit"), which can be crucial for internal Red Hat classifications.
• Parent Product: Information linking to a higher-level product (e.g., a specific OpenShift version might list Red Hat Enterprise Linux as its parent).
• Phases List: A comprehensive list of all defined lifecycle phases applicable to the product. Each phase would have precise details regarding its scope and associated rules.
• Versions List: An enumeration of all existing versions for the product. Each version would be uniquely identified by a CPE ID. For each version, additional metadata would include:
• Links to the previous and next versions.
• The current lifecycle phase it is in at a given moment.
• The associated end date for that specific phase.

A critical aspect of OpenEoX is the detailed definition of lifecycle phases. As demonstrated by the speaker, each phase (e.g., "GA date," "End of Full Support") is not merely a label but includes a precise scope. This scope, represented as an array of multiple selections, dictates what is included or provided during that phase. For instance, a phase might explicitly state it includes "new features," "bug fixes," and crucially, "security patches." The granularity of security patch information is a significant technical contribution, allowing vendors to specify support based on vulnerability severity. An example given was a vendor declaring that for a specific product version in a particular phase, "only critical security updates" would be released, providing an unambiguous expectation for customers. This level of detail empowers users to understand exactly what kind of support they can expect at any given point in a product's lifecycle.

The project is still in its early stages, and several technical challenges are being actively discussed:

• Universal Taxonomy: Developing a taxonomy that can cater to the diverse requirements of all potential users and product types.
• Scope vs. Granularity: Deciding whether a single, broad scope interpretation for a phase is sufficient, or if a more granular phase definition combined with a detailed scope array is preferable.
• Date Representation: Determining if date ranges are necessary for phases or if a single end date is sufficient, potentially inferring start dates from the end of the previous phase.

Internally at Red Hat, additional challenges include:

• Cross-Organizational Adoption: Ensuring consistent usage of the OpenEoX standard across all internal teams.
• Customization Scope: Defining the boundaries between internal-only lifecycle data and the information that should be made public, addressing privacy and proprietary concerns.

Ultimately, OpenEoX aims to serve as the missing contextual layer that clarifies existing security data. While SBOMs list components and CSAF/VEX files detail vulnerabilities, they often lack the crucial "what exactly it is" context and the associated support promises. OpenEoX provides this by defining the product, its vendor, its type, its full lifecycle, and the explicit commitments made within each phase, offering a single source of truth for product longevity and support.

Demo / Proof of Concept

▶ Watch: The problem: Life cycle data in human-readable formats (9:00)

While no live software demonstration or interactive proof-of-concept tool was presented during the talk, the speaker effectively illustrated the core concepts of OpenEoX through conceptual examples and real-world scenarios.

Rogue provided a screenshot from Red Hat's public web page detailing the lifecycle of Red Hat OpenShift Container Platform. This image served as a powerful visual representation of the current problem: six different OpenShift streams supported simultaneously, each in a unique support phase with varying end dates. This manual, human-readable format underscored the complexity and the difficulty of programmatically extracting precise lifecycle information.

Following this, Rogue presented a conceptual example of how the same complex lifecycle data could be represented in a structured, machine-readable OpenEoX format. This example, though not tied to a specific schema (like JSON or YAML), outlined the key data fields: a product identifier, product type, parent product information, a list of all defined lifecycle phases with their scopes, and a list of versions identified by CPE IDs, each linking to its current phase and associated end date (e.g., OpenShift 4.12 in "end of extended support" until January 2026). The detailed phase definition included a scope array, illustrating how specific support elements like "new features," "bug fixes," and even "security patches" (distinguished by CVE severity level) could be precisely defined for each phase.

These illustrative examples, rather than a functional demo, served to articulate the project's vision, demonstrate the current challenges, and highlight how OpenEoX proposes to bring clarity and automation to a historically opaque and manual process.

Defensive Implications

▶ Watch: Vendor-specific life cycles for similar products (9:40)

The advent of OpenEoX carries profound implications for cybersecurity defenders, offering a critical missing piece in the puzzle of comprehensive risk management and supply chain security. By standardizing machine-readable product lifecycle data, OpenEoX empowers defenders to make more informed, proactive, and automated decisions.

1. Enhanced Visibility and Risk Prioritization: Defenders will gain unprecedented visibility into the support status of every product and component within their environment. Knowing the precise lifecycle phase (e.g., "full support," "extended support," "end of vulnerability support," or "end of life") and the explicit scope of maintenance (e.g., "only critical security updates") allows security teams to accurately prioritize vulnerabilities. A critical CVE in an actively supported product receiving full security patches can be treated differently from the same CVE in a product nearing EOL or only receiving limited support. This enables a more intelligent allocation of limited security resources.

1. Proactive Obsolescence Management: OpenEoX data allows organizations to proactively identify products and components approaching their End of Life (EOL) or End of Support (EOS). This foresight is invaluable for planning upgrades, migrations, or implementing compensating controls well in advance, rather than reacting to a sudden lack of vendor support. It minimizes the risk of operating unsupported software, which often becomes a significant attack surface.

1. Automated Compliance and Auditing: Compliance teams can leverage OpenEoX to automate checks for adherence to internal policies and external regulations regarding software support. Systems can be automatically flagged if they are running unsupported software, streamlining auditing processes and reducing manual effort. This machine-readable data provides clear evidence of support status, which is crucial for demonstrating due diligence.

1. Integrated Supply Chain Security: OpenEoX acts as a vital contextual layer when integrated with other supply chain security initiatives like SBOMs and VEX. An SBOM might list a vulnerable component, and a VEX file might state its exploitability, but OpenEoX provides the crucial information about whether the vendor is still patching that specific version. This holistic view is essential for understanding the true risk posture of software obtained from third parties. For example, if an SBOM identifies a vulnerable dependency, OpenEoX can immediately tell a defender if the product containing that dependency is still receiving security patches for that specific vulnerability level.

1. Improved Vendor Relationship Management: The standardized format facilitates clearer communication and expectation setting with vendors. Defenders can easily query and integrate vendor-provided OpenEoX data into their systems, reducing ambiguities about support timelines and deliverables. This transparency fosters more robust vendor relationships and accountability.

1. Resource Allocation and Strategy: By providing a clear picture of product longevity and support commitments, OpenEoX assists security leaders in strategic planning. It helps inform decisions about technology investments, retirement plans, and where to focus defensive efforts to maximize impact against evolving threats.

In essence, OpenEoX moves the industry beyond merely identifying vulnerabilities to understanding the full context of a product's life, enabling defenders to shift from reactive firefighting to proactive, data-driven security strategies.

Key Takeaways

• Standardized Lifecycle Data: OpenEoX aims to create a universal, machine-readable standard for exchanging product lifecycle information, moving away from fragmented, human-readable formats.
• Addresses Product Ambiguity: The project tackles the fundamental problem of inconsistent product definitions and provides a clear "single source of truth" for what a product is, its vendor, and its support commitments.
• Crucial for Holistic Security: OpenEoX is designed to integrate seamlessly with existing security data standards like SBOMs, CSAF, and VEX, providing essential context about product support status to enhance overall security posture.
• Granular Support Definitions: The standard allows for precise definition of lifecycle phases, including the specific scope of maintenance (e.g., new features, bug fixes), and critically, the ability to specify security patch levels based on vulnerability severity (e.g., only critical updates).
• Automation and Efficiency: The primary goal is to enable fast, automated gathering of product lifecycle data for various teams, including security, compliance, support, and product management, streamlining operations and improving decision-making.
• Early Development Stage: OpenEoX is currently in its early stages of development, with ongoing discussions about universal taxonomy, phase granularity, and internal/external data management challenges, particularly at Red Hat.

About the Speaker(s)

Shamusaf Roguski, who prefers to be called Rogue, is a Principal Security Engineer at Red Hat. His work focuses on critical security aspects within the software product lifecycle, and he is a key driver behind initiatives like the OpenEoX project, aiming to improve data representation and exchange in the security domain.