pith. sign in

arxiv: 2605.04249 · v1 · submitted 2026-05-05 · 💻 cs.CR · cs.NI

Towards a Zero-Trust Supply-Chain Assurance Rubric for ORAN RIC Applications

Chun Yin Chiu This is my paper

Pith reviewed 2026-05-08 17:34 UTC · model grok-4.3

classification 💻 cs.CR cs.NI
keywords supply chain securityzero trustO-RANRIC applicationsthreat modelprovenanceonboardingassurance levels
0
0 comments X

The pith

An incremental assurance rubric lets operators evaluate supply chains for third-party RIC applications using threat models and evidence checks.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper aims to give network operators a structured method for handling security risks when third-party applications enter Open RAN environments at a rapid pace. It builds this method around a lifecycle view of how applications are built, signed, published, onboarded, run, and updated, then connects those stages to specific evidence that can be verified. If the rubric holds, operators shift from implicit trust to graded checks that combine development practices, material lists, and provenance records into clear acceptance tiers. This matters because frequent app changes expand the points where tampering or substitution can occur across the chain from developer to runtime. The work shows the approach through mappings and example decision flows rather than large-scale measurements.

Core claim

The paper's central claim is that a zero-trust supply-chain assurance rubric for RIC applications can be formed from three elements: an app-centric threat model across build, signing, publication, onboarding, runtime, and update stages; a mapping that links those threats to security controls and supporting evidence; and an operator-facing profile that places secure development practices, software bill of materials transparency, and provenance records into incremental onboarding levels. Analytical case-study walkthroughs and a minimal evidence-checking workflow then demonstrate how the profile supports explicit Accept, Escalate, or Block decisions.

What carries the argument

The operator-facing assurance profile that tiers evidence requirements from basic secure development practices through software bill of materials and provenance records to support graded onboarding decisions.

If this is right

  • Operators gain explicit criteria to decide whether to accept, escalate, or block an application at onboarding time.
  • The rubric applies across the full sequence of stages from application build through runtime updates and rollbacks.
  • Case-study walkthroughs show how evidence from development practices and provenance records can be examined systematically.
  • The profile integrates existing secure development practices with material transparency and provenance records into progressive levels.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same staged threat model and evidence tiers could be tested on other third-party functions that run in disaggregated radio access networks.
  • Automated scanners for the listed evidence types could be built to reduce manual review time while preserving the decision workflow.
  • Running the rubric against documented past supply-chain incidents would reveal whether its levels catch the actual attack paths.

Load-bearing premise

The lifecycle threat model and its mapping to controls and evidence fully cover relevant supply-chain risks, and operators can apply the evidence-checking steps without excessive cost or mistaken outcomes.

What would settle it

A recorded supply-chain attack that reaches a RIC application after it passed the rubric's checks at a given assurance level, with all required evidence present.

Figures

Figures reproduced from arXiv: 2605.04249 by Chun Yin Chiu.

Figure 1
Figure 1. Figure 1: RIC app lifecycle trust boundaries: producer build environment -> signed release -> registry -> operator onboarding -> view at source ↗
Figure 2
Figure 2. Figure 2: Minimal evidence-checking workflow: submission package -> evidence verifier -> policy checker -> assurance score -> view at source ↗
read the original abstract

Open RAN enables third-party xApps and rApps to be onboarded and updated at operational cadence, creating a software supply chain that spans developers, CI systems, registries, onboarding pipelines, and runtime enforcement points. This preprint proposes a zero-trust supply-chain assurance rubric for O-RAN RIC applications. It makes three contributions: first, an app-centric lifecycle threat model for RIC applications across build, signing, publication, onboarding, runtime, and update or rollback stages; second, a WG11-aligned threat-control-evidence mapping that relates lifecycle threats to O-RAN security baselines and complementary supply-chain evidence; and third, an operator-facing assurance profile that combines secure software development practices, SBOM transparency, and SLSA-style provenance into incremental onboarding levels. Analytical case-study walkthroughs and a minimal evidence-checking workflow illustrate how the rubric can support explicit Accept, Escalate, or Block decisions during RIC app onboarding. The evaluation is intended to assess applicability rather than deployment-scale performance; empirical measurements of operational overhead, decision consistency, and detection coverage are left for future work.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 0 minor

