Telco Work Group

• 1: A Handbook for Software Supply Chain Security in the Telco Industry
• 2: 2025-12-04 SBOM 표준화와 최신 이슈들
• 3: 2025-11-06 CISA 셧다운의 영향과 SBOM 품질 가이드 집중 점검
• 4: 2024-12-06 SBOM 가이드라인 업데이트 논의

1 - A Handbook for Software Supply Chain Security in the Telco Industry

Chapter 1: Why the Telco Industry Needs SBOMs Now

1.1. The New Threat Landscape in the Global Software Supply Chain

1.1.1. Growing Reliance on Open Source in 5G and Cloud-Native Environments

The telecommunications industry is undergoing a period of rapid digital transformation. The rollout of 5G networks, adoption of cloud-native technologies, and explosive growth of IoT devices have exponentially increased software complexity and interdependence.

Today, over 90% of software development relies on open source. In telecom infrastructure, open-source communication protocols like OPC UA and MQTT are vital for real-time data exchange. The complex architecture of 5G networks involves thousands of software components, with increasingly intricate dependency relationships.

1.1.2. The Log4j Incident: A Supply Chain Wake-Up Call

The Log4Shell (Log4j vulnerability) disclosed in December 2021 had a profound impact on the global software ecosystem, including the telecommunications industry. This vulnerability exposed several critical issues:

• Widespread Impact: Log4j is one of the most widely deployed open-source libraries globally, affecting millions of systems. According to IBM’s X-Force Threat Intelligence Index, vulnerabilities surged by 34% between 2020 and 2021, largely attributed to Log4Shell.
• Detection and Response Challenges: Many companies spent significant time simply identifying whether their systems used third-party products containing the Log4j library. Even two years after its disclosure, 38% of applications using Log4j remained vulnerable.
• Discovery of Subsequent Vulnerabilities: Following the initial vulnerability (CVE-2021-44228), seven additional vulnerabilities were discovered, highlighting the need for continuous monitoring and updates.

1.1.3. The Push for Transparency with SBOMs

The Log4j incident starkly demonstrated the dangers of lacking visibility into software components. In its wake, governments and industries worldwide began pushing for the adoption of a Software Bill of Materials (SBOM) to secure the software supply chain.

In May 2021, the Biden administration issued an Executive Order on Improving the Nation’s Cybersecurity, which mandated strengthening software supply chain security. Similarly, the South Korean government announced plans to reinforce software development and supply chain security in its K-Cyber Quarantine Promotion Strategy.

1.2. Unique Challenges of the Telco Industry

1.2.1. A Complex Ecosystem with a Multi-Layered Supply Chain

The telecommunications industry features a complex, multi-layered supply chain structure:

• Hardware Layer: Network equipment manufacturers supply firmware and embedded software for base stations, routers, and switches.
• Software Layer: Various network software suppliers provide solutions like SDN/NFV, network management, and security.
• Service Layer: Telecom operators deliver end-user services such as 5G, cloud, and IoT.

In this structure, a single vulnerability can create a massive cascading effect across the entire network.

1.2.2. Demanding Standards for Reliability and Security

Telecommunications infrastructure is designated as critical national infrastructure, requiring exceptionally high levels of security and reliability. 5G networks, in particular, introduce new security challenges:

• Massive IoT Connectivity: A 5G environment connects billions of IoT devices, each a potential attack vector.
• Distributed Edge Computing: As data processing shifts to the network edge, centralized security management becomes more difficult.
• Network Slicing Isolation: A security breach in one network slice could potentially impact others.
• The Rise of Open RAN (O-RAN): The promotion of open RAN interfaces, mainly driven by the O-RAN Alliance, allows equipment from multiple vendors to be used together, breaking away from traditional single-vendor lock-in. However, this introduces new supply chain risks. For equipment from different vendors to interoperate safely and securely, they must exchange mutually trusted information about their software composition. An SBOM is the foundational mechanism that provides this basis of trust.

1.2.3. Mounting Regulatory and Customer Pressure for SBOMs

The demand for SBOMs from regulators and customers is rapidly intensifying:

• Government and Public Sector: Public institutions, like the Korea Meteorological Administration, are beginning to require SBOM submission in procurement notices.
• Global Regulatory Trends:
  • United States: Mandated the provision of SBOMs for all software delivered to the federal government.
  • EU: Is advancing SBOM mandates through the Cyber Resilience Act (CRA).
  • Other major countries like Japan and South Korea are pursuing similar policies.
• Customer Demands: Large telecom operators, equipment manufacturers, and network solution providers increasingly specify SBOM delivery as a contractual requirement.
• Industry Momentum: Industry-led initiatives like the OpenChain Project are building consensus and proposing practical, industry-specific SBOM guides for telecommunications to address these growing needs from the ground up.
• Future Standardization: It is anticipated that formal Standards Development Organizations (SDOs), such as ETSI, will address this topic more formally in the future, potentially building on the work done by industry groups in response to regulations like the EU’s Cyber Resilience Act (CRA).

These shifts signal a fundamental need to innovate software supply chain security in the telecommunications industry. An SBOM is no longer an option but a core requirement for survival and competitiveness in the telco sector.

Chapter 2: An Introduction to the OpenChain Telco SBOM Guide

• English (Original): OpenChain Telco SBOM Guide 1.1
• Korean (한국어): OpenChain Telco SBOM 가이드 1.1

2.1. Background and Core Objectives

2.1.1. Addressing SBOM Fragmentation in the Telco Industry

The telecommunications industry is one of the world’s most complex and interconnected software ecosystems. As 5G infrastructure, cloud-native solutions, and network virtualization converge, organizations have adopted disparate methods and requirements for creating SBOMs.

This fragmentation has created several significant challenges:

• Lack of Compatibility: An SBOM from a telecom operator might not match the format provided by an equipment manufacturer, leading to added conversion work and costs.
• Redundant Investment: As each organization developed its own tools and processes, the industry as a whole made inefficient, redundant investments.
• Limited Risk Management: Non-standardized SBOMs made it difficult to track vulnerabilities and respond quickly across the entire supply chain.

In response, the OpenChain Project formed the Telco Working Group in 2023 to develop a specialized SBOM guide for the telecommunications industry.

2.1.2. A New Standard for Interoperability, Repeatability, and Efficiency

The OpenChain Telco SBOM Guide introduces a practical approach that reflects the unique needs of the telecommunications industry while ensuring compatibility with global standards. The guide’s core objectives are:

• Repeatability: Provide clear criteria to ensure that an SBOM of consistent quality can be generated for the same software, regardless of who creates it or when.
• Streamlined Tooling: Enable various SBOM generation tools to produce standardized outputs that are compatible across organizations.
• Supply Chain Transparency: Allow all entities that produce and consume SBOMs to exchange software component information based on a common standard.

2.2. The Three Core Principles of the Guide

2.2.1. Principle 1: Standardization

The OpenChain Telco SBOM Guide adopts the SPDX (Software Package Data Exchange) format, which is certified as international standard ISO/IEC 5962:2021. This choice was driven by several strategic factors:

• International Standard Compliance: SPDX is the only SBOM format officially adopted by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) as of September 2021.
• Technical Advantages: SPDX offers more robust features for license compliance than other formats and supports a human-readable structure.
• Industry Validation: Global companies like Ericsson, Intel, Microsoft, Siemens, Sony, and Nokia use SPDX for their software supply chain management, making it a proven standard.

