/
Discussion about updates of the parent CVE page

Discussion about updates of the parent CVE page

Table of Contents

Scope

This page should guide the discussions around CVEs and it handling to update the parent page.

Situation

It is not realistically possible to prevent someone from creating a CVE (Common Vulnerabilities and Exposures) report against code published under the O-RAN Software Community (O-RAN-SC). The process of reporting CVEs is open and cannot be controlled or influenced by O-RAN-SC.

CVEs are not inherently negative - in fact, they provide transparency and can help guide secure software development efforts.

However, within O-RAN-SC, many code artifacts are created specifically to:

  • Drive the development of requirements within the O-RAN Alliance specifications, or

  • Serve as pre-specification prototypes.

Such code is not designed or intended for use in commercial products. As a result, CVEs reported against this type of code are often misleading or irrelevant when evaluated in the context of product security.

Unfortunately, this distinction is not always visible to downstream users of the code. This creates a gap in clarity and expectations, which should be addressed.

Proposal

We propose that repositories or specific code directories be explicitly tagged or marked to indicate that the code is not intended for production use.

This is particularly important unless a contributor or project chooses to invest effort into hardening and maintaining the code for potential product use.

To improve transparency for all kinds of users - both humans and automated systems—this tagging should be implemented in two complementary ways:

  1. Human-readable:

    • Add a file like NOT_DESIGNED_FOR_PRODUCTION.md

    • Include visible notices in README.md

    • Use badge-style labels in documentation

  2. Machine-readable:

    • Introduce a structured file such as repo-metadata.yaml

    • Add semantic tags in CI/CD metadata or tooling descriptors

    • Annotate repositories with standardized labels if supported

By distinguishing between production-grade and pre-specification code, we help consumers, integrators, auditors, and automation systems make informed decisions and avoid misinterpretations, especially regarding CVE relevance.Tag for humans

Human-readable

A file next in the root of a repository or in a directory should indicate the status and the intention of the code including its expected CVE handling. The filename and the text in the file should be always the same.

Filename: NOT_DESIGNED_FOR_PRODUCTION.md

Content if the file in Markdown format:

Start of file: NOT_DESIGNED_FOR_PRODUCTION.md

⚠️ NOT DESIGNED FOR PRODUCTION

This component, module, or repository is not intended for production use.

Purpose

The code contained here is provided as a pre-specification reference implementation and is meant to support the development and validation of technical requirements under discussion within the O-RAN Alliance. It may be used for prototyping, research, and early feedback, but:

  • It is not complete,

  • It may not conform to finalized specifications,

  • It may contain known or unknown security vulnerabilities,

  • It is not monitored for CVEs, and

  • It receives no guarantee of support, updates, or fixes.

Disclaimer

This software is made available as-is and without warranty of any kind.
Use in production systems is strongly discouraged.
Any use in products or deployments is at the user's own risk.

For production-grade implementations, please consult finalized O-RAN specifications and implementations that explicitly state compliance and maintenance support.

© [YEAR] [Your Organization / Project Name] - Licensed under the terms in the LICENSE file.

End Start of file: NOT_DESIGNED_FOR_PRODUCTION.md

It would be beneficial to add a link to such file in the README.md of the repository.

Machine-readable

The format Markdown is not very useful for tooling and automated scanning, there for a yaml file should be used:
Filename: .repo-metadata.yaml

Content example of the file in yaml format:

# Metadata for O-RAN-SC Experimental Repository repo: name: o-ran-sc/<your-repo-name> status: experimental production_ready: false pre_spec: true description: > This repository contains prototype code developed under the O-RAN Software Community (O-RAN-SC) for exploring features described in early O-RAN Alliance drafts. It is not intended for production use. compliance: cve_handling: false license: Apache-2.0 support_committee: RSAC maintainer_policy: community-driven security_contact: none tags: - pre-spec - not-for-production - experimental - no-cve-support visibility: warning_banner: true NOT_DESIGNED_FOR_PRODUCTION.md: present

 

The status could be also reflected as GitHub Topic (Tag)

  • pre-spec

  • not-for-production

  • experimental

  • prototype

  • draft

As Linux Foundation Gerrit doesn’t support UI tags like GitHub, but you can adopt the following strategy:

Add a banner badge in README.md

Gerrit displays the repo content on the Gitweb view, and contributors browsing the repo or cloning it will see the badge.

# Experimental O-RAN-SC Module ![Status: Not for Production](https://img.shields.io/badge/status-not--for--production-red) ![Status: Experimental](https://img.shields.io/badge/CVE%20Support-none-lightgrey) > This repository is pre-spec and not intended for production use. No CVE remediation or production guarantees apply.

You can host the badge with https://shields.io (which doesn’t require GitHub).

Add a comment to .gitreview

The .gitreview file (used by Gerrit for change submission) could include a comment like:

[gerrit] host=gerrit.o-ran-sc.org port=29418 project=o-ran-sc/<repo-name>.git # ⚠️ This repository is pre-spec and not intended for production use.

Not a formal mechanism, but helps contributors see the status when cloning or using git review.