Summary. The paper claims to introduce a zero-trust supply-chain assurance rubric for O-RAN RIC applications, consisting of an app-centric lifecycle threat model, a WG11-aligned threat-control-evidence mapping, and an incremental operator-facing assurance profile that integrates secure software development practices, SBOM transparency, and SLSA-style provenance. It demonstrates the rubric through analytical case-study walkthroughs and a minimal evidence-checking workflow for making Accept, Escalate, or Block decisions, while deferring empirical performance evaluation to future work.

Significance. If the proposed rubric holds up under validation, it would represent a meaningful contribution to securing the software supply chain in open RAN environments. By providing a structured, incremental approach aligned with O-RAN WG11 and supply-chain standards, it could help operators manage risks from third-party xApps and rApps more effectively. The emphasis on evidence-based decisions is particularly relevant for zero-trust architectures in telecommunications.

major comments (2)
  1. [Abstract] Abstract: The abstract explicitly defers empirical measurements of operational overhead, decision consistency, and detection coverage to future work. This is load-bearing for the central claim that the WG11-aligned mapping and incremental profile enable reliable Accept/Escalate/Block decisions, since the evidence-checking workflow's real-world applicability rests only on analytical case studies.
  2. [Case-study walkthroughs] Case-study walkthroughs: The analytical illustrations demonstrate the workflow conceptually but provide no data on false decision rates, operator overhead, or coverage gaps, leaving the assumption that the app-centric threat model comprehensively captures supply-chain risks untested.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive review and for acknowledging the potential value of the proposed rubric in O-RAN supply-chain security. We address each major comment point by point below, clarifying the intended scope of the work as a conceptual framework with analytical illustrations. We agree that empirical validation is necessary for full assessment of operational aspects and will make targeted revisions to improve transparency without altering the core contributions.

read point-by-point responses

  1. Referee: [Abstract] Abstract: The abstract explicitly defers empirical measurements of operational overhead, decision consistency, and detection coverage to future work. This is load-bearing for the central claim that the WG11-aligned mapping and incremental profile enable reliable Accept/Escalate/Block decisions, since the evidence-checking workflow's real-world applicability rests only on analytical case studies.

    Authors: We agree that the abstract's deferral of empirical metrics is central and that the current evidence for the workflow's reliability is limited to analytical case studies. The manuscript's primary contribution is the definition of the app-centric threat model, WG11-aligned mapping, and incremental assurance profile, with the walkthroughs serving to demonstrate conceptual application rather than to validate performance. To address this, we will revise the abstract to more explicitly position the work as proposing the rubric and illustrating its use through analysis, while stating that claims of enabling reliable decisions are preliminary and subject to future empirical confirmation. This revision will better bound the scope without misrepresenting the evidence presented. revision: yes

  2. Referee: [Case-study walkthroughs] Case-study walkthroughs: The analytical illustrations demonstrate the workflow conceptually but provide no data on false decision rates, operator overhead, or coverage gaps, leaving the assumption that the app-centric threat model comprehensively captures supply-chain risks untested.

    Authors: The case-study walkthroughs are analytical illustrations intended to show how the threat model, mapping, and evidence-checking workflow can be applied to specific RIC app scenarios for Accept/Escalate/Block decisions. We acknowledge that they provide no quantitative data on false decision rates, overhead, or coverage gaps, and that the comprehensiveness of the threat model therefore rests on reasoned construction from standard supply-chain risks adapted to the O-RAN lifecycle and WG11 baselines. This leaves the coverage assumption untested empirically, as noted in the manuscript. We will revise the evaluation and discussion sections to explicitly state these limitations and to outline the planned empirical studies, thereby increasing transparency while preserving the analytical focus appropriate for introducing the rubric. revision: yes