The guide requires compliance with SPDX version 2.2 or 2.3 and specifies that SBOMs be provided in Tag:Value or JSON format.

2.2.2. Principle 2: Clarity

The OpenChain Telco SBOM Guide builds on the minimum requirements from the NTIA (National Telecommunications and Information Administration) but establishes clear, practical criteria tailored to the telecommunications industry’s needs:

• Required SPDX Elements:

  • Document Creation Information: SPDXVersion, DataLicense, Creator, Created, etc.
  • Package Information: PackageName, PackageVersion, PackageSupplier, PURL, etc.
  • Relationship Information: Dependency relationships like DESCRIBES, CONTAINS, etc.

• Delivery Timing and Method:

  • Timing: The SBOM must be delivered concurrently with the software.
  • Method: The primary method is to embed the SBOM within the software package. If technically infeasible, web hosting is permitted, with access guaranteed for at least 18 months.
  • Note: The SBOM may be made available before delivery is the SBOM provider so wishes, however, it is still a requirement to also deliver it concurrently with the software.

• Mandatory Generation Information:

  • The Creator field must include the organization’s name and the tool’s name/version.
  • The CreatorComment field must include the CISA-defined SBOM Type (e.g., Design, Source, Build).

2.2.3. Principle 3: Comprehensiveness

Modern software has numerous transitive dependencies, which are major vectors for security vulnerabilities. As the Log4j incident demonstrated, the spread of vulnerabilities through these dependencies is unpredictable and can cause extensive damage.

The OpenChain Telco SBOM Guide reflects this reality by requiring a comprehensive scope:

• All Open Source Included: All open-source software delivered with the product, including all transitive dependencies, must be listed.
• Commercial Components Recommended: The guide recommends including all commercial components. If excluded, they must be reported as “known unknowns.”
• Container Environment Support: The scope includes packages installed in a container, components copied or downloaded to it, and dependencies used to build compiled components within it.

2.3. Key Requirements at a Glance

The following table summarizes the key requirements of the OpenChain Telco SBOM Guide:

Through this systematic and practical approach, the OpenChain Telco SBOM Guide provides a solid foundation for advancing software supply chain management in the telecommunications industry. Nokia’s adoption of this guide for its internal framework testifies to its practicality and effectiveness.

Chapter 3: The Business Value of Guide Compliance

Adhering to the OpenChain Telco SBOM Guide is not just a compliance task; it’s a strategic investment that delivers tangible business value. By standardizing SBOM practices, your organization can enhance risk management, boost business competitiveness, increase operational efficiency, and reduce costs.

3.1. Strengthened Supply Chain Risk Management

3.1.1. Proactive Vulnerability Analysis and Rapid Response

Complying with the guide dramatically accelerates vulnerability response times. Organizations with mature SBOM-driven vulnerability management systems can reduce response times by 30%.

During the Log4j incident, companies with SBOMs identified affected systems in minutes, while those without took weeks or even months. One software vendor testified that “an SBOM capability alone could have easily saved 240 hours”.

Japan’s Ministry of Economy, Trade and Industry (METI) reported that using SBOMs for vulnerability management in the medical device sector reduced the workload by approximately 70% compared to manual methods.

3.1.2. Automated Open Source License Compliance

By managing component license information in the standardized SPDX format, organizations can proactively prevent legal risks and fines from license violations. Automating compliance tasks, such as license scanning and policy enforcement, significantly reduces administrative overhead.

3.2. Enhanced Business Competitiveness

3.2.1. Meeting Customer and Partner Demands for SBOMs

Many System Integrators (SIs) and Software Vendors (SVs) now view SBOM adoption as a key driver for regulatory compliance and building trust. An organization with proven SBOM capabilities gains a clear competitive advantage by:

• Securing a differentiated position with security-conscious customers.
• Meeting mandatory requirements in contracts with government agencies and large corporations.
• Demonstrating compliance with global regulations like the EU’s Cyber Resilience Act (CRA) and the US Executive Order 14028.

3.2.2. Gaining an Edge in RFPs and Contracts

The ability to provide a standardized SBOM is a tangible asset that can shorten sales cycles. An API management vendor CEO noted, “Being able to present an SBOM early in the conversation enables a completely different level of dialogue.”

3.2.3. Demonstrating Compliance for Global Market Access

The guide’s foundation in the ISO/IEC 5962:2021 (SPDX) standard ensures that your SBOMs can be submitted for international procurement and exports without costly format conversions, ensuring compatibility and trust with global partners.

3.3. Increased Development and Operational Efficiency

3.3.1. Standardized and Automated Processes

By adopting a standard format (SPDX 2.2/2.3) and clear requirements, organizations can automate the SBOM generation, verification, and delivery processes. This can lead to significant time savings—over five hours per engineer per week—that can be reinvested into core development tasks.

3.3.2. Clearer Internal Guidelines for Development Teams

A consistent, organization-wide standard for SBOMs eliminates the confusion and inefficiency of redundant scans and manual management. This efficiency is accelerated by integrating automated tools into CI/CD pipelines.

3.4. Significant Cost Reduction

3.4.1. Preventing Losses from Supply Chain Attacks

A single software supply chain attack costs an average of $4.35 million, with the total annual impact projected to reach $80.6 billion by 2026. A systematic approach using the OpenChain Telco SBOM Guide can proactively prevent these multimillion-dollar losses.

3.4.2. Operational Savings through Automation

There are numerous cases of organizations saving hundreds of hours on vulnerability analysis with an SBOM. One company reported reducing its vulnerability review time “from a full day to less than an hour,” saving an estimated 500 hours per open-source project.

3.5. Simplified Regulatory and Standards Compliance

3.5.1. A Clear Path to Global Regulatory Compliance

The OpenChain Telco SBOM Guide provides a practical foundation for responding to global requirements from bodies like NTIA, CISA, and ISO. This is crucial as key regulations take full effect:

• USA: SBOM provision is mandatory for federal government software procurement.
• EU: SBOM mandates under the Cyber Resilience Act (CRA) are being actively advanced.
• Japan, South Korea: Similar policies are being rolled out.

3.5.2. Stronger Multinational Partnerships

Standardized SBOM exchange is a global imperative. Adhering to the guide ensures compatibility with third-party SBOMs, eliminating collaboration barriers. Nokia’s adoption of the guide for its internal framework is a prime example of its practicality and business value.

Chapter 4: Role-Based Applications and Scenarios

The OpenChain Telco SBOM Guide is designed to be flexible, offering distinct value depending on each stakeholder’s role within the telecommunications ecosystem. This chapter provides specific scenarios for telecom operators (consumers), equipment manufacturers (producers), solution providers (producers), and compliance officers (practitioners) to strategically leverage the guide.

4.1. For Telecom Operators (as Consumers)

Telecom operators are the primary stewards of the supply chain and key consumers of SBOMs. They procure equipment and solutions from numerous suppliers to deliver final services. Their main objective is to proactively identify security risks in procured software and ensure transparency across their entire supply chain.

4.1.1. Scenario: Verifying the Supply Chain for External Solutions

• Situation: A telecom operator plans to introduce a new orchestration solution for 5G network slicing. They receive proposals from several global vendors, but the lack of standardized SBOMs makes an objective risk assessment difficult.

• Applying the OpenChain Telco SBOM Guide:

  1. Step 1: Set Clear Requirements

     • Mandate Guide Compliance in RFPs: Include the submission of an SBOM in SPDX 2.2 or 2.3 format as a mandatory evaluation criterion. This establishes a single standard for quality and format.
     • Require Complete SBOMs: In line with the guide, demand an SBOM that includes not only direct dependencies but also all transitive dependencies to uncover hidden security and license risks.

  2. Step 2: Perform Quantitative Risk Assessments

     • Use Automated Analysis: Feed the standardized SBOMs into an internal Software Composition Analysis (SCA) tool to automatically scan for known vulnerabilities (CVEs) and quantify their severity.
     • Verify License Compliance: Analyze the license information (PackageLicenseConcluded, PackageLicenseDeclared) to check for conflicts with internal policies or commercial use restrictions.
     • Assess Transparency: Use the known unknowns field as a metric to evaluate how transparently a vendor manages its software components.

  3. Step 3: Ensure Continuous Management

     • Define Contractual Obligations: For instance, the contract could include a clause specifying that “an updated SBOM must be provided concurrently with any software patch or version update.” As the OpenChain Project does not provide legal advice, all contractual clauses should be developed in consultation with your legal counsel.
     • Guarantee Accessibility: As per the guide, ensure that web-hosted SBOMs are accessible for at least 18 months to support long-term security management and audits.

• Expected Benefits:

  • Rapid Threat Response: During a zero-day event like Log4j, identify affected systems across the supply chain in minutes and prioritize the response.
  • Data-Driven Vendor Selection: Objectively compare supplier security levels based on standardized data, not just on business relationships.
  • Stronger Security Governance: Gain a transparent view of software assets across the supply chain, simplifying compliance with regulatory audits and internal policies.

4.1.2. Tip: Specifying SBOM Requirements in RFPs and Contracts

Formalizing SBOM requirements is the most effective way to drive supplier accountability.

• Standard RFP Clause Example:

  “All proposals must include an SBOM compliant with the ‘OpenChain Telco SBOM Guide v1.1’ for all software products. The SBOM must be in SPDX v2.2 or v2.3 (Tag:Value or JSON format) and include all open source and commercial components, along with their transitive dependencies. SBOM quality and completeness will be a key evaluation criterion.”

• Key Contractual Clauses:

  • SBOM Provision and Timing: “The Supplier shall provide an SBOM compliant with the ‘OpenChain Telco SBOM Guide,’ as specified in Appendix X, concurrently with each software delivery.”
  • Accuracy Warranty: “The Supplier warrants that the information in the provided SBOM is materially accurate and complete.”
  • Update Obligation: “The Supplier shall provide an updated SBOM to the Client within seven (7) days of releasing a major update or security patch for the software.”
  • Breach of Contract: “Failure to comply with these SBOM obligations shall be considered a material breach of this contract, and the Client may pursue remedies including, but not limited to, termination and claims for damages.”

4.2. For Telecom Equipment Manufacturers (Hardware-Coupled Producers)

Telecom equipment manufacturers develop software tightly integrated with hardware, such as firmware and embedded OS, making them critical producers of SBOMs. Their goal is to efficiently meet diverse customer requirements and demonstrate the reliability and competitiveness of their products.

4.2.1. Scenario: Automating SBOM Delivery for Network Equipment

• Situation: An equipment manufacturer supplies 5G routers to global telecom operators, but varying SBOM requirements lead to costly manual work for each product release.

• Applying the OpenChain Telco SBOM Guide:

  1. Standardize Internal Processes with an ‘SBOM Factory’

     • CI/CD Pipeline Integration: Integrate automated SBOM generation and validation into the CI/CD pipeline for firmware builds. A successful build is contingent on generating a compliant SBOM.
     • Automate Metadata: Automatically populate the Creator field with the organization name and tool version, and set SBOM Type: Build based on the build time to ensure traceability.

  2. Implement Product-Centric SBOM Management

     • Version Control: Integrate with Git to automatically generate and link SBOMs to each firmware version, simplifying version-specific vulnerability analysis.
     • Design for Accessibility: Embed a compressed SBOM within the package or print a QR code linking to the SBOM download on product packaging.
     • Ensure Integrity: Apply a digital signature (e.g., using Sigstore) to the SBOM file to prevent tampering and increase customer trust.

  3. Establish an Efficient Customer Response System

     • Provide a Single Standard: Offer a standard SBOM based on the guide to all customers by default.
     • Enable Flexible Conversion: If a customer requires a different format (e.g., CycloneDX), use a conversion tool with the standard SPDX SBOM as the source for a quick response.
     • Integrate with Technical Support: Train support teams to instantly access the SBOM for a specific product version to accurately answer customer questions about vulnerabilities and licenses.

• Expected Benefits:

  • Increased Productivity: A ‘Create Once, Use Many’ approach can reduce custom SBOM work by over 80%.
  • Enhanced Trust and Competitiveness: Proactively providing a standardized, verified SBOM demonstrates product transparency and security, creating a competitive advantage.
  • Simplified Global Compliance: Adherence to an ISO-based guide streamlines entry into regulated markets like the US and EU.

4.2.2. Tip: Managing SBOMs for Firmware and Embedded OS

Managing SBOMs for embedded environments requires special consideration.

• Technical Implementation:

  • Build System Integration: Integrate SBOM generation tools or plugins into embedded Linux build systems like Yocto or Buildroot to automatically extract component data during the build.
  • Use Binary Analysis: For third-party binaries or drivers without source code, use SCA tools with binary analysis capabilities to identify components for the SBOM.

• Management Processes:

  • Product Lifecycle Integration: Align SBOM creation, updates, and retirement with the full product lifecycle, from development to end-of-life.
  • Sync with Security Patches: When deploying a new firmware version, ensure the corresponding SBOM is updated to reflect the patch details and communicated to customers.
  • Manage Legacy Products: For out-of-production but still-supported products, retroactively generate SBOMs and provide information on known vulnerabilities to minimize customer risk.

4.3. For Network Solution & Service Providers (Software-Only Producers)

Network solution and service providers are key SBOM producers in modern software environments like cloud-native, SaaS, and containers. Their goal is to develop flexible SBOM strategies that adapt to rapid technological changes and leverage this capability for a competitive service advantage.

4.3.1. Scenario: SBOM Strategy for SaaS and On-Premise Solutions

• Situation: A network security company offers both a cloud-based SaaS solution and an on-premise firewall. A major client requests detailed SBOMs for both, creating challenges, especially for the continuously updated SaaS environment.

• Applying the OpenChain Telco SBOM Guide:

  1. Develop Differentiated Strategies by Solution Design distinct SBOM strategies tailored to each solution’s deployment model.

     • On-Premise Solution (Installable):

       • Embed in Package: As recommended by the guide, embed the SBOM file directly into the installation package (e.g., RPM, DEB, MSI).
       • Container-Based Deployment: For Docker/Kubernetes deployments, include the SBOM in a container image layer or store it alongside the image in a registry, following OCI (Open Container Initiative) standards.

     • SaaS Solution (Service):

       • Tiered Service Offering: Since SaaS application is optional in the guide, structure SBOM delivery as a premium service. Offer summary information to basic customers and detailed, API-accessible SBOMs to enterprise customers for a fee, creating a new revenue stream.
       • Provide a Security Portal: Offer a dedicated portal for enterprise customers to securely view and download the latest SBOMs for the service.
       • Enable API-Based Access: Provide SBOM data via API to allow integration with customer security systems (e.g., SOAR).

  2. Integrate Fully with Your DevSecOps Pipeline

     • Generate SBOMs per Microservice: In a microservice architecture (MSA), generate individual SBOMs in each service’s build pipeline.
     • Define Relationships: During deployment, merge the individual SBOMs into a unified SBOM using SPDX relationship definitions (e.g., DESCRIBES, CONTAINS) to clearly map the solution’s architecture.
     • Automate with Continuous Deployment (CD): Establish a system where an SBOM is automatically updated whenever a new microservice version is deployed, reflecting the change in the unified SBOM in real-time.