Circularity Check

0 steps flagged

No significant circularity; rubric and mapping are constructive proposals

full rationale

The paper defines an app-centric lifecycle threat model, a WG11-aligned threat-control-evidence mapping, and an incremental assurance profile that combines existing practices (secure development, SBOM, SLSA-style provenance) into onboarding levels. These are presented as contributions illustrated by analytical case-study walkthroughs, with no equations, parameter fitting, predictions, or derivations that reduce to inputs by construction. No self-citations are load-bearing for any uniqueness claim or ansatz, and the text explicitly defers empirical validation rather than claiming first-principles results. The central output is a rubric and workflow, not a reduction of any quantity to itself.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The proposal relies on domain assumptions about O-RAN security baselines and the sufficiency of SBOM/provenance evidence without introducing new entities or fitted parameters.

axioms (2)
  • domain assumption O-RAN WG11 security baselines provide an appropriate foundation for mapping supply-chain threats.
    The threat-control-evidence mapping is built directly on these baselines.
  • domain assumption SBOM transparency and SLSA-style provenance supply adequate evidence for Accept/Escalate/Block decisions.
    The assurance profile assumes these controls are effective and usable by operators.

pith-pipeline@v0.9.0 · 5479 in / 1237 out tokens · 50238 ms · 2026-05-08T17:34:48.173965+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