• Expected Benefits:

  • Create New Business Opportunities: Position SBOM delivery as a premium security service to generate additional revenue.
  • Increase Customer Retention: Strengthen partnerships with large, security-conscious customers by offering advanced, API-integrated security services.
  • Demonstrate Technological Leadership: Showcase your ability to systematically manage complex SBOMs in a cloud-native environment, building a brand image as a technology leader.

4.3.2. Tip: Using SBOMs for Customer Support and Maintenance

SBOMs create significant value in post-sales support and maintenance.

• Proactive Vulnerability Management:

  • When a new CVE is disclosed, automatically scan all product SBOMs to instantly identify affected customers.
  • Proactively notify them before they inquire: “The [Component Name] in v2.1 of the [Product Name] you are using is affected by CVE-2025-XXXX. A patch is in development; temporary mitigation measures are available here.”

• Transparent License Compliance:

  • During a customer audit, provide the precise SBOM for that point in time to support license status reporting.

• Efficient Maintenance:

  • Before an update, compare the old and new SBOMs to proactively identify changed components and potential conflicts, reducing the risk of update failures.

4.4. For Open Source & Compliance Officers

Open source and compliance officers are the central architects of an organization’s SBOM governance. Their goal is to create clear, actionable policies that reduce developer workload while minimizing organizational risk.

4.4.1. Scenario: Establishing an Internal SBOM Policy

• Situation: The head of the open source program office (OSPO) at a large company needs to create a company-wide SBOM policy but faces conflicting requirements from development, security, procurement, and legal teams.

• Establishing a Policy Based on the Guide: Use the objective, internationally recognized guide as the foundation to mediate disagreements and build consensus.

  1. Construct the Policy Framework

     [Internal SBOM Management Policy]
     
     Article 1 (Purpose): To ensure software supply chain transparency and systematically manage related risks by complying with the 'OpenChain Telco SBOM Guide v1.1'.
     
     Article 2 (Scope): This policy applies to all software developed, purchased, or distributed by the company.
     
     Article 3 (Quality Requirements): All SBOMs must meet the requirements of the 'OpenChain Telco SBOM Guide' (e.g., data format, required fields, delivery method).
     

  2. Define Clear Departmental Roles (R&R)

     • Development: Generate SPDX-format SBOMs using standard tools in the CI/CD pipeline.
     • Procurement: Include standard SBOM clauses in all software purchase contracts.
     • Security: Conduct regular vulnerability monitoring and analysis using SBOMs.
     • Legal/Compliance: Review license information in SBOMs for compliance risks.

  3. Standardize Processes and Tools

     • Approve Standard SCA Tools: Define and support a list of official SCA tools.
     • Automate Quality Gates: Use open-source tools like sbomqs to automatically score SBOM quality during generation and fail builds that fall below a set threshold.
     • Provide Education and Support: Offer regular training, online guides, and internal communities to help developers follow the policy.

4.4.2. Tip: Selecting and Adopting an SBOM Tool (SCA Tool)

Successful SBOM management depends on choosing the right tool.

• Phased Adoption Plan:
  1. Define Requirements: List essential features based on your tech stack, budget, and security policies.
  2. Market Research: Select 3-4 candidate tools based on industry reports (e.g., Gartner, Forrester) and community evaluations.
  3. Conduct a Proof of Concept (PoC): Test the candidates on a real project to compare performance, accuracy, and usability.
  4. Select and Roll Out: Choose the optimal tool based on PoC results and implement a phased, organization-wide rollout, starting with a pilot team.

4.5. Collaborative Scenario: A Unified Supply Chain

The ultimate value of an SBOM is realized when it connects the entire supply chain, acting as a common language.

• Integrated Scenario: A major 5G private network project involves a telecom operator, an equipment manufacturer (tier 1), and a solution provider (tier 2), all collaborating based on the OpenChain Telco SBOM Guide.

  1. Project Kick-off: The project contract mandates compliance with the guide for all parties. They exchange initial SBOMs to jointly analyze the system’s integrated security posture.
  2. Development and Integration: The solution provider delivers its SBOM to the equipment manufacturer. The manufacturer merges this with its own firmware SBOM using SPDX relationship definitions to create a unified equipment SBOM for the operator.
  3. Operation and Maintenance: The operator ingests the final SBOM into a central monitoring system for real-time asset management. When a zero-day vulnerability appears, the operator can instantly identify the affected equipment and solution and demand a patch from the responsible supplier.

• Expected Benefits:

  • End-to-End Supply Chain Visibility: Immediately pinpoint the source of a problem instead of wasting time in multi-vendor blame games.
  • Maximized Collaboration Efficiency: Eliminate the costs and delays of data conversion and re-interpretation by using a shared standard.
  • Strengthened Critical Infrastructure Security: Enhance the resilience of the nation’s critical telecommunications infrastructure beyond the efforts of any single company.

Chapter 5: A Phased Implementation Plan

Successfully adopting the OpenChain Telco SBOM Guide is not a one-time project but a continuous journey of cultural and procedural integration. This chapter presents a practical, three-phase plan—Assess → Build → Scale—to help your organization effectively implement and operate its SBOM management system.

5.1. Phase 1: Assess – Diagnosis and Goal Setting

Goal: To accurately assess your current state and define clear objectives.

This foundational phase is crucial for success. Rushing to adopt tools or policies without a proper diagnosis can lead to inefficient outcomes disconnected from business needs. The first step is to clearly understand your organization’s current capabilities and challenges.

5.1.1. Organizational Assessment and Maturity Evaluation

Objectively assess your organization’s current software supply chain management practices to identify risks and improvement opportunities.

• Map the Current Software Supply Chain:

  • Product/Service Inventory: List all software currently in development and operation to define the scope of SBOM management.
  • Component Management Practices: Review how open-source and commercial components are introduced, used, and retired. Determine if management is manual (e.g., spreadsheets) or automated.
  • Risk Management Process Review: Analyze existing vulnerability management and license compliance processes.
  • Historical Analysis: Review supply chain-related security incidents from the past 2–3 years to identify key vulnerabilities.

• SBOM Maturity Self-Assessment: Use this three-stage model to diagnose your organization’s current maturity level.

• Gap Analysis: Based on the assessment, identify the gaps between the OpenChain Telco SBOM Guide’s requirements and your current capabilities.
  • Data Format: Does your current SBOM comply with SPDX 2.2/2.3?
  • Required Fields: Are all required fields (e.g., PackageName, PURL) included?
  • Process: Is there a process to deliver the SBOM concurrently with the software?
  • Resources: Are the necessary tools, personnel, and budget secured?

5.1.2. Stakeholder Identification and Task Force Formation

SBOM adoption is an enterprise-wide project that requires cross-functional collaboration.

• Secure Key Stakeholder Involvement:

  • Development: Responsible for SBOM generation and CI/CD integration.
  • Security: Responsible for vulnerability analysis and policy validation.
  • Compliance/Legal: Responsible for license management and legal risk review.
  • Procurement: Responsible for including SBOM requirements in supplier contracts.
  • Executive Leadership: Responsible for providing strategic direction and resources.

• Form an SBOM Adoption Task Force: This should be an execution-oriented team with clear Roles & Responsibilities (R&R).

  • TF Lead: Manages the overall project and reports to the executive team.
  • Technical Expert: Evaluates and implements tools.
  • Process Architect: Designs the end-to-end SBOM workflow.
  • Change Manager: Leads training and communication to drive adoption.

5.1.3. Goal Setting and Scope Definition

Set realistic, measurable goals to focus resources and define success.

• Set SMART Goals:

  • (Example) “By Q4 2025, automate the generation and delivery of SBOMs compliant with the OpenChain Telco SBOM Guide for our three flagship telecom equipment product lines.”

• Define Scope by Priority: Expand the scope in phases based on business importance and risk.

  1. Priority 1 (Strategic): Core products or new flagship services delivered to external customers.
  2. Priority 2 (Risk-Based): Product lines subject to regulatory requirements or with high open-source dependencies.
  3. Priority 3 (Internal): Internally used development projects.

5.2. Phase 2: Build – Tool Selection and Process Integration

Goal: To build a sustainable, automated system based on the established plan.

This phase involves implementing the systems and processes defined in Phase 1. The key is to create an automated system that is naturally integrated into the development lifecycle.

5.2.1. SBOM Generation Tool Evaluation and Selection

Select the optimal tool for your organization’s tech stack, budget, and goals.

• Establish Tool Selection Criteria: Create an objective evaluation model by weighting criteria based on organizational needs.

• Compare Tools and Conduct a Proof of Concept (PoC): Test 2–3 candidate tools in a real development environment.
  • Apply them to a pilot project to compare performance, accuracy, and usability.
  • Gather developer feedback to assess practical utility.
  • Conduct a Return on Investment (ROI) analysis to inform the final selection.

5.2.2. Process Design and Standardization

Design a standardized SBOM management process that fits your development culture.

• Design a CI/CD-Integrated Workflow: Make SBOM generation an automated part of the development process, not an extra task.

  1. Code Commit: The pipeline is triggered when a developer commits code.
  2. Build & Scan: The code is built, and an SCA tool scans for dependencies.
  3. SBOM Generation: An SPDX-formatted SBOM is automatically generated.
  4. Quality Validation: The SBOM is automatically validated against the guide’s requirements.
  5. Policy Check: The SBOM is used to scan for vulnerabilities and license violations. (Fail the build if policies are violated).
  6. Sign & Store: A digital signature is applied, and the SBOM is stored in a central repository.
  7. Deploy: The SBOM is included in the final deployment package.

• Document Policies and Guidelines: Provide clear, written standards for all team members.

  • Corporate SBOM Policy: Defines principles and responsibilities for SBOM management.
  • Tool Usage Guide: Provides step-by-step instructions and best practices.
  • Quality Checklist: A self-verification checklist for guide compliance.

5.2.3. Internal Training and Capability Building

New tools and processes require sufficient training to ensure adoption.

• Customized Training Programs:
  • Executives: Briefing on the strategic value and business impact of SBOMs.
  • Developers: Hands-on training on tool usage and CI/CD integration.
  • Security/Compliance Teams: Advanced training on SBOM-based vulnerability and license auditing.

5.3. Phase 3: Scale – Pilot Project and Enterprise Rollout

Goal: To prove value through a small success and expand across the organization.

Apply the SBOM process to a real project to verify its effectiveness, then drive company-wide adoption.

5.3.1. Execute a Pilot Project

Follow the principle: “Start small, succeed fast, and scale.”

• Pilot Project Selection Criteria:

  • Representative: Has moderate complexity and represents a typical project.
  • Cooperative: Involves a development team that is receptive to change.
  • Influential: Is a project whose success can positively influence other teams.

• Pilot Execution and Performance Measurement: Run the pilot for a defined period (e.g., 8 weeks) and measure performance using Key Performance Indicators (KPIs).

5.3.2. Gradual Rollout Strategy

Use the successes and lessons from the pilot to create a systematic roadmap for enterprise-wide expansion.

• Establish a Rollout Roadmap: Expand the scope in phases by product line and business unit.

  • (Example) Phase 1 (3 months): Pilot completion & rollout to 3 core products → Phase 2 (6 months): Expansion to 50% of major product lines → Phase 3 (12 months): Enterprise-wide standardization complete.

• Lead Change and Overcome Resistance:

  • Communication: Transparently share the reasons for adoption and regularly communicate progress.
  • Support: Operate dedicated support channels (helpdesk, internal community) to resolve issues promptly.
  • Participation: Actively listen to feedback from the field and reflect it in process improvements.

5.3.3. Establish and Advance Governance

Build a continuous management system to embed SBOM management as a core competency.

• Operate an SBOM Center of Excellence (CoE): Establish an expert organization to oversee the company-wide SBOM strategy, quality management, technical support, and training.
• Create a Continuous Improvement Process: Identify improvement opportunities through quarterly performance reviews and incorporate evolving external standards and technologies.
• Measure Performance and Demonstrate Value: Quantitatively analyze the ROI of SBOM adoption—such as reduced vulnerability response times and lower license violation risks—to report to management and secure ongoing investment.

Chapter 6: Conclusion – The First Step Toward a More Secure Telco Ecosystem

6.1. The Significance and Future of the OpenChain Telco SBOM Guide

The OpenChain Telco SBOM Guide represents a pivotal step forward in securing the telecommunications software supply chain. In an era where large-scale attacks like Log4Shell and SolarWinds threaten global digital infrastructure, the guide provides a crucial solution: a specialized SBOM standard built for the telecommunications industry.

The guide’s development over 18 months, the release of Version 1.1, and its adoption as an internal framework by global leaders like Nokia prove that it is more than a document—it is an industry standard driving tangible change.

Its greatest significance lies in fostering interoperability and standardization, which maximizes efficiency across the entire industry. As Gergely Csatári of Nokia noted, the guide addresses the real-world need for “harmonization of completeness, quality, and content to ensure interoperability of SBOMs, both internally and at external interfaces.”

Furthermore, the announcement of commercial tool support from SCANOSS marks a significant milestone, signaling the guide’s evolution from a theoretical standard to a practical, automated solution.

6.2. Why You Must Start Now

The window of opportunity for proactive adoption is closing. Three key trends underscore the urgency of implementing a robust SBOM strategy today.

6.2.1. The Shifting Regulatory Landscape

The years 2025–2026 represent a critical inflection point for SBOM mandates. Key regulatory deadlines are fast approaching:

• USA: Full implementation of mandatory SBOM provision for federal government software procurement.
• EU: SBOM requirements under the Cyber Resilience Act (CRA) will be fully enforced from September 2026.
• Japan, South Korea: Acceleration of government-led SBOM adoption policies.

Experts predict that “2026 will be the real year of SBOM adoption,” making early action a competitive necessity.