18 extracted references · 18 canonical work pages

  1. [1]

    O-RAN Architecture Description (O-RAN.WG1.OAD-R003-v08.00),

    European Telecommunications Standards Institute (ETSI), "O-RAN Architecture Description (O-RAN.WG1.OAD-R003-v08.00)," ETSI TS 103 982 V8.0.0, Jan. 2024

    work page 2024

  2. [2]

    O-RAN Security Requirements and Controls Specifications (O- RAN.WG11.SecReqSpecs-R003-v09.01),

    European Telecommunications Standards Institute (ETSI), "O-RAN Security Requirements and Controls Specifications (O- RAN.WG11.SecReqSpecs-R003-v09.01)," ETSI TS 104 104 V9.1.0, Jun. 2025. Available: https://www.etsi.org/deliver/etsi_ts/104100_104199/104104/09.01.00_60/ts_104104v090100p.pdf

    work page 2025

  3. [3]

    O-RAN Security Protocols Specifications (O-RAN.WG11.Security-Protocols- Specification.O-R003-v09.00),

    European Telecommunications Standards Institute (ETSI), "O-RAN Security Protocols Specifications (O-RAN.WG11.Security-Protocols- Specification.O-R003-v09.00)," ETSI TS 104 107 V9.0.0, May 2025. Available: https://www.etsi.org/deliver/etsi_ts/104100_104199/104107/09.00.00_60/ts_104107v090000p.pdf

    work page 2025

  4. [4]

    O-RAN Security Test Specifications (O-RAN.WG11.Security-Test- Specifications-R003-v07.00),

    European Telecommunications Standards Institute (ETSI), "O-RAN Security Test Specifications (O-RAN.WG11.Security-Test- Specifications-R003-v07.00)," ETSI TS 104 105 V7.0.0, Jun. 2025. Available: https://www.etsi.org/deliver/etsi_ts/104100_104199/104105/07.00.00_60/ts_104105v070000p.pdf

    work page 2025

  5. [5]

    O-RAN Security Threat Modeling and Risk Assessment (O- RAN.WG11.Threat-Modeling.O-R003-v03.00),

    European Telecommunications Standards Institute (ETSI), "O-RAN Security Threat Modeling and Risk Assessment (O- RAN.WG11.Threat-Modeling.O-R003-v03.00)," ETSI TR 104 106 V3.0.0, Jun. 2025. Available: https://www.etsi.org/deliver/etsi_tr/104100_104199/104106/03.00.00_60/tr_104106v030000p.pdf

    work page 2025

  6. [6]

    Specialpublication800-207,NationalInstituteofStandardsandTechnology (NIST) (2020).https://doi.org/10.6028/NIST.SP.800-207

    S. Rose, O. Borchert, S. Mitchell, and S. Connelly, "Zero Trust Architecture," NIST Special Publication 800-207, Aug. 2020. doi: 10.6028/NIST.SP.800-207. 7

    work page doi:10.6028/nist.sp.800-207 2020

  7. [7]

    O-RAN ALLIANCE Security Update 2025,

    O-RAN Alliance, "O-RAN ALLIANCE Security Update 2025," 2025. Available: https://www.o-ran.org/blog/o-ran-alliance-security- update-2025

    work page 2025

  8. [8]

    Secure Software Development Framework (SSDF) Version 1.1,

    National Institute of Standards and Technology (NIST), "Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities," NIST Special Publication 800-218, Feb. 2022. doi: 10.6028/NIST.SP.800-218

    work page doi:10.6028/nist.sp.800-218 2022

  9. [9]

    The Minimum Elements for a Software Bill of Materials (SBOM),

    National Telecommunications and Information Administration (NTIA), "The Minimum Elements for a Software Bill of Materials (SBOM)," Jul. 2021. Available: https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom

    work page 2021

  10. [10]

    SLSA Specification v1.2,

    SLSA Community, "SLSA Specification v1.2," 2025. Available: https://slsa.dev/spec/v1.2/ Accessed: May 2026

    work page 2025

  11. [11]

    ECMA-424: CycloneDX Bill of Materials Specification,

    Ecma International, "ECMA-424: CycloneDX Bill of Materials Specification," 2nd ed., Dec. 2025. Available: https://ecma- international.org/publications-and-standards/standards/ecma-424/

    work page 2025

  12. [12]

    SPDX Specification Version 2.3.0,

    SPDX Workgroup, "SPDX Specification Version 2.3.0," 2022. Available: https://spdx.github.io/spdx-spec/v2.3/

    work page 2022

  13. [13]

    in-toto: Providing farm-to-table guarantees for bits and bytes,

    S. Torres-Arias, H. Afzali, T. K. Kuppusamy, et al., "in-toto: Providing farm-to-table guarantees for bits and bytes," in Proc. 28th USENIX Security Symposium, 2019

    work page 2019

  14. [14]

    Cosign and keyless signing documentation,

    The Sigstore Authors, "Cosign and keyless signing documentation," 2026. Available: https://docs.sigstore.dev/cosign/signing/overview/ Accessed: May 2026

    work page 2026

  15. [15]

    Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies,

    A. Birsan, "Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies," 2021. Available: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

    work page 2021

  16. [16]

    The 2020 SolarWinds Software Supply Chain Compromise Against a U.S. Energy Provider: Precursor Analysis Report,

    Idaho National Laboratory, Cybersecurity for the Operational Technology Environment (CyOTE) Program, "The 2020 SolarWinds Software Supply Chain Compromise Against a U.S. Energy Provider: Precursor Analysis Report," 2025. Available: https://cyote.inl.gov/content/uploads/24/2025/12/CyOTE-Case-Study_SolarWinds.pdf

    work page 2020

  17. [17]

    Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges,

    M. Polese, L. Bonati, S. D'Oro, S. Basagni, and T. Melodia, "Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges," IEEE Communications Surveys & Tutorials, vol. 25, no. 2, pp. 1376-1411, 2023. doi: 10.1109/COMST.2023.3239220

    work page doi:10.1109/comst.2023.3239220 2023

  18. [18]

    Attacking O-RAN Interfaces: Threat Modeling, Analysis and Practical Experimentation,

    P. Baguer, G. M. Yilma, E. Municio, G. Garcia-Aviles, A. Garcia-Saavedra, M. Liebsch, and X. Costa-Perez, "Attacking O-RAN Interfaces: Threat Modeling, Analysis and Practical Experimentation," IEEE Open Journal of the Communications Society, vol. 5, pp. 4559-4577, 2024. doi: 10.1109/OJCOMS.2024.3431681

    work page doi:10.1109/ojcoms.2024.3431681 2024