6.2.2. The Exponential Growth of Supply Chain Attacks

The threat landscape continues to escalate, underscoring the urgency:

• Threats in open-source package repositories have increased by 1,300% (Source).
• Weaponized vulnerabilities have increased by 10%, with nearly 1% of all vulnerabilities actively exploited in attacks (Source).
• The average loss from a single software supply chain attack is $4.35 million (Source).

Two years after Log4Shell, 38% of applications remain vulnerable, highlighting the critical need for systematic SBOM management.

6.2.3. The Maturation of the Tool Ecosystem

The year 2025 marks a turning point as SBOM management shifts from manual effort to an automated system. Tools that support the OpenChain Telco SBOM Guide are now readily available:

• Validation Tool: The Nokia-contributed OpenChain Telco SBOM Guide Validator.
• Commercial Tool: Native support from SCANOSS.
• Next-Generation Tool: AI-based accuracy enhancement solutions like SIT.

These developments signal a decisive turning point in the history of software supply chain security.

This guide is not about pursuing a grand, unattainable transformation. It is about taking a small but definitive first step. We encourage you to take that step, use this guide to advance your organization’s software supply chain security, and help build a more resilient telecommunications ecosystem for everyone.

Appendix

Appendix A: Full Text of the OpenChain Telco SBOM Guide

• Download the official guide (English): OpenChain-Telco-SBOM-Guide_EN.md
• Download the official guide (Korean): OpenChain-Telco-SBOM-Guide_KR.md

Appendix B: Glossary

Appendix C: Frequently Asked Questions (FAQ)

Q1. Do I have to use a specific tool to create an SBOM?

A. No. The guide is tool-agnostic and only defines the requirements for the final output (SPDX 2.2/2.3 format). You are free to choose any Software Composition Analysis (SCA) tool—such as Syft, FOSSA, SCANOSS, or Black Duck—that best fits your technology stack and budget.

Q2. Is providing an SBOM for our SaaS offering mandatory?

A. The guide defines SBOMs for SaaS as optional (MAY), recognizing the operational complexities. However, it is a recommended best practice, especially for enterprise customers who require transparency. If you choose to provide one, you can deliver it through a secure customer portal or via API.

Q3. How can I quickly verify if an SBOM complies with the guide?

A. To verify compliance, check that the SBOM meets these key requirements:

1. Format: Adheres to SPDX 2.2 or 2.3 in either Tag:Value or JSON format.
2. Completeness: Includes all required fields for Document Creation, Package, and Relationship Information.
3. Traceability: Contains creator information, tool version, and the appropriate CISA SBOM Type (e.g., Build, Source).
4. Scope: Covers all open source and transitive dependencies.
5. Integrity: Includes a digital signature (recommended) to ensure the file is authentic and unaltered.

Q4. How should we update an existing, non-compliant SBOM?

A. Follow these steps:

1. Analyze: Scan the existing SBOM to identify missing fields and format inconsistencies compared to the guide’s requirements.
2. Enrich: Use an SCA tool to re-scan the software and add missing data, such as PURLs, license information, and transitive dependencies.
3. Convert: Transform the enriched data into the required SPDX 2.2/2.3 format (Tag:Value or JSON).
4. Update Metadata: Add the required Creator, Created, and CreatorComment fields.
5. Verify: Apply a digital signature and use a validator tool to confirm full compliance.

Q5. How can we generate an SBOM for a legacy product with limited source code access?

A. For legacy products, a multi-faceted approach is needed:

• Binary Analysis: Use an SCA tool with binary analysis capabilities to generate an SBOM directly from the compiled artifacts.
• Documentation: Supplement the analysis with information from existing build scripts, developer notes, and product documentation.
• Transparency: If some components cannot be identified, explicitly list them as known unknowns to maintain transparency.
• Delivery: If embedding the SBOM is not possible, provide it via a web-hosted link, ensuring access for at least 18 months.

Q6. When and how should we merge multiple SBOM files?

A. Merging is necessary when a single product is assembled from multiple, independently developed components (e.g., microservices, firmware + application). You can use SPDX’s Relationship fields (like CONTAINS or DESCRIBES) to define how the individual SBOMs relate to each other, creating a single, comprehensive SBOM for the entire product. Tools like sbomasm can automate this process.

2 - 2025-12-04 SBOM 표준화와 최신 이슈들

source: https://openchainproject.org/news/2025/12/12/recording-openchain-telco-work-group-2025-12-04

일시: 2025년 12월 4일

참석자: Jimmy Ahlberg (Ericsson), Takashi Ninjouji (Honda), Marc-Etienne Vargenau (Nokia)

주요 의제: CycloneDX 이슈, OpenChain 운영진 변경, CISA 규제 현황, 신규 툴 소개, SPDX 3.0 전환 이슈

1. 주요 공지사항 및 운영 이슈

OpenChain General Manager 사임

OpenChain 프로젝트의 핵심 인물이었던 Shane이 General Manager직을 내려놓게 되었습니다. 그의 마지막 근무일은 12월 12일이며, 현재 후임자는 정해지지 않은 상태입니다. 프로젝트 측에서는 적합한 후보자 추천을 환영하고 있으며, 리더십 공백을 최소화하기 위해 노력하고 있습니다.

반독점(Anti-trust) 정책 준수

미팅은 언제나처럼 OpenChain의 반독점 정책 고지를 확인하며 시작되었습니다. 이는 오픈 소스 컴플라이언스 활동이 공정한 경쟁 환경을 저해하지 않도록 하기 위한 필수적인 절차입니다.

2. SBOM 표준 관련 이슈

CycloneDX v1.7과 우려 사항

최근 릴리스된 CycloneDX v1.7 표준에 대해 Ericsson의 Jimmy Ahlberg가 중요한 우려를 제기했습니다. 이번 버전부터 특허(Patents) 및 특허 패밀리(Patent Families)에 대한 지원이 공식적으로 포함되었는데, 이 필드들이 자칫 ‘특허 괴물(Patent Trolls)‘들에게 악용될 소지가 있다는 점입니다.

• 핵심 이슈: SBOM 내에 특허 정보가 명시적으로 포함될 경우, 공격적인 특허 소송을 주도하는 단체들에게 불필요한 정보를 제공하거나 타겟이 될 위험이 증가할 수 있습니다. 이는 표준 도입 시 신중하게 검토해야 할 부분으로 지적되었습니다.

3. 규제 및 정책 동향: CISA 및 BSI

CISA 최소 요소(Minimum Elements) 문서 지연

미국 사이버보안 및 인프라 보안국(CISA)의 ‘Minimum Elements’ 문서에 대한 업데이트가 지연되고 있습니다. Nokia 측에서 의견을 제출했으나 아직 공식 사이트(regulations.gov)에 반영되지 않았으며, 최종 버전의 발행 시점 또한 불투명한 상황입니다. 이는 관련 기업들의 컴플라이언스 준비에 불확실성을 더하고 있습니다.

독일 BSI의 SPDX 3.0 요구와 업계의 괴리

Honda의 Takashi Ninjouji는 독일 연방정보기술보안청(BSI)의 최신 문서가 SPDX 3.0 사용을 요구하고 있다는 점을 지적했습니다.

• 문제점: 이전 버전에서는 SPDX 2.0만 요구했으나 갑작스럽게 요건이 상향되었습니다. 하지만 Black Duck을 포함한 대부분의 상용 툴은 현재 SPDX 2.0만 지원하고 있어 현장과의 괴리가 큽니다.
• 대안: 현재로서는 spdx-tools-java와 같은 변환 도구를 사용하여 SPDX 2.0 데이터를 3.0으로 변환하는 것이 가장 현실적인 해결책으로 논의되었습니다.

4. 기술 업데이트 및 신규 도구 소개

이번 미팅에서는 실무자들에게 도움이 될 만한 구체적인 툴 업데이트 소식이 다수 공유되었습니다.

(1) Python ntia-conformance-checker 업데이트

NTIA 적합성 검사 도구가 업데이트되어 이제 CISA 문서에 대한 적합성 검사도 지원합니다.

• 기능: 라이선스 및 저작권자(Copyright Holder) 정보 포함 여부를 확인할 수 있습니다.
• 참고: 기본 설정은 여전히 NTIA 기준이므로, CISA 기준을 검사하려면 별도 옵션을 추가해야 합니다. 이 툴을 사용하는 openchain-telco-sbom-validator에는 아직 직접적인 영향이 없습니다.

(2) openchain-telco-sbom-validator 0.3.3 릴리스

Telco 가이드라인 준수 여부를 확인하는 검증기의 새 버전이 배포되었습니다.

• 수정 사항: CISA SBOM 타입 뒤에 주석(comment)이 추가될 때 발생하던 사소한 버그가 수정되었습니다.

(3) Nokia의 신규 도구: pypispdx

Nokia에서 PyPI(Python Package Index)에 등록된 패키지들을 위한 SBOM 생성 도구인 pypispdx를 공개했습니다.

• 주요 기능:
  • SPDX 2.3 포맷 지원 (tag:value, JSON, RDF, XML, YAML)
  • OpenChain Telco SBOM 가이드 준수
  • 패키지의 재귀적 의존성(Recursive dependencies) 포함
  • 패키지 다운로드 위치, 체크섬(SHA256, MD5), 라이선스 정보 자동 포함

5. 향후 계획 및 워킹 그룹 활동

Telco 가이드의 SPDX 3.0 대응

Automotive 워킹 그룹에서는 이미 Yocto 프로젝트에서 생성된 SPDX 3.0 데이터를 Telco 가이드 기준으로 검증하려는 시도가 있었습니다. 하지만 현재 검증기가 사용하는 Python 라이브러리가 SPDX 3.0을 파싱하지 못하는 한계가 있습니다.

• 대응: 관련 라이브러리의 새 유지보수자가 지명되었으므로 업데이트를 기다리는 중이며, Telco 워킹 그룹 차원에서도 가이드라인을 SPDX 3.0까지 포용할 수 있도록 개정하는 논의를 시작하기로 했습니다.

문서 개선

Jimmy Ahlberg는 암호화(Encryption) 관련 단락의 문구를 더 명확하게 개선하여 업데이트할 예정입니다.

마치며

이번 12월 미팅은 기술적 표준의 변화(SPDX 3, CycloneDX 1.7)와 규제 기관의 요구사항(CISA, BSI) 사이에서 실무적인 대응 방안을 모색하는 자리였습니다. 특히 툴링 생태계가 표준의 진화 속도를 따라가지 못하는 상황에서, pypispdx와 같은 새로운 도구의 등장은 환영할 만한 소식입니다.

OpenChain Telco Work Group은 누구나 참여할 수 있는 열린 공간입니다. 관심 있는 분들은 언제든 메일링 리스트나 GitHub을 통해 참여해 주시기 바랍니다.

• 메일링 리스트: https://lists.openchainproject.org/g/telco
• GitHub 저장소: https://github.com/OpenChain-Project/Telco-WG

by Gemini 3.0

3 - 2025-11-06 CISA 셧다운의 영향과 SBOM 품질 가이드 집중 점검

source: https://openchainproject.org/news/2025/11/11/telco-2025-11-06

일시: 2025년 11월 6일

참석자: Marc-Etienne Vargenau (Nokia, 의장), Shane Coughlan (OpenChain), Norio Koboto (Sony), Masahiro Daikoku (KDDI), Jari Koivisto (Analog Devices) 등

이번 OpenChain Telco Work Group(이하 Telco WG) 정기 미팅에서는 미국 정부 셧다운이 CISA(사이버보안 및 인프라 보안국)의 업무에 미치는 영향부터, 차기 Telco Guide 업데이트 방향, 그리고 최근 업데이트된 SBOM 품질 가이드(Quality Guide)에 대한 심도 있는 기술적 검토가 이루어졌습니다.

미팅에 직접 참여하지 못하신 분들을 위해 핵심 내용을 상세히 요약해 드립니다.

1. CISA 동향: 정부 셧다운과 인력 공백

이번 미팅의 서두는 현재 미국 정부의 셧다운 사태가 공급망 보안 규제 기관인 CISA에 미치는 영향에 대한 논의로 시작되었습니다.

주요 업데이트

• 업무 마비: 현재 셧다운으로 인해 CISA 직원의 약 2/3가 사무실에 출근하지 못하고 있는 상황입니다.
• 핵심 인력 부재: SBOM 확산을 주도했던 Allan Friedman이 CISA를 떠났으며, 그의 후임자 역시 셧다운 영향으로 업무를 시작하지 못한 상태라 리더십 공백이 발생했습니다.
• 의견 수렴 지연: OpenChain WG와 Nokia 등 여러 기업이 CISA의 ‘Minimum Elements(최소 요소)’ 문서에 대한 의견(Comments)을 제출했으나, 셧다운으로 인해 처리가 지연되고 있습니다. 특히 마감 직전에 제출된 Nokia의 코멘트는 시스템에 반영조차 되지 않은 상태입니다.

쟁점: SBOM에 ‘라이선스 정보’가 필요한가?

CISA 문서에 대한 업계의 피드백은 엇갈리고 있습니다.

• 찬성 측: 라이선스 정보도 투명성 확보 차원에서 포함되어야 한다.
• 반대 측: 라이선스는 ‘보안(Security)‘과 직접적인 관련이 없으므로 보안 중심 문서인 SBOM 필수 요소에서 제외해야 한다.

Telco WG의 대응 방향:

현재 Telco Guide v1.0 및 1.1에서는 라이선스 정보가 필수지만, 값을 NOASSERTION(정보 없음)으로 표기하는 것을 허용하고 있습니다.

하지만 Draft v1.2에서는 NOASSERTION을 허용하지 않고 실제 라이선스 정보를 기입하도록 강화할 예정이었습니다. WG는 CISA가 최종적으로 라이선스 정보를 필수 요소로 확정할지 여부를 지켜본 후, 이 방침을 유지할지 결정하기로 했습니다.

2. Telco Guide 및 Validator(검증기) 업데이트

암호화(Encryption) 챕터 추가 건

Ericsson의 Jimmy Ahlberg가 제안했던 ‘암호화 관련 챕터’ 추가는 문구 수정이 더 필요한 상황입니다. 제안자가 현재 아시아 출장 및 한국 행사 참석 일정으로 인해 수정안을 제출하지 못해, 다음 미팅에서 다시 논의하기로 했습니다.

Validator(검증 도구) 이슈

• 버그 수정: CISA SBOM Type을 처리하는 과정에서 발견된 사소한 버그가 수정되어 곧 마이너 릴리스가 배포될 예정입니다.
• SPDX 3.0 지원의 어려움: 지난 10월 미팅에서 Telco Validator가 SPDX 3.0 스펙을 지원해야 한다는 제안이 있었습니다. 하지만 현재 Validator가 의존하고 있는 파이썬 라이브러리(tools-python)가 SPDX 3.0을 지원하지 않아 구현이 어렵습니다.
  • 해당 라이브러리는 1년 넘게 업데이트가 없었으나, 최근 새로운 메인테이너가 지명되어 향후 업데이트를 기대해볼 수 있는 상황입니다.

3. 심층 분석: SBOM 품질 가이드(Quality Guide) 검토

미팅의 대부분은 현재 작성 중인 SBOM Quality Guide 문서를 검토하는 데 할애되었습니다.

(1) BSI(독일 연방정보보안청)의 급진적인 SPDX 3.0 도입

독일 BSI의 최신 가이드라인(TR-03183-2 v2.1.0) 내용이 공유되었는데, 이 내용이 상당히 파격적이라 우려의 목소리가 나왔습니다.

• 내용: BSI는 SBOM 포맷으로 SPDX 3.0.1 이상 또는 CycloneDX 1.6 이상을 의무화(Mandate)하고, SPDX 2.x 버전 사용을 사실상 배제했습니다.
• WG의 우려: 이는 시기상조(Premature)라는 의견이 지배적입니다. 현재 BlackDuck을 포함한 대다수의 상용 SCA 도구들이 여전히 SPDX 2.2나 2.3만 지원하고 있으며, SPDX 3.0을 완벽히 지원하는 도구는 거의 없기 때문입니다.

(2) 용어의 명확화: “Build Information”

가이드 문서의 섹션 3.5인 “SBOM Build information"이라는 용어가 혼란을 줄 수 있다는 지적이 있었습니다.

• 문제점: 독자들이 이를 ‘소프트웨어를 빌드하는 시점의 정보’로 오해할 수 있음.
• 수정 제안: “SBOM Document Build Information"으로 명칭을 변경하여, 이것이 소프트웨어 자체가 아니라 SBOM 문서가 생성된 시점과 도구에 대한 정보임을 명확히 하기로 했습니다.

(3) 패키지 식별자 (Package Identifier)

문서에서는 SWHID, PURL, CPE 등 다양한 식별자를 나열하고 있습니다.

• Telco WG의 권장: Telco Guide는 PURL (Package URL) 사용을 권장합니다.
• 표준화 현황: PURL은 곧 ECMA 표준이 될 예정이며, 이후 패스트트랙을 통해 ISO 표준으로 제정될 것으로 예상됩니다. Shane Coughlan(OpenChain)은 ECMA 표준 제정 후 ISO화 되기까지 약 9개월 정도가 소요될 것으로 전망했습니다.

(4) ‘알려진 미지(Known Unknowns)‘의 표현

공급망 내에서 일부 종속성 정보가 누락되었음을 인지하고 있지만, 그 내용이 무엇인지 모르는 경우(Known Unknowns)를 SPDX로 표현하는 것이 기술적으로 까다롭다는 논의가 있었습니다.

• 현업에서는 종종 공급업체가 하위 모듈에 대한 조사를 하지 않아 정보를 제공하지 않으면서, 단순히 “모른다"고만 표기하는 경우가 많습니다. 이를 데이터 필드에 어떻게 정확히 매핑할지가 과제로 남아 있습니다.

4. 향후 일정 및 참여 안내

문서 검토 요청

이번에 논의된 문서들은 오는 12월 일본에서 열리는 Open Compliance Summit에서 발표될 예정입니다. 따라서 WG 멤버들은 그전까지 문서에 대한 코멘트를 적극적으로 제출해 줄 것을 요청받았습니다.

참여 방법

OpenChain Telco WG는 모든 이에게 열려 있습니다. 관심 있는 분들은 아래 채널을 통해 참여하실 수 있습니다.

• 메일링 리스트: https://lists.openchainproject.org/g/telco
• GitHub 저장소: https://github.com/OpenChain-Project/Telco-WG

by Gemini 3.0

4 - 2024-12-06 SBOM 가이드라인 업데이트 논의

source: https://openchainproject.org/news/2024/12/12/telco-work-group-2024-12-06

목차

1. 인도의 SBOM 기술 가이드라인 검토
2. OpenChain Telco SBOM 가이드 개선 방안
3. SBOM 도구 관련 업데이트

1. 웨비나 개요

발표자 소개

이번 웨비나는 OpenChain Telco Work Group의 정기 미팅으로, Nokia의 오픈소스 전문가가 진행을 맡았습니다.

웨비나 목적

SBOM 관련 최신 기술 가이드라인을 검토하고 OpenChain Telco SBOM 가이드의 개선 방안을 논의하기 위해 개최되었습니다.

2. 인도의 SBOM 기술 가이드라인 검토

가이드라인 개요

Indian Computer Emergency Response Team (CERT-In)에서 2023년 10월에 발표한 SBOM 기술 가이드라인에 대해 논의했습니다. 이 가이드라인은 주로 공공 부문의 보안 관점에 초점을 맞추고 있습니다.

주요 특징

• 21개의 필수 요소를 정의하고 있으며, 이는 NTIA 최소 요구사항보다 더 많은 항목을 포함
• End-of-life date와 같은 현실적으로 구현이 어려운 필드들이 포함
• 공공 부문과 필수 서비스 영역을 주요 대상으로 함
• 강제성은 없으나 SBOM 생성과 제공을 권장

(참고) 인도 정부 발간 SBOM 가이드라인 한국어 번역

• 인도 SBOM 가이드라인

3. OpenChain Telco SBOM 가이드 개선 방안

버전 1.1 업데이트 제안사항

• Component Hash 제공 방식 유연화
  • Package Checksum 외에도 Package Verification Code 허용
  • CISA의 Common SBOM Requirements와 일관성 유지

필수 필드 완화

• File Analyzed 필드를 필수에서 제외
• Package License (concluded/declared) 관련 SPDX 2.2와 2.3 버전 차이 반영
• External Ref 필드와 PURL 관련 요구사항 조정

도구 관련 업데이트

• SBOM 병합 도구로 Interlink의 ASML을 추천
• SPDX 유효성 검증 개선 사항 반영

4. 향후 계획

• 버전 1.1 초안에 대한 커뮤니티 피드백 수집
• 보안 정보의 SBOM 포함 여부에 대한 추가 논의 필요
• 일본 SBOM 그룹과의 협력 강화

요약 보고서

기업 오픈소스 관리자를 위한 시사점

1. SBOM 표준화가 전 세계적으로 진행 중이며, 특히 공공 부문을 중심으로 확산
2. 필수 요소에 대한 국가별/산업별 요구사항이 상이하므로 유연한 대응 필요
3. SBOM 도구 생태계가 지속적으로 발전 중이며, 도구 선택 시 표준 준수성 고려 필요

주요 Action Items

1. SBOM 생성 시 Component Hash 제공 방식 검토 및 개선
2. SPDX 2.2/2.3 버전 차이를 고려한 라이선스 정보 관리 체계 수립
3. SBOM 병합 도구 평가 및 도입 검토
4. 보안 정보 관리 방안 수립 (SBOM 포함 여부 결정)
5. 국가별 SBOM 가이드라인 모니터링 및 대응 체계 구축