Resource

• 1: Specification
• 2: Curriculum
• 3: External Resources
• 4: AI Work Group
• 4.1: 2025-12-02 AI SBOM 규정 준수 가이드의 완성도 제고와 조달용 AI 설문지 도입 논의
• 4.2: 2025-10-20 OpenChain AI SBOM 컴플라이언스 가이드
• 4.3: 2025-10-09 AI SBOM 가이드 완성 및 글로벌 거버넌스 전략
• 4.4: 2024-12-03 AI Compliance BOM 가이드 웨비나
• 4.5: 2024-11-05 AI BOM 관리와 워킹그룹 전환 논의
• 5: SBOM Work Group
• 5.1: SOFTWARE BILL OF MATERIALS (SBOM)에 대한 기술 가이드라인 (인도 정부 발간)
• 5.2: 2025-11-26 대규모 공급망에서 SBOM을 어떻게 운영 단계에 적용할 것인가?
• 5.3: 2025-10-27 SBOM 품질 가이드와 규제 대응의 구체화
• 5.4: 2024-11-27 취약점과 미래 - 다층적 소프트웨어 취약점과 대응 전략
• 5.5: 2024-10-29 SBOM 관련 다양한 규제와 가이드라인에 대한 개요
• 5.6: 2024-07-30 킥오프 웨비나: SBOM의 실제 활용 방안 모색
• 6: Telco Work Group
• 6.1: A Handbook for Software Supply Chain Security in the Telco Industry
• 6.2: 2025-12-04 SBOM 표준화와 최신 이슈들
• 6.3: 2025-11-06 CISA 셧다운의 영향과 SBOM 품질 가이드 집중 점검
• 6.4: 2024-12-06 SBOM 가이드라인 업데이트 논의
• 7: Webinars
• 7.1: 2025-12-03 생성형 AI, 개발의 '속도'와 '위험' 사이: 우리는 어떻게 관리해야 할까?
• 7.2: 2025-12-03 Software Hash ID (SWHID): 이제는 선택이 아닌 필수입니다
• 7.3: 2025-11-07 컨테이너와 오픈소스 컴플라이언스: 무엇이 문제이고 어떻게 해결할 것인가?
• 7.4: 2025-09-16 EU Cyber Resilience Act (CRA): 오픈소스 개발자가 반드시 알아야 할 생존 가이드
• 7.5: 2025-09-12 컨테이너 컴플라이언스, OSADL Base Image로 해결하세요
• 7.6: 2024-12-20 DeviceCode - 크라우드소싱 기반 디바이스 데이터 파서
• 7.7: 2024-12-16 ISO 표준화의 여정 – OpenChain 사례를 통해 배우는 표준 개발
• 7.8: 2024-12-13 ISO 5230과 ISO 18974가 법률 전문가에게 미치는 영향과 2024년 전망
• 7.9: 2024-12-12 CHAOSS Practitioner Guides를 활용한 건강하고 지속 가능한 OSS 프로젝트 구축
• 7.10: 2024-12-05 리눅스 재단에서 SBOM을 활성화하는 과정
• 7.11: 2024-12-04 OpenChain ISO 표준이 InnerSource를 지원하는 방법 이해하기
• 7.12: 2024-10-29 SBOM 시각화 - SBOM 검토를 위한 대안적 접근법
• 7.13: 2024-10-10 데이터가 AI 공급망에서 차지하는 역할
• 7.14: 2024-09-27 AI: 현재의 법적 환경

1 - Specification

What is the OpenChain Specification?

The OpenChain Specification is a 12-page standard specification that defines key requirements for open source compliance, and is designed to be suitable for companies in all fields regardless of the size or industry of the enterprise. In December 2020, the OpenChain Specification 2.1 was released, describing six requirements that companies must perform to achieve open source compliance and defining a list of verification materials that can prove that companies are doing so.

1. Program Foundation
2. Relevant Tasks Defined and Supported
3. Open Source Content Review and Approval
4. Compliance Artifact Creation and Delivery
5. Understanding Open Source Community Engagements
6. Adherence to the Specification Requirements

If you are new to open source compliance, you can improve your level by meeting the requirements of this OpenChain Specification one by one.

Specification translation policy

In the case of the specification, the OpenChain Project does not adopt the translations made by one individual as an official version. They have a policy that requires translation and supervision by at least two individuals or organizations to ensure that correct translations are released.

For detailed translation policy on OpenChain Specification, refer to the following page. : https://www.openchainproject.org/contribute-to-the-standard

Specification translation status

The Korean translation of the OpenChain Specification has been translated up to version 2.1 and can be downloaded from the following page. : https://github.com/OpenChain-Project/Specification/tree/master/Official/ko/2.1

Specification Contributors

The main contributors to Korean translation of the OpenChain Specification are as follows.

How to join

Specification Korean translation is jointly performed on GitHub, and anyone can participate. Please join!

2 - Curriculum

What is OpenChain Curriculum?

The OpenChain Project created and released educational materials necessary for building a compliance program.: https://github.com/OpenChain-Project/Curriculum

Since it was released as CC-0, companies can use it to create training materials within the company, and the most recent materials can be downloaded from the following link.

• PPT
• PDF
• ODP

Translation status

The Korean translation of OpenChain Curriculum has been translated up to version 1.2 and can be downloaded from the following page.

• OpenChain Curriculum Korean

Contributors

The main contributors to Korean translation are as follows.

How to join

Curriculum Korean translation is jointly performed on GitHub, and anyone can participate. Please join!

3 - External Resources

Training materials

NCSOFT open source training materials

• NCSOFT training materials : LINK
• Kakao training materials : LINK

Study materials

Open Source Compliance in the Enterprise book summary

NCSOFT summarizes the main contents of this book in Korean, and after obtaining permission from the author, Ibrahim, published on GitHub.

For more information, refer to the following link: LINK

Open Source Tools

Source Code Scanning Tools

• FOSSology: FOSSology Introduction and Usage

Dependency Analysis Tools

• ORT (OSS Review Toolkit) : https://github.com/oss-review-toolkit/ort#analyzer

• FOSSLight Dependency Scanner : https://github.com/fosslight/fosslight_dependency_scanner

SBOM Management Tools

• SW360: SW360 Introduction and Usage
• FOSSLight: https://fosslight.org

Open Source Compliance Artifact Generation Tools

• Open Source Notice Generation Tools - onot: https://github.com/sktelecom/onot

Open Source Compliance Output Archive Tool

• SK Telecom Open Source Website Case: https://github.com/sktelecom/sktelecom.github.io

4 - AI Work Group

4.1 - 2025-12-02 AI SBOM 규정 준수 가이드의 완성도 제고와 조달용 AI 설문지 도입 논의

source: https://openchainproject.org/news/2025/12/11/recording-openchain-ai-work-group-monthly-workshop-for-north-america-and-europe-2025-12-02

OpenChain AI 워크그룹은 오픈 소스 컴플라이언스의 국제 표준인 OpenChain(ISO/IEC 5230)의 원칙을 인공지능(AI) 영역으로 확장하여, 신뢰할 수 있는 AI 공급망 구축을 목표로 매월 워크숍을 진행하고 있습니다. 이번 12월 2일 북미/유럽 세션은 Matthew Crawford(Arm) 와 Dave Marr(Qualcomm) 의 주재로 진행되었으며, 주로 AI 시스템 자재명세서(AI SBOM) 컴플라이언스 가이드의 세부 문구 조정과 AI 조달(Procurement)을 위한 표준 설문지 개발 필요성에 대한 논의가 이루어졌습니다.

1. 주요 안건 개요

이번 워크숍의 핵심 아젠다는 크게 두 가지로 요약됩니다.

1. AI SBOM 컴플라이언스 가이드(Compliance Guide) 최종 검토: 기배포된 가이드의 세부 조항(특히 프로세스 및 역량 관련)에 대한 피드백 반영 및 문구 수정.
2. AI 조달용 표준 설문지(AI Questionnaire) 제안: 기업 간 AI 솔루션 도입 시 반복적으로 발생하는 중복 질문을 해소하기 위한 표준화된 질의서 개발 논의.

2. 상세 논의 내용: AI SBOM 컴플라이언스 가이드

미팅의 전반부는 현재 마무리 단계에 있는 ‘AI SBOM 컴플라이언스 가이드’의 특정 섹션을 검토하고 수정하는 데 할애되었습니다. 단순한 오타 수정이 아닌, 실제 현업에서 적용 가능한 ‘프로세스’와 ‘정책’의 정의를 명확히 하는 토론이 주를 이루었습니다.

2.1. 역할과 역량(Competence)의 명문화

참석자들은 AI 컴플라이언스 프로그램의 성패가 결국 ‘사람’에게 달려 있다는 점에 동의하며, 가이드 내에 “프로그램 참여자의 역량(Competence)” 을 규정하는 문구를 다듬었습니다.

• 주요 변경 사항: 프로그램의 효과성과 성과에 영향을 미치는 역할을 식별하고, 해당 역할을 수행하는 담당자의 역량을 결정해야 한다는 내용이 강조되었습니다.
• 세부 요건: 담당자는 적절한 기술(skills), 지식(knowledge), 경험(experience)을 갖추어야 하며, 해당 사용 사례(use case)와 관련된 기능 조직과 긴밀히 협력해야 합니다.

2.2. 정책(Policy) vs 프로세스(Process)

논의 중 가장 흥미로웠던 부분은 ‘정책’과 ‘프로세스’를 구분하여 기술하는 방식에 대한 것이었습니다.

• 쟁점: 급변하는 AI 규제 환경(예: EU AI Act 등)을 고려할 때, 너무 경직된 규칙을 만들면 실제 규제가 바뀌었을 때 가이드가 무용지물이 될 수 있다는 우려가 제기되었습니다.
• 합의점:
  • 정책(Policy): 조직이 갖춰야 할 대원칙(예: “우리는 AI SBOM을 관리한다”).
  • 프로세스(Process): 정책을 실행하기 위한 구체적인 과업(Task).
  • 워크그룹은 이 두 가지를 분리하여 접근하되, “두 가지 모두를 검토할 수 있는 프로세스를 갖추라"는 식의 유연한 언어를 사용하기로 했습니다. 이는 규제 변화에 유동적으로 대응하면서도 운영의 연속성을 보장하기 위함입니다.

2.3. AI SBOM의 정의와 범위

AI SBOM 생성 및 관리에 대한 조항도 구체화되었습니다.

• 포맷의 자유: AI SBOM은 특정 포맷에 구애받지 않으나(This can be in any format), 반드시 존재해야 합니다.
• 범위: 특히 제3자로부터 유입되는 인바운드(Inbound) 자료를 반드시 포함해야 함을 명시했습니다. 이는 공급망 보안의 핵심으로, 외부에서 도입한 모델이나 데이터셋의 출처를 투명하게 관리해야 한다는 의무를 강조한 것입니다.

3. 신규 제안: AI 조달용 표준 설문지 (AI Questionnaire)

미팅 후반부에는 Matthew Crawford가 제안한 새로운 이니셔티브인 ‘조달 목적의 AI 설문지(AI Questionnaire for Procurement Purposes)’ 가 논의되었습니다.

3.1. 문제 제기

현재 많은 기업이 외부 공급업체로부터 AI 도구나 서비스를 도입할 때, 각자의 기준대로 수많은 질문을 던지고 있습니다.

• “이 모델의 학습 데이터는 무엇인가?”
• “데이터 카드는 존재하는가?”
• “모델 카드는 작성되었는가?”

이로 인해 공급업체는 고객사마다 다른 양식의 질문에 답변해야 하는 비효율이 발생하고, 구매사는 필요한 정보를 누락할 위험이 있습니다.

3.2. 제안 내용

OpenChain 프로젝트 차원에서 이러한 질문들을 표준화하자는 제안이 나왔습니다. 기존의 프로세스 점검을 넘어, 모델(Model), 데이터셋(Dataset), 데이터 카드(Data Cards), 모델 카드(Model Cards) 와 관련된 구체적인 스펙을 묻는 공통 질문지를 만들자는 것입니다.

• 목표: 공급업체가 한 번 작성하면 여러 고객사에게 제출할 수 있는 표준 양식을 제공하여 생태계 전반의 효율성을 높임.
• 반응: 참석자들은 이에 대해 긍정적인 반응을 보였으며, 단순히 프로세스 유무를 묻는 것을 넘어 실제 AI 자산(Asset)에 대한 구체적인 정보를 요구하는 방향으로 발전시키기로 했습니다.

4. 향후 계획 및 참여 안내

4.1. 1월 웨비나 예고

다음 달(2026년 1월) 미팅은 일반적인 워크숍 형식이 아닌, 대중을 위한 웨비나(Webinar) 형태로 진행될 예정입니다.

• 주제: AI SBOM 컴플라이언스 가이드의 역사와 개발 과정, 그리고 최종 가이드의 내용을 상세히 설명 (“Walk through the guide”).
• 목적: 가이드를 널리 알리고 더 많은 기업이 채택하도록 독려하기 위함입니다.

4.2. 커뮤니티 참여 요청

워크그룹은 AI 전문가들(Practitioners)과의 교류를 강조했습니다. 법무팀이나 컴플라이언스팀뿐만 아니라, 실제 AI를 개발하고 운영하는 엔지니어들의 피드백이 가이드의 현실성을 높이는 데 필수적이기 때문입니다. 학회나 컨퍼런스에서 AI 개발자들을 만난다면 OpenChain의 활동을 알리고 피드백을 받아달라는 요청이 있었습니다.

5. 결론 및 요약

이번 12월 워크숍은 AI 컴플라이언스 가이드의 완성도를 높이는 작업과 시장의 비효율을 해결할 새로운 도구(표준 설문지)를 구상하는 단계로 요약할 수 있습니다. 특히 ‘사람의 역량’과 ‘인바운드 자재 관리’를 강조한 점은 AI 거버넌스가 단순한 서류 작업을 넘어 실질적인 리스크 관리로 진화하고 있음을 보여줍니다.

OpenChain 프로젝트는 누구나 참여할 수 있는 개방형 커뮤니티입니다. 이번 논의 내용에 대해 의견이 있거나, 1월 웨비나에 참여하고 싶으신 분들은 아래 채널을 참고해 주시기 바랍니다.

• 메일링 리스트 가입: https://lists.openchainproject.org/g/ai
• 공식 홈페이지: https://www.openchainproject.org

by Gemini 3.0

4.2 - 2025-10-20 OpenChain AI SBOM 컴플라이언스 가이드

source: https://openchainproject.org/news/2025/10/20/welcoming-the-openchain-ai-system-bill-of-materials-compliance-guide

안녕하세요! OpenChain 프로젝트에서 새롭게 공개한 AI System Bill of Materials (AI SBOM) Compliance Guide를 블로그 포스팅 형태로 소개해 드리겠습니다.

이 가이드는 AI 기술이 급격히 확산되는 공급망 환경에서, 조직 간의 신뢰를 구축하고 투명성을 확보하기 위해 만들어진 중요한 자료입니다.

인공지능(AI) 기술이 소프트웨어 공급망의 핵심 요소로 자리 잡으면서, AI 시스템을 구성하는 데이터, 모델, 라이선스 등을 투명하게 관리하는 것이 그 어느 때보다 중요해졌습니다. 리눅스 재단(Linux Foundation) 산하의 OpenChain Project는 이러한 요구에 발맞춰 “AI 시스템 자재 명세서(AI SBOM) 컴플라이언스 관리 가이드"를 공식 발표했습니다.

이 가이드는 AI 솔루션을 주고받는 조직들이 신뢰할 수 있는 컴플라이언스 프로그램을 구축하는 데 필요한 핵심 기준을 제시합니다.

1. 가이드의 목적 (Purpose)

이 가이드의 가장 큰 목적은 AI 솔루션을 교환하는 조직 간의 신뢰 구축입니다.

AI 시스템은 코드뿐만 아니라 학습 데이터(Data), 가중치(Weights), 모델(Model) 등 복합적인 요소로 이루어져 있어, 기존의 소프트웨어보다 관리가 까다롭습니다. 이 가이드는 조직이 고품질의 ‘AI SBOM 컴플라이언스 프로그램’을 갖추기 위해 충족해야 할 주요 요구사항을 정의하여, 일종의 벤치마크(Benchmark) 역할을 합니다.

2. 가이드의 쓰임새와 특징 (Usage & Features)

이 문서는 구체적인 기술적 구현 방법(“How"나 “When”)보다는 프로그램이 무엇을 갖춰야 하고(What), 왜 필요한지(Why)에 집중합니다.

• 유연성(Flexibility): 기업의 규모나 시장 환경에 따라 정책과 프로세스를 유연하게 적용할 수 있도록 설계되었습니다.
• 핵심 프로세스 식별: AI 컴플라이언스 프로그램에 반드시 포함되어야 할 주요 프로세스 포인트(정책, 역량, 라이선스 의무 등)를 명시합니다.
• 표준 기반: 오픈소스 컴플라이언스 국제 표준인 ISO/IEC 5230에서 영감을 받았으며, AI 경영 시스템 표준인 ISO/IEC 42001 등 관련 국제 표준을 참조하여 작성되었습니다.

[한국어 번역] AI SBOM 공급망 컴플라이언스 관리 가이드

본 번역은 독자의 이해를 돕기 위해 원문을 바탕으로 작성되었습니다. 공식적인 법적 효력은 원문(Version 1.0)에 있습니다.

1. 범위 (Scope)

이 문서는 공급망 내에서 AI 컴플라이언스를 관리하기 위한 주요 요구사항을 명시합니다. 특히 이 목표를 달성하기 위해 AI SBOM(AI 시스템 자재 명세서)을 사용하는 데 중점을 둡니다.

2. 용어 및 정의 (Terms and Definitions)

• 2.1 인공지능 (Artificial Intelligence, AI): 이전에 인간의 지능이 필요했던 작업을 수행할 수 있는 컴퓨터 시스템.
• 2.2 인공지능 시스템 자재 명세서 (AI SBOM): AI 시스템의 전체 또는 일부를 구성하는 컴포넌트(구성 요소)와 해당 컴포넌트에 대한 관련 정보의 목록.
• 2.3 AI SBOM 컴플라이언스 (Compliance): 라이선스, 규제 또는 비즈니스 요구사항을 지원하기 위해 자재 명세서(Bill of Materials)를 사용하는 AI 관련 컴플라이언스 활동.
• 2.5 식별된 라이선스 (Identified Licenses): 공급된 소프트웨어를 구성하는 컴포넌트를 식별하는 적절한 방법을 따른 결과로 확인된 라이선스 집합.
• 2.8 공급된 소프트웨어 (Supplied Software): 조직이 제3자에게 제공하거나 사용 가능하게 만든 소프트웨어.

3. 지침 (Guidance)

조직이 AI 관련 컴플라이언스를 달성하는 방법은 조직의 규모, 산업, 사법권, AI 시스템의 형태(서비스, 모델, 데이터 등)에 따라 달라질 수 있습니다. 본 가이드는 대부분의 조직에 적용할 수 있는 핵심 프로세스 포인트를 다음과 같이 식별합니다.

3.1 정책 (Policy)

AI SBOM 컴플라이언스를 관할하는 서면 정책이 존재해야 합니다.

• 이 정책은 내부적으로 소통되어야 하며, 비즈니스 전략, 관련 사법권의 법적 요구사항, 사용 사례에 적합한 위험 수준을 반영해야 합니다.
• 검증 자료: 문서화된 정책 및 해당 정책을 프로그램 참여자들에게 알리는 절차(교육, 내부 위키 등).

3.2 역량 (Competence)

조직은 프로그램의 효과성에 영향을 미치는 역할과 책임을 식별해야 합니다.

• 거버넌스, 보안, 안전, 프라이버시, 개발, 공급업체 관리 등과 관련된 참여자의 역량을 결정하고, 적절한 교육이나 경험을 통해 이를 보장해야 합니다.
• 검증 자료: 역할 및 책임 목록, 각 역할에 필요한 역량 명세서, 역량 평가 기록.

3.3 인식 (Awareness)

조직은 프로그램 참여자들이 다음 사항을 인지하도록 보장해야 합니다.

• AI SBOM 정책 및 관련 비즈니스 목표.
• 프로그램 효과성에 대한 본인의 기여.
• 프로그램 요구사항을 따르지 않았을 때의 영향(Implications).

3.4 프로그램 범위 (Program Scope)

프로그램이 적용되는 범위를 명확히 선언해야 합니다. (예: 단일 제품 라인, 전체 부서 또는 전체 조직)

3.5 라이선스 의무 (License Obligations)

AI 시스템의 코드, 가중치(Weights), 데이터셋(학습, 테스트, 검증 데이터 포함) 및 AI 시스템 자체에 대해 식별된 라이선스를 검토하는 프로세스가 존재해야 합니다.

• AI 시스템의 의도된 사용 목적을 고려하여 각 라이선스가 부여하는 의무, 제한 사항, 권리를 결정해야 합니다.
• 참고: AI 시스템은 모델 트리(Model Tree)에 식별된 다른 여러 AI 시스템으로 학습되었을 수 있으며, 각각 별도의 라이선스를 가질 수 있습니다.

3.6 투명성 의무 (Transparency Obligations)

학습, 테스트, 검증 데이터셋 등을 포함하여 규제로부터 발생하는 투명성 의무가 있는지 검토하는 프로세스가 존재해야 합니다.

• 학습 데이터의 사용 사례가 투명성 맥락에서 이슈(예: 다운스트림 수신자에 대한 공개 의무)를 발생시키는 경우, 적절한 위험 완화 조치를 취해야 합니다.

3.7 접근성 (Access)

외부의 AI SBOM 컴플라이언스 문의에 효과적으로 대응하는 프로세스를 유지해야 합니다.

• 제3자가 문의할 수 있는 수단(예: 공개된 이메일 주소)을 공개적으로 식별해야 합니다.

3.8 효과적인 자원 지원 (Effectively Resourced)

• 프로그램 과제의 성공적인 실행을 위해 책임을 할당하고, 시간과 예산을 충분히 배정해야 합니다.
• 정책 및 지원 과제를 검토하고 업데이트하는 프로세스가 있어야 합니다.
• AI SBOM 컴플라이언스 문제를 해결하기 위한 프로세스와 법적 전문 지식에 대한 접근성이 확보되어야 합니다.

3.9 AI 시스템 자재 명세서 (AI System Bill of Materials)

AI SBOM을 생성하고 관리하는 프로세스가 존재해야 합니다.

• 형식은 SPDX, CycloneDX 또는 기타 형식이 될 수 있습니다.
• AI SBOM은 제3자로부터 유입된 자재(Inbound materials)를 설명할 수 있어야 합니다.
• 검증 자료: AI 시스템의 컴포넌트(모델, 데이터셋 등)와 관련된 정보를 식별, 추적, 검토, 승인, 보관하는 문서화된 절차.

3.10 거버넌스 (Governance)

조직은 AI 시스템이 책임감 있게 개발, 배포, 관리되도록 보장하는 AI 거버넌스 프레임워크를 갖추어야 합니다.

• EU AI 법(EU AI Act) 등 신흥 AI 법규 준수를 강조하고 윤리적 고려사항, 위험 관리, 투명성을 다룹니다.
• AI 시스템의 수명 주기를 모니터링하고 의도된 사용에 대한 지속적인 분석을 수행할 수 있어야 합니다.

이 가이드는 현재 버전 1.0이며, 빠르게 변화하는 AI 생태계에 맞춰 지속적으로 업데이트될 예정입니다. 더 자세한 내용이나 원문(PDF)은 OpenChain 프로젝트 공식 웹사이트를 참고하시기 바랍니다.

by Gemini 3.0

4.3 - 2025-10-09 AI SBOM 가이드 완성 및 글로벌 거버넌스 전략

source: https://openchainproject.org/news/2025/10/27/recording-openchain-ai-work-group-asia-sync-2025-10-09

작성일: 2025년 10월 27일

주제: OpenChain AI 워크그룹 Asia Sync 미팅 (2025-10-09) 핵심 요약 및 인사이트

안녕하세요. 지난 10월 9일 진행된 OpenChain AI Work Group – Asia Sync 미팅의 상세 내용을 정리하여 공유드립니다. 이번 미팅은 북미/유럽 워크숍의 논의 내용을 바탕으로 아시아 시간대 참여자들을 위해 진행되었으며, 무엇보다 ‘AI SBOM 규정 준수 관리 가이드(AI SBOM Compliance Management Guide)‘의 완성이라는 중대한 마일스톤이 발표된 자리였습니다.

단순한 일정 공유를 넘어, 현재 글로벌 AI 공급망 관리가 어떤 방향으로 흐르고 있는지, 그리고 오픈체인 프로젝트가 규제 당국(UK 등) 및 타 단체(FINOS)와 어떻게 협력하고 있는지에 대한 중요한 로드맵이 제시되었습니다.

1. 핵심 성과: AI SBOM 규정 준수 관리 가이드 완성 및 런칭

이번 미팅의 가장 큰 뉴스는 단연 AI SBOM 규정 준수 관리 가이드(AI SBOM Compliance Management Guide)의 완성 소식입니다.

가이드의 목적과 의의

OpenChain 프로젝트팀은 지난 2024년 1월부터 AI 공급망 내에서 규정 준수(Compliance)를 어떻게 관리할 것인지에 대해 치열하게 고민해 왔습니다. 이번에 완성된 가이드는 그 결과물로서, AI 시스템을 구성하는 모델, 데이터셋, 코드, 그리고 각종 종속성(Dependencies)을 투명하게 관리하기 위한 실질적인 프레임워크를 제공합니다.

• 투명성(Transparency) 확보: AI 모델이 어떤 데이터로 학습되었고 어떤 라이선스 정책을 따르는지 명확히 문서화합니다.
• 리스크 관리: 공급망 내에서 발생할 수 있는 법적, 보안적 리스크를 식별하고 관리할 수 있는 프로세스를 제안합니다.
• 단순함과 명확성: 복잡한 통제보다는 ‘무엇이 존재하는가’에 대한 명확성(Clarity)에 초점을 맞추어, 기업들이 실행 가능한 정책을 수립하도록 돕습니다.

런칭 일정 및 홍보

이 가이드는 미팅 직후인 10월 20일에 공식적으로 라이브(Go-Live) 되었습니다. 워크그룹은 이 가이드가 단순한 문서로 남지 않고 업계의 표준 레퍼런스로 자리 잡을 수 있도록 커뮤니티 차원의 적극적인 홍보와 확산을 요청했습니다. 이는 기업들이 다가오는 AI 규제(EU AI Act 등)에 선제적으로 대응할 수 있는 강력한 도구가 될 것입니다.

2. 전략적 협력: 글로벌 정책 및 규제 대응 (UK & Legal)

단순히 가이드를 만드는 것을 넘어, 이 가이드가 실제 법적 효력이나 국제 표준으로서의 위상을 갖출 수 있도록 고위급 레벨의 조율이 시작되었습니다.

영국 상원(House of Lords)과의 연계

이번 미팅에서는 Lord Clement-Jones와의 협력 논의가 중요하게 다뤄졌습니다. Lord Clement-Jones는 영국 상원의 AI 특별위원회 위원장이자 OECD AI 의회 그룹의 창립 멤버로서, 국제 AI 규제 및 정책 수립에 막대한 영향력을 가진 인물입니다.

OpenChain AI 워크그룹이 그와 직접적인 코디네이션을 시작했다는 것은, 우리가 만든 AI SBOM 가이드가 영국의 AI 규제 프레임워크나 향후 정책 방향과 정합성을 맞추고 있음을 의미합니다. 이는 향후 이 가이드가 글로벌 표준으로 채택될 가능성을 높이는 전략적 행보입니다.

법률 및 스펙 그룹과의 공조

또한, 리눅스 재단(LF)의 법률 컨퍼런스(Legal Conference) 및 파이토치(PyTorch) 컨퍼런스와의 연계도 진행 중입니다. 기술적인 구현(PyTorch)과 법적인 해석(LF Legal) 양쪽을 모두 아우르며, AI 거버넌스의 사각지대를 없애겠다는 의지입니다.

3. FINOS(금융 오픈소스 재단)와의 협업 및 표준화 논의

금융 산업은 AI 도입에 있어 가장 보수적이면서도 규제가 강력한 분야입니다. 이번 미팅에서는 금융 오픈소스 재단인 FINOS(Fintech Open Source Foundation)와의 협력 모델이 구체적으로 논의되었습니다.

FINOS AI 거버넌스 프레임워크와의 연계

FINOS는 현재 자체적인 ‘AI 거버넌스 프레임워크’를 개발 중이며, 이를 ISO 표준으로 발전시키려는 계획을 가지고 있습니다. OpenChain 워크그룹은 FINOS와 경쟁하는 것이 아니라, 상호 보완적인 관계를 맺기로 했습니다.

• 역할 분담: OpenChain은 공급망 전반의 투명성과 프로세스 관리(Process Management)에 집중하고, FINOS는 금융 산업 특화된 거버넌스와 리스크 통제에 집중합니다.
• 표준화(Spec) 협력: 만약 FINOS의 프레임워크나 OpenChain의 AI 가이드가 국제 표준(ISO 등)으로 발전해야 한다면, OpenChain 내의 ‘Spec Group(사양 워크그룹)‘과 긴밀히 협력하여 기술적 완성도를 높이기로 했습니다.

이는 AI 거버넌스 분야에서 파편화된 표준이 난립하는 것을 막고, 산업계가 신뢰할 수 있는 단일한 기준점을 만들기 위한 노력입니다.

4. 시장 피드백(Market Feedback)과 향후 계획

가이드 1.0 버전의 완성은 끝이 아니라 시작입니다. 미팅에서는 ‘초기 시장 피드백(Early Market Feedback)‘의 중요성이 강조되었습니다.

• Solution/Market Fit: 완성된 가이드가 실제 기업 현장에서 적용될 때 어떤 어려움이 있는지, 과도하거나 부족한 부분은 없는지 피드백을 수집하여 가이드를 지속적으로 업데이트할 예정입니다.
• 참여 요청: 워크그룹은 미팅 참석자들에게 가이드를 직접 사용해 보고, 개선 제안을 적극적으로 해달라고 요청했습니다. 이는 오픈소스 프로젝트의 핵심인 ‘집단 지성’을 통해 가이드의 완성도를 높이기 위함입니다.

[요약 및 결론] 참여 방법

이번 10월 9일 Asia Sync 미팅은 “AI SBOM 가이드의 완성"이라는 결실을 확인하고, 이를 “글로벌 규제(UK)” 및 “특화 산업(FINOS)“과 연결하는 거대한 로드맵을 공유하는 자리였습니다.

AI 거버넌스는 혼자서 해결할 수 있는 문제가 아닙니다. 여러분의 조직이 AI를 도입하고 있거나 도입할 예정이라면, 지금 바로 OpenChain AI 워크그룹에 합류하여 글로벌 표준 수립 과정에 목소리를 내주시기 바랍니다.

참여 및 리소스 링크:

• AI 워크그룹 메일링 리스트: https://lists.org/g/aiopenchainproject
• 향후 미팅 일정 및 참여 방법: https://www.org/participateopenchainproject
• OpenChain 공식 웹사이트: https://openchainproject.org

미팅 녹화본은 아래 유튜브 링크를 통해 다시 보실 수 있습니다.

• 녹화 영상 보기: https://www.youtube.com/watch?v=ooVyaIw3KuQ

이 블로그 포스트는 OpenChain AI Work Group의 공개된 미팅 기록과 자료를 바탕으로 작성되었습니다.

by Gemini 3.0

4.4 - 2024-12-03 AI Compliance BOM 가이드 웨비나

source: https://openchainproject.org/news/2024/12/04/full-recording-openchain-ai-work-group-monthly-workshop-for-north-america-and-europe-2024-12-03

목차

1. 웨비나 소개
2. AI BOM의 필요성과 배경
3. SPDX 3.0과 AI 프로파일
4. AI BOM 작성 시 고려사항
5. 데이터셋과 모델 라이선스 이슈
6. AI 거버넌스와 규제 준수
7. OpenChain과 SPDX의 협력 방안
8. Q&A

1. 웨비나 소개

제목

OpenChain AI Work Group: AI Compliance BOM 가이드 웨비나

발표자 소개

• Gopi Krishnan Rajbahadur: SPDX AI 워킹 그룹 멤버
• Karen Copenhaver: SPDX 법률 팀 멤버

웨비나 소개와 목적

이 웨비나는 OpenChain Project의 AI Work Group에서 주최한 것으로, AI Compliance BOM(Bill of Materials) 가이드 작성을 위한 첫 번째 공식 미팅입니다. 이전의 AI Study Group에서 AI Work Group으로 전환되어 AI BOM 컴플라이언스에 대한 실질적인 가이드라인을 만드는 것을 목표로 하고 있습니다.

2. AI BOM의 필요성과 배경

AI 시스템의 복잡성이 증가함에 따라 전통적인 소프트웨어 BOM(SBOM)을 넘어서는 새로운 형태의 BOM이 필요해졌습니다. AI BOM은 AI 컴포넌트와 데이터셋을 포함한 전체 시스템을 표현할 수 있어야 합니다.

SPDX 3.0에서는 이러한 요구사항을 반영하여 AI와 데이터셋 프로파일을 추가했습니다. 이를 통해 AI 시스템의 핵심 요소들을 효과적으로 기술할 수 있게 되었습니다.

3. SPDX 3.0과 AI 프로파일

SPDX 3.0은 다음과 같은 특징을 가지고 있습니다:

• 코어 프로파일: 모든 SPDX BOM의 기본이 되는 요소 정의
• 소프트웨어 프로파일: 소프트웨어 아티팩트 기술
• AI 프로파일: AI 특화 요소 기술 (컴플라이언스, 추적성, 투명성 등)
• 데이터셋 프로파일: 데이터셋 자체에 대한 기술

AI 프로파일은 모델 유형, 준수 표준, 운영 도메인, 자율성 수준 등을 캡처합니다. 데이터셋 프로파일은 데이터의 유형, 크기, 노이즈, 기밀성 수준, 수집 프로세스 등을 기술합니다.

4. AI BOM 작성 시 고려사항

Gopi는 실제 Simple HTR 프로젝트를 예로 들어 AI BOM 작성 과정에서 겪은 어려움을 공유했습니다:

• 자동화된 AI BOM 생성 도구의 부재
• 메타데이터의 분산과 불완전성
• 라이선스 정보의 모호성과 충돌

이러한 문제들로 인해 간단한 프로젝트의 AI BOM 작성에도 상당한 시간과 전문성이 요구되었습니다.

5. 데이터셋과 모델 라이선스 이슈

AI 시스템에서는 데이터셋과 모델의 라이선스가 복잡한 문제를 야기할 수 있습니다. 예를 들어:

• 데이터셋은 비상업적 연구 목적으로만 사용 가능하지만, 이를 사용해 학습한 모델은 MIT 라이선스로 배포되는 경우
• Foundation Model을 사용해 생성한 합성 데이터의 라이선스 문제
• 사용자 피드백 데이터의 소유권과 GDPR 준수 문제

이러한 복잡한 라이선스 이슈에 대해 아직 명확한 법적 해석이나 가이드라인이 부족한 상황입니다.

6. AI 거버넌스와 규제 준수

AI 시스템에 대한 규제가 증가하면서 (예: EU AI Act), AI BOM은 규제 준수를 입증하는 중요한 도구가 될 수 있습니다. 그러나 현재의 규제는 “충분한 투명성"이나 “적절한 인간 감독” 등 모호한 표현을 사용하고 있어, 이를 구체적으로 해석하고 구현하는 것이 과제입니다.

7. OpenChain과 SPDX의 협력 방안

OpenChain의 프로세스 거버넌스 경험과 SPDX의 기술적 표준화 노력을 결합하여 AI BOM에 대한 포괄적인 가이드라인을 만들 수 있을 것으로 기대됩니다. 구체적인 협력 방안으로는:

• OpenChain의 프로세스 거버넌스 프레임워크를 SPDX AI BOM 명세에 통합
• AI 시스템의 전체 라이프사이클을 고려한 프로세스 뷰 개발
• 규제 요구사항을 시스템 요구사항으로 매핑하는 프레임워크 개발

8. Q&A

Q: 데이터셋 출처 추적이 모델 출처 추적보다 더 어려운 문제 아닌가요? A: 네, 데이터셋의 출처와 계보를 추적하는 것이 더 어려운 문제입니다. 하지만 모델의 프로세스와 출처도 여전히 중요한 이슈입니다.

Q: 오픈소스와 클로즈드 소스 모델에 대한 BOM 작성에 차이가 있나요? A: 클로즈드 소스 모델의 경우 상세 정보를 얻기 어려울 수 있지만, BOM 표준 자체는 동일하게 적용될 수 있습니다. 다만, 공개 범위에 차이가 있을 수 있습니다.

Q: AI 시스템 전체에 대한 BOM이 필요하지 않을까요? A: 네, SPDX 3.0은 시스템 전체를 기술할 수 있는 능력을 갖추고 있습니다. 모델과 다른 소프트웨어 컴포넌트 간의 관계도 캡처할 수 있습니다.

요약 보고서

기업의 오픈소스 관리 담당자에게 주는 의미

1. AI 시스템 도입 증가: AI와 머신러닝 기술의 도입이 늘어남에 따라, 기존 SBOM을 넘어서는 AI BOM의 필요성이 커지고 있습니다.

2. 컴플라이언스 복잡성 증가: AI 컴포넌트와 데이터셋을 포함한 전체 시스템의 라이선스 및 규제 준수 문제가 더욱 복잡해지고 있습니다.

3. 새로운 표준 등장: SPDX 3.0과 같은 새로운 표준이 등장하여 AI 시스템의 BOM을 더 효과적으로 관리할 수 있게 되었습니다.

4. 법적 불확실성: AI 시스템, 특히 생성형 AI와 관련된 라이선스 및 저작권 문제에 대한 법적 해석이 아직 명확하지 않습니다.

5. 규제 대응 필요성: EU AI Act 등 새로운 AI 규제에 대응하기 위해 AI BOM이 중요한 도구가 될 수 있습니다.

고려해야 할 Action Item

1. AI BOM 도입 준비: SPDX 3.0 등 AI BOM 표준을 학습하고, 조직 내 도입 계획을 수립합니다.

2. 메타데이터 관리 강화: AI 모델과 데이터셋에 대한 상세한 메타데이터를 체계적으로 관리하는 프로세스를 구축합니다.

3. 라이선스 관리 체계 개선: AI 컴포넌트, 데이터셋, 생성된 데이터 등에 대한 복잡한 라이선스 관계를 추적하고 관리할 수 있는 체계를 마련합니다.

4. 자동화 도구 개발/도입: AI BOM 생성과 관리를 자동화할 수 있는 도구의 개발이나 도입을 검토합니다.

5. 거버넌스 프로세스 수립: AI 시스템의 개발, 배포, 운영 전반에 걸친 거버넌스 프로세스를 수립합니다.

6. 규제 모니터링: AI 관련 규제 동향을 지속적으로 모니터링하고, 대응 전략을 수립합니다.

7. 협업 강화: 법무팀, 데이터 과학팀, 개발팀 간의 협업을 강화하여 AI BOM 관리에 대한 통합적 접근을 추진합니다.

8. 교육 및 인식 제고: 조직 내 AI BOM의 중요성과 관리 방법에 대한 교육을 실시합니다.

9. 업계 표준화 활동 참여: OpenChain, SPDX 등의 표준화 활동에 참여하여 AI BOM 관련 best practice를 공유하고 학습합니다.

10. 듀 딜리전스 문서화: AI 시스템 개발 및 도입 과정에서의 모든 준수 노력을 상세히 문서화합니다.

4.5 - 2024-11-05 AI BOM 관리와 워킹그룹 전환 논의

source: https://openchainproject.org/news/2024/11/06/ai-study-group-2024-11-05-recording

목차

1. 웨비나 소개
2. AI BOM 관리를 위한 스크래치패드 논의
3. 정식 워킹그룹으로의 전환
4. 질의응답
5. 향후 계획

1. 웨비나 소개

제목

OpenChain AI 스터디 그룹: 북미 및 유럽을 위한 월간 워크샵 - 2024년 11월 5일

발표자 소개

이번 웨비나는 OpenChain Project의 AI 스터디 그룹에 의해 진행되었습니다. 특정 발표자의 이름은 제공된 정보에 명시되어 있지 않습니다.

웨비나 소개와 목적

이 워크샵은 OpenChain AI 스터디 그룹의 정기 모임으로, 2024년 11월 5일에 개최되었습니다. 주요 목적은 두 가지였습니다:

1. AI BOM (Bill of Materials) 관리를 위한 초안 스크래치패드에 대한 논의
2. 현재의 스터디 그룹을 정식 워킹그룹으로 전환하는 방안 검토

2. AI BOM 관리를 위한 스크래치패드 논의

이 세션에서는 AI BOM 관리를 위한 초안 스크래치패드에 대해 심도 있는 논의가 이루어졌습니다. AI BOM은 AI 시스템의 구성 요소를 문서화하는 중요한 도구로, 이를 효과적으로 관리하기 위한 방법론과 best practice에 대해 참가자들이 의견을 나누었습니다.

주요 논의 사항:

• AI 모델의 구성 요소 식별 방법
• 데이터셋 및 알고리즘의 출처 추적
• AI BOM의 표준화 필요성
• 보안 및 규제 준수를 위한 AI BOM 활용 방안

3. 정식 워킹그룹으로의 전환

스터디 그룹을 정식 OpenChain 워킹그룹으로 전환하는 방안에 대해 논의가 이루어졌습니다. 이는 AI 관련 오픈소스 관리에 대한 중요성이 증가함에 따라 더욱 체계적이고 공식적인 접근이 필요하다는 인식에서 비롯되었습니다.

전환 시 고려사항:

• 워킹그룹의 목표 및 범위 설정
• 멤버십 구조 및 운영 방식
• 다른 OpenChain 워킹그룹과의 협력 방안
• 정기적인 성과 보고 및 평가 체계

4. 질의응답

참가자들의 질문과 그에 대한 답변이 이어졌습니다. 주요 질문들은 AI BOM의 실제 적용 사례, 법적 고려사항, 그리고 워킹그룹 전환 후의 활동 계획 등에 집중되었습니다.

5. 향후 계획

스터디 그룹 활동 참여 방법

• OpenChain AI 스터디 그룹 메일링 리스트를 통해 지속적으로 논의에 참여할 수 있습니다. 이는 산업 분야나 전문성에 관계없이 모든 사람에게 열려 있습니다.

향후 미팅 참석

• 모든 향후 AI 스터디 그룹 미팅의 일정과 참여 방법은 OpenChain 참여 페이지에서 확인할 수 있습니다.

이번 워크샵은 AI 기술의 오픈소스 관리에 대한 중요한 논의의 장을 제공했으며, 향후 더욱 체계적인 접근을 위한 기반을 마련했습니다.

요약 보고서

기업의 오픈소스 관리 담당자에게 주는 의미

1. AI 기술 관리의 중요성 인식: AI 기술이 기업 환경에 빠르게 도입됨에 따라, 오픈소스 관리 담당자들은 AI 관련 오픈소스 컴포넌트의 관리에 대한 중요성을 인식해야 합니다.

2. AI BOM의 도입 필요성: AI Bill of Materials (BOM)는 AI 시스템의 구성 요소를 추적하고 관리하는 데 필수적인 도구가 될 것입니다. 이는 기존의 소프트웨어 BOM 관리 경험을 AI 영역으로 확장하는 것을 의미합니다.

3. 규제 대비: AI 기술에 대한 규제가 강화될 것으로 예상되므로, 오픈소스 관리 담당자들은 이에 대비하여 AI 관련 오픈소스 사용을 더욱 철저히 관리해야 합니다.

4. 협업의 중요성: AI 기술의 복잡성을 고려할 때, 오픈소스 관리 담당자는 AI 개발팀, 법무팀, 보안팀 등과의 긴밀한 협력이 필요합니다.

5. 지속적인 학습과 적응: AI 기술과 관련 오픈소스 생태계가 빠르게 변화하고 있으므로, 지속적인 학습과 적응이 필요합니다.

고려해야 할 Action Item

1. AI BOM 관리 체계 구축: AI 프로젝트에 사용되는 모든 오픈소스 컴포넌트를 식별하고 문서화하는 체계를 구축합니다.

2. AI 관련 오픈소스 정책 수립: 기존의 오픈소스 정책을 AI 기술의 특성에 맞게 업데이트합니다.

3. 교육 및 인식 제고: 개발자와 관리자를 대상으로 AI 관련 오픈소스 사용의 특징과 주의사항에 대한 교육을 실시합니다.

4. AI 오픈소스 컴플라이언스 점검: AI 프로젝트에 대한 정기적인 오픈소스 컴플라이언스 점검을 실시합니다.

5. OpenChain AI 워킹그룹 참여: OpenChain AI 워킹그룹의 활동에 적극적으로 참여하여 최신 동향을 파악하고 best practice를 공유합니다.

6. AI 공급망 관리 강화: AI 모델, 데이터셋, 알고리즘 등의 출처와 라이선스를 철저히 관리합니다.

7. 법적 리스크 평가: AI 관련 오픈소스 사용에 따른 잠재적 법적 리스크를 평가하고 대응 방안을 마련합니다.

8. 보안 강화: AI 시스템의 보안 취약점을 식별하고 관리하는 프로세스를 구축합니다.

9. 성과 측정 체계 수립: AI 관련 오픈소스 관리의 효과성을 측정할 수 있는 KPI를 설정하고 정기적으로 평가합니다.

이러한 action item들을 실행함으로써, 기업의 오픈소스 관리 담당자들은 AI 기술의 도입과 확산에 따른 새로운 도전에 효과적으로 대응할 수 있을 것입니다.

5 - SBOM Work Group

5.1 - SOFTWARE BILL OF MATERIALS (SBOM)에 대한 기술 가이드라인 (인도 정부 발간)

1. Executive Summary

소프트웨어 제품은 다양한 구성 요소로 이루어져 있으며, 이 중 일부는 외부 소스에서 가져옵니다. 이러한 외부 구성 요소와 의존성에는 취약점이 있을 수 있어, 공격자가 이를 악용해 보안 사고나 침해로 이어질 수 있습니다. 주요 위협으로는 악성 코드 삽입, 오래된 구성 요소의 취약점 이용, 공급업체 침해 등이 있습니다. 이로 인해 데이터 유출, 운영 중단, 평판 손상 등의 문제가 발생할 수 있습니다. 이러한 위협에 대응하려면 소프트웨어 구축이나 개발에 사용되는 구성 요소에 대한 가시성과 투명성을 확보해야 합니다. 소프트웨어 부품 명세서(Software Bill of Materials, SBOM)는 조직이 소프트웨어나 자산에 포함된 구성 요소를 정확히 파악하여 취약점을 식별하고 수정하는 데 도움을 줍니다. SBOM을 활용하면 조직은 소프트웨어 보안을 개선하고 잠재적 위협으로부터 보호할 수 있습니다.

소프트웨어 부품 명세서(SBOM) 는 소프트웨어를 구성하는 모든 요소, 라이브러리, 모듈의 목록으로, 소프트웨어 구성에 대한 투명성을 제공합니다. 소프트웨어가 더욱 복잡해지고 외부 구성 요소에 대한 의존도가 높아짐에 따라 소프트웨어 구성을 이해하는 것이 중요해졌습니다. 사이버 보안 측면에서 소프트웨어를 공격으로부터 보호하려면 소프트웨어 구축에 사용된 의존성과 구성 요소를 파악해야 합니다. 따라서 SBOM은 현대 사이버 보안 절차에서 핵심적인 도구입니다.

SBOM은 소프트웨어 보안 유지에 필수적입니다. 이를 통해 조직은 소프트웨어의 구성 요소를 이해하고, 잠재적 위험을 관리하며, 보안 문제에 대응하고, 규정을 준수할 수 있습니다. 다음은 조직이 SBOM을 구현함으로써 얻을 수 있는 주요 이점입니다:

1. 보안 관리 강화: 소프트웨어의 구성 요소를 파악함으로써 조직은 보안 위협에 취약할 수 있는 요소를 식별하고 대응할 수 있습니다.
2. 효과적인 사고 대응: 사이버 보안 사고 발생 시 SBOM은 상세한 구성 요소 정보를 제공하여 신속한 대응을 가능하게 합니다.
3. 취약점 식별 및 패치 관리: 모든 구성 요소를 나열함으로써 조직은 소프트웨어의 알려진 취약점을 빠르게 발견하고 패치할 수 있습니다.
4. 공급망 보안: 소프트웨어 제작에 사용된 외부 구성 요소에 대한 가시성을 확보함으로써 공급망 위험을 크게 줄일 수 있습니다.
5. 규정 준수 지원: SBOM은 소프트웨어 구성의 투명성을 제공하여 조직이 보안 규정, 지침 및 모범 사례를 준수하는 과정을 간소화합니다.
6. 운영 효율성 향상: 소프트웨어 구성 요소에 대한 명확한 이해를 통해 조직은 취약점 관리 프로세스를 간소화하여 시간과 자원을 절약할 수 있습니다.

인도 컴퓨터 비상 대응팀(CERT-In)은 특히 공공 부문, 정부, 필수 서비스, 소프트웨어 수출 및 서비스 산업 관련 조직을 위한 기술적 SBOM 지침을 발표했습니다. 부서와 조직은 보안을 강화하고 사이버 위협의 위험을 줄이기 위해 소프트웨어 조달 및 개발 과정에서 SBOM의 생성과 제공을 의무적인 표준 관행으로 삼도록 권장됩니다.

다음 장에서는 SBOM의 다양한 기술적 측면을 살펴보고 그 목적과 소프트웨어 공급망 생태계에서의 중요성이 증가하는 이유를 설명합니다. 두 번째 장에서는 SBOM의 개요와 범위 및 구현에 대해 논의하고, 이어서 SBOM 생태계에 대한 장에서는 SBOM의 다양한 수준과 분류에 대해 설명합니다. 그 다음 장에서는 SBOM 정보를 표현하는 데 사용되는 다양한 표준과 데이터 형식을 살펴보고, 최소 요소, 데이터 필드 및 자동화 지원에 대해 자세히 설명합니다. SBOM과 관련된 모든 프로세스와 관행의 목표, 안전한 SBOM 공유 및 배포에 대해 이 문서에서 상세히 다루며, SBOM의 취약점 추적 및 분석을 위한 접근 방식도 포함됩니다. 마지막으로, 문서의 마지막 장에서는 SBOM 구현을 위한 권장 사항과 모범 사례를 소개합니다.

2. SBOM 개요

2.1 필요성 및 활용

소프트웨어가 점점 복잡해짐에 따라 SBOM의 필요성이 더욱 커지고 있습니다. SBOM은 소프트웨어 구성 분석(SCA) 도구의 기반이 되며, 취약점 탐지, 라이선스 준수 지원, 공급업체 위험 관리에 중요한 역할을 합니다.

소프트웨어 정의 시스템의 증가로 사이버 위협 환경이 크게 확대되었습니다. 공격자들은 민감한 시스템과 데이터에 침투하기 위해 소프트웨어 공급망을 점점 더 많이 노리고 있습니다.

부서와 조직은 소프트웨어 개발 및 조달 과정에서 소프트웨어 부품 명세서(SBOM)의 생성과 제공을 표준 관행으로 삼도록 권장됩니다. 이를 통해 보안, 규정 준수, 위험 관리, 공급망 투명성, 품질 보증, 상호 운용성, 공급업체 관리를 개선할 수 있습니다.

조직은 소프트웨어 수명 주기의 모든 단계(설계, 개발, 분석, 배포, 유지 관리, 업데이트 포함)와 관련된 중요 구성 요소를 철저히 분석하고 SBOM 사용을 의무화해야 합니다.

SBOM은 다음 세 가지 주요 목적을 달성하는 데 도움을 줍니다:

1. 정부 부서와 조직이 소프트웨어 구매에 대해 정보에 기반한 사전 결정을 내릴 수 있도록 지원합니다.
2. 정부 기관 및 필수 서비스 조직 전반에 걸쳐 취약점 관리, 자산 추적, 규정 준수를 촉진합니다.
3. 조직의 소프트웨어 개발 및 제품 유지 관리를 지원합니다.

모든 정부, 공공 부문, 필수 서비스 조직은 소프트웨어와 솔루션 구매/조달 요구 사항에 SBOM을 포함해야 합니다. 또한 사용자 조직의 보안 팀은 취약점 관리 작업 과정에 SBOM 목록을 반드시 포함해야 합니다.

2.2 적용 & 범위

이 가이드라인은 인도 컴퓨터 비상 대응팀(CERT-In)에서 다음과 같은 기관, 특히 정부, 공공 부문, 필수 서비스 조직 및 소프트웨어 수출과 서비스 산업 관련 조직을 위해 발행되었습니다:

1. 소프트웨어 소비자 - 운영 지원, 생산성 향상, 비즈니스 목표 달성을 위해 소프트웨어 애플리케이션을 구매하는 조직.
2. 소프트웨어 개발자 - 맞춤형 소프트웨어 솔루션을 개발하는 조직.
3. 시스템 통합업체/소프트웨어 재판매업체 - 소프트웨어 제품을 배포하고 맞춤화, 통합, 지원, 교육 등 부가가치 서비스를 제공하는 조직.

SBOM은 가시성 확보, 취약점 패치, 노출 감소, 신속한 대응을 위한 필수 도구가 되고 있습니다. 예를 들어, 일반적인 조직은 상호 연결된 시스템, 엔드포인트, 제어 시스템, 자동화 소프트웨어, 운영 기술(OT) 구성 요소의 방대한 네트워크에 의존합니다. 이러한 복잡한 IT 및 OT 환경에 대한 정확한 SBOM을 유지하면 보안 팀이 공격 표면을 더 잘 이해하고 취약점에 더 효과적으로 대응할 수 있습니다. 이러한 사전 예방적 접근 방식은 조직이 운영을 보호하고 사이버 위협에 대한 복원력을 확보하는 데 도움이 됩니다.

예를 들어, 금융 기관에서 SBOM은 사이버 보안 관점에서 매우 중요합니다. 은행과 핀테크 기업은 디지털 서비스와 백엔드 시스템을 운영하기 위해 다양한 상용 제품(COTS) 소프트웨어, 오픈 소스 라이브러리, 맞춤 개발 구성 요소를 활용합니다. 이러한 다양한 소프트웨어 환경에 대해 최신 SBOM을 유지하면 보안 팀이 취약점을 신속하게 식별하고 완화하며, 산업 규정을 준수하고, 공급망 위험을 더 잘 관리할 수 있습니다.

소프트웨어 개발, 공급망 관리, 사이버 보안, 규제 준수와 관련된 SBOM의 사용 사례는 다음과 같습니다:

2.2.1 소프트웨어 개발 및 유지 관리

SBOM은 소프트웨어 시스템을 구성하는 요소와 의존성의 상세한 목록을 제공합니다. 이 정보를 통해 개발자는 취약점을 더 효과적으로 관리하고, 라이선스를 추적하며, 소프트웨어의 출처를 모니터링할 수 있습니다. 정확하고 최신 상태의 SBOM을 유지하는 것은 조직이 소프트웨어 공급망 위험을 이해하고 애플리케이션의 보안과 무결성을 보장하기 위한 사전 조치를 취하는 데 중요합니다.

2.2.2 공급망 관리

SBOM은 소프트웨어 공급망에 대한 투명성을 제공하여 조직이 외부 구성 요소의 보안과 신뢰성을 평가할 수 있게 합니다. 이는 외부 라이브러리나 구성 요소 사용과 관련된 잠재적 위험을 식별하는 데 도움이 되며 조달 및 공급업체 관리에 대한 정보에 기반한 의사 결정을 용이하게 합니다.

2.2.3 사이버 보안

SBOM은 기존 보안 도구와의 통합, 자동화된 취약점 탐지, 복구를 지원하며 사이버 보안 관행에서 중요한 역할을 합니다. SBOM은 소프트웨어 구성 요소와 그 의존성에 대한 가시성을 제공하여 조직이 보안 취약점을 효과적으로 식별하고 완화할 수 있게 합니다. 소프트웨어 구성에 대한 포괄적인 이해를 통해 조직은 보안 사고에 신속하게 대응하고, 취약점을 패치하며, 소프트웨어 시스템의 무결성과 보안을 보장할 수 있습니다.

2.2.4 규제 준수

SBOM은 특히 의료, 금융, 정부와 같은 필수 서비스를 다루는 산업에서 규제 준수를 위한 요구 사항이 되고 있습니다. 전 세계적으로 규제 기관들은 SBOM을 유망한 도구로 인식하고 있으며 EU 사이버 복원력 법(Cyber Resilience Act)과 같은 규정을 통해 SBOM 채택을 강조하고 있습니다.

2.2.5 위험 관리

SBOM은 소프트웨어 공급망에 대한 통찰력을 제공함으로써 위험 관리 노력을 지원합니다. 조직은 알려진 취약점, 라이선스 충돌, 더 이상 사용되지 않는 라이브러리와 같은 특정 소프트웨어 구성 요소와 관련된 잠재적 위험을 평가할 수 있습니다. 이러한 위험을 사전에 관리함으로써 조직은 소프트웨어 시스템의 복원력을 향상시키고 보안 침해나 규정 준수 문제의 가능성을 최소화할 수 있습니다.

2.2.6 상호 운용성 및 호환성

SBOM은 소프트웨어 구성 요소와 그 버전에 대한 상세한 정보를 제공함으로써 상호 운용성 및 호환성 테스트를 용이하게 합니다. 이는 서로 다른 소프트웨어 시스템이 호환성 문제 없이 원활하게 작동할 수 있도록 보장하는 데 도움이 되며, 따라서 소프트웨어 제품의 전반적인 품질과 신뢰성을 향상시킵니다.

2.3 SBOM 구현

SBOM은 모든 새로운 소프트웨어 구성 요소 출시에 대해 구현되어야 하며, 업데이트, 업그레이드, 출시, 패치 등 변경 사항이 있을 때마다 신속하게 갱신되어야 합니다. SBOM의 정확성은 구성 요소 자체가 변경되지 않았더라도 포함된 구성 요소에 대한 새로운 정보가 있을 때마다 업데이트하여 유지됩니다. 기존 구성 요소를 수정할 때는 일관된 접근 방식을 선택하세요. 변경 사항을 새로운 구성 요소로 취급하거나 기존 구성 요소를 업데이트하는 방식 중 하나를 선택하세요. 명확성을 위해 전체적으로 표준화된 버전 관리 방법을 사용하세요.

다음과 같은 조직의 시나리오를 고려해 보겠습니다:

A. 정부 조직 GovInsights는 소프트웨어 개발 회사 TechGenius를 고용하여 데이터 분석 애플리케이션 DataAnalyzer를 개발합니다.

B. DataAnalyzer 제품을 개발하기 위해 TechGenius 회사는 다음 구성 요소를 사용합니다:

1. MessageMaster 회사의 Postfix & Twilio SDK라는 SMS 및 이메일 서비스
2. DataVault 회사의 데이터베이스 구성 요소: PostgreSQL
3. ServerSolutions 회사에서 제공하는 Apache Tomcat Server (이 서버는 많은 오픈 소스 라이브러리를 사용했습니다)

앞서 언급한 시나리오의 다양한 구성 요소/소프트웨어와 해당 SBOM 유형 및 상태는 아래 표에 제공되어 있습니다:

Table 1: 소프트웨어 구성 요소와 SBOM 작성자 현황

이 시나리오에서 이해관계자와 구성 요소 간의 상호 관계는 Figure 1에 시각적으로 표현되어 있습니다. 묘사된 바와 같이, SBOM 생태계 내의 수많은 주체는 소프트웨어의 제공자와 소비자 역할을 모두 수행합니다. 이는 다른 주체가 제공한 SBOM의 정보를 활용할 뿐만 아니라 새로 개발된 구성 요소에 대한 SBOM을 생성하고 이를 다른 주체와 공유하는 것을 포함합니다. 이상적으로는 소프트웨어 구성 요소의 제작자가 해당 SBOM의 작성자가 되어야 합니다.

Figure 1: 시나리오 흐름도

• SBOM 소비자: 완전한 SBOM을 요청해야 합니다.
• 소프트웨어 개발자: 정확하고 완전한 SBOM이 소비자에게 제공되도록 해야 합니다.

3. 생태계

SBOM 생태계는 소프트웨어 공급망 전반에 걸쳐 SBOM의 생성, 배포, 분석, 활용에 관여하는 이해관계자, 도구, 표준, 프로세스의 네트워크를 포함합니다. 이 섹션에서는 소프트웨어 소비자/개발자/시스템 통합업체 조직이 조직 수준에서 SBOM 생태계를 개발하기 위한 접근 방식을 설명합니다. 또한 SBOM의 다양한 분류에 대해 설명합니다.

3.1 SBOM 수준

SBOM의 다양한 수준은 각각 다른 정도의 세부성과 복잡성을 제공하며, 특정 요구 사항과 각 소프트웨어 환경의 복잡성을 반영합니다. 조직은 투명성, 위험 관리, 운영 효율성의 효과적인 균형을 달성하기 위해 하나 이상의 SBOM 수준을 구현하도록 선택해야 합니다.

Figure 2: SBOM 수준

다중 SBOM 접근 방식을 채택하면 조직의 사이버 복원력을 크게 향상시킬 수 있습니다. 조직은 민감한 데이터를 노출하지 않고 보안 요구 사항을 해결하는 맞춤형 SBOM을 소비자를 위해 생성해야 합니다. 동시에 “완전한” 수준의 내부 SBOM을 유지하여 해당 소프트웨어와 관련된 취약점 업데이트를 식별하고 주기적으로 의무적으로 소비자와 상세히 공유해야 합니다. 이 접근 방식은 특히 조직이 완전한 소프트웨어 및 의존성 세부 정보를 공유함으로써 발생하는 데이터 유출 및 지적 재산 도용에 대한 제약이나 우려에 직면한 상황에서 생태계 전반에 걸쳐 사이버 복원력, 데이터 기밀성, 협력적 보안의 균형을 맞춥니다.

Table 2: SBOM을 작성한 조직의 시나리오에 따른 수준 매핑

3.2 SBOM의 분류

SBOM 분류는 소프트웨어 개발 생명주기 단계와 일치하며, 각각 고유한 데이터와 통찰력을 제공합니다. SBOM의 다양한 분류는 다음과 같습니다:

Figure 3: SDLC 단계와 일치하는 SBOM 분류

• 3.2.1 Design SBOM: 계획된 구성 요소를 포착하며, 실제로 존재하기 전에도 이를 기록합니다.
• 3.2.2 Source SBOM: 개발 환경을 반영하며, 소스 파일과 의존성을 포함합니다.
• 3.2.3 Build SBOM: 빌드 과정 중에 생성되며, 소스 파일, 의존성 및 사전 빌드된 구성 요소에 대한 세부 정보를 포함합니다.
• 3.2.4 Analyzed SBOM: 빌드 후 최종 소프트웨어 결과물을 검사하여 생성됩니다.
• 3.2.5 Deployed SBOM: 특정 시스템에 설치 및 구성된 소프트웨어의 목록을 제공합니다. 다양한 SBOM 유형의 정보를 결합하고 배포 환경을 고려합니다.
• 3.2.6 Runtime SBOM: 실행 중인 소프트웨어 구성 요소를 모니터링하여 생성됩니다. 외부 상호작용과 동적으로 로드된 의존성을 포함하여 런타임 실행 중의 정보를 캡처합니다.

3.3 조직의 SBOM 개발 및 채택을 위한 로드맵

조직 내 SBOM 생태계 구축은 단계적 접근이 필요합니다. 기본 토대(START)를 시작으로 발전(PROGRESS)시키고 최종적으로 성숙하고 확장 가능한 SBOM 구현(ADVANCE)에 도달해야 합니다. 활동 순서는 예시일 뿐이며, 조직의 보안 요구사항, 프로젝트 일정, 리소스 가용성에 따라 조정할 수 있습니다.

3.3.1 PHASE-1 (START): 기초 활동

이 단계의 기초 활동들은 SBOM 프로그램의 기반을 마련합니다. 첫 SBOM은 조달 과정에서 공급업체로부터 획득할 가능성이 높습니다. 소프트웨어는 아키텍처, 기존 리소스, 예산, 인력 가용성 측면에서 다양할 수 있으므로, 이 단계의 목적은 조직 내 SBOM 생태계 구축 방법을 수립하는 것입니다.

• 3.3.1.1 중요 자산 식별 및 프로젝트 계획 수립: 역할, 책임, 일정, 리소스 요구사항을 정의하는 종합적인 프로젝트 계획을 수립합니다. 새로운 SBOM 프로세스에 대한 이해관계자의 동의를 얻기 위한 변경 관리 요구사항도 식별합니다.

• 3.3.1.2 SBOM 형식 및 최소 요구사항 결정: SBOM 생성 전에 형식과 최소 데이터 요구사항을 정의합니다. 이는 공급망 전반에 걸쳐 일관된 공유와 처리가 가능한 표준화된 기계 판독 가능 구조를 보장합니다.

• 3.3.1.3 보안 요구사항, 안전한 저장소 및 도구 식별: 사이트 보안 정책에 맞는 적절한 분류 및 처리 절차를 결정합니다. SBOM을 위한 안전한 저장소를 구축하고, 초기에는 개별 SBOM을 전용 저장소에 분리 저장합니다. SBOM 프로그램이 성숙해지면 자산 관리 애플리케이션과 통합하고 취약점 데이터 등 다른 보안 관련 정보와 연결합니다.

• 3.3.1.4 조달 과정의 일부로 SBOM 획득: 구매 주문서나 계약서에 공급업체의 SBOM 제공 요구사항을 명시하고, SBOM 요소, 제공 시기 및 방법을 지정하여 투명성을 보장하고 SBOM 통합 프로세스를 용이하게 합니다.

3.3.2 PHASE – 2 (PROGRESS)

이 단계는 안전한 설치 및 구성 관리를 확립하고, 공급업체 및 구성 요소 네임스페이스 문제를 해결하기 위해 고유한 구성 요소 식별을 통합하는 지속적인 활동을 포함합니다. 소프트웨어 개발 조직에 의한 보안 소프트웨어 개발 수명주기(SSDLC)와의 통합은 빌드 단계에서 소프트웨어를 보호하기 위한 실행 가능한 보안 정보를 제공하기 시작할 것입니다.

• 3.3.2.1 안전한 설치 및 운영 지침 개발: 공급업체는 소비자 조직과 협력하여 대상 소비자의 기술 분야와 사용 요구에 맞춘 포괄적인 안전한 소프트웨어 설치 및 운영 체크리스트를 작성해야 합니다. 안전한 운영을 보장하기 위해 안전한 애플리케이션 설계, 개발, 구현 및 운영 지침에서 핵심 체크리스트 항목을 도출할 수 있으며, 이는 애플리케이션 수명 주기의 배포 및 운영 단계에서 다루어야 할 필수 고려 사항을 강조합니다.

• 3.3.2.2 각 구성 요소에 고유 식별자 할당: 소비자가 리브랜딩을 인식하지 못하면 보안 업데이트나 취약점을 간과할 수 있어 악용에 취약해질 수 있습니다. 이로 인해 소비자가 자체 SBOM에 포함할 정확한 데이터 필드(예: 현재 공급업체 및 구성 요소 이름)를 조사하기 어려워집니다. 공급업체 및 구성 요소 이름 변경은 SBOM 수정과 이전 SBOM에서 후속 버전으로의 링크를 통해 수정 이력을 유지해야 합니다. 이를 해결하기 위해 고유 식별자를 생성해야 합니다.

Table 3: 고유 식별자의 구문 및 예시

위 시나리오에 대한 고유 식별자는 다음과 같습니다: pkg:supplier/ApacheSoftwareFoundation/ApacheTomcat@9.0.71?arch=x86_64&os=linux#server/webapps

Table 4: 고유 식별자의 유용성

• 3.3.2.3 공급업체의 SBOM과 소비자의 내부 SBOM 매핑: 소비자 조직은 공급업체가 제공한 SBOM을 기반으로 내부 SBOM을 매핑하고 개발해야 합니다. 또한 내부 SBOM 개발자의 무결성과 효율적인 업데이트를 추적하기 위해 작성자 이름(소비자 조직의 담당자)과 타임스탬프를 포함해야 합니다.

• 3.3.2.4 SBOM 준비: SBOM은 공급업체와 소비자 조직 모두에서 준비해야 합니다. 알려진 취약점 데이터와 공급업체 취약점 증명을 상호 연관시켜 취약점이 있는 설치된 구성 요소를 식별합니다. 이를 바탕으로 조직 내부적으로 또는 소프트웨어 공급업체에 의해 외부적으로 complete-level SBOM을 생성하여 공급망 공격에 대한 보안과 가시성을 향상시켜야 합니다.

• 3.3.2.5 보안 소프트웨어 개발 수명주기의 각 단계에 SBOM 통합: 소프트웨어 개발 조직은 SSDLC의 각 단계에 SBOM을 통합할 수 있습니다. 설계 단계에서 SBOM은 구성 요소 선택 및 잠재적 보안 위험에 대한 결정을 알려야 합니다. 소프트웨어 개발 중 SBOM 사용은 효율성을 향상시키고 개발자와 사용자 모두에게 빌드 및 소스 구성 요소뿐만 아니라 제품 기능에 대한 더 큰 통찰력을 제공할 수 있습니다.

• 3.3.2.6 안전한 구성 관리 수립: SBOM의 안전한 구성 관리를 보장하기 위해 엄격한 접근 제어, 암호화, 주기적인 소프트웨어 감사 및 보안 프레임워크와의 통합을 구현합니다.

3.3.3 PHASE-3 (ADVANCE):

취약점 모니터링과 취약점 관리 및 사고 대응을 위한 security orchestration tool과 SBOM의 원활한 통합 관련 활동 강화

• 3.3.3.1 취약점 추적 프로세스 강화: SBOM과 연관된 취약점 정보를 수집합니다. 과거 취약점 정보는 SBOM 생태계에 통합되어야 하며, 전문가들은 SBOM repository에 나열된 component와 식별된 취약점을 상호 참조하고 관련 구성 데이터에 대한 장비 데이터베이스를 확인하여 알려진 취약점의 추적 및 분석을 위한 영향과 잠재적 완화 조치를 평가하는 절차를 보유해야 합니다.

• 3.3.3.2 사고 대응 프로세스 강화: CERT-In은 다양한 위협에 대한 경고, 취약점 노트 및 권고사항을 발행합니다. 이러한 위협은 주로 새롭게 공개된 소프트웨어 취약점과 관련이 있습니다. 조직은 threat hunting team을 구성하여 이 정보를 활용해 새로 발견된 위협에 대해 조직이 취약한지, 그리고 이미 침해당했는지 여부를 판단해야 합니다.

• 3.3.3.3 기존 SBOM 업데이트를 위한 정기적 분석 및 검토: 소프트웨어 component와 그 dependency가 최신 기록과 일치하는지 확인하고 적시에 업데이트를 보장하는 작업을 포함합니다.

• 3.3.3.4 새로운 소프트웨어 component와 산업 발전에 대한 인식 유지: 조직은 SBOM 실무자들이 직면한 과제를 준수하면서 조직 내 구현, 새로운 SBOM 형식, 데이터 요소에 대한 정보를 공유하기 위해 독립적으로 또는 third-party 조직과 협력하여 SBOM 인식 프로그램을 유지하도록 권장됩니다.

3.4 라이선스 관리

라이선스 관리는 SBOM의 초기 활용 사례 중 하나입니다. 이는 복잡한 소프트웨어 포트폴리오를 가진 큰 조직이 다양한 소프트웨어 구성 요소의 라이선스와 조건을 추적하는 데 도움을 줍니다. 특히 오픈 소스 소프트웨어에 대해 중요합니다. SBOM은 각 구성 요소의 라이선스 정보를 제공할 수 있어, 사용자가 법적 위험 없이 해당 소프트웨어를 다른 애플리케이션의 구성 요소로 사용할 수 있는지 판단할 수 있게 합니다. 소프트웨어에 포함된 구성 요소의 라이선스 정보를 확인하면 규정 준수 실수를 방지하고, 라이선스 위반 위험과 관리에 필요한 노력을 줄일 수 있습니다.

다음은 라이선스 관리 과정을 간소화하고 규정 미준수 위험을 줄이는 데 도움이 되는 방법들입니다:

1. 사용자가 평가 중인 제품의 라이선스와 모든 개별 구성 요소의 라이선스를 볼 수 있어야 합니다. 이를 통해 사용자는 제품 선택과 비즈니스 요구에 맞는 라이선스 계약 결정에 더 나은 판단을 할 수 있습니다.

2. SPDX 식별자와 같은 식별자로 각 소프트웨어 라이선스를 구분합니다. 이 식별자들은 특정 라이선스 조건을 나타내는 고유 코드 역할을 합니다. 조직은 이를 활용해 소프트웨어 자산의 라이선스 의무를 효과적으로 관리하고 이해해야 합니다.

3. 주요 데이터베이스에서 라이선스 식별자를 찾을 수 없다면, Scancode, LicenseDB, AboutCode 같은 다른 라이선스 데이터베이스를 살펴봐야 합니다. 이런 대체 식별자에는 출처를 나타내는 접두사(예: “LicenseRef-scancode-")를 붙여 쉽게 파악하고 이해할 수 있게 해야 합니다.

4. SPDX 같은 잘 알려진 목록에 없는 라이선스를 만나면, 조직은 고유한 식별자를 부여해야 합니다. 이렇게 하면 시스템 내에서 알려지지 않은 라이선스를 제대로 식별하고 추적할 수 있습니다.

5. 라이선스를 자리 표시자나 템플릿으로 수정할 때는 기본 조건이 바뀌지 않도록 주의해야 합니다. 대신 SPDX 라이선스 표현 같은 고유 식별자로 구분되는 원본 라이선스의 일부로 봐야 합니다. 이는 라이선스 관리의 명확성과 일관성을 유지하는 데 도움이 됩니다.

6. 소프트웨어에 여러 라이선스가 적용될 때는 연산자(예: SPDX 연산자)를 사용해 올바르게 조합하는 것이 중요합니다. 이 연산자들은 서로 다른 라이선스 식별자를 연결해 라이선스 표현의 명확성과 일관성을 보장합니다. 이를 통해 소프트웨어에 적용되는 라이선스 조건을 정확히 나타낼 수 있습니다.

7. 라이선스 관리 시 라이선스 텍스트에 붙은 예외 조항은 “WITH” 같은 적절한 연산자를 써서 주 라이선스 식별자와 연결해야 합니다. 또한 예외 조항 이름은 라이선스 식별에 대한 정해진 요구 사항에 따라 식별자로 설명되어야 합니다.

8. 라이선스 텍스트를 조금 바꿀 때, 수정 내용이 원본 라이선스의 의미를 크게 바꾸지 않는다면 원본 라이선스와 같은 식별자를 쓰는 것이 좋습니다.

4. SBOM 준비

4.1 SBOM의 최소 요소

SBOM의 최소 요소는 소프트웨어 구성 요소와 관련된 필수 정보인 “Data Fields"를 규정합니다. “Automation Support” 탐지 및 관리는 보안 오케스트레이션 도구와 조직의 SBOM 구현을 위한 “Process 및 Practice"와 통합하여 개선될 수 있습니다. “Minimum Elements"의 범주와 정의는 다음과 같습니다.

Table 5: SBOM의 최소 요소

4.2 Data Fields

Data fields는 추적하고 유지해야 하는 각 구성 요소에 대한 기본 정보를 포함합니다. 조직은 소프트웨어 구성 요소, dependency, 관련 메타데이터의 포괄적인 목록을 만들어 소프트웨어 개발 수명 주기 전반에 걸쳐 더 나은 투명성, 보안 및 위험 관리를 가능하게 할 수 있습니다.

Data fields의 목적은 이러한 구성 요소를 적절히 식별하는 것입니다. 이를 통해 소프트웨어 공급망 전반에 걸쳐 추적이 쉬워지고 취약점이나 라이선스 데이터베이스 같은 다른 유용한 데이터 소스와 연결할 수 있습니다. 기본 구성 요소 정보는 다음을 포함합니다:

1. Component Name: SBOM에 포함된 소프트웨어 구성 요소나 library의 이름
2. Component Version: 소프트웨어 구성 요소의 버전 번호나 식별자
3. Component Description: 소프트웨어 구성 요소의 기능과 목적에 대한 간단한 설명
4. Component Supplier: vendor, third-party supplier 또는 오픈소스 프로젝트와 같이 소프트웨어 구성 요소를 제공한 주체나 조직
5. Component License: 소프트웨어 구성 요소가 배포되는 라이선스로, 라이선스 유형, 조건 및 제한 사항과 같은 세부 정보 포함
6. Component Origin: 소프트웨어 구성 요소의 출처나 기원(독점, 오픈소스 또는 third-party vendor에서 획득)
7. Component Dependencies: 현재 구성 요소가 의존하는 다른 소프트웨어 구성 요소나 library(이름과 버전 포함)
8. Vulnerabilities: 소프트웨어 구성 요소와 관련된 알려진 보안 취약점이나 약점에 대한 정보(심각도 등급 및 보안 권고 또는 CVE 식별자에 대한 참조 포함)
9. Patch Status: 알려진 취약점이나 문제를 해결하기 위한 패치나 업데이트의 가용성을 나타내는 소프트웨어 구성 요소의 패치 또는 업데이트 상태
10. Release Date: 소프트웨어 구성 요소가 출시되거나 사용 가능하게 된 날짜
11. End-of-Life (EOL) Date: 소프트웨어 구성 요소에 대한 지원이나 유지보수가 종료되도록 예정된 날짜로, 수명 주기의 종료를 나타냄
12. Criticality: 애플리케이션의 전반적인 기능이나 보안에 대한 소프트웨어 구성 요소의 중요도(주로 critical, high, medium, low로 분류)
13. Usage Restrictions: 수출 통제 제한이나 지적 재산권과 같이 소프트웨어 구성 요소와 관련된 사용 제한이나 제약 사항
14. Checksums or Hashes: 무결성과 신뢰성을 보장하기 위한 소프트웨어 구성 요소 파일의 암호화 체크섬이나 해시
15. Comments or Notes: 소프트웨어 구성 요소나 SBOM 포함과 관련된 추가 설명, 메모 또는 주석
16. Author of SBOM Data: 이 구성 요소에 대한 SBOM 데이터를 생성하는 주체의 이름
17. Timestamp: SBOM 데이터 조립의 날짜와 시간 기록
18. Executable Property: SBOM 내의 구성 요소가 실행 가능한지를 나타내는 속성
19. Archive Property: SBOM 내의 구성 요소가 아카이브나 압축 파일로 저장되어 있는지를 나타내는 특성
20. Structured Property: SBOM에 나열된 구성 요소 내 데이터의 구성된 형식을 정의하는 설명자
21. Unique Identifier: 각 소프트웨어 구성 요소에 할당된 고유 코드로, “pkg:supplier/OrganizationName/ComponentName@Version?qualifiers&subpath” 형식으로 구성되어 소유권 변경과 버전 업데이트를 추적하여 정확하고 일관된 소프트웨어 구성 요소 관리를 보장

Table 6: 조직별 시나리오에서 활용된 Component의 Data Fields

4.3 Automation Support

자동 생성 및 기계 판독성과 같은 자동화 지원은 소프트웨어 생태계와 조직 경계를 넘어 확장을 가능하게 합니다. SBOM 데이터를 다양한 도구와 프로세스에 원활하게 통합하여 소프트웨어 공급망 전반에 걸친 협업과 가시성을 촉진합니다.

Figure 5: SBOM의 Automation Support 이점

SBOM 데이터를 활용하기 위해서는 일관된 데이터 형식과 구현이 필요한 도구가 필요합니다. 자동화는 SBOM의 생성, 유지 관리 및 활용의 여러 측면을 지원할 수 있습니다. 이는 일관성 있는 변경 사항 구현, 시간 절약, 취약점 관리 개선 등 다양한 이점을 제공합니다. 자동화된 SBOM 생성은 감사 및 규정 준수 절차를 간소화하고 보안 취약점에 대한 대응 시간을 단축시킵니다. 조직은 이 기능을 현재의 취약점 관리 절차와 보안 정책의 실시간 감사 compliance에 포함할 수 있습니다. 두 가지 모두 표준화된 기계 판독 가능한 데이터 형식을 필요로 하는 자동화에 크게 의존합니다. SBOM을 생성하고 사용하는 데 사용되는 표준 형식은 다음과 같습니다:

1. Software Package Data eXchange (SPDX)
2. CycloneDX

5. 소프트웨어 Consumer/Developer/Integrator 조직을 위한 SBOM 프로세스와 관행

이 섹션에서는 실무자들이 SBOM을 어떻게 인식해야 하며, 실제로 이를 다루기 위해 어떤 프로세스를 수립해야 하는지 논의합니다. 이 장에서 언급된 주제들은 SBOM 생성, 배포 및 공유, 검증 및 확인, 취약점 및 악용 가능성 관리와 같은 SBOM 관행의 분석에서 도출되었습니다.

5.1 역할과 책임 수립

SBOM을 구현하기 위해서는 필요한 역할과 책임을 식별해야 합니다. 여기에는 관리 후원자, 프로젝트 리더, 시스템 엔지니어, 설계 엔지니어, 조달 전문가 및 운영 담당자가 포함되어야 합니다. 프로젝트 일정과 보안 요구사항에 따라 IT, 사이버보안 및 유지보수 인력과 같은 추가 지원을 포함시켜야 합니다. 이러한 역할들 간의 명확한 소유권과 협력을 보장하여 SBOM 구현과 기존 프로세스와의 통합을 추진해야 합니다.

Figure 6: 역할 및 책임 수립 단계

1. 주요 이해관계자 식별: SBOM 프로그램의 주요 이해관계자를 식별하기 위해 조직은 소프트웨어 개발, IT 운영, 보안, 조달, 비즈니스 리더십, compliance 팀 및 규제 기관의 대표자를 고려해야 합니다. 보안 데이터 처리, 취약점 관리 및 위험 평가에 대한 전문 지식을 제공하기 위해 사이버보안 전문가를 포함해야 합니다.

2. SBOM 관련 책임 정의: SBOM 생성, 소비, 취약점 모니터링, supplier 참여 및 보안 데이터 관리와 같은 작업을 설명합니다. 다음과 같은 사이버보안 중심의 책임을 할당합니다: 민감도와 위험에 따른 SBOM 데이터 분류, 보안 SBOM 저장소 및 접근 제어 구현, 취약점 관리 및 사고 대응 프로세스와 SBOM 데이터 통합.

3. 역할 및 소유권 할당: 사이버보안 전문가를 SBOM 프로그램 소유자 또는 공동 소유자로 지정하여 전반적인 보안이 보장되도록 합니다. 사이버보안 팀이 핵심 역할을 수행하면서 이해관계자의 전문성을 기반으로 SBOM 책임을 할당합니다.

4. 거버넌스 수립: 거버넌스 구조는 첫 번째 포인트에서 논의된 대로 조직 전반의 주요 이해관계자를 포함해야 합니다. 이 거버넌스 기구는 SBOM 관련 정책, 표준, 프로세스를 개발하고 명확한 책임을 할당하며, SBOM 데이터를 보호하기 위한 통제를 구현합니다.

5. 협업 활성화: 소프트웨어, IT 및 사이버보안 팀 간의 부서 간 협업을 촉진하여 SBOM 보안 과제를 해결합니다. 보안 SBOM 관행, 새로운 위협 및 최고 수준의 보안 통제에 대한 지식 공유를 장려합니다.

6. 교육 및 리소스 제공: SBOM 보안 요구사항, 보안 데이터 처리 및 SSDLC의 각 단계와 SBOM 통합에 대한 전문 교육을 제공합니다. 팀에 보안 SBOM 생성, 저장 및 소비 도구와 취약점 관리 및 위협 인텔리전스 리소스를 제공합니다.

7. 모니터링 및 개선: 조직은 정기적인 감사와 평가를 수행해야 합니다. 여기에는 SBOM 프로그램의 보안 태세를 지속적으로 평가하고 진화하는 위협과 compliance 요구사항을 해결하기 위한 조정이 포함되어야 합니다.

5.2 SBOM 기능 탐색을 위한 로드맵

이 섹션에서는 SBOM의 세 가지 주요 측면인 관행, 도구 지원 및 관련 문제의 목표를 탐구합니다. 이를 통해 소프트웨어 Developer/Consumer/Integrator 조직에게 다양한 기능을 탐색하고 SBOM의 특정 측면에서 실제로 달성해야 할 사항에 대한 로드맵을 제공합니다.

Table 7: SBOM 개념의 목표

5.3 보안 SBOM 배포: 접근 제어와 Public/Private SBOM

SBOM 데이터를 안전하게 통합하고 관리하려면 명확한 조건이 정의되어야 합니다. 이러한 조건은 라이선싱, 계약, 또는 소프트웨어 사용 및 권한 관리를 위한 기존 메커니즘을 통해 수립될 수 있습니다. supplier(오픈소스 관리자 포함)는 public SBOM 데이터를 선호할 수 있지만, 일부는 기밀성을 유지하며 특정 사용자에게만 접근을 제한할 수 있습니다. 이러한 단계를 통해 조직은 SBOM의 안전하고 통제된 배포를 구현하여 민감한 정보가 승인된 당사자에게만 접근 가능하도록 하면서도 소프트웨어 공급망의 투명성과 신뢰를 유지할 수 있습니다.

5.3.1 접근 제어

• 5.3.1.1 SBOM 데이터에 대한 접근을 관리하기 위한 role-based access control (RBAC) 시스템을 정의합니다.
• 5.3.1.2 다양한 이해관계자(예: developer, security team, supply chain partner)와 각자의 접근 요구사항을 식별합니다.
• 5.3.1.3 각 역할에 적합한 권한과 특권을 할당합니다(예: 일반 사용자를 위한 읽기 전용 접근, SBOM 관리자를 위한 편집 및 업데이트 접근, 민감하거나 기밀인 SBOM 데이터에 대한 제한된 접근).

5.3.2 Public 및 Private SBOM

• 5.3.2.1 SBOM의 두 가지 버전을 유지:
  • a) Public SBOM: 모든 이해관계자와 공유 가능한 비민감 정보를 포함합니다.
  • b) Private SBOM: 승인된 당사자만 접근할 수 있는 취약점과 같은 민감하거나 기밀 정보를 포함합니다.

5.3.3 보안 배포 메커니즘

• 5.3.3.1 HTTPS와 같은 보안 통신 프로토콜을 활용하여 당사자 간 SBOM 데이터를 전송합니다.
• 5.3.3.2 디지털 서명이나 암호화를 구현하여 SBOM 데이터의 무결성과 기밀성을 보장합니다.
• 5.3.3.3 접근 제어 및 감사 기능을 제공하는 보안 파일 공유 플랫폼이나 도구를 사용합니다.

5.3.4 자동화된 SBOM 생성 및 업데이트

• 5.3.4.1 최신 상태와 정확성을 유지하기 위해 SBOM 생성 프로세스를 software development lifecycle (SDLC)에 통합합니다.
• 5.3.4.2 소프트웨어 구성 요소나 dependency에 변경이 발생할 때 SBOM 업데이트 프로세스를 자동화합니다.

5.3.5 SBOM 소비 및 검증

• 5.3.5.1 SBOM 데이터를 소비하고 검증하는 방법에 대한 명확한 지침과 문서를 제공합니다.
• 5.3.5.2 이해관계자가 특정 요구사항과 보안 정책에 따라 SBOM을 검증할 수 있는 프로세스와 도구를 개발합니다.

5.3.6 모니터링 및 감사

• 5.3.6.1 SBOM 데이터에 대한 접근과 변경을 추적하기 위한 로깅 및 감사 메커니즘을 구현합니다.
• 5.3.6.2 정의된 접근 제어 정책의 compliance를 보장하기 위해 접근 로그와 감사 추적을 정기적으로 검토합니다.

5.3.7 사고 대응 및 복구

• 5.3.7.1 SBOM 데이터와 관련된 보안 사고나 침해를 처리하기 위한 사고 대응 절차를 수립합니다.
• 5.3.7.2 취약점이나 사고의 영향을 신속히 평가하고 관련 이해관계자와 복구 노력을 조율하기 위한 프로세스를 구현합니다.

5.4 SBOM 공유

소프트웨어 공급망의 투명성, 보안 및 compliance를 높이기 위해서는 supplier와 사용자 간에 SBOM을 공유하는 것이 필요합니다.

조직 내부에서 SBOM 문서를 공유하면 development, security, operations 및 법률 팀이 프로젝트에서 사용되는 소프트웨어 구성 요소와 dependency에 대한 통찰력을 얻을 수 있습니다. 이는 투명성을 촉진하고 협업을 강화하며 라이선싱 및 보안 요구사항의 compliance를 용이하게 합니다.

SBOM 문서 공유는 외부 partner, supplier 및 vendor 간의 신뢰를 높이는 데도 기여하며, 소프트웨어 제품이나 시스템 내에서 구현된 구성 요소, 라이선싱, 보안 조치에 대한 감사 가능한 증거를 제공합니다.

SBOM 문서 공유는 다음과 같은 채널과 형식을 통해 촉진됩니다:

1. Secure File Sharing Platform: 승인된 당사자와 안전하게 문서를 공유할 수 있는 환경 제공.
2. API Integration: 시스템 간 자동화되고 안전한 데이터 교환 지원.
3. Collaboration Tool: 프로젝트 관리 플랫폼이나 문서 공유 애플리케이션을 활용하여 팀 내부 또는 조직 간 안전한 공유 촉진.
4. Industry Platform and Repository: 특정 산업이나 커뮤니티 내에서 문서의 공유와 배포를 촉진하기 위해 구축된 플랫폼 활용.

문서를 공유할 때는 클라이언트가 진위성을 확인하고 변조 여부를 검증할 수 있도록 디지털 서명을 첨부하는 것이 권장됩니다. 또한, 어떤 정보를 public 또는 private으로 설정해야 하는지 명확히 식별하는 것이 중요합니다.

6. SBOM의 취약점 추적 및 분석

이 챕터에서는 Software Bill of Materials (SBOM)를 사용한 취약점 추적 및 분석에 대해 Vulnerability Exchange Document (VEX)와 Common Security Advisory Framework (CSAF)를 통해 설명합니다. VEX는 취약점 정보의 표준화된 공유를 용이하게 하고, CSAF는 보안 권고사항을 설명하기 위한 구조화된 프레임워크를 제공합니다.

a) VEX Document 설계: Vulnerability Exchange Document (VEX)는 취약점이 발견된 후 소프트웨어 공급망 관리를 담당하는 조직이나 주체(예: supplier)가 설계해야 합니다. VEX는 consumer가 수정 작업의 우선순위를 정할 수 있도록 취약점의 악용 가능성 상태를 알리는 역할을 합니다. 여기에는 소프트웨어 developer, vendor 또는 조달 및 compliance 관련 조직으로 구성된 팀이 포함되어야 하며, 이들은 소프트웨어의 취약점 추적과 분석을 담당합니다. VEX document는 supplier가 수행한 시간과 함께 수정, 해결 방법, 재시작/다운타임 요구사항, 점수 및 위험을 포함하여 취약점의 각 업데이트마다 반복적으로 업데이트됩니다. VEX document는 특정 소프트웨어 제품의 취약점 상태에 대해 다음 사항을 포함해야 합니다:

• Not affected - 이 취약점에 대한 수정이 필요하지 않음
• Affected - 이 취약점을 수정하거나 해결하기 위한 조치가 권장됨
• Fixed - 이러한 제품 버전에 취약점에 대한 수정사항이 포함되어 있음을 나타냄
• Under Investigation - 이러한 제품 버전이 취약점의 영향을 받는지 여부가 아직 확인되지 않음. 추후 릴리스에서 업데이트가 제공될 예정

b) Common Security Advisory Framework (CSAF) 채택: VEX document 이후에 supplier는 취약점에 대한 설명, 영향을 받는 제품 버전, 심각도 평가 및 권장되는 완화 단계와 같은 자세한 정보가 포함된 CSAF 권고사항을 제공해야 합니다. 이는 다음 예시를 통해 이해할 수 있습니다:

Figure 7: SBOM의 취약점 추적 및 분석 단계 시퀀스 예시

Log4j 취약점은 위 그림에 설명된 개념을 매핑하고 설명하는 예시로 사용됩니다:

1. Vulnerability Discovery: 2021년 12월, 널리 사용되는 Log4j logging library에서 심각한 취약점이 발견되었습니다.
2. VEX Publication (1주): 일주일 내에 Apache Software Foundation(Log4j의 관리자)은 취약점이 “Exploitable"이라고 명시한 VEX document를 발행했습니다.
3. CSAF Publication (3주): 최초 발견 약 3주 후, Apache Software Foundation은 Log4j 취약점에 대한 상세 정보가 포함된 CSAF 권고사항을 발표했습니다. CSAF 권고사항에는 취약점 설명, 영향을 받는 버전, CVSS 점수 10.0(심각도 위험), 완화 단계가 포함되었습니다.
4. Patch/Mitigation Instructions: CSAF 권고사항은 사용자가 Log4j의 패치된 버전으로 업데이트하거나 취약점을 해결하기 위한 다른 완화 조치를 구현하는 방법에 대한 지침을 제공했습니다.
5. Ongoing Updates: Apache Software Foundation은 상황을 계속 모니터링하고 새로운 정보나 추가 완화 전략이 가용해짐에 따라 업데이트를 제공했습니다.
6. SBOM Integration: Log4j library가 소프트웨어 구성 요소에 포함된 조직은 VEX와 CSAF 데이터를 자신의 SBOM에 통합하여 시스템의 영향을 받는 부분을 식별할 수 있었습니다. 이를 통해 수정 작업의 우선순위를 정하고 시스템이 Log4Shell 취약점으로부터 보호되도록 할 수 있었습니다.

c) 다양한 취약점 데이터베이스 및 권고사항과의 통합: supplier와 consumer는 SBOM 데이터를 취약점 데이터베이스, CERT-In 취약점 노트, 경고, 위협 인텔리전스 플랫폼 및 vendor별 권고사항과 통합하여 소프트웨어의 보안 상태에 대한 포괄적인 가시성을 확보할 수 있습니다. supplier는 SBOM 데이터를 직접 통합하여 구성 요소를 알려진 취약점에 매핑한 다음 향상된 SBOM을 customer에게 제공합니다. consumer는 API, 데이터 피드 또는 수동 프로세스를 활용하여 SBOM을 취약점 데이터와 통합함으로써 수정 작업을 식별하고 우선순위를 정할 수 있습니다.

d) Shift-left 접근 방식 및 취약점 스캐닝 구현: supplier는 보안 도구를 소프트웨어 개발 pipeline에 통합하여 shift-left 취약점 스캐닝을 구현해야 합니다. 이는 빌드 및 패키징 단계와 같은 SDLC의 초기 단계에서 소프트웨어 구성 요소의 취약점을 식별하기 위해 SBOM 데이터를 자동으로 분석하는 것을 포함합니다.

7. 권장사항 및 모범 사례

이 챕터에서는 소프트웨어 공급망 보안을 강화하기 위해 SBOM을 효과적으로 관리하기 위한 실용적인 권장사항과 모범 사례를 다룹니다.

7.1 권장사항

• 7.1.1 모든 정부, 공공 부문, 필수 서비스 조직 및 소프트웨어 수출과 서비스 산업 관련 조직은 모든 소프트웨어와 솔루션 구매/조달에 SBOM 요구사항을 포함해야 합니다.

• 7.1.2 정부, 공공 부문 및 필수 서비스 조직/부서에 공급되는 모든 소프트웨어는 complete SBOM이 동반되어야 합니다.

• 7.1.3 모든 정부, 공공 부문 및 필수 서비스 조직/부서는 사용, 조달 및 개발 중인 소프트웨어의 SBOM을 유지해야 합니다.

• 7.1.4 정부 및 공공 부문 조직/부서에 공급되는 소프트웨어의 SBOM은 이 문서의 4.2장에서 언급된 데이터 필드를 포함해야 합니다.

• 7.1.5 정부 및 공공 부문 조직/부서에 공급되는 소프트웨어의 SBOM을 생성하는 형식은 Software Package Data eXchange (SPDX) 또는 CycloneDX여야 합니다.

• 7.1.6 정부 및 공공 부문 조직/부서에 소프트웨어를 공급하는 소프트웨어 developer/integrator 조직은 취약점이 발견된 후 Vulnerability Exchange Document (VEX)를 설계하여 consumer가 수정 작업의 우선순위를 정할 수 있도록 악용 가능성 상태를 알려야 합니다. VEX document는 특정 소프트웨어 제품의 취약점 상태에 대해 다음을 포함해야 합니다:

  • Not affected - 이 취약점에 대한 수정이 필요하지 않음
  • Affected - 이 취약점을 수정하거나 해결하기 위한 조치가 권장됨
  • Fixed - 이러한 제품 버전에 취약점에 대한 수정사항이 포함되어 있음
  • Under Investigation - 이러한 제품 버전이 취약점의 영향을 받는지 여부가 아직 확인되지 않음. 추후 릴리스에서 업데이트가 제공될 예정

  VEX document 이후에 supplier는 취약점에 대한 설명, 영향을 받는 제품 버전, 심각도 평가 및 권장되는 완화 단계와 같은 상세 정보가 포함된 CSAF 권고사항을 제공해야 합니다.

• 7.1.7 Software Developer/Consumer/Integrator 조직은 SBOM 데이터를 취약점 데이터베이스, CERT-In 취약점 노트, 경고, threat intelligence platform 및 vendor별 권고사항과 통합하여 소프트웨어의 보안 상태에 대한 포괄적인 가시성을 확보해야 합니다.

• 7.1.8 Consumer 조직은 적용된 패치나 완화조치를 반영하기 위해 자체 SBOM을 업데이트해야 합니다.

• 7.1.9 각 소프트웨어 버전에 대해 별도의 SBOM을 유지하고, 추가 구성 요소 정보가 제공되거나 SBOM 오류가 수정될 때만 업데이트합니다.

• 7.1.10 Consumer 조직(특히 정부 및 공공 부문 조직)은 supplier가 제공한 SBOM을 기반으로 내부 SBOM을 매핑하고 개발해야 합니다.

• 7.1.11 소프트웨어 consumer 조직의 보안 팀은 취약점 관리 워크플로우에 SBOM 목록을 포함해야 합니다.

• 7.1.12 SBOM 프로세스의 정확성과 완전성을 보장하기 위해 정기적인 감사와 평가를 수행해야 합니다.

• 7.1.13 Consumer 조직은 VEX의 취약점 상태 정보와 SBOM의 구성 요소 데이터를 결합하여 소프트웨어 취약점을 식별하고 해결하기 위한 표적화된 접근 방식을 가능하게 하는 취약점 상태의 최신 뷰를 제공해야 합니다.

• 7.1.14 SBOM 데이터는 암호화, 접근 제어 및 기타 보안 조치를 사용하여 민감한 정보를 보호하면서 안전하게 저장되고 전송되도록 보장해야 합니다.

• 7.1.15 새로운 소프트웨어 구성 요소가 도입되거나 기존 구성 요소가 업데이트될 때 SBOM을 정기적으로 업데이트하기 위한 워크플로우를 수립해야 합니다.

7.2 모범 사례

• 7.2.1 구성 요소 이름, 버전, 라이선스 및 고유 식별자와 같은 상세한 메타데이터를 SBOM에 포함하도록 보장합니다.

• 7.2.2 SBOM의 정확성과 적시성을 유지하기 위해 secure software development lifecycle (SSDLC) 및 CI/CD pipeline에 SBOM 생성을 통합합니다.

• 7.2.3 심각도, 악용 가능성 및 잠재적 비즈니스 영향과 같은 요소를 기반으로 취약점 수정의 우선순위를 정하기 위한 위험 기반 접근 방식을 구현합니다.

• 7.2.4 SBOM 데이터의 처리, 공유 및 배포를 위한 명확한 정책과 절차를 수립합니다.

• 7.2.5 소프트웨어 공급망 보안과 관련된 compliance를 입증하고 규제 보고 의무를 충족할 수 있도록 SBOM 데이터를 생성해야 합니다.

• 7.2.6 중요한 보안 이벤트에 대해 관련 이해관계자에게 즉시 알림을 제공하여 적시에 수정할 수 있도록 경보 시스템을 구현합니다.

• 7.2.7 SBOM 분석을 통해 식별된 취약점의 수정 관리와 보안 사고 대응을 위한 상세한 플레이북을 개발합니다.

• 7.2.8 암묵적 신뢰 가정을 제거하여 보안을 강화하기 위해, 네트워크에 연결하려는 모든 사용자와 장치를 검증하는 zero-trust 보안 모델을 채택합니다.

• 7.2.9 시스템과 데이터에 대한 무단 접근의 위험을 줄이기 위해 추가 보안 계층으로 Multi Factor Authentication (MFA) 메커니즘을 구현합니다.

• 7.2.10 보안 취약점을 신속하게 식별하고 해결하기 위해 정기적인 취약점 평가와 측정을 수행합니다.

• 7.2.11 취약점을 감지하고 신속하게 해결하기 위해 소프트웨어 구성 요소와 dependency에 대한 지속적인 모니터링을 구현합니다.

• 7.2.12 제공된 SBOM의 정확성, 완전성 및 적시성에 대해 third-party 소프트웨어 vendor와 supplier로부터 보증을 받고, SBOM 요구사항 compliance를 보장하기 위한 계약 협약을 수립합니다.

• 7.2.13 애플리케이션이나 소프트웨어 내의 모든 소프트웨어 구성 요소의 라이선스가 서로 호환되는지 확인하기 위한 철저한 분석을 수행합니다. 서로 다른 라이선스가 적용된 구성 요소를 결합할 때 발생할 수 있는 충돌이나 제한사항을 식별합니다.

• 7.2.14 SBOM에 대한 변경, 추가 또는 업데이트와 함께 VEX document와 CSAF 기반 권고사항의 제공 및 정기적인 업데이트를 보장합니다.

• 7.2.15 developer부터 security team까지 모든 직원에게 SBOM의 중요성과 소프트웨어 공급망 보안 강화에서의 역할에 대한 포괄적인 교육 및 인식 프로그램을 제공합니다.

• 7.2.16 주요 구성 요소가 서로 다른 메타 정보를 가진 여러 인스턴스에 의존하는 경우, 각 인스턴스는 개별 메타 정보와 함께 별도로 나열되어야 합니다.

5.2 - 2025-11-26 대규모 공급망에서 SBOM을 어떻게 운영 단계에 적용할 것인가?

source: https://openchainproject.org/news/2025/11/27/recording-openchain-sbom-work-group-monthly-meeting-2025-11-26

일시: 2025년 11월 26일 (수)

주제: 복잡한 대규모 공급망에서 SBOM을 어떻게 ‘운영(Production)’ 단계에 적용할 것인가?

발표자: Thomas Graf (Siemens)

들어가며: “만드는 것"을 넘어 “쓰는 것"으로

지난 11월 26일 열린 OpenChain SBOM Work Group 정기 미팅은 SBOM(Software Bill of Materials) 논의가 이제 새로운 국면에 접어들었음을 보여주는 중요한 자리였습니다. 그동안 업계의 논의가 “SBOM을 어떻게 생성할 것인가(How to generate)?“에 머물러 있었다면, 이번 미팅의 핵심 질문은 “생성된 SBOM을 실제 운영 환경(Production)과 복잡한 공급망에서 어떻게 활용할 것인가?“였습니다.

특히, 제조 및 산업 자동화 분야의 거인인 지멘스(Siemens)의 Thomas Graf가 연사로 나서, 이론이 아닌 현장의 SBOM 구현 사례를 공유했다는 점에서 큰 의미가 있었습니다. 이 글에서는 미팅의 핵심 내용을 상세히 정리하여, SBOM 도입을 고민하는 실무자들에게 실질적인 인사이트를 제공하고자 합니다.

1. Keynote: 지멘스(Siemens)의 실전 SBOM 구현 전략

이번 미팅의 하이라이트는 단연 Thomas Graf의 발표였습니다. 지멘스는 수만 개의 소프트웨어 컴포넌트와 하드웨어 제품을 다루는 복잡한 공급망을 가진 기업입니다. 그들이 어떻게 SBOM을 표준화하고 관리하는지에 대한 내용은 대규모 조직에게 훌륭한 레퍼런스가 됩니다.

1.1. ‘지멘스 표준 BOM(Siemens Standard BOM)‘의 정의

지멘스는 거대한 조직 특성상 수많은 부서가 각기 다른 도구와 언어를 사용합니다. 이를 통합하기 위해 그들은 ‘지멘스 표준 BOM’이라는 개념을 도입했습니다.

• CycloneDX의 부분집합(Subset) 활용: 지멘스는 OWASP CycloneDX 표준을 기반으로 하되, 모든 스펙을 다 쓰는 것이 아니라 자신들의 비즈니스 로직에 필요한 필수 필드를 정의하여 사용합니다. 이는 데이터의 일관성을 유지하고, 불필요한 복잡성을 줄이기 위함입니다.
• 기술 중립성(Technology Agnostic): Java, Python, .NET 등 특정 언어나 생태계에 종속되지 않는 독립적인 JSON 포맷을 유지합니다. 이를 통해 어떤 개발 환경에서든 동일한 방식의 SBOM 처리가 가능합니다.

1.2. SBOM은 ‘퍼즐(Puzzle)’ 맞추기다

Thomas Graf는 SBOM을 하나의 거대한 퍼즐에 비유했습니다. 하나의 완벽한 SBOM이 뚝딱 만들어지는 것이 아니라, 여러 출처의 데이터를 조립해야 비로소 전체 그림이 보인다는 것입니다.

• 다양한 소스 통합: 오픈소스 라이브러리, 컨테이너 이미지, 3rd Party 벤더가 제공하는 상용 소프트웨어, 그리고 파트너사의 컴포넌트 등 출처가 다른 데이터를 하나의 포맷으로 통합해야 합니다.
• 상호운용성(Interoperability) 확보: 결국 핵심은 ‘상호운용성’입니다. 내부적으로 생성한 데이터와 외부에서 수신한 데이터가 서로 대화할 수 있어야 하며, 이를 위해 지멘스는 자체 툴링을 개발하여 이 간극을 메우고 있습니다.

1.3. 자동화와 툴링의 중요성

“모든 팀은 다르다(Nearly every team is different).“라는 현실적인 문제 앞에서 지멘스는 ‘중앙집중식 강제’보다는 ‘도구 제공’에 초점을 맞춥니다.

• 개발자들이 쉽게 SBOM을 생성하고 라이선스를 검증할 수 있도록 내부(Inner Source) 또는 오픈소스 도구를 제공합니다.
• Thomas Graf는 이러한 도구들이 단순히 지멘스 내부용에 그치지 않고, 오픈소스 생태계에 기여(Upstream contribution)하거나 공개될 가능성도 열어두었습니다. 이는 생태계 전체의 성장을 도모하겠다는 의지입니다.

2. Open Q&A: 커뮤니티의 고민들

발표 이후 이어진 Q&A 세션에서는 전 세계 실무자들의 날카로운 질문들이 이어졌습니다. (미팅 영상 참조: YouTube 링크)

주요 논의 주제는 다음과 같았습니다:

• 레거시 시스템 대응: SBOM 생성이 고려되지 않았던 오래된 시스템(Legacy)에서 어떻게 데이터를 추출할 것인가?
• 데이터 품질(Quality): 벤더로부터 받은 SBOM의 품질이 낮을 때(예: 필수 필드 누락) 이를 어떻게 검증하고 보완할 것인가?
• VEX(Vulnerability Exploitability eXchange) 연동: 단순히 취약점이 있다는 사실을 넘어, 실제로 ‘영향을 받는지’ 여부를 판단하기 위해 VEX 정보를 SBOM과 어떻게 매핑할 것인가?

이러한 논의들은 SBOM이 단순한 ‘문서’가 아니라, 보안 및 컴플라이언스 대응을 위한 ‘살아있는 데이터’로 다뤄져야 함을 재확인시켜 주었습니다.

3. Study Group Updates & 참여 방법

미팅의 마지막 순서로 의장(Chair)의 업데이트가 있었습니다. OpenChain SBOM Work Group은 현재 “대규모 공급망에서의 SBOM 운영"이라는 난제를 해결하기 위해 스터디 그룹을 운영하고 있습니다.openchainproject

이 스터디 그룹은 단순히 이론을 공부하는 것이 아니라, 실제 기업들이 겪는 문제를 공유하고 해결책을 모색하는 실무 중심의 모임입니다. 누구나 참여할 수 있으며, 여러분의 경험이 생태계의 표준이 될 수 있습니다.

[참여 및 정보 확인 방법]

관심 있는 분들은 아래 채널을 통해 지난 자료를 확인하거나 향후 미팅에 참여할 수 있습니다.

• 미팅 다시보기: YouTube 영상 바로가기
• 공식 미팅 로그: OpenChain Project News
• 메일링 리스트 가입: https://lists..org/g/sbom
• GitHub 저장소: https://github.com/OpenChain-Project/SBOM-sg
• 향후 일정 확인: OpenChain Participate Page

맺음말

2025년 11월 미팅은 SBOM이 규제 준수를 위한 ‘숙제’에서, 소프트웨어 공급망 투명성을 확보하는 ‘핵심 인프라’로 진화하고 있음을 보여주었습니다. 지멘스의 사례처럼, 이제는 “어떻게 표준화된 포맷으로, 자동화된 파이프라인 안에서 SBOM을 굴릴 것인가"를 고민해야 할 때입니다.

by Gemini 3.0

5.3 - 2025-10-27 SBOM 품질 가이드와 규제 대응의 구체화

source: https://openchainproject.org/news/2025/10/27/recording-openchain-sbom-work-group-monthly-meeting-2025-10-22

작성일: 2025년 10월 27일

주제: OpenChain SBOM Work Group Monthly Meeting (2025-10-22) 상세 리뷰

안녕하세요. 오늘은 지난 10월 22일에 진행된 OpenChain SBOM 워크 그룹(OpenChain SBOM Work Group) 정기 미팅의 핵심 내용을 정리해 드립니다.

이번 미팅은 지난 9월 ‘스터디 그룹(Study Group)‘에서 ‘워크 그룹(Working Group)‘으로 승격된 이후 본격적으로 진행된 논의라는 점에서 큰 의미가 있었습니다. 특히, 현재 업계의 가장 큰 화두인 “단순히 SBOM을 만드는 것을 넘어, 어떻게 고품질의 SBOM을 만들고 규제에 대응할 것인가?“에 대한 구체적인 가이드라인 작업 현황이 공개되었습니다.

미팅에 직접 참석하지 못하셨더라도 이 글을 통해 현재 논의되고 있는 핵심 아젠다와 향후 방향성을 충분히 이해하실 수 있도록 상세히 정리했습니다.

1. 주요 안건 개요 (Executive Summary)

이번 10월 미팅의 핵심은 단연 ‘SBOM 품질 가이드(Guide to SBOM Quality)‘의 구체화였습니다. 단순히 이론적인 논의에 그치지 않고, 실제 법적 규제와 SBOM 데이터 요소를 매핑(Mapping)하는 실무적인 작업이 진행되고 있음을 확인할 수 있었습니다.

• 그룹 위상 변경: SBOM 스터디 그룹이 공식 ‘워크 그룹(Working Group)‘으로 명칭 및 위상이 변경됨에 따라 활동 범위가 확대되었습니다.
• 품질 가이드 업데이트: ‘Guide to SBOM Quality’ 문서의 챕터 6(규제 매핑 테이블)과 부록 1(환경 다이어그램)이 집중적으로 업데이트되었습니다.
• 앰배서더 프로그램: 워크 그룹 활동을 알릴 2명의 공식 앰배서더가 선정되었습니다.

2. 핵심 업데이트: SBOM 품질 가이드 (Guide to SBOM Quality)

미팅의 대부분은 현재 작성 중인 ‘OpenChain SBOM Document Quality Guide’의 진척 상황을 공유하고 토론하는 데 할애되었습니다. 현재 이 문서는 구글 닥스(Google Docs)를 통해 공동 편집되고 있으며, 추후 마크다운(Markdown) 포맷으로 변환되어 GitHub에 공식 배포될 예정입니다.

2.1. 챕터 6: 규제와 SBOM 요소의 매핑 (Mapping Regulations)

이번 미팅에서 가장 주목해야 할 부분은 Chapter 6의 업데이트입니다. 워크 그룹은 전 세계적으로 강화되고 있는 사이버 보안 규제와 가이드라인을 실제 SBOM 데이터 필드와 연결하는 작업을 진행했습니다.

• 배경: 기업들은 “미국 행정명령(EO 14028)이나 EU 사이버복원력법(CRA)을 준수하려면 SBOM에 정확히 어떤 필드가 있어야 하는가?“라는 질문을 끊임없이 던집니다.
• 업데이트 내용: 챕터 6에 ‘규제/가이드라인과 SBOM 요소 간의 매핑 테이블’이 추가되었습니다. 이는 특정 규제(예: NTIA 최소 요소, CRA 등)가 요구하는 사항을 만족시키기 위해 SBOM 내에 어떤 태그(Tag)나 데이터가 필수적으로 포함되어야 하는지를 일목요연하게 보여줍니다.
• 현재 상태: 이 작업은 아직 진행 중(Work in Progress)이며, 미팅에서는 3가지 주요 가이드라인을 우선적으로 선정하여 매핑 작업을 진행하고 있다고 밝혔습니다.

2.2. 부록 1: 환경 다이어그램 (Environment Diagram)

단순한 텍스트 나열을 넘어, 시각적인 이해를 돕기 위한 부록(Appendix 1) 업데이트도 있었습니다.

• 내용: 각 가이드라인을 준수하기 위해 “누가(Which entity)” SBOM 문서를 생성해야 하는지를 보여주는 환경 다이어그램(Environment Diagram)이 추가되었습니다.
• 의의: 공급망은 매우 복잡합니다. 오픈소스 프로젝트 관리자, 패키지 배포자, 최종 제품 벤더 등 다양한 주체가 섞여 있습니다. 이 다이어그램은 각 주체가 공급망의 어느 단계에서 어떤 책임을 지고 SBOM을 생성해야 하는지를 명확히 하여, 책임 소재의 모호함을 줄이는 데 기여할 것입니다.

3. 워크 그룹 운영 및 기타 소식

3.1. 스터디 그룹에서 ‘워크 그룹’으로

지난 9월, OpenChain 이사회(Board)는 기존의 SBOM 스터디 그룹을 ‘워크 그룹(Working Group)‘으로 승격시켰습니다. 이는 해당 모임이 단순한 학습이나 정보 공유를 넘어, 실질적인 표준과 가이드라인을 생산하는 조직으로 인정받았음을 의미합니다. 이에 따라 10월 미팅부터는 공식적으로 변경된 그룹 명칭이 사용되었습니다.

3.2. 앰배서더(Ambassador) 프로그램

워크 그룹의 활동을 외부에 더 널리 알리고 참여를 독려하기 위해, OpenChain 프로젝트는 앰배서더 프로그램을 도입했습니다. 이번 미팅에서는 SBOM 워크 그룹을 위해 두 명의 앰배서더가 활동하게 되었음을 공지했습니다. 이들은 향후 메일링 리스트와 소셜 미디어를 통해 워크 그룹의 성과를 전파하는 역할을 맡게 됩니다.

3.3. 11월 자동차(Automotive) 관련 미팅 예고

다가오는 11월 중순에는 자동차 산업에 특화된 별도의 미팅이 예정되어 있습니다.

• 형식: 단순한 발표(Presentation) 형식이 아닌, 참여자 간의 활발한 토론(Discussion) 중심으로 진행될 예정입니다.
• 목표: 자동차 산업의 복잡한 공급망 특성을 반영하여 실질적인 문제를 해결하는 자리가 될 것으로 기대됩니다.

4. 참여 방법 및 리소스

OpenChain SBOM 워크 그룹은 모든 과정이 투명하게 공개되며, 누구나 참여할 수 있습니다. “대규모 공급망에서 SBOM을 어떻게 실제로 운영(Production)할 것인가?“라는 난제를 함께 풀어나가고 싶다면 아래 채널을 참고해 주세요.

• 메일링 리스트: https://lists.openchainproject.org/g/sbom (주요 공지 및 논의가 이루어지는 곳)
• GitHub 리포지토리: https://github.com/OpenChain-Project/SBOM-sg (회의록, 가이드 문서 초안 등 자료 아카이브)
• 미팅 참여: OpenChain 프로젝트의 참여 페이지(Participate Page)에서 향후 미팅 일정과 접속 정보를 확인할 수 있습니다.

5. 마치며: ‘양’에서 ‘질’로의 전환

이번 10월 미팅은 SBOM 논의가 ‘생성(Generation)‘의 단계를 지나 ‘품질(Quality)과 규제 준수(Compliance)‘의 단계로 깊어지고 있음을 보여주었습니다.

단순히 SBOM 파일을 만들어내는 것만으로는 충분하지 않습니다. 그 SBOM이 “규제가 요구하는 필수 요소를 포함하고 있는가?”, “누가 그 데이터의 정확성을 책임지는가?“에 대한 답을 내릴 수 있어야 합니다. 현재 워크 그룹이 작성 중인 ‘품질 가이드’는 바로 이 질문에 대한 해답이 될 것입니다.

by Gemini 3.0

5.4 - 2024-11-27 취약점과 미래 - 다층적 소프트웨어 취약점과 대응 전략

source: https://openchainproject.org/news/2024/12/04/sbom-study-group-2024-11-27

목차

1. 소개
2. 발표자 소개
3. 웨비나 개요
4. Software Bill of Materials (SBOM)의 중요성
5. 공급망 위험과 취약점
6. 오픈소스 소프트웨어의 보안 성숙도
7. 취약점 해결 전략
8. Software Heritage 프로젝트 소개
9. CycloneDX의 도전과제
10. 질의응답
11. 결론

1. 소개

이 블로그 포스트는 OpenChain Project의 SBOM Study Group 웨비나에서 발표된 “취약점과 미래 - 다층적 소프트웨어 취약점과 대응 전략"에 대한 내용을 다룹니다. 이 웨비나는 소프트웨어 공급망 보안과 취약점 관리의 중요성을 강조하며, 현재의 도전과제와 미래의 전략을 탐구합니다.

2. 발표자 소개

발표자인 Okada San은 OWASP Japan의 전문가로, 일본 기업에서 애플리케이션 보안 강화와 소프트웨어 생산성 팀을 지원하는 보안 연구원입니다. OWASP 재단의 평생 회원으로, 20년 이상 다양한 문서 번역 작업에 참여해 왔습니다.

3. 웨비나 개요

이 웨비나는 소프트웨어 취약점의 다층적 특성과 이에 대한 효과적인 대응 전략을 다룹니다. 특히 Software Bill of Materials (SBOM)의 중요성과 CycloneDX와 같은 표준의 역할에 초점을 맞춥니다. 또한 오픈소스 소프트웨어의 보안 성숙도와 공급망 위험에 대해 심도 있게 논의합니다.

4. Software Bill of Materials (SBOM)의 중요성

SBOM은 소프트웨어 구성 요소의 투명성을 제공하는 중요한 도구입니다. Okada San은 SBOM이 단순히 형식이 아닌 소프트웨어 구성과 투명성에 대한 정보를 교환하는 방법이라고 강조합니다. CycloneDX와 SPDX와 같은 표준은 이러한 정보 교환을 위한 프레임워크를 제공합니다.

5. 공급망 위험과 취약점

Okada San은 소프트웨어 공급망의 세 가지 주요 위험 지점을 설명합니다:

1. 공격 대상으로서의 오픈소스 소프트웨어
2. 오픈소스 의존성의 낮은 보안 성숙도
3. 업데이트를 맹목적으로 신뢰하는 사용자

이러한 위험은 typosquatting과 같은 공격 기법을 통해 악용될 수 있으며, 이는 오픈소스 저장소의 보안 중요성을 강조합니다.

6. 오픈소스 소프트웨어의 보안 성숙도

Open Source Security Foundation (OpenSSF)의 보고서에 따르면, 전문가의 약 3분의 1이 안전한 소프트웨어 개발 관행에 익숙하지 않다고 합니다. 이는 오픈소스 프로젝트의 보안 성숙도 향상이 시급함을 시사합니다.

7. 취약점 해결 전략

Okada San은 취약점 해결을 위한 여러 전략을 제시합니다:

1. 소프트웨어 구성 분석 (SCA) 수행
2. 프로젝트의 신뢰성 평가
3. 코드 품질과 업데이트 빈도 확인
4. OWASP Dependency-Track과 같은 도구 활용

8. Software Heritage 프로젝트 소개

Software Heritage 프로젝트는 다양한 저장소의 아카이브를 제공합니다. 이 프로젝트를 통해 개발자의 기여 이력과 패치의 품질을 추적할 수 있어, 프로젝트나 개발자의 신뢰성을 평가하는 데 유용합니다.

9. CycloneDX의 도전과제

Okada San은 CycloneDX의 주요 도전과제를 다음과 같이 설명합니다:

1. 공개 사례 연구의 부족
2. 호스팅된 250개 이상의 도구에 대한 재분류 필요
3. 하드웨어 제조업체의 제한적인 입력
4. 확장되는 생태계를 지원할 추가 유지 관리자 모집

10. 질의응답

Q: 일본 외 다른 지역의 OWASP 지부가 있나요? A: 네, 전 세계에 많은 OWASP 지부가 있습니다. 월간 또는 분기별 모임을 통해 애플리케이션 보안 전문가들과 쉽게 교류할 수 있습니다.

Q: Software Heritage를 어떻게 활용하고 있나요? A: 저는 주로 Protestware와 관련된 개발자를 추적하고, 그들이 다른 프로젝트에 기여하는지 확인하는 데 사용했습니다. 이를 통해 다른 위험 요소들도 발견할 수 있었습니다.

11. 결론

Okada San은 소프트웨어 투명성과 보안의 중요성을 강조하며 발표를 마무리합니다. 그는 모든 참가자들에게 CycloneDX 커뮤니티에 참여하고, 소프트웨어 투명성에 대한 논의에 기여할 것을 권장합니다.

요약 보고서

기업의 오픈소스 관리 담당자에게 주는 의미

1. 투명성의 중요성: SBOM을 통한 소프트웨어 구성 요소의 투명성 확보가 필수적입니다.
2. 보안 성숙도 향상: 오픈소스 프로젝트의 보안 성숙도를 평가하고 개선하는 노력이 필요합니다.
3. 공급망 위험 관리: 오픈소스 의존성에 대한 지속적인 모니터링과 관리가 중요합니다.
4. 커뮤니티 참여: CycloneDX와 같은 표준화 커뮤니티에 적극적으로 참여해야 합니다.
5. 도구 활용: Software Heritage, OWASP Dependency-Track 등의 도구를 활용한 프로젝트 평가가 필요합니다.

고려해야 할 Action Item

1. SBOM 생성 및 관리 프로세스 구축
2. 오픈소스 의존성에 대한 정기적인 보안 감사 실시
3. 개발자 대상 보안 교육 프로그램 강화
4. CycloneDX나 SPDX와 같은 표준 채택 및 구현
5. Software Heritage를 활용한 프로젝트 및 개발자 신뢰성 평가 체계 수립
6. OWASP Dependency-Track 등의 도구를 CI/CD 파이프라인에 통합
7. 오픈소스 커뮤니티 활동 참여 및 기여 장려
8. 내부 취약점 관리 정책 및 프로세스 개선
9. 공급업체 관리 정책에 SBOM 요구사항 포함
10. 정기적인 위험 평가 및 대응 전략 수립

이러한 액션 아이템을 실행함으로써, 기업은 소프트웨어 공급망 보안을 강화하고 잠재적인 취약점에 대한 대응 능력을 향상시킬 수 있습니다.

5.5 - 2024-10-29 SBOM 관련 다양한 규제와 가이드라인에 대한 개요

source: https://openchainproject.org/news/2024/10/29/openchain-sbom-study-group-october-2024-10-23-full-recording

목차

1. 세미나 개요
2. 발표 내용
3. 질의응답
4. 결론 및 향후 계획

1. 세미나 개요

제목

OpenChain SBOM 스터디 그룹 - 2024년 10월 세미나

발표자 소개

이번 세미나의 발표자는 도시바의 Ninjouji-san입니다. 도시바는 일본의 대표적인 다국적 전자 기업으로, 오픈소스 및 SBOM 관련 분야에서 풍부한 경험을 보유하고 있습니다.

웨비나 소개와 목적

이번 OpenChain SBOM 스터디 그룹 세미나는 다양한 규제와 가이드라인에 대한 개요를 제공하고, 향후 미팅에서 필요한 사항들에 대해 논의하는 것을 목적으로 합니다. SBOM(Software Bill of Materials)은 소프트웨어 구성 요소를 투명하게 관리하고 보안 취약점을 효과적으로 대응하기 위한 중요한 도구로 주목받고 있습니다.

2. 발표 내용

SBOM 관련 규제 및 가이드라인 개요

Ninjouji-san은 SBOM과 관련된 주요 규제 및 가이드라인에 대해 상세히 설명했습니다. 이는 다음과 같은 내용을 포함합니다:

1. 미국 사이버보안 및 기반시설 보안국(CISA)의 SBOM 요구사항
2. 유럽연합(EU)의 사이버 복원력 법안
3. 일본 경제산업성(METI)의 소프트웨어 관리 지침

각 규제와 가이드라인의 주요 특징, 적용 범위, 기업에 미치는 영향 등을 자세히 다루었습니다.

SBOM 도구 및 표준 포맷

발표자는 SBOM 생성 및 관리를 위한 다양한 도구들을 소개했습니다:

1. SPDX: 리눅스 재단에서 개발한 오픈소스 라이선스 및 보안 정보 교환 표준
2. CycloneDX: OWASP에서 개발한 경량화된 SBOM 표준
3. SWID: 소프트웨어 식별 태그 표준

각 도구의 특징, 장단점, 적용 사례 등을 비교 분석하여 참가자들의 이해를 도왔습니다.

SBOM 구현 전략

Ninjouji-san은 기업이 SBOM을 효과적으로 구현하기 위한 전략을 제시했습니다:

1. 소프트웨어 공급망 매핑
2. SBOM 생성 자동화 도구 선택
3. 지속적인 모니터링 및 업데이트 프로세스 수립
4. 보안 취약점 관리와 SBOM 연계

이러한 전략을 통해 기업은 규제 준수뿐만 아니라 소프트웨어 품질 및 보안 향상을 도모할 수 있습니다.

3. 질의응답

세미나 참가자들로부터 다양한 질문이 제기되었습니다:

Q: SBOM 구현 시 가장 큰 도전 과제는 무엇인가요? A: Ninjouji-san은 레거시 시스템에 대한 SBOM 생성과 서드파티 소프트웨어 컴포넌트의 정확한 추적이 주요 과제라고 답변했습니다.

Q: 중소기업도 SBOM을 도입해야 하나요? A: 발표자는 기업 규모와 관계없이 SBOM 도입이 중요하며, 오픈소스 도구를 활용하여 비용 효율적으로 시작할 수 있다고 조언했습니다.

Q: SBOM과 DevSecOps의 연계 방안은? A: SBOM을 CI/CD 파이프라인에 통합하여 지속적인 보안 검증을 수행할 수 있다고 설명했습니다.

4. 결론 및 향후 계획

Ninjouji-san은 SBOM이 소프트웨어 공급망 보안의 핵심 요소로 자리잡고 있음을 강조하며 세미나를 마무리했습니다. 향후 스터디 그룹 미팅에서는 다음과 같은 주제를 다룰 예정입니다:

1. SBOM 생성 자동화 사례 연구
2. 클라우드 네이티브 환경에서의 SBOM 관리
3. SBOM과 취약점 관리 연계 방안

참가자들은 이번 세미나를 통해 SBOM의 중요성과 실제 구현 방안에 대한 깊이 있는 이해를 얻을 수 있었습니다.

요약 보고서

기업의 오픈소스 관리 담당자에게 주는 의미

1. 규제 대응 필요성: SBOM은 미국, EU, 일본 등 주요국의 사이버보안 규제 대응에 필수적인 요소로 자리잡고 있습니다. 오픈소스 관리 담당자는 이러한 규제 동향을 주시하고 선제적으로 대응해야 합니다.

2. 소프트웨어 품질 향상: SBOM을 통해 사용 중인 오픈소스 컴포넌트를 정확히 파악하고 관리함으로써 전반적인 소프트웨어 품질을 향상시킬 수 있습니다.

3. 보안 취약점 관리 강화: SBOM은 사용 중인 오픈소스 컴포넌트의 취약점을 신속하게 식별하고 대응할 수 있게 해줍니다. 이는 기업의 사이버보안 태세를 강화하는 데 크게 기여합니다.

4. 공급망 투명성 확보: SBOM을 통해 소프트웨어 공급망의 투명성을 높일 수 있어, 고객 신뢰도 향상 및 리스크 관리에 도움이 됩니다.

5. DevSecOps 통합: SBOM을 개발 및 운영 프로세스에 통합함으로써 보안을 개발 초기 단계부터 고려하는 DevSecOps 문화를 촉진할 수 있습니다.

고려해야 할 Action Item

1. SBOM 생성 도구 평가 및 선택: SPDX, CycloneDX 등 다양한 SBOM 표준과 도구를 평가하고, 기업의 환경에 가장 적합한 솔루션을 선택합니다.

2. 자동화 프로세스 구축: CI/CD 파이프라인에 SBOM 생성 및 검증 과정을 자동화하여 통합합니다.

3. 교육 및 인식 제고: 개발자, 보안 팀, 법무 팀 등 관련 부서 직원들에게 SBOM의 중요성과 활용 방법에 대한 교육을 실시합니다.

4. 정책 및 가이드라인 수립: SBOM 관리에 대한 조직 내 정책과 가이드라인을 수립하고 이를 문서화합니다.

5. 취약점 관리 프로세스 개선: SBOM 정보를 활용하여 취약점 스캐닝 및 패치 관리 프로세스를 개선합니다.

6. 공급업체 관리 강화: 서드파티 소프트웨어 공급업체에 SBOM 제공을 요구하고, 이를 평가 기준에 포함시킵니다.

7. 규제 준수 모니터링: SBOM 관련 국내외 규제 동향을 지속적으로 모니터링하고, 필요시 신속히 대응합니다.

8. SBOM 공유 체계 구축: 고객 및 파트너사와 SBOM을 안전하게 공유할 수 있는 체계를 구축합니다.

이러한 액션 아이템을 체계적으로 이행함으로써, 기업은 SBOM을 효과적으로 도입하고 활용하여 소프트웨어 공급망 보안을 강화할 수 있을 것입니다.

5.6 - 2024-07-30 킥오프 웨비나: SBOM의 실제 활용 방안 모색

source: https://www.slideshare.net/slideshow/openchain-sbom-study-group-kick-off-call-2024-07-30/270623321

목차

1. 웨비나 소개
2. SBOM의 중요성과 OpenChain 프로젝트의 역할
3. SBOM 활용의 실제적 고려사항
4. SPDX Lite: SBOM 생성을 위한 간소화된 접근
5. 향후 계획 및 참여 방법

1. 웨비나 소개

제목

OpenChain SBOM Study Group 킥오프 웨비나

발표자 소개

• Shane Coughlan: OpenChain 프로젝트 총괄 매니저
• Kate Stewart: Linux Foundation의 오픈소스 기술 부사장
• Kobota San: Sony에서 근무하며, 2024년 SBOM Study Group의 의장

웨비나 소개와 목적

이 웨비나는 OpenChain 프로젝트의 새로운 SBOM Study Group의 킥오프 미팅입니다. 주요 목적은 대규모 및 복잡한 공급망에서 SBOM(Software Bill of Materials)을 실제로 어떻게 활용할 수 있는지에 대한 논의를 시작하는 것입니다. 이를 통해 SBOM의 실용적인 적용 방안과 공급망 내에서의 신뢰 구축 방법을 모색하고자 합니다.

2. SBOM의 중요성과 OpenChain 프로젝트의 역할

OpenChain 프로젝트는 2026년 설립 이후 지속적으로 컴플라이언스 및 보안 표준의 일환으로 SBOM을 요구해왔습니다. 프로젝트는 SBOM 분야에 다양한 방식으로 기여해왔으며, 특히 공급업체를 위한 간단한 SBOM 형식인 SPDX Lite의 개발과 SBOM 품질 평가 가이드 제작 등을 수행했습니다.

Shane Coughlan은 SBOM의 중요성을 강조하며, 이는 단순한 기술적 도구가 아닌 비즈니스 프로세스의 핵심 요소라고 설명합니다. SBOM은 소프트웨어 구성 요소의 투명성을 제공하여 보안, 라이선스 준수, 품질 관리 등 다양한 영역에서 중요한 역할을 합니다.

3. SBOM 활용의 실제적 고려사항

Kate Stewart는 SBOM 활용에 있어 실제적인 고려사항들을 제시합니다:

SBOM 생성 및 소비의 주체

• 소프트웨어 개발자
• 제품 관리자
• 보안 전문가
• 법무 및 컴플라이언스 팀
• 구매 담당자
• 고객

SBOM의 주요 활용 사례

• 취약점 관리
• 라이선스 컴플라이언스
• 소프트웨어 구성 요소 추적
• 공급망 리스크 관리

SBOM 구현 시 고려사항

• 데이터 형식 (예: SPDX, CycloneDX)
• 생성 도구 및 프로세스
• 저장 및 배포 방식
• 업데이트 주기 및 버전 관리

4. SPDX Lite: SBOM 생성을 위한 간소화된 접근

Kate Stewart는 SPDX Lite에 대해 상세히 설명합니다. SPDX Lite는 전체 SPDX 규격의 간소화된 버전으로, SBOM 생성의 진입 장벽을 낮추고자 개발되었습니다.

SPDX Lite의 주요 특징

• 필수 필드 수를 줄여 간편한 SBOM 생성 가능
• 기본적인 소프트웨어 구성 요소 정보 제공
• 확장 가능성을 통해 필요에 따라 더 상세한 정보 추가 가능

SPDX Lite 활용 사례

• 소규모 프로젝트나 간단한 소프트웨어 패키지에 적합
• 대규모 SBOM 구현의 첫 단계로 활용 가능
• 공급업체와 고객 간의 기본적인 소프트웨어 구성 정보 교환에 유용

5. 향후 계획 및 참여 방법

Shane Coughlan은 SBOM Study Group의 향후 계획과 참여 방법에 대해 안내합니다:

• 정기적인 미팅을 통해 SBOM 관련 실제 사례와 도전 과제 논의
• 다양한 산업 분야의 전문가들과 협력하여 SBOM 활용 방안 개발
• OpenChain 커뮤니티를 통한 지식 공유 및 네트워킹 기회 제공

SBOM, 공급망에서의 SBOM 활용, 그리고 공급망 신뢰 증진에 관심 있는 모든 분들의 참여를 환영합니다. 특히 Sony의 Kobota San이 2024년 study group의 의장을 맡아 활동을 이끌어갈 예정입니다.

요약 보고서

기업의 오픈소스 관리 담당자에게 주는 의미

1. SBOM의 전략적 중요성 인식: SBOM은 단순한 기술적 도구를 넘어 비즈니스 프로세스의 핵심 요소로 자리잡고 있습니다. 오픈소스 관리 담당자는 SBOM을 통해 소프트웨어 공급망의 투명성을 확보하고, 보안 및 컴플라이언스 리스크를 효과적으로 관리할 수 있습니다.

2. 다양한 이해관계자와의 협업: SBOM은 개발자, 보안 전문가, 법무팀, 구매 담당자 등 다양한 부서와의 협업을 필요로 합니다. 오픈소스 관리자는 이러한 협업을 주도하여 조직 전체의 SBOM 활용을 촉진할 수 있습니다.

3. SBOM 표준 및 도구에 대한 이해: SPDX, CycloneDX 등 다양한 SBOM 표준과 관련 도구에 대한 이해가 필요합니다. 특히 SPDX Lite와 같은 간소화된 접근 방식은 SBOM 도입의 진입 장벽을 낮출 수 있습니다.

4. 공급망 관리 강화: SBOM을 통해 소프트웨어 구성 요소의 출처와 라이선스 정보를 명확히 파악할 수 있어, 공급망 리스크 관리와 라이선스 컴플라이언스를 강화할 수 있습니다.

고려해야 할 Action Item

1. SBOM 생성 및 관리 프로세스 수립: 조직 내 SBOM 생성, 유지보수, 공유를 위한 표준화된 프로세스를 개발하고 구현합니다.

2. SBOM 도구 선정 및 도입: 조직의 needs에 맞는 SBOM 생성 및 분석 도구를 선정하고 도입합니다. SPDX Lite와 같은 간소화된 접근부터 시작할 수 있습니다.

3. 교육 및 인식 제고: 개발자, 관리자, 법무팀 등 관련 부서 직원들을 대상으로 SBOM의 중요성과 활용 방법에 대한 교육을 실시합니다.

4. 공급업체 관리 정책 수립: 외부 공급업체로부터 SBOM을 요구하고 평가하는 정책을 수립합니다. 이를 통해 전체 소프트웨어 공급망의 투명성을 확보합니다.

5. SBOM 데이터 통합 및 분석: SBOM 데이터를 기존의 보안 및 컴플라이언스 도구와 통합하여 종합적인 리스크 분석을 수행합니다.

6. 지속적인 모니터링 및 개선: SBOM 관련 기술과 표준의 발전을 지속적으로 모니터링하고, 조직의 SBOM 프로세스를 지속적으로 개선합니다.

7. 커뮤니티 참여: OpenChain SBOM Study Group과 같은 커뮤니티에 참여하여 최신 동향을 파악하고 다른 조직의 best practices를 학습합니다.

이러한 action item들을 체계적으로 실행함으로써, 기업의 오픈소스 관리 담당자는 SBOM을 효과적으로 활용하여 조직의 소프트웨어 관리 및 보안 체계를 강화할 수 있을 것입니다.

6 - Telco Work Group

6.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.

6.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

6.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

6.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 가이드라인 모니터링 및 대응 체계 구축

7 - Webinars

7.1 - 2025-12-03 생성형 AI, 개발의 '속도'와 '위험' 사이: 우리는 어떻게 관리해야 할까?

source: https://openchainproject.org/news/2025/12/04/webinar-a-panel-on-generative-ai-risks-and-management

일시: 2025년 12월 4일

주최: OpenChain Project

패널: Bitsea, Jun Legal, FossID, SCANOSS의 전문가 그룹

지난 2025년 12월 4일, 오픈소스 컴플라이언스와 공급망 관리의 글로벌 표준을 이끄는 OpenChain Project가 매우 시의적절한 웨비나를 개최했습니다. 주제는 바로 “생성형 AI(Generative AI)의 위험과 관리(Risks and Management)“였습니다.

개발자들 사이에서 ‘코파일럿(Copilot)‘이나 ‘챗GPT(ChatGPT)’ 없는 코딩은 상상하기 힘들어진 지금, 기업은 생산성 향상이라는 달콤한 과실과 법적/보안 리스크라는 쓴 뿌리를 동시에 마주하고 있습니다. 이번 웨비나에서는 Bitsea, Jun Legal, FossID, SCANOSS 등 업계 최고의 전문가들이 모여, 단순히 AI를 “사용한다/안 한다"의 이분법을 넘어, “어떻게 안전하게 관리하며 활용할 것인가"에 대한 실질적인 해답을 논의했습니다.

1. 환상적인 속도, 그리고 숨겨진 함정

웨비나의 서두는 생성형 AI가 가져온 압도적인 효율성에 대한 인정으로 시작되었습니다. 패널들은 현장의 목소리를 빌려, AI 도구 도입 후 개발 속도가 25%에서 50%, 심지어 그 이상 빨라졌다는 보고가 잇따르고 있다고 전했습니다.

하지만 이러한 속도 뒤에는 반드시 해결해야 할 과제가 있습니다. 바로 ‘검증되지 않은 코드의 유입’입니다. 개발자가 AI가 짜준 코드를 그대로 복사해서 붙여넣을 때, 그 코드가 어디서 왔는지, 어떤 라이선스를 가지고 있는지, 보안 취약점은 없는지 확인하는 과정이 생략되기 쉽다는 점이 지적되었습니다.

2. 충격적인 사례: “AI가 우리 코드를 표절했다?”

이날 논의에서 가장 인상 깊었고, 청중들의 이목을 집중시켰던 사례는 바로 SCANOSS의 경험담이었습니다.

소프트웨어 구성 분석(SCA) 및 컴플라이언스 전문 기업인 SCANOSS는 어느 날 황당한 사실을 발견했습니다. 생성형 AI가 자신들의 독자적인(Proprietary) 코드 혹은 특정 오픈소스 코드를 토씨 하나 틀리지 않고 그대로 생성해낸 것입니다.

이는 생성형 AI가 단순히 코딩 문법을 학습해서 새로운 코드를 ‘창작’하는 것이 아니라, 학습 데이터에 포함된 코드를 ‘암기’했다가 그대로 ‘반복(Regurgitate)‘할 수 있음을 보여주는 결정적인 증거였습니다. 만약 기업이 이 코드를 그대로 제품에 사용한다면? 본의 아니게 타사의 지식재산권을 침해하거나, 강력한 카피레프트(Copyleft) 라이선스 의무를 위반하게 될 수도 있는 것입니다. 이 사례는 AI가 생성한 코드가 결코 ‘저작권 청정 구역’이 아니라는 점을 시사합니다.

3. 패러다임의 전환: “두려워 말고, 관리하라”

이러한 위험성에도 불구하고, 패널들의 결론은 “AI를 쓰지 말자"가 아니었습니다. 오히려 FossID의 전문가는 이렇게 강조했습니다.

“우리는 생성형 AI를 두려워해서는 안 됩니다. 솔직히 말해서, 이건 환상적인 도구입니다. 우리의 역할은 위험을 과장해서 겁을 주는 게 아니라, 개발자들이 이 도구를 안전하고 효율적으로 활용할 수 있도록 필요한 도구와 프로세스를 제공하는 것입니다.”

즉, 무조건적인 금지보다는 ‘관리 가능한 위험(Manageable Risk)‘으로 접근해야 한다는 것입니다. 웨비나 진행자 역시 자신도 Copilot, ChatGPT, Claude 등 다양한 AI 도구를 매일 사용하고 있음을 밝히며, 핵심은 “어떻게 관리(Manage)하느냐"에 달려 있다고 역설했습니다.

4. 실전 가이드: 기업은 무엇을 해야 하는가?

그렇다면 구체적으로 기업은 어떤 준비를 해야 할까요? 패널들은 크게 세 가지 측면에서 실무적인 조언을 제시했습니다.

① ‘사일로(Silo)‘를 파괴하라: 법무, 제품, OSPO의 협업

AI 리스크는 법무팀 혼자서, 혹은 보안팀 혼자서 해결할 수 있는 문제가 아닙니다. 패널들은 법무(Legal), 제품(Product), 그리고 오픈소스 전담 조직(OSPO)이 반드시 함께 움직여야 한다고 강조했습니다.

• 법무: 라이선스 및 저작권 리스크 판단
• 제품: AI 도입을 통한 생산성 목표 설정
• OSPO: 실제 개발 프로세스 내 가이드라인 수립 및 교육

② 정책의 범위를 명확히 하라

단순히 “라이선스를 확인해라” 정도의 모호한 지침은 부족합니다.

• 우리 회사가 허용하는 AI 도구는 무엇인가?

• AI가 생성한 코드를 상용 제품에 포함시킬 때의 검수 절차는 무엇인가?

• 입력 데이터(프롬프트)에 회사 기밀을 넣지 않도록 하는 보안 지침은 무엇인가?

  이처럼 구체적인 정책(Policy)과 허용 범위(Scope)를 먼저 합의하고 정의하는 것이 첫걸음입니다.

③ 개발자를 움직이는 힘: ‘교육’과 ‘도구’

웨비나 중 진행된 실시간 설문조사에서 “AI가 생성한 코드가 법적으로 안전한지 확인하고 있는가?“라는 질문에 대해, “그렇다"는 응답은 8명에 불과했고, “모른다"는 답변도 5명이나 되었습니다.

개발자들이 보안 절차를 귀찮아하거나 거부감을 느끼는 경우에 대해, 패널들은 “강요가 아닌 이해"를 해법으로 제시했습니다.

• 개발자에게 “그냥 검사해"라고 시키면 따르지 않습니다.
• *“왜 이것이 위험한지”, “이 코드가 회사의 IP를 어떻게 위협할 수 있는지"를 명확히 교육하면, 개발자들은 스스로 조심하고 움직입니다.
• 더불어, 개발자의 워크플로우를 방해하지 않는 자동화된 검증 도구(Tooling)를 제공하여 검사 과정을 간소화해 주는 것이 필수적입니다.

5. 결론: AI 시대의 새로운 ‘체인지 메이커’가 되자

웨비나는 참석자들에게 긍정적인 비전을 제시하며 마무리되었습니다. 과거 오픈소스가 처음 등장했을 때도 기업들은 보안과 라이선스 문제로 두려움에 떨었습니다. 하지만 지금 오픈소스는 IT 산업의 표준이 되었습니다.

생성형 AI도 마찬가지입니다. 지금의 혼란과 리스크 관리 과정은 우리에게 새로운 프로세스 전문가, 변화 관리자(Change Manager)가 될 기회를 제공합니다. AI라는 거대한 파도를 두려워만 할 것이 아니라, 그 파도 위에 올라타는 법을 익히는 조직만이 다음 단계로 도약할 수 있을 것입니다.

3줄 요약

1. AI는 양날의 검: 개발 속도를 50%까지 높여주지만, 타사 코드 표절이나 라이선스 위반 같은 치명적 리스크도 함께 가져온다.
2. 금지보단 관리: AI 사용을 막을 수는 없다. 법무-제품-OSPO 팀이 협력하여 ‘안전한 사용 가이드라인’을 만드는 것이 유일한 해법이다.
3. 도구와 교육: 개발자가 스스로 납득할 수 있는 리스크 교육을 제공하고, 개발 흐름을 끊지 않는 자동화된 검증 도구를 도입해야 한다.

이 포스팅은 2025년 12월 4일 진행된 OpenChain 웨비나 내용을 바탕으로 재구성되었습니다. 원본 영상은 여기에서 확인하실 수 있습니다.

by Gemini 3.0

7.2 - 2025-12-03 Software Hash ID (SWHID): 이제는 선택이 아닌 필수입니다

source: https://openchainproject.org/webinar/2025/12/03/webinar-software-hash-id-you-will-not-be-able-to-live-without-it

2025년 12월 3일, OpenChain Project는 매우 중요한 주제로 웨비나를 개최했습니다. 바로 SWHID(Software Hash Identifier)입니다.

“소프트웨어 식별자? 그냥 URL이나 버전 넘버 쓰면 되는 거 아냐?“라고 생각하셨나요? 만약 그랬다면 오늘 이 글을 끝까지 읽으셔야 합니다. 2025년 4월, ISO/IEC 18670:2025 국제 표준으로 제정된 SWHID는 이제 소프트웨어 공급망 보안과 컴플라이언스의 새로운 기준(New Normal)이 되었기 때문입니다.

이번 웨비나에서는 Software Heritage의 CTO인 Thomas Aynaud가 연사로 나서 SWHID의 기술적 원리와 거버넌스, 그리고 우리가 왜 이것 없이는 살 수 없게 될 것인지에 대해 심도 깊은 이야기를 나누었습니다. 웨비나를 놓치신 분들을 위해 핵심 내용을 상세히 정리해 드립니다.

1. 문제의 시작: “그 코드, 어디 갔지?”

우리는 매일 수많은 오픈소스와 라이브러리에 의존해 소프트웨어를 개발합니다. 하지만 우리가 의존하는 그 코드를 식별하는 방식은 생각보다 불안정합니다.

• URL은 깨집니다 (Link Rot): GitHub 저장소가 삭제되거나, 프로젝트가 다른 곳으로 이사 가면 URL은 무용지물이 됩니다.
• 버전 넘버는 모호합니다: v1.0이라는 태그는 개발자가 덮어쓰기 나름입니다. 어제 다운로드한 v1.0과 오늘 다운로드한 v1.0이 100% 같다고 보장할 수 있을까요?

Thomas Aynaud는 이 문제를 해결하기 위해 ‘고유 식별자(Intrinsic Identifier)‘의 개념을 소개했습니다.

외재적(Extrinsic) vs. 내재적(Intrinsic) 식별자

이것이 이번 웨비나의 핵심 개념입니다.

• 외재적 식별자 (Extrinsic): 외부 시스템(레지스트리)이 부여하는 이름입니다. 예: 주민등록번호, URL, DOI.
  • 문제점: 발급 기관(레지스트리)이 사라지거나 실수를 하면 식별자와 대상의 연결이 끊어집니다.
• 내재적 식별자 (Intrinsic): 대상 그 자체에서 계산된 이름입니다. 예: 지문, DNA, SWHID.
  • 장점: 레지스트리가 필요 없습니다. 코드(Content)가 같다면, 언제 어디서 누가 계산해도 항상 똑같은 식별자가 나옵니다.

SWHID는 바로 이 ‘내재적 식별자’입니다. 중앙 관리 기구 없이도 소프트웨어 아티팩트의 무결성을 수학적으로 보장합니다.

2. SWHID 해부: 어떻게 생겼나요?

SWHID는 단순한 난수가 아닙니다. 체계적인 구조를 가진 문자열입니다. 웨비나에서 소개된 SWHID의 표준 구조를 살펴보겠습니다.

textswh:1:cnt:94a9ed024d3859793618152ea559a168bbcbb5e2

이 식별자는 다음과 같이 3부분으로 나뉩니다.

1. Prefix (swh:1): 이것이 SWHID이며 버전 1이라는 뜻입니다.
2. Object Type: 식별하고 있는 대상의 종류입니다.
   • cnt (Content): 파일 내용 그 자체 (Blob)
   • dir (Directory): 파일과 하위 디렉토리 구조
   • rev (Revision): 특정 시점의 커밋 (작성자, 날짜 정보 포함)
   • rel (Release): 특정 릴리즈 (태그 등)
   • snp (Snapshot): 저장소의 전체 상태 (모든 브랜치와 태그 포함)
3. Hash: 객체의 내용을 암호화(SHA1)하여 생성한 고유한 지문입니다.

Merkle DAG (머클 트리) 구조

SWHID는 파일 하나만 식별하는 게 아닙니다. 파일들이 모여 디렉토리가 되고, 디렉토리가 모여 커밋이 되는 전체 구조를 수학적으로 연결합니다. 파일 하나라도 내용이 1비트만 바뀌면, 상위 디렉토리와 커밋의 SWHID 값도 연쇄적으로 완전히 달라집니다. 이것이 바로 완벽한 무결성(Integrity)입니다.

3. 왜 SWHID가 필수인가요? (Use Cases)

Thomas Aynaud는 SWHID가 단순한 아카이빙 도구를 넘어, 산업계의 핵심 인프라가 되고 있음을 강조했습니다.

1. 소프트웨어 공급망 보안 (Software Supply Chain Security)

SBOM(Software Bill of Materials)이 중요해지면서, “정확히 어떤 코드가 들어갔는가?“를 증명해야 합니다. SWHID를 사용하면 외부 저장소가 해킹당해 코드가 변조되더라도, 해시값이 달라지므로 즉시 탐지할 수 있습니다. EU Cyber Resilience Act (CRA)와 같은 규제 대응에 있어 SWHID는 가장 강력한 무기입니다.

2. 장기 보존 및 추적성 (Long-term Traceability)

오픈소스 프로젝트가 사라져도(폐기되더라도), Software Heritage는 전 세계의 코드를 크롤링하여 보관합니다(현재 260억 개 이상의 소스 파일 보관 중). SWHID만 있다면 원본 저장소가 사라져도 아카이브에서 정확히 그 코드를 찾아낼 수 있습니다. “깨지지 않는 링크"가 생기는 셈입니다

3. 과학적 재현성 (Reproducibility)

연구 논문에서 “GitHub의 X 프로젝트를 사용했다"라고 쓰는 것만으로는 부족합니다. 코드가 업데이트되면 연구 결과를 재현할 수 없기 때문입니다. SWHID를 사용하면 “정확히 이 버전의, 이 파일들을 사용했다"고 명시할 수 있어 연구의 신뢰도를 높일 수 있습니다.

4. ISO 표준화와 거버넌스

2025년 4월, SWHID는 ISO/IEC 18670:2025라는 국제 표준이 되었습니다. 이것이 주는 의미는 큽니다.

• 특정 기업의 소유물이 아닙니다: SWHID는 Software Heritage가 처음 만들었지만, 이제는 국제 표준으로서 전 세계 누구라도 자유롭게 구현하고 사용할 수 있습니다.
• 오픈 거버넌스: 투명한 거버넌스 모델 아래에서 관리되므로, 특정 벤더에 종속(Lock-in)될 위험이 없습니다.

5. 결론: SWHID를 준비하세요

웨비나의 제목인 “You will not be able to live without it"은 과장이 아니었습니다.

소프트웨어가 세상을 먹어치우고 있는 지금, 그 소프트웨어를 ‘정확하게 지칭하고’, ‘변조되지 않았음을 증명하고’, ‘영구적으로 보존하는’ 유일한 방법이 바로 SWHID이기 때문입니다.

더 이상 깨질 수 있는 URL에 의존하지 마세요. 이제는 코드의 지문, SWHID를 사용할 때입니다.

관련 링크

• 웨비나 다시보기: YouTube 링크
• SWHID 공식 스펙: ISO/IEC 18670:2025
• OpenChain Project: https://openchainproject.org

본 포스팅은 2025년 12월 3일 진행된 OpenChain 웨비나 내용을 바탕으로 작성되었습니다.

by Gemini 3.0

7.3 - 2025-11-07 컨테이너와 오픈소스 컴플라이언스: 무엇이 문제이고 어떻게 해결할 것인가?

source: https://openchainproject.org/news/2025/11/07/webinar-containers-and-compliance

2025년 11월 7일, OpenChain Project는 최근 소프트웨어 개발의 핵심인 ‘컨테이너(Container)‘와 ‘컴플라이언스(Compliance)‘를 주제로 심도 깊은 패널 토의를 진행했습니다. 이번 웨비나는 Chris Wood의 진행 하에 Caren Kresse (OSADL), Heather Meeker, Mary Hardy, Till Jaeger 등 최고의 오픈소스 법률 및 기술 전문가들이 모여 열띤 토론을 벌였습니다.

컨테이너 기술은 배포를 혁신적으로 단순화시켰지만, 동시에 라이선스 관리와 컴플라이언스 측면에서는 복잡한 “블랙박스"를 만들어냈습니다. 이번 포스팅에서는 웨비나에서 논의된 핵심 이슈 3가지와 전문가들의 제언을 상세히 정리해 드립니다.

웨비나 개요

• 주제: Containers and Compliance (컨테이너와 컴플라이언스)
• 일시: 2025년 11월 7일
• 패널:
  • Chris Wood (Chair): OpenChain Specification Chair
  • Caren Kresse: OSADL (Open Source Automation Development Lab)
  • Heather Meeker: 오픈소스 법률 전문가
  • Mary Hardy: 오픈소스 컴플라이언스 전문가
  • Till Jaeger: 오픈소스 전문 변호사

핵심 논의 1: 패키지 매니저의 불투명성 (Transparency Issues)

개발자들은 npm, pip, maven 같은 패키지 매니저를 믿고 의존성을 설치합니다. 하지만 전문가들은 이 과정에 심각한 “투명성 부족” 문제가 있다고 지적했습니다.

문제점: “메타데이터는 거짓말을 한다”

패널들은 패키지 매니저가 제공하는 정보가 불완전하거나, 오래되었거나, 심지어 틀린 경우가 많다고 입을 모았습니다.

• Caren Kresse & Heather Meeker: “패키지 매니저의 메타 정보만 믿고 컴플라이언스를 진행하는 것은 위험하다. 실제 소스 코드의 라이선스와 패키지 정보가 불일치하는 경우가 비일비재하다.”
• Till Jaeger: “패키지 매니저는 결국 업스트림 프로젝트가 입력한 정보만 보여줄 뿐이다. 입력 단계에서 오류가 있다면, 패키지 매니저는 잘못된 정보를 그대로 전파하게 된다.”

해결 방향: “ClearlyDefined"와 같은 공용 DB 활용

Mary Hardy는 ClearlyDefined와 같은 공공 데이터베이스의 활용을 제안했습니다. 이는 오픈소스 패키지의 실제 라이선스 정보를 스캔하고 사람이 검증한(Curated) 데이터를 제공하므로, 불확실한 패키지 매니저 정보보다 신뢰할 수 있는 기준점이 될 수 있습니다.

핵심 논의 2: 바이너리 스캐너의 한계 (Binary Scanner Limitations)

컨테이너는 기본적으로 이미 빌드된 ‘바이너리(Binary)’ 형태의 이미지입니다. 소스 코드가 없는 상태에서 바이너리만 보고 라이선스를 판별하는 것은 기술적으로 매우 어렵습니다.

문제점: “겉만 보고 속을 알 수 없다”

• 스캐너의 한계: 현재의 라이선스 스캐너들은 주로 바이너리의 최상위 레벨 라이선스만 식별할 수 있습니다. 바이너리 안에 정적으로 링크된 라이브러리나 복잡한 종속성 구조까지 완벽하게 파헤치지 못합니다.
• Caren Kresse: “바이너리 스캐너가 제대로 작동하려면 해당 바이너리가 ‘어디서 왔고(Origin)’, ‘어떻게 빌드되었는지(Build Info)‘를 역추적할 수 있어야 하는데, 현재 기술로는 이것이 매우 어렵다.”

미래 전망: AI와 고도화된 스캐닝

Heather Meeker와 Mary Hardy는 AI 코딩 도구의 발전이 오히려 스캐닝 기술의 부활을 이끌 수 있다고 전망했습니다. AI가 코드의 출처를 추적하는 기술이 발전함에 따라, 바이너리의 기원을 찾아내는 기술도 함께 고도화될 것이라는 긍정적인 예측이 나왔습니다.

핵심 논의 3: 개발자 인식 개선 (Developer Awareness)

가장 근본적인 문제는 결국 “사람"에 있습니다. 개발자들이 컨테이너를 만들 때 라이선스 정보를 제대로 기입하지 않거나, 베이스 이미지(Base Image)의 법적 리스크를 고려하지 않는 관행이 지적되었습니다.

문제점: “기본값의 함정”

• Marcel (참가자 코멘트): “Maven 같은 도구에서 default로 설정된 라이선스(예: Apache)를 개발자가 의도치 않게 그대로 사용하는 경우가 많다. 실제로는 다른 라이선스를 써야 함에도 설정을 바꾸지 않아 잘못된 정보가 퍼진다.”
• Chris Wood: “호환되지 않는 라이선스들이 컨테이너 하나에 섞여 들어갔을 때, 이를 기술적으로 해결(Remediation)하는 방법이 마땅치 않다.”

해결 방향: 교육과 “신뢰할 수 있는 베이스 이미지”

• Till Jaeger: “모든 개발자가 법률 전문가가 될 순 없다. 대신 ‘검증된 베이스 이미지(Trusted Base Images)‘를 사용하도록 가이드해야 한다.” OSADL과 같은 기관에서 법적 검토가 끝난 베이스 이미지를 제공하고, 개발자들은 그 위에서 애플리케이션만 올리는 방식이 현실적인 대안으로 제시되었습니다.

결론: 컨테이너 컴플라이언스, 앞으로의 과제

이번 웨비나의 결론은 명확했습니다. “자동화 도구(Tooling)만으로는 아직 충분하지 않다"는 것입니다.

1. 소스 코드 확보의 중요성: 바이너리 스캔만으로는 한계가 있으므로, 가능한 한 소스 코드를 확보하여 분석해야 합니다.
2. 업스트림과의 협력: 라이선스 정보가 누락되었을 때는 직접 업스트림 프로젝트에 기여(Contribution)하여 정보를 수정하는 문화가 필요합니다.
3. 프로세스의 표준화: OpenChain(ISO/IEC 5230)과 같은 표준 프로세스를 도입하여, 개발 단계에서부터 올바른 라이선스 정보가 기입되도록 강제하는 체계가 필요합니다.

컨테이너는 편리하지만, 그 편리함 뒤에 숨겨진 ‘법적 부채’를 무시해서는 안 됩니다. 이번 웨비나는 그 부채를 어떻게 관리 가능한 수준으로 만들 것인가에 대한 중요한 이정표를 제시해주었습니다.

🔗 관련 자료

• OpenChain Project: https://openchainproject.org
• OSADL (Open Source Automation Development Lab): https://osadl.org
• ClearlyDefined: https://clearlydefined.io

본 포스팅은 2025년 11월 7일 진행된 OpenChain 웨비나의 요약 및 패널 토의 내용을 바탕으로 재구성되었습니다.

by Gemini 3.0

7.4 - 2025-09-16 EU Cyber Resilience Act (CRA): 오픈소스 개발자가 반드시 알아야 할 생존 가이드

source: https://openchainproject.org/news/2025/09/16/webinar-cra

2025년 9월 16일, OpenChain Project는 유럽 연합(EU)의 새로운 사이버 보안법인 CRA(Cyber Resilience Act)를 주제로 긴급 웨비나를 개최했습니다. 이번 웨비나에서는 Linux Foundation의 오픈소스 공급망 보안 책임자이자 20년 이상의 경력을 가진 보안 전문가 David A. Wheeler가 연사로 나서 CRA의 핵심과 대응 방안을 명쾌하게 풀어냈습니다.

“나는 유럽에 안 사는데?”, “우리 회사는 미국 회사인데?“라고 생각하셨나요? 만약 당신이 만드는 소프트웨어가 유럽 시장에 판매되거나 사용된다면, 이 법은 100% 당신에게 적용됩니다. 심지어 오픈소스 개발자라도 예외가 아닐 수 있습니다.

이번 포스팅에서는 웨비나의 핵심 내용을 A to Z로 상세히 정리해 드립니다.

1. CRA란 무엇인가? (그리고 왜 중요한가?)

이것은 ‘가이드라인’이 아니라 ‘법(Law)‘입니다.

CRA는 단순한 권고 사항이 아닙니다. EU 시장에 출시되는 “디지털 요소가 포함된 모든 제품(Products with Digital Elements, PDE)“에 적용되는 강력한 규제입니다.

• 시행일: 2024년 12월 10일 발효 (이미 법입니다!)
• 본격 적용: 2027년 12월 11일 (완전 적용)
• 벌금: 최대 1,500만 유로(약 220억 원) 또는 전 세계 매출의 2.5% 중 더 큰 금액

전 세계가 영향권입니다

David Wheeler는 강조했습니다. “CRA는 EU 법이지만 사실상 글로벌 법이다.”

소프트웨어 시장은 국경이 없습니다. 당신이 한국이나 미국에서 개발했더라도, 그 결과물이 유럽 시장에 배포된다면 CRA 준수 의무가 발생합니다.

2. 나는 어떤 역할인가? (Manufacturer vs. Steward)

CRA에서 가장 헷갈리면서도 중요한 부분은 “내가 어떤 역할로 정의되는가"입니다. 역할에 따라 의무가 천지 차이이기 때문입니다.

Manufacturer (제조업체)

가장 무거운 책임을 지는 주체입니다.

• 정의: 상업적 활동(Commercial Activity)의 일환으로 제품을 시장에 출시하는 자.
• 핵심 기준: 돈을 받고 파는가? (직접 판매, 유료 지원, 특정 데이터 수집 등)
• 오픈소스라도? 네. 오픈소스 프로젝트라도 상업적 이익(Monetization)을 위해 운영된다면 Manufacturer로 간주됩니다.

Open Source Software Steward (오픈소스 스튜어드)

이번 최종 법안에 새로 추가된 중요한 개념입니다.

• 정의: 상업적 목적 없이 오픈소스 프로젝트의 개발을 지속적으로 지원하는 법인 (예: Linux Foundation, Eclipse Foundation 등).
• 의무: Manufacturer보다는 가볍지만 여전히 중요합니다. 보안 정책 수립, 취약점 관리 및 보고 협력 등의 의무가 있습니다.

순수 오픈소스 개발자/기여자

• 희소식: 단순히 취미로 개발하거나 비영리 목적으로 코드만 기여하는 개인 개발자는 CRA 적용 대상이 아닙니다.
• 주의: 하지만 당신의 코드를 가져다 쓰는 기업(Manufacturer)은 당신에게 “이 코드 안전한가요?“라고 묻기 시작할 것입니다.

3. Manufacturer가 해야 할 일 (To-Do List)

만약 당신이 Manufacturer로 분류된다면, 다음의 의무를 반드시 지켜야 합니다.

1. CE 마크 부착: 제품이 CRA 요구사항을 충족함을 증명하는 마크를 붙여야 판매 가능합니다.
2. 보안 내재화 (Security by Design): 개발 초기부터 보안을 고려해야 합니다. (알려진 악용 가능 취약점이 없어야 함)
3. SBOM(Software Bill of Materials) 제공: 최소한 최상위 의존성(Top-level dependencies) 목록을 포함한 SBOM을 보유해야 합니다.
4. 취약점 보고 (Vulnerability Reporting): 이게 가장 무섭습니다.
   • 24시간 이내: 활발히 악용되는 취약점(Actively Exploited Vulnerability) 인지 시 조기 경보(Early Warning) 제출.
   • 72시간 이내: 상세 보고서 제출.
   • 14일 이내: 조치 완료 후 최종 보고서 제출.
   • David의 코멘트: “24시간은 영업일 기준이 아닙니다. 주말, 공휴일 상관없이 그냥 24시간입니다.”

4. 어떻게 준비해야 하나요? (Action Plan)

David Wheeler는 “지금 당장 준비하지 않으면 나중에 패닉에 빠질 것"이라고 경고하며 3가지 액션 플랜을 제시했습니다.

Step 1: 무료 교육 듣기 (강력 추천)

Linux Foundation과 OpenSSF가 만든 무료 교육 코스가 있습니다. 이 코스를 듣고 수료 배지를 따세요. 팀원들에게도 듣게 하세요.

• 과정명: Understanding the EU Cyber Resilience Act (LFEL1001)
• 비용: 무료
• 링크: https://training.linuxfoundation.org/express-learning/understanding-the-eu-cyber-resilience-act-cra-lfel1001/

Step 2: 보안 교육 이수

개발자들이 보안 코딩을 할 줄 알아야 합니다.

• 추천 과정: Developing Secure Software (LFD121) - 역시 무료입니다.

Step 3: 표준 준수

CRA는 매우 높은 수준의 요구사항만 명시하고, 구체적인 기술적 방법은 “표준(Standards)“을 따르라고 합니다. 현재 CEN/CENELEC이 표준을 만들고 있습니다. 이 표준을 준수하면 법을 준수한 것으로 간주(Presumption of Conformity)되므로, 관련 표준 동향을 예의주시해야 합니다.

결론: 규제를 기회로

CRA는 귀찮은 규제일 수 있지만, 반대로 생각하면 “보안이 검증된 소프트웨어"라는 품질 보증 마크가 될 수 있습니다.

2027년은 멀어 보이지만, 제품 개발 사이클을 고려하면 내일부터 당장 준비해야 합니다. 지금 바로 팀 내에서 “우리는 Manufacturer인가?“라는 질문부터 시작해 보세요.

관련 링크

• 웨비나 다시보기: YouTube 링크
• 무료 CRA 교육 코스: LFEL1001 바로가기
• OpenChain Project: https://openchainproject.org

본 포스팅은 2025년 9월 16일 진행된 OpenChain 웨비나 내용을 바탕으로 재구성되었습니다.

by Gemini 3.0

7.5 - 2025-09-12 컨테이너 컴플라이언스, OSADL Base Image로 해결하세요

source: https://openchainproject.org/news/2025/09/12/osadl-base-image-webinar

2025년 9월 12일, OpenChain Project는 컨테이너 환경에서의 오픈소스 라이선스 준수(Compliance) 문제를 해결하기 위한 실질적인 솔루션을 주제로 웨비나를 개최했습니다. 이번 웨비나에서는 OSADL(Open Source Automation Development Lab)의 Caren Kresse가 연사로 나서, 복잡한 컨테이너 계층 구조 속에서 법적 의무를 손쉽게 준수할 수 있도록 돕는 ‘OSADL Base Image’ 프로젝트를 상세히 소개했습니다.

개발자에게는 배포의 혁명인 ‘컨테이너’가 컴플라이언스 담당자에게는 악몽이 될 수 있다는 사실, 알고 계셨나요? 이번 포스팅에서는 그 이유와 OSADL이 제시하는 명쾌한 해답을 정리해 드립니다.

1. 문제 제기: 컨테이너는 왜 컴플라이언스가 어려울까요?

컨테이너 기술(Docker 등)은 소프트웨어 배포를 단순화시켰지만, 라이선스 관리 측면에서는 새로운 난관을 만들었습니다. Caren Kresse는 크게 두 가지 핵심 문제를 지적했습니다.

복잡한 계층(Layered) 구조

컨테이너는 여러 개의 레이어가 쌓여서 하나의 이미지를 만듭니다. 우리는 보통 FROM ubuntu:latest 처럼 베이스 이미지를 가져다 쓰고, 그 위에 우리만의 애플리케이션을 얹습니다.

• 문제: 내가 작성한 코드(Upper Layer)는 관리할 수 있지만, 가져다 쓴 베이스 이미지(Base Image) 안에 들어있는 수많은 오픈소스 패키지의 라이선스 의무는 누가 책임질까요?

컴플라이언스 자료의 부재

Docker Hub 등에서 쉽게 다운로드할 수 있는 대부분의 베이스 이미지들은 ‘실행’을 위한 바이너리만 제공할 뿐, 라이선스 고지문이나 소스 코드(GPL 의무 등)와 같은 컴플라이언스 자료는 포함하고 있지 않습니다.

• 리스크: 이 상태로 컨테이너를 배포하면, 오픈소스 라이선스 위반으로 법적 분쟁에 휘말릴 수 있습니다.

2. 해결책: OSADL Base Image란?

OSADL은 “모두가 공통으로 쓰는 베이스 이미지라면, 컴플라이언스 작업도 한 번만 해서 공유하면 되지 않을까?“라는 아이디어로 이 프로젝트를 시작했습니다.

OSADL Base Image는 단순한 OS 이미지가 아닙니다. “모든 법적 정보와 컴플라이언스 자료가 이미 완벽하게 포함된” 컨테이너 베이스 이미지입니다.

주요 특징

• 완벽한 법적 정보: 라이선스 텍스트, 저작권 고지, 소스 코드(또는 제공 제안서)가 모두 포함되어 있습니다.
• 검증된 데이터: OSADL의 OSSelot 프로젝트를 통해 전문가가 큐레이션(Curation)한 신뢰도 높은 라이선스 정보를 사용합니다.
• 다양한 배포판 지원: Debian (slim), Ubuntu (minimal), Alpine 등 널리 쓰이는 리눅스 배포판을 지원합니다.

3. 기술적 심층 분석: 어떻게 만들어지나요?

웨비나에서는 OSADL Base Image가 생성되는 4단계 기술적 프로세스가 상세히 공개되었습니다.youtube

1. 최소화된 환경 구축 (Minimal Setup):

   debootstrap(Debian/Ubuntu)이나 apk static(Alpine) 같은 도구를 사용해 꼭 필요한 패키지만 포함된 최소한의 파일 시스템(chroot 환경)을 만듭니다. 불필요한 패키지를 줄여 이미지 크기를 최소화합니다.

2. 라이선스 스캔 및 큐레이션 (Scan & Curation):

   이미지에 포함된 모든 소스 패키지를 다운로드한 뒤, FOSSology와 같은 스캐너를 돌립니다. 이때 OSADL이 관리하는 큐레이션 데이터베이스(OSSelot)를 활용해 스캔 결과의 정확도를 높이고 오탐(False Positive)을 제거합니다.

3. 컴플라이언스 자료 생성 (Compliance Material):

   스캔 결과를 바탕으로 SPDX 리포트, 라이선스 고지문(Legal Notices)을 생성합니다. 사용자가 컨테이너를 실행할 때 법적 정보를 확인할 수 있도록 시작 메시지 등에 포함시킵니다.

4. 이미지 빌드 (Build):

   최종적으로 이 모든 정보가 담긴 파일 시스템을 컨테이너 이미지로 빌드하여 배포합니다.

4. 실무 활용 가이드: 두 가지 버전

OSADL Base Image는 사용자의 상황에 맞춰 두 가지 버전을 제공합니다.

버전 1: 소스 코드 포함형 (Immediate Delivery)

• 특징: 이미지 안에 모든 오픈소스 패키지의 소스 코드가 포함되어 있습니다.
• 장점: 별도의 소스 코드 제공 절차 없이 이미지만 배포하면 GPL 등의 의무를 즉시 만족합니다. 가장 안전하고 편리한 방법입니다.
• 단점: 소스 코드가 들어가므로 이미지 용량이 큽니다.

버전 2: 소스 코드 미포함형 (Delayed Delivery)

• 특징: 소스 코드는 빼고, 실행 바이너리와 ‘소스 코드 제공 제안서(Written Offer)‘만 포함되어 있습니다.
• 장점: 이미지 용량이 훨씬 작습니다.
• 단점: 사용자가 요청할 경우 소스 코드를 별도로 제공해야 하는 번거로움이 있습니다(하지만 OSADL이 해당 소스 패키지를 별도로 제공하므로 대응은 쉽습니다).

5. 결론: “바퀴를 다시 발명하지 마세요”

여러분의 회사가 컨테이너를 배포한다면, 베이스 이미지의 라이선스 분석에 시간을 낭비하지 마세요. 이미 OSADL이 법적으로 검토를 마친 OSADL Base Image를 FROM으로 불러와 사용하면 됩니다. 여러분은 그 위에 얹는 여러분의 애플리케이션에 대한 컴플라이언스만 신경 쓰면 됩니다.

이것이 바로 오픈소스의 정신인 “공유와 협력"을 컴플라이언스 영역에 적용한 모범 사례입니다.

🔗 관련 링크

• 웨비나 다시보기: YouTube 링크
• OSADL 프로젝트 페이지: https://www.osadl.org/base-image
• Docker Hub (다운로드): https://hub.docker.com/r/osadl/

본 포스팅은 2025년 9월 12일 진행된 OpenChain 웨비나 내용을 바탕으로 작성되었습니다.

7.6 - 2024-12-20 DeviceCode - 크라우드소싱 기반 디바이스 데이터 파서

source: https://openchainproject.org/news/2024/12/20/openchain-webinar-devicecode-a-crowdsourced-device-data-parser

목차

1. 발표자 소개
2. 웨비나 소개와 목적
3. DeviceCode 프로젝트 배경
4. DeviceCode의 구현 및 기능
5. 데이터 수집 및 처리 방법
6. 현재의 한계점과 향후 과제
7. 질의응답

1. 발표자 소개

이번 웨비나의 발표자는 Armijn Hemel입니다. 그는 Tjaldur Software Governance Solutions의 소유주로, 오픈소스 라이선스 컴플라이언스 엔지니어링과 출처 연구 분야의 전문 컨설팅 회사를 운영하고 있습니다. Hemel은 오픈소스 라이선스 컴플라이언스 분야에서 오랜 경험을 가지고 있으며, GPL-violations.org 프로젝트와 Binary Analysis Tool 및 Binary Analysis Next Generation 도구 개발에 참여한 바 있습니다.

2. 웨비나 소개와 목적

이번 웨비나는 OpenChain Project의 14번째 웨비나로, 지난 4년간 90회 이상의 웨비나를 진행해왔습니다. 이번 세션에서는 Armijn Hemel이 개발 중인 ‘DeviceCode’라는 프로젝트에 대해 소개합니다. DeviceCode는 다양한 위키에서 크라우드소싱된 디바이스 데이터를 파싱하고 정리하는 도구입니다.

3. DeviceCode 프로젝트 배경

3.1 시장의 현실

전자제품 시장에서 많은 소비자들은 브랜드에 따라 제품의 품질이 다르다고 생각합니다. 하지만 실제로는 여러 브랜드의 제품들이 동일한 ODM(Original Design Manufacturer)에서 생산되거나 같은 칩셋 제조업체의 소프트웨어를 사용하는 경우가 많습니다. 이는 마치 주유소에서 판매하는 휘발유가 실제로는 같은 정제소에서 생산된 것과 비슷한 상황입니다.

3.2 취약점 보고의 문제점

현재 CVE(Common Vulnerabilities and Exposures)는 개별 디바이스에 초점을 맞추고 있어, 동일한 취약점을 가진 다른 제품들이 간과되는 경우가 많습니다. 예를 들어, CVE-2006-2560과 CVE-2006-2561은 서로 다른 벤더의 제품에 대한 동일한 취약점을 설명하고 있지만, 실제로는 같은 ODM에서 생산된 제품일 가능성이 높습니다.

3.3 정보 접근의 어려움

디바이스의 하드웨어 정보, 특히 사용된 ODM이나 칩셋에 대한 정보는 쉽게 접근할 수 없습니다. 기업들은 이러한 정보를 공개하지 않는 경향이 있어, 제품의 실제 내부 구성을 파악하기 어렵습니다.

4. DeviceCode의 구현 및 기능

4.1 데이터 소스

DeviceCode는 다음과 같은 다양한 소스에서 데이터를 수집합니다:

• Tech Info Depot
• OpenWrt Table of Hardware
• FCC 문서

4.2 주요 기능

DeviceCode는 다음과 같은 기능을 제공합니다:

• 위키 데이터 파싱 및 정리
• FCC 문서 분석
• 데이터 통합 및 JSON 형식으로 출력
• 텍스트 기반 UI를 통한 데이터 브라우징
• 브랜드, ODM, 칩셋, 설치된 소프트웨어 등으로 검색 가능

5. 데이터 수집 및 처리 방법

5.1 위키 데이터 처리

Hemel은 위키의 덤프 파일을 다운로드하여 파이썬 스크립트로 처리합니다. 이 과정에서 데이터 정리와 통합 작업이 이루어집니다. 위키 사용자들이 데이터를 일관성 없이 입력하는 경우가 많아 이를 정리하는 작업이 필요합니다.

5.2 FCC 문서 분석

FCC 웹사이트에서 제공하는 문서들을 다운로드하여 분석합니다. 이 문서들에는 사용자 매뉴얼 등이 포함되어 있어, GPL 라이선스 제안 등의 정보를 추출할 수 있습니다.

5.3 데이터 통합

위키 데이터와 FCC 문서에서 얻은 정보를 통합하여 하나의 JSON 파일로 출력합니다. 이 과정에서 서로 다른 소스의 정보를 비교하고 통합하는 작업이 이루어집니다.

6. 현재의 한계점과 향후 과제

6.1 데이터의 완전성

현재 DeviceCode의 데이터는 주로 위키와 FCC 문서에 의존하고 있어 완전하지 않습니다. 향후 더 많은 데이터 소스를 통합하고, 기업들이 자발적으로 정보를 제공할 수 있도록 하는 것이 과제입니다.

6.2 상업화 가능성

Hemel은 현재 이 프로젝트의 상업적 가치에 대해 확신하지 못하고 있습니다. 하지만 inlets foundation의 지원을 받아 개발을 진행 중이며, 향후 더 많은 투자를 유치할 방안을 모색 중입니다.

6.3 통합 및 확장

DeviceCode는 AboutCode 프로젝트의 일부로 통합될 예정입니다. 이를 통해 ScanCode, VulnerableCode 등 다른 오픈소스 도구들과의 연계가 가능해질 것으로 기대됩니다.

7. 질의응답

Q: 위키에 정보를 입력하는 사람들의 동기는 무엇인가요? A: 일부 사람들은 데이터 수집에 대한 강박적인 취미를 가지고 있습니다. 또한 자신의 디바이스 내부를 알고 싶어 하거나, 대체 펌웨어를 만들고자 하는 사람들도 있습니다.

Q: 이 데이터를 상업적으로 활용할 수 있는 방안이 있나요? A: 현재로서는 상업적 가치에 대해 확신하지 못하고 있습니다. 하지만 수리 업체들이 이러한 정보에 관심을 가질 수 있을 것 같습니다.

Q: JSON 형식의 데이터 구조는 문서화되어 있나요? A: GitHub 저장소에 문서화가 되어 있어 쉽게 통합할 수 있을 것입니다. 또한 데이터셋도 제공하고 있어 바로 사용해볼 수 있습니다.

요약 보고서

기업의 오픈소스 관리 담당자에게 주는 의미

1. 공급망 투명성 향상: DeviceCode는 기업이 사용하는 디바이스의 실제 구성 요소와 소프트웨어를 더 잘 이해할 수 있게 해줍니다. 이는 SBOM(Software Bill of Materials) 관리에 도움이 될 수 있습니다.

2. 취약점 관리 개선: 특정 디바이스의 취약점이 발견되었을 때, 유사한 다른 디바이스들도 같은 취약점을 가지고 있을 가능성을 쉽게 파악할 수 있습니다. 이는 보안 관리를 더욱 효과적으로 만들어줍니다.

3. 규제 준수 지원: EU의 CRA(Cyber Resilience Act)나 제품 책임 지침 등의 규제 준수를 위한 기초 자료로 활용될 수 있습니다.

4. 비용 절감: 동일한 하드웨어나 소프트웨어를 사용하는 디바이스들을 파악함으로써, 중복 투자를 줄이고 효율적인 관리가 가능해집니다.

고려해야 할 Action Item

1. DeviceCode 프로젝트 모니터링: 이 프로젝트의 발전 상황을 지속적으로 모니터링하고, 기업에 적용 가능한 시점을 파악합니다.

2. 데이터 기여 검토: 기업이 보유한 디바이스 정보를 DeviceCode 프로젝트에 기여할 수 있는지 검토합니다. 이는 전체 생태계의 발전에 도움이 될 수 있습니다.

3. 내부 디바이스 인벤토리 구축: DeviceCode의 접근 방식을 참고하여, 기업 내부에서 사용 중인 디바이스들의 상세 정보를 체계적으로 관리하는 시스템을 구축합니다.

4. 보안 팀과의 협력: DeviceCode에서 제공하는 정보를 활용하여, 보안 팀과 협력하여 잠재적 취약점을 사전에 파악하고 대응 방안을 마련합니다.

5. 공급업체 관리 강화: DeviceCode를 통해 얻은 정보를 바탕으로, 공급업체들에게 더 상세한 디바이스 정보를 요구하고, 이를 계약 조건에 반영하는 것을 고려합니다.

6. 오픈소스 컴플라이언스 프로세스 개선: DeviceCode가 제공하는 정보를 활용하여, 사용 중인 디바이스들의 오픈소스 소프트웨어 현황을 더 정확히 파악하고, 이에 따른 컴플라이언스 프로세스를 개선합니다.

7. 정책 입안자들과의 소통: DeviceCode와 같은 프로젝트의 중요성을 정책 입안자들에게 알리고, 디바이스 정보의 투명성을 높이기 위한 정책적 지원을 요청합니다.

7.7 - 2024-12-16 ISO 표준화의 여정 – OpenChain 사례를 통해 배우는 표준 개발

source: https://openchainproject.org/news/2024/12/16/2024-recap-creating-standards-from-writing-a-spec-to-obtaining-iso-status-open-source-summit-europe-full-recording

목차

1. 발표자 소개
2. 웨비나 소개와 목적
3. OpenChain 프로젝트란?
4. ISO/IEC 5230:2020 표준화 과정
5. 표준 개발의 핵심 원칙
6. 청중 질의응답
7. 결론 및 주요 시사점

1. 발표자 소개

이 웨비나의 발표자는 Shane Coughlan으로, OpenChain 프로젝트의 총괄 매니저이자 오픈소스 및 표준화 분야에서 오랜 경력을 가진 전문가입니다. 그는 Free Software Foundation Europe의 법률 네트워크 창립자였으며, 오픈소스 라이선스 준수 및 지적재산권 관리에 깊은 전문성을 보유하고 있습니다. 또한, OpenChain 프로젝트를 통해 오픈소스 공급망 신뢰성을 높이는 데 기여하며 ISO/IEC 5230:2020 표준화를 성공적으로 이끌었습니다.

2. 웨비나 소개와 목적

이번 웨비나는 “Creating Standards – From Writing a Spec to Obtaining ISO Status"라는 주제로 진행되었습니다. OpenChain ISO/IEC 5230:2020을 사례로 삼아, 빈 페이지에서 시작해 국제 표준으로 자리 잡기까지의 과정을 상세히 다룹니다. 특히, 다음과 같은 질문에 답을 제시합니다:

• 표준 개발은 어떤 단계로 이루어지는가?
• ISO 표준화가 필요한 이유는 무엇인가?
• 성공적인 표준화를 위해 어떤 실질적인 결정을 내려야 하는가?

참석자들은 이 웨비나를 통해 자신만의 표준을 정의하고, 구축하며, 배포하는 방법을 배우게 됩니다.

3. OpenChain 프로젝트란?

OpenChain 프로젝트는 오픈소스 공급망에서 신뢰를 구축하기 위한 프로세스 관리 표준을 개발하는 글로벌 커뮤니티입니다. 이 프로젝트는 다음과 같은 문제를 해결하기 위해 시작되었습니다:

• 복잡한 공급망: 다단계 공급망에서 라이선스 준수 정보를 신뢰하기 어려운 문제.
• 오픈소스 지적재산권(IP) 관리: 제3자 IP가 포함된 오픈소스를 효과적으로 관리하는 방법.

OpenChain은 이러한 문제를 해결하기 위해 간단하고 명확한 프로세스를 제시합니다:

• Inbound, Internal, Outbound 프로세스: 교육, 정책 수립, 책임자 지정 등 기본적인 요구사항을 명확히 정의.
• ISO/IEC 5230: 오픈소스 라이선스 준수를 위한 국제 표준으로 자리 잡음.

4. ISO/IEC 5230:2020 표준화 과정

OpenChain 프로젝트가 ISO 표준으로 발전한 과정은 다음과 같습니다:

4.1 초기 단계 – 커뮤니티 형성

2015년 Qualcomm 등 주요 기업들이 모여 공급망 내 공통 문제를 논의하며 시작되었습니다. 초기 목표는 기업들이 이미 보유한 경험과 지식을 바탕으로 간단하면서도 효과적인 프로세스를 정의하는 것이었습니다.

4.2 사양 초안 작성

Wind River의 Mark Gisi가 초안 작성 책임자로 나서며 핵심 프로세스를 정리했습니다. 여러 기업이 제공한 교육 자료와 정책 템플릿을 분석하고 이를 최소 요구사항으로 압축하여 첫 번째 사양 초안을 완성했습니다.

4.3 시장 피드백 반영

2016년 첫 사양이 공개된 이후, 시장 피드백을 수집하며 지속적으로 개선했습니다. 이를 통해 언어적 명확성과 범위 조정을 거쳐 더욱 실용적인 문서로 발전시켰습니다.

4.4 JTC-1 PAS Transposition Process 참여

Joint Development Foundation(JDF)의 지원을 받아 JTC-1 PAS Transposition Process를 통해 ISO 표준화를 추진했습니다. 이 과정에서 사양 포맷 조정, 제출 절차 이해 등 JDF와 협력하며 순조롭게 진행되었습니다.

4.5 ISO 인증 획득

2020년 OpenChain 사양은 ISO/IEC 5230으로 공식 인증받았습니다. 이는 오픈소스 라이선스 준수를 위한 최초의 국제 표준으로, 현재 다양한 산업에서 채택되고 있습니다.

5. 표준 개발의 핵심 원칙

Shane Coughlan은 성공적인 표준 개발을 위해 다음과 같은 원칙을 강조했습니다:

5.1 명확한 목표 설정

표준은 특정 문제를 해결하기 위한 도구여야 하며, 범위를 좁게 설정해야 합니다(OpenChain은 “What"에만 집중).

5.2 커뮤니티 중심 접근

사용자 커뮤니티가 직접 참여하여 사양을 개발하고 개선하도록 유도해야 합니다.

5.3 기존 이해관계자와 협력

기존 표준화 기구(BSI, DIN 등)와 협력하여 중복이나 충돌을 방지하고 상호 보완적인 관계를 구축해야 합니다.

5.4 실질적 피드백 반영

시장 요구사항에 따라 지속적으로 사양을 업데이트하고 개선해야 합니다.

6. 청중 질의응답

웨비나 말미에는 청중들의 질문이 이어졌습니다:

Q1: 기존 산업 표준과 충돌하지 않으면서 새로운 표준을 만드는 방법은?
A1: 기존 이해관계자와 협력하여 중복이나 충돌 가능성을 최소화해야 합니다. 예를 들어 OpenChain은 SC27(정보 기술 보안)과 협력하여 기존 작업과 겹치지 않도록 조율했습니다.

Q2: 에너지 산업처럼 보수적인 분야에서 혁신적 접근법을 도입하려면?
A2: 기존 이해관계자와 대화하며 신뢰를 구축하고, 새로운 아이디어를 점진적으로 도입해야 합니다. 또한, 초기에는 참고 구현(reference implementation)을 통해 실질적 효과를 입증하는 것이 중요합니다.

7. 결론 및 주요 시사점

OpenChain 프로젝트는 오픈소스 커뮤니티와 전통적인 표준화 기구 간 협력을 통해 성공적으로 ISO 표준화를 달성했습니다. 이 사례는 다음과 같은 교훈을 제공합니다:

• 모든 아이디어가 반드시 “표준"이 될 필요는 없습니다.
• 명확한 목표와 제한된 범위 설정이 필수입니다.
• 커뮤니티 중심 접근법과 투명한 프로세스가 신뢰 구축에 중요합니다.
• 기존 이해관계자와의 협력이 성공적인 결과를 보장합니다.

오픈소스 관리 담당자는 이러한 원칙을 바탕으로 자신만의 조직적 요구사항에 맞는 프로세스를 설계하고 실행할 수 있습니다.

요약 보고서

기업 오픈소스 관리 담당자에게 주는 의미

ISO/IEC 5230은 복잡한 공급망 내에서 오픈소스 라이선스 준수를 간소화하고 신뢰성을 높이는 데 중요한 도구입니다. 이를 통해 기업은 다음과 같은 이점을 얻을 수 있습니다:

• 공급망 전반에 걸친 공통 언어 제공.
• 지적재산권(IP) 관련 리스크 감소.
• 글로벌 시장에서 신뢰받는 파트너로 자리매김.

고려해야 할 Action Items

1. ISO/IEC 5230 채택 검토: 조직 내 라이선스 준수 프로그램이 국제 기준에 부합하는지 평가.
2. 커뮤니티 참여: OpenChain 워크그룹에 참여하여 최신 동향 파악 및 네트워크 강화.
3. 교육 및 훈련 강화: 내부 팀이 사양 요구사항을 이해하고 실행할 수 있도록 교육 프로그램 마련.
4. 공급망 협력 강화: 파트너사들과 공통 프로세스를 공유하여 전체 공급망 신뢰성 향상.
5. 새로운 도전 과제 탐색: AI 또는 SBOM(Software Bill of Materials) 등 emerging 분야에서 추가 가이드라인 필요 여부 검토.

이를 통해 기업은 더욱 체계적이고 효율적인 오픈소스 관리 체계를 구축할 수 있을 것입니다!

7.8 - 2024-12-13 ISO 5230과 ISO 18974가 법률 전문가에게 미치는 영향과 2024년 전망

source: https://openchainproject.org/news/2024/12/04/webinar-enabling-sboms-across-the-linux-foundation

목차

1. 발표자 소개
2. 웨비나 소개와 목적
3. ISO 5230과 ISO 18974의 주요 내용
4. 법률 전문가에게 미치는 영향
5. 청중과의 질의응답
6. 앞으로의 전망

1. 발표자 소개

이번 웨비나의 발표자는 OpenChain 프로젝트의 주요 멤버로, 오픈소스 라이선스 준수 및 보안 표준화에 깊은 전문성을 가진 전문가입니다. 그는 ISO/IEC 5230:2020 및 ISO/IEC 18974:2023 표준 개발 과정에 직접 참여했으며, 관련 법률 및 산업적 적용에 대한 풍부한 경험을 보유하고 있습니다.

2. 웨비나 소개와 목적

이 웨비나는 ISO/IEC 5230(오픈소스 라이선스 준수)와 ISO/IEC 18974(오픈소스 보안 보증)가 법률 전문가들에게 미칠 영향을 중심으로 진행되었습니다. 특히, 2024년을 기준으로 이 표준들이 기업의 조달 협상, 인수합병(M&A), 공급망 관리에 어떤 변화를 가져올지에 대해 다루었습니다.

또한, 최근 CRA(Cyber Resilience Act)와 SPDX ISO/IEC 5962와 같은 인접 표준의 발전이 이들 표준에 어떤 영향을 미칠지 설명하며, 기존 자료와 커뮤니티 지원, 상업적 제공자들의 도움을 활용하는 방법도 제시했습니다. 마지막으로 AI 컴플라이언스(OpenChain Study Group)와 같은 새로운 연구 그룹의 등장도 논의되었습니다.

3. ISO 5230과 ISO 18974의 주요 내용

ISO/IEC 5230:2020

ISO/IEC 5230은 오픈소스 소프트웨어 사용 시 라이선스 준수를 위한 국제 표준입니다. 이 표준은 기업이 오픈소스를 사용할 때 발생할 수 있는 법적 리스크를 줄이고, 체계적인 관리 시스템을 구축하도록 돕습니다. 특히, 조달 프로세스에서 명확한 라이선스 조건을 확인하고 준수하는 데 중요한 역할을 합니다.

ISO/IEC 18974:2023

ISO/IEC 18974는 오픈소스 소프트웨어의 보안 보증을 다룬 새로운 국제 표준입니다. 이 표준은 공급망 전반에서 오픈소스 소프트웨어의 보안 상태를 평가하고 관리하는 데 초점을 맞추고 있습니다. 특히, 최근 증가하는 사이버 공격 위협 속에서 기업이 안전한 소프트웨어를 제공받고 유지할 수 있도록 돕습니다.

4. 법률 전문가에게 미치는 영향

이 두 표준은 법률 전문가들에게 여러 가지 중요한 영향을 미칩니다:

• 조달 협상: 계약 단계에서 명확한 라이선스 조건과 보안 요건을 요구하는 것이 필수적입니다.
• 인수합병(M&A): 딜 과정에서 대상 기업의 오픈소스 관리 상태를 평가하는 것이 중요해졌습니다.
• 공급망 관리: 공급업체가 ISO 표준을 준수하고 있는지 확인해야 하며, 이를 통해 전체 공급망의 신뢰성을 강화할 수 있습니다.

CRA와 같은 규제 변화는 이러한 표준 준수를 더욱 중요하게 만들고 있으며, SPDX와 같은 다른 표준들과 함께 적용될 가능성이 높습니다.

5. 청중과의 질의응답

웨비나 중 청중들은 다음과 같은 질문을 했습니다:

1. ISO 인증 프로세스는 얼마나 복잡한가요?

   • 발표자는 인증 프로세스가 체계적으로 설계되어 있으며, OpenChain 커뮤니티와 같은 지원 네트워크를 활용하면 쉽게 접근할 수 있다고 설명했습니다.

2. AI 관련 연구 그룹은 어떤 역할을 하나요?

   • AI 컴플라이언스 연구 그룹은 AI 기술이 오픈소스 소프트웨어 및 라이선스를 준수하는 방식에 대해 연구하며, 향후 새로운 가이드라인을 제시할 예정입니다.

6. 앞으로의 전망

발표자는 ISO/IEC 5230과 ISO/IEC 18974가 점차 더 많은 기업에서 필수적인 기준으로 자리 잡을 것이라고 전망했습니다. 특히, AI 기술 및 자동화 도구가 이러한 표준 준수를 지원하면서 더 많은 기업들이 이를 채택할 것으로 예상됩니다.

또한, OpenChain 프로젝트는 지속적으로 새로운 참고 자료와 가이드를 제공하며, 기업들이 변화하는 규제 환경에 적응하도록 도울 것입니다.

요약 보고서

기업 오픈소스 관리 담당자를 위한 주요 의미

ISO/IEC 5230과 ISO/IEC 18974는 오픈소스를 사용하는 모든 기업에게 필수적인 가이드라인을 제공합니다. 이를 통해 법적 리스크를 줄이고, 보안 수준을 강화하며, 공급망 전체에서 투명성과 신뢰성을 확보할 수 있습니다.

고려해야 할 Action Item

• 표준 준수 시스템 구축: 내부적으로 ISO 인증 절차를 검토하고 필요한 시스템을 도입하세요.
• 교육 및 훈련: 직원들에게 관련 표준과 규정에 대한 교육을 제공하세요.
• 공급망 점검: 공급업체들이 해당 표준을 준수하고 있는지 확인하세요.
• AI 컴플라이언스 준비: AI 기술이 적용된 소프트웨어에서도 이러한 표준이 어떻게 적용될지 연구하세요.

이를 통해 변화하는 규제 환경에 효과적으로 대응하고 경쟁력을 유지할 수 있을 것입니다.

7.9 - 2024-12-12 CHAOSS Practitioner Guides를 활용한 건강하고 지속 가능한 OSS 프로젝트 구축

source: https://openchainproject.org/news/2024/12/12/webinar-chaoss-practitioner-guides

목차

1. 발표자 소개
2. 웨비나 소개와 목적
3. CHAOSS 프로젝트 개요
4. Practitioner Guide 주요 내용
   • Responsiveness (응답성)
   • Contributor Sustainability (기여자 지속 가능성)
   • Organizational Participation (조직 참여)
   • Security (보안)
5. 청중 질문과 답변
6. 결론 및 주요 시사점

1. 발표자 소개

이번 웨비나의 발표자는 Dawn Foster로, 오픈소스 커뮤니티와 데이터 과학 분야에서 오랜 경력을 쌓아온 전문가입니다. Dawn은 CHAOSS 프로젝트의 데이터 과학 리더이자 이사회 멤버로 활동 중이며, CNCF Contributor Strategy Technical Advisory Group의 공동 의장 및 OpenUK 이사로도 활약하고 있습니다. 그녀는 오픈소스 프로젝트의 건강성과 지속 가능성을 개선하기 위해 데이터 기반 접근 방식을 제안하며, CHAOSS 프로젝트 내 다양한 활동을 이끌고 있습니다.

2. 웨비나 소개와 목적

이번 웨비나는 CHAOSS 프로젝트가 개발한 Practitioner Guides를 중심으로 진행되었습니다. 이 가이드는 오픈소스 소프트웨어(OSS) 프로젝트와 커뮤니티의 지속 가능성을 개선하기 위해 설계된 자료로, MIT 라이선스로 제공됩니다. 특히, 데이터 분석 경험이 많지 않은 사람들도 커뮤니티 메트릭을 활용해 의미 있는 통찰을 얻고 실행 가능한 개선 방안을 도출할 수 있도록 돕는 것을 목표로 합니다.

웨비나에서는 다음과 같은 핵심 주제를 다뤘습니다:

• 커뮤니티 메트릭의 해석과 활용법.
• 메트릭을 통해 식별된 문제 영역에서 개선할 수 있는 구체적인 아이디어.
• OSS 프로젝트 및 커뮤니티의 장기적 지속 가능성을 위한 전략.

3. CHAOSS 프로젝트 개요

CHAOSS는 Community Health Analytics for Open Source Software의 약자로, 오픈소스 소프트웨어 커뮤니티의 건강성을 측정하고 개선하기 위한 메트릭과 도구를 개발하는 Linux Foundation 산하 프로젝트입니다.

주요 특징:

• 글로벌 참여: 전 세계 다양한 지역에서 기여자가 활동.
• 다양한 작업 그룹: 데이터 과학, DEI(Diversity, Equity, Inclusion), OSPO(Open Source Program Office) 등 여러 주제에 초점.
• 소프트웨어 도구 제공: Augur와 GrimoireLab이라는 두 가지 주요 메트릭 수집 및 분석 도구를 운영.
• Practitioner Guides 시리즈: 특정 주제에 대한 메트릭 활용 가이드 제공.

CHAOSS는 단순히 코드 기여만이 아니라 문서화, 커뮤니티 관리 등 다양한 기여 형태를 중요하게 생각하며, 이를 통해 OSS 프로젝트의 건강성과 지속 가능성을 강화하려고 합니다.

4. Practitioner Guide 주요 내용

4.1 Responsiveness (응답성)

응답성은 OSS 프로젝트가 기여자들의 요청(예: Pull Request)에 얼마나 신속하게 대응하는지를 측정합니다.

중요성:

• 신속한 응답은 기여자 유지율을 높이고 커뮤니티 성장을 촉진합니다.
• 지연된 응답은 기술 부채를 증가시키고 기여자들의 참여 의욕을 저하시킬 수 있습니다.

개선 방안:

1. 기대치 설정: 기여자들에게 응답 시간을 명확히 알리기.
2. 리더십 확대: 신뢰할 수 있는 기여자를 유지관리자로 승격.
3. 템플릿 개선: 고품질 요청을 쉽게 제출할 수 있도록 Issue 및 Pull Request 템플릿 최적화.

4.2 Contributor Sustainability (기여자 지속 가능성)

기여자 지속 가능성은 프로젝트가 장기적으로 충분한 기여자를 확보하고 유지할 수 있는 능력을 측정합니다.

중요성:

• 단일 유지관리자 중심의 프로젝트는 실패 위험이 높습니다.
• 다양한 형태의 기여(문서화, 커뮤니티 관리 등)를 장려해야 합니다.

개선 방안:

1. 장벽 제거: 신규 기여자가 쉽게 참여할 수 있도록 온보딩 문서 개선.
2. 역할 확장: 기존 유지관리자의 시간을 절약하기 위해 문서화 및 마케팅 전문가 영입.
3. 기여 독려: 기존 기여자를 인정하고 추가적인 역할을 맡도록 격려.

4.3 Organizational Participation (조직 참여)

조직별 참여 데이터를 분석해 특정 회사에 지나치게 의존하지 않도록 하는 것이 중요합니다.

중요성:

• 단일 조직 의존은 전략 변화나 자금 문제 발생 시 프로젝트 지속 가능성을 위협합니다.

개선 방안:

1. 투명성 강화: 모든 작업을 공개적으로 진행해 외부 조직도 쉽게 참여할 수 있도록 유도.
2. 다양성 확보: 다른 조직에서 더 많은 기여를 유도하기 위해 연락 및 협업 강화.

4.4 Security (보안)

보안은 OSS 프로젝트의 지속 가능성과 신뢰도를 결정짓는 중요한 요소입니다.

중요성:

• 보안 취약점 패치 지연은 사용자 신뢰를 저하시킵니다.
• 정기적인 릴리스와 의존성 업데이트는 필수적입니다.

개선 방안:

1. 보안 정책 문서화: security.md 파일에 취약점 보고 절차 명시.
2. 자동화 도구 사용: Dependabot 또는 Renovate Bot으로 의존성 업데이트 관리.
3. 릴리스 프로세스 최적화: 보안 패치를 신속히 릴리스에 반영.

5. 청중 질문과 답변

질문 1: 어떤 시점에서 메트릭을 고려해야 할까요?

초기에는 메트릭보다 기본적인 인프라 구축(예: 컨트리뷰팅 가이드 작성)에 집중하는 것이 좋습니다. 다만, 데이터를 꾸준히 수집해 3~6개월 후부터 트렌드를 분석하는 것이 효과적입니다.

질문 2: 메트릭 측정을 위한 도구는 무엇이 있나요?

CHAOSS의 Augur와 GrimoireLab 외에도 GitHub Insights, OpenSauced 등 다양한 도구가 있습니다. 간단한 분석에는 GitHub API를 활용하는 것도 추천됩니다.

6. 결론 및 주요 시사점

CHAOSS Practitioner Guides는 OSS 프로젝트와 커뮤니티가 직면한 다양한 문제를 해결하기 위한 실질적인 지침을 제공합니다.

기업 담당자를 위한 시사점:

• 메트릭을 통해 OSS 프로젝트의 건강성과 리스크를 사전에 파악할 수 있습니다.
• 중요한 OSS 프로젝트에 적극적으로 기여함으로써 장기적인 안정성과 신뢰도를 확보해야 합니다.

Action Items:

1. 주요 OSS 프로젝트에 대한 메트릭 분석 시작.
2. 조직 내 개발자가 OSS에 기여할 시간을 할당.
3. CHAOSS Practitioner Guides를 참고해 맞춤형 전략 수립.

CHAOSS는 단순히 데이터를 제공하는 것을 넘어, 이를 통해 실질적인 변화를 이끌어내는 데 초점을 맞추고 있습니다. 기업과 개인 모두 이러한 접근법을 활용해 OSS 생태계를 더욱 건강하고 지속 가능하게 만들 수 있을 것입니다!

7.10 - 2024-12-05 리눅스 재단에서 SBOM을 활성화하는 과정

source: https://openchainproject.org/news/2024/12/04/webinar-enabling-sboms-across-the-linux-foundation

목차

1. 발표자 소개
2. 웨비나 소개와 목적
3. SBOM의 개념과 중요성
4. 리눅스 재단의 SBOM 생성 과정
5. 주요 도구와 프로세스
6. SBOM 통합과 향후 계획
7. 청중 질의응답

1. 발표자 소개

Gary O’Neall

Gary O’Neall은 SPDX 표준에 기여한 전문가로, 오픈소스 소프트웨어의 구성요소, 라이선스, 저작권, 보안 참조 정보를 전달하는 데 중점을 둔 표준을 개발해왔습니다. 그는 Source Auditor Inc.에서 제품 개발 및 기술을 담당하며, 오픈소스 소프트웨어의 기술적 및 법적 위험 관리를 돕는 도구를 개발하고 있습니다.

Jeff Shapiro

Jeff Shapiro는 리눅스 재단의 라이선스 스캐닝 디렉터로, 30년 이상의 소프트웨어 산업 경험을 보유하고 있습니다. 그는 오픈소스 스캐닝 및 OSS(오픈소스 소프트웨어) 라이선스 준수 교육에 전문성을 가지고 있으며, 현재 리눅스 재단에서 중요한 프로젝트들의 코드 관리와 SBOM 생성에 기여하고 있습니다.

2. 웨비나 소개와 목적

이번 웨비나는 리눅스 재단(Linux Foundation)에서 **SBOM(Software Bill of Materials)**을 활성화하는 과정을 설명하고, 이를 통해 오픈소스 프로젝트의 라이선스 준수 및 보안 관리 방안을 제시하는 것을 목표로 합니다.

리눅스 재단은 기존의 소스 코드 레벨 라이선스 스캐닝 경험을 바탕으로 SBOM을 생성하며, 정부 규제 기준(CISA NTIA Minimum Specification)을 충족하거나 초과하는 SBOM을 제공하고자 합니다.
SBOM은 소프트웨어 구성요소와 의존성을 추적하여 보안 취약점과 라이선스를 관리하는 데 필수적인 도구로, 이번 웨비나는 다음과 같은 내용을 다룹니다:

• SBOM 생성 과정과 사용 도구
• 직면한 도전 과제와 해결 방안
• 향후 계획 및 커뮤니티 참여 방법

3. SBOM의 개념과 중요성

SBOM은 소프트웨어 구성요소를 추적하여 보안 취약점과 라이선스 준수를 관리하는 데 사용됩니다. 이는 소프트웨어의 “재료 목록"으로 비유되며, 다음과 같은 특징을 가집니다:

• 구성요소와 관계를 명확히 식별: 각 구성요소 간의 관계를 명확히 정의.
• 기계 판독 가능: 표준 형식(SPDX 등)을 사용하여 자동화 가능.
• 보안 및 라이선스 관리: 다운스트림 사용자에게 구성요소 정보 제공.

리눅스 재단은 1,000개 이상의 프로젝트를 호스팅하며, 이들 프로젝트가 중요한 인프라를 지원하기 때문에 SBOM은 특히 중요합니다.

4. 리눅스 재단의 SBOM 생성 과정

리눅스 재단은 개발 단계에서 “Source-level SBOM"을 생성합니다. 이는 빌드 단계에서 생성되는 “Build-level SBOM"과는 차이가 있지만, 다음과 같은 장점이 있습니다:

• 소스 코드와 메타데이터를 기반으로 구성요소 정보를 수집.
• 의존성 분석을 통해 라이선스 정보와 보안 취약점 데이터를 통합.

리눅스 재단은 Trivy, Scaffold, Parlay 등의 오픈소스 도구를 활용하여 자동화된 SBOM 생성을 진행하며, 이를 통해 정부 규제 기준을 충족하는 결과물을 제공합니다.

5. 주요 도구와 프로세스

주요 도구

1. Trivy: 의존성 분석 및 SPDX 파일 생성.
2. Scaffold: 스캔 작업 자동화 및 메타데이터 통합.
3. Parlay: 외부 메타데이터 추가(예: 보안 정보).
4. SPDX Tools: 최종 검증 및 표준 준수 확인.

프로세스 단계

1. 생성(Generation): Trivy로 초기 SPDX 파일 생성.
2. 증강(Augmentation): Scaffold로 프로젝트 메타데이터 추가.
3. 강화(Enrichment): Parlay로 외부 데이터 추가.
4. 검증(Validation): SPDX Tools로 표준 준수 확인.

6. SBOM 통합과 향후 계획

리눅스 재단은 현재 소스 코드와 의존성 데이터를 통합하여 “Unified SBOM"을 개발 중입니다. 이는 다음 단계를 포함합니다:

• 파일 수준 정보 추가: 파일 체크섬, 선언/결론된 라이선스, 저작권 텍스트 등.
• SPDX 3.x 지원: 최신 표준 적용.
• LFX 플랫폼 통합: GitHub 외에도 LFX 플랫폼에서 SBOM 제공.

향후 모든 리눅스 재단 프로젝트에 대해 자동화된 SBOM 생성을 목표로 하고 있습니다.

7. 청중 질의응답

주요 질문과 답변

1. LF Minimum SBOM Spec에 기여하려면?

   • GitHub 이슈 또는 PR 제출 가능.
   • 직접 이메일로 의견 전달도 환영.

2. SPDX 3.x 전환 계획?

   • 현재 SPDX 2.3 사용 중이며, 도구가 업데이트되면 즉시 전환 예정.

3. 도구 체인을 SDLC에 어떻게 매핑하나요?

   • 리눅스 재단의 도구 체인은 개발 단계에서 정적 분석을 수행하며, 빌드 단계 이전에 라이선스 및 보안 상태를 사전 점검하는 역할을 합니다.

요약 보고서

기업 오픈소스 관리 담당자에게 주는 의미

1. 라이선스 준수 강화: SBOM은 오픈소스를 사용하는 기업이 법적 위험을 줄이고 규정을 준수하도록 돕습니다.
2. 보안 취약점 관리: 의존성 정보를 통해 잠재적 보안 위협을 사전에 식별 가능.
3. 정부 규제 대응: CISA NTIA Minimum Specification 등 글로벌 규제를 충족할 수 있는 기반 마련.

고려해야 할 Action Items

1. SBOM 도입 계획 수립:

   • 내부 소프트웨어 개발 프로세스를 분석하고 적절한 도구 선택.
   • Trivy, Scaffold 등 오픈소스를 활용한 초기 테스트 권장.

2. 빌드 단계 통합 검토:

   • Build-level SBOM 생성을 위한 CI/CD 시스템 연계 방안 마련.

3. 커뮤니티 참여:

   • LF Minimum Spec 개선 작업에 기여하거나 관련 논의를 적극적으로 모니터링.

4. 규제 변화 모니터링:

   • 미국 CISA 외에도 EU 및 일본 등 글로벌 규제를 지속적으로 추적하여 대응 전략 수립.

SBOM은 단순한 기술 트렌드를 넘어 기업의 법적/보안적 안정성을 강화하는 핵심 요소로 자리잡고 있습니다.

7.11 - 2024-12-04 OpenChain ISO 표준이 InnerSource를 지원하는 방법 이해하기

source: https://openchainproject.org/news/2024/12/04/full-recording-understanding-how-openchain-iso-iec-5230-and-iso-iec-18974-support-innersource-innersource-commons-summit-2024

목차

1. 발표자 소개
2. 웨비나 소개와 목적
3. OpenChain ISO/IEC 5230 및 ISO/IEC 18974의 개요
4. InnerSource와의 연관성
5. ISO 표준의 실제 적용 사례
6. 커뮤니티와 지원 자료
7. 결론 및 제안

1. 발표자 소개

Shane Coughlan은 OpenChain Project의 General Manager로, 오픈소스 표준화와 관련된 글로벌 리더십을 제공하고 있습니다. 그는 오픈소스 생태계에서의 라이선스 준수 및 보안 보증을 위한 국제 표준 개발에 주력하며, InnerSource와 같은 새로운 소프트웨어 개발 방식에도 이를 적용하는 방법을 모색하고 있습니다.

2. 웨비나 소개와 목적

이번 웨비나는 InnerSource Commons Summit 2024에서 진행된 세션으로, OpenChain ISO/IEC 5230(오픈소스 라이선스 준수 국제 표준)와 ISO/IEC 18974(오픈소스 보안 보증 국제 표준)가 InnerSource 프로그램에 어떻게 기여할 수 있는지를 다룹니다.

InnerSource는 내부 협업과 코드 공유를 통해 혁신을 촉진하는 소프트웨어 개발 접근법입니다. 본 발표는 내부 공급망 관리에서 ISO 표준을 활용해 효율성을 높이고, 외부 공급망과의 일관성을 유지하며, 프로세스 불일치로 인한 문제를 최소화하는 방법을 제시합니다.

3. OpenChain ISO/IEC 5230 및 ISO/IEC 18974의 개요

OpenChain ISO/IEC 5230

• 목적: 오픈소스 라이선스 준수를 위한 프로세스 관리 표준 제공.
• 특징: 조직 규모에 관계없이 유연하게 적용 가능하며, 자체 인증(self-certification) 또는 제3자 인증(third-party certification)을 통해 준수 여부를 확인할 수 있음.
• 활용: 조직 내 라이선스 준수 정책 수립 및 실행에 필요한 기본 프레임워크 제공.

ISO/IEC 18974

• 목적: 오픈소스 보안 보증을 위한 프로세스 관리 표준 제공.
• 특징: 코드베이스의 보안 취약점을 식별하고 이를 관리하기 위한 정책과 절차를 포함.
• 활용: 내부 및 외부 공급망에서 보안 위험을 줄이고, 대응 속도를 높이는 데 기여.

4. InnerSource와의 연관성

InnerSource는 조직 내부에서 오픈소스 개발 방식을 채택하여 협업과 혁신을 촉진합니다. 그러나 내부 공급망 관리에서도 외부 공급망과 동일한 수준의 프로세스 관리가 필요합니다.

• 공급망 관리의 확장: 내부 팀 간 코드 공유도 하나의 공급망으로 간주되며, 이를 효과적으로 관리하기 위해 OpenChain ISO 표준이 적용될 수 있음.
• 프로세스 일관성: 내부에서 사용된 프로세스가 외부 공급망으로 확장될 때 번역이나 재구축 없이 그대로 활용될 수 있음.
• InnerSource Program Office 지원: ISO 표준은 InnerSource Program Office가 효율적인 프로세스를 구축하고 운영하는 데 필요한 지침을 제공합니다.

5. ISO 표준의 실제 적용 사례

Adoption 사례

• 전 세계적으로 약 121개 기업이 OpenChain ISO/IEC 5230를 공식 채택했으며, 대표적으로 KT, 삼성 SDS 등이 포함됩니다.
• 독일에서는 PwC가 진행한 연구에 따르면, 대규모 기업(2,000명 이상) 중 약 31%가 해당 표준을 이미 사용하거나 도입 계획 중임.

인증 방식

1. 자체 인증(Self-Certification):
   • 체크리스트를 기반으로 기업이 자체적으로 준수 여부를 확인.
   • 비용이 적고 빠르게 도입 가능.
2. 제3자 인증(Third-Party Certification):
   • 외부 인증 기관이 검증하여 신뢰도를 높임.
   • 규제가 많은 산업에서 선호됨.

성공 사례

• Bosch는 전체 기업 차원에서 OpenChain ISO/IEC 5230를 준수하며, 자체 인증 방식을 통해 효과적인 결과를 얻음.

6. 커뮤니티와 지원 자료

OpenChain 프로젝트는 글로벌 커뮤니티 중심으로 운영되며, 다양한 지원 자료를 제공합니다:

• 교육 자료: 오픈소스 교육 슬라이드 및 체크리스트 제공.
• 정책 템플릿: 조직별 요구사항에 맞춘 정책 작성 지원.
• 산업별 워크그룹: 자동차, 통신 등 특정 산업에 특화된 그룹 운영.
• 공식 파트너 프로그램: 도메인 전문성을 가진 파트너들과 협력하여 표준 채택 지원.

7. 결론 및 제안

ISO 표준은 InnerSource 프로그램이 내부 및 외부 공급망 모두에서 일관성과 효율성을 유지할 수 있도록 돕습니다. 이를 통해 조직은 다음과 같은 이점을 얻을 수 있습니다:

1. 프로세스 최적화: 공급망 전반에 걸쳐 프로세스를 통합하여 중복 작업 제거.
2. 리스크 감소: 라이선스 준수 및 보안 문제를 사전에 예방.
3. 시장 출시 시간 단축: 문제 해결 시간을 줄이고 혁신 속도를 높임.

기업 담당자를 위한 Action Items:

1. 조직 내 InnerSource Program Office 설립 또는 강화.
2. OpenChain ISO/IEC 5230 및 ISO/IEC 18974 도입 검토.
3. 자체 인증 또는 제3자 인증 방식 선택 후 실행 계획 수립.
4. 커뮤니티 활동 참여를 통해 최신 정보와 모범 사례 공유.

ISO 표준은 단순히 규정을 따르는 것을 넘어, 조직이 지속 가능한 소프트웨어 개발 문화를 구축하는 데 핵심적인 역할을 합니다.

7.12 - 2024-10-29 SBOM 시각화 - SBOM 검토를 위한 대안적 접근법

source: https://openchainproject.org/news/2024/10/29/webinar-sbom-visualization

목차

1. 소개
2. SBOM의 중요성과 과제
3. SBOM 시각화 도구 소개
4. 시각화 요소 및 기능
5. Chromium 프로젝트 사례 분석
6. Q&A 세션
7. 결론

1. 소개

발표자 소개

이번 웨비나의 발표자는 Bitsea GmbH의 창립자이자 CEO인 Andreas Kotulla 박사입니다. Andreas 박사는 소프트웨어 시스템 감사와 기업의 숨겨진 위험 식별 분야의 전문가입니다. 그는 기술 실사를 지원하고 주요 기반 시설(KRITIS) 운영자들에게 조언을 제공합니다. 또한 오픈소스 전략, 거버넌스, 프로세스, 툴체인에 대해 고객들에게 자문을 제공하며, 오픈소스 프로그램 오피스(OSPO) 및 스캐닝 관리 서비스를 제공합니다.

웨비나 소개와 목적

이 웨비나는 OpenChain Project 웨비나 시리즈의 일환으로 진행되었습니다. 이번 세션에서는 Software Build of Materials(SBOM)의 시각화에 대해 다룹니다. SBOM은 계층 구조, 연결, 수정, 수출 제한, 보안 취약점, 배포 유형, 버전 등 다차원적인 정보를 포함하고 있습니다. 이러한 복잡한 정보를 빠르고 이해하기 쉬운 방식으로 표시하기 위해 메타 정보의 시각화를 구현한 방법에 대해 논의합니다. 이 연구 프로젝트는 독일 연방 경제기후보호부(BMWi)의 지원을 받아 Bonn-Rhein-Sieg University of Applied Sciences와 Bitsea가 공동으로 수행했습니다.

2. SBOM의 중요성과 과제

오늘날 소프트웨어 개발에서 오픈소스는 필수적인 요소가 되었습니다. 2012년경에는 일반적인 프로젝트에서 약 200개의 오픈소스 컴포넌트를 사용했지만, 최근에는 그 수가 3,000개 이상으로 증가했습니다. 이러한 증가는 패키지 관리자의 발전, 작은 컴포넌트들의 사용 증가, 새로운 생태계(npm, Ruby gems, pip 등)의 등장 등 여러 요인에 기인합니다.

이렇게 많은 컴포넌트를 관리하는 것은 매우 복잡한 작업입니다. 라이선스 의무, 보안 취약점, 수출 제한, 운영 위험 등 다양한 측면을 고려해야 합니다. 기존의 리스트 형태의 SBOM으로는 이러한 복잡성을 효과적으로 관리하기 어렵습니다.

3. SBOM 시각화 도구 소개

이러한 문제를 해결하기 위해 SBOM 시각화 도구가 개발되었습니다. 이 도구는 SBOM의 복잡한 정보를 직관적이고 이해하기 쉬운 그래픽으로 표현합니다. 마치 지리적 요소를 보여주는 지도처럼, SBOM 시각화는 소프트웨어의 다양한 컴포넌트와 그들 간의 관계, 특성을 보여줍니다.

시각화의 장점

1. 빠른 개요 및 명확성: 소프트웨어 컴포넌트와 의존성을 시각적으로 표현하여 전체 구조를 직관적으로 이해할 수 있습니다.
2. 간단한 탐색: 개발자와 프로젝트 관리자가 컴포넌트 간의 연결을 인식하고, 잠재적 약점을 식별하며, 변경의 영향을 이해하는 데 도움을 줍니다.
3. 의존성 식별: 컴포넌트 간의 의존 관계, 잠재적 병목 현상이나 위험, 소프트웨어의 중요 부분을 쉽게 파악할 수 있습니다.
4. 커뮤니케이션 및 협력 강화: 팀 전체가 동일한 SBOM 뷰를 공유함으로써 의사소통이 개선됩니다.
5. 명확한 계획 수립: SBOM의 그래픽 표현은 소프트웨어 환경을 상세하고 포괄적으로 보여주는 지도 역할을 합니다.

4. 시각화 요소 및 기능

SBOM 시각화 도구는 다양한 시각적 요소를 사용하여 복잡한 정보를 표현합니다:

컴포넌트 표현

• 기본 형태: 컴포넌트는 이름과 제목이 있는 직사각형으로 표시됩니다.
• 스니펫 표시: 전체 컴포넌트가 아닌 일부만 사용된 경우, 직사각형의 일부가 잘린 형태로 표시됩니다.

라이선스 정보

• 색상 스키마: 신호등 체계를 사용하여 라이선스 의무를 표시합니다.
  • 빨간색: 카피레프트 라이선스 (강한 카피레프트는 진한 빨간색, 약한 카피레프트는 연한 빨간색)
  • 노란색: 특별한 특징이 있는 라이선스, 상업적 라이선스, 수정된 라이선스 등
  • 초록색: 허용적 라이선스

보안 취약점

• 빨간색 정지 표지판: 알려진 보안 취약점이 있는 경우 표시됩니다.
• 숫자 표시: 알려진 취약점의 수를 표시합니다.

기타 정보

• 수출 제한: 느낌표가 있는 주의 표지로 표시
• 수정 여부: 작은 펜 아이콘으로 표시
• 법적 승인 여부: 파란색 물음표로 표시
• 특허 영향: 망치 아이콘으로 표시
• 운영 위험: 별 모양의 느낌표로 표시
• AI 생성 코드: 상단의 파란색 막대로 표시

의존성 표현

• 정적 링킹: 실선으로 연결
• 동적 링킹: 점선으로 연결
• Linux 시스템 콜: 노란색 느낌표로 표시

추가 정보

팝업 메뉴를 통해 소프트웨어 이름, 계층 구조, 라이선스 유형, 전체 라이선스 텍스트, URL, 취약점 목록, 영향을 받는 파일, 저작권 정보 등 추가 정보를 제공합니다.

5. Chromium 프로젝트 사례 분석

발표자는 Google Chromium 프로젝트를 예로 들어 SBOM 시각화 도구의 실제 적용을 보여주었습니다. Chromium은 매우 큰 프로젝트로, 수많은 컴포넌트로 구성되어 있습니다.

시각화 예시

• 전체 뷰: 처음에는 매우 복잡해 보이지만, 필터링과 검색, 확대/축소 기능을 통해 쉽게 탐색할 수 있습니다.
• 확대 뷰: 개별 컴포넌트, 라이선스, 의존성 등을 자세히 볼 수 있습니다.
• 디렉토리 뷰: 컴포넌트의 계층 구조를 더 쉽게 이해할 수 있습니다.

필터링 및 시뮬레이션 기능

• 검색 필터: 특정 라이선스, 이름, 특성 등으로 컴포넌트를 검색할 수 있습니다.
• 보안 취약점 필터: 보안 취약점이 있는 컴포넌트만 표시할 수 있습니다.
• 카피레프트 라이선스 필터: 카피레프트 라이선스를 사용하는 컴포넌트만 표시할 수 있습니다.
• 라이선스 영향 시뮬레이션: 특정 라이선스의 영향을 받는 컴포넌트를 시각적으로 확인할 수 있습니다.
• 라이선스 비호환성 시뮬레이션: 호환되지 않는 라이선스 간의 충돌을 식별할 수 있습니다.

6. Q&A 세션

Q: 이 도구를 직접 테스트해볼 수 있나요? A: 현재 도구는 오픈소스로 공개되지 않았지만, 11월이나 12월경에 공개할 예정입니다. 그 전에 테스트해보고 싶으신 분들은 개인적으로 연락 주시면 도와드리겠습니다.

Q: AI로 생성된 코드를 어떻게 식별하나요? A: 현재로서는 자동으로 식별하는 메커니즘은 없습니다. 이 정보가 제공되면 표시할 수 있습니다.

Q: 특허 영향은 어떻게 정의되나요? A: Apache 라이선스와 같이 특허에 대한 조항이 있는 라이선스를 사용할 때 특허 영향이 있다고 표시합니다. 사용자가 직접 설정할 수도 있습니다.

Q: SPDX나 CycloneDX와 같은 표준 SBOM 형식에서 어떤 정보를 추출하나요? A: 시각화에 표시된 모든 정보와 팝업에 표시되는 추가 정보를 추출합니다. 일부 정보는 다른 도구를 통해 얻어야 할 수도 있습니다.

Q: 라이선스 분류는 어떻게 이루어지나요? A: 기본적인 분류를 제공하지만, 사용자가 직접 설정할 수 있습니다. 예를 들어, AGPL이나 GPL은 강한 카피레프트로, 다른 공개 라이선스는 약한 카피레프트로 분류합니다.

Q: 현재 데이터베이스에는 몇 개의 라이선스가 분석되어 있나요? A: 약 1,000개의 다른 라이선스가 데이터베이스에 있습니다.

7. 결론

SBOM 시각화 도구는 복잡한 소프트웨어 구성을 쉽게 이해하고 관리할 수 있게 해줍니다. 이는 마치 최신 내비게이션 시스템처럼 SBOM의 복잡한 “거리와 동네"를 탐색하는 데 도움을 줍니다. 이 도구의 주요 장점은 복잡한 정보를 명확하고 포괄적으로 제시하며, 상호작용이 가능하다는 것입니다.

소프트웨어 환경을 쉽게 탐색할 수 있게 해주며, 잠재적 위험을 빠르게 식별할 수 있습니다. 특히 내부 사용, SaaS, 제품 배포 등 다양한 사용 모델에 따라 오픈소스 사용의 영향이 다를 수 있는데, 이 도구를 통해 각 상황에 맞는 위험을 쉽게 파악할 수 있습니다.

이 SBOM 시각화 도구는 오픈소스로 공개될 예정이며, 향후 유럽 사이버 복원력 법(Cyber Resilience Act)에 대응하기 위한 프로젝트의 일부로 포함될 예정입니다.

7.13 - 2024-10-10 데이터가 AI 공급망에서 차지하는 역할

source: https://openchainproject.org/news/2024/10/10/webinar-the-role-of-data-in-the-supply-chain-of-ai

목차

1. 발표자 소개
2. 웨비나 소개와 목적
3. AI 공급망과 데이터의 중요성
4. 공개 데이터셋 및 AI 모델의 활용과 리스크
5. AI 규제와 데이터 투명성의 미래
6. 기업을 위한 전략 및 액션 아이템

1. 발표자 소개

Nick Schifano는 FastCatalog.ai의 CEO이자 창립자로, AI와 법적 프레임워크 분야의 전문가입니다. Microsoft에서 11년간 근무하며 기술 규제 및 AI/ML 법적 검토를 주도했으며, 특히 AI 모델 훈련에 필요한 데이터 사용 검토 시스템을 설계했습니다. 현재 FastCatalog.ai를 통해 AI 공급망 관리 기술과 서비스를 제공하고 있습니다.

2. 웨비나 소개와 목적

이번 웨비나는 AI 공급망에서 데이터가 차지하는 역할과 관련된 주요 이슈를 다루며, 다음과 같은 주제를 중심으로 논의되었습니다:

• 모델 계보와 훈련 데이터에 숨겨진 리스크
• 데이터 투명성의 중요성과 기업에 미치는 영향
• AI 및 데이터 공급망 관리 전략
• EU AI Act 등 새로운 규제에 대비하는 방법

Nick Schifano는 이러한 주제를 통해 기업들이 새로운 규제 환경에 대비하고 AI 공급망을 효과적으로 관리할 수 있도록 실질적인 가이드를 제공했습니다.

3. AI 공급망과 데이터의 중요성

3.1 AI 시스템 구축 과정

AI 시스템은 크게 네 단계로 나뉩니다:

1. 소싱(Source): 훈련 데이터, 기존 모델, 훈련 프레임워크 등 필요한 자원을 확보.
2. 구축(Build): 데이터를 사용해 모델을 훈련하거나 기존 모델을 미세 조정.
3. 배포(Deploy): 완성된 모델을 클라우드, 온프레미스 또는 디바이스에 배포.
4. 관리(Manage): 전체 프로세스를 지속적으로 모니터링하고 규제 준수 여부를 확인.

3.2 데이터의 역할

AI 모델 훈련에는 다양한 형태의 데이터가 필요합니다:

• 공개 데이터셋 (예: Common Crawl, Red Pajama)
• 오픈소스 모델 (예: Meta Llama)
• 훈련 프레임워크 (예: PyTorch, TensorFlow)

Nick은 특히 공개 데이터셋과 오픈소스 모델이 제공하는 기회와 위험 요소를 강조하며, 각 구성 요소가 어떻게 AI 제품에 영향을 미치는지를 설명했습니다.

4. 공개 데이터셋 및 AI 모델의 활용과 리스크

4.1 주요 공개 데이터셋

• Common Crawl: 인터넷 전반을 크롤링한 텍스트 데이터를 포함하며, OpenAI 및 Meta 등의 대규모 언어 모델 훈련에 활용됨.
• Red Pajama: Apache 2.0 라이선스를 따르지만 Common Crawl 기반으로 생성되어 법적 복잡성이 존재.
• BookCorpus: 전자책 데이터를 포함하며 저작권 문제를 야기할 가능성이 있음.

4.2 오픈소스 모델

• Llama 3.1 (Meta): 특정 라이선스 조건(예: “Built with Llama” 표시 의무) 포함.
• Black Forest FLUX: 비상업적 사용만 허용하는 라이선스를 따름.

4.3 주요 과제

Nick은 다음과 같은 문제들을 지적했습니다:

• 데이터 출처 불명확성으로 인한 법적 리스크.
• 저작권 침해 가능성과 이에 따른 소송 사례(예: 뉴욕타임즈 vs OpenAI).
• 특정 지역(예: EU)에서 요구되는 투명성 기준 충족 여부.

5. AI 규제와 데이터 투명성의 미래

5.1 주요 규제 동향

Nick은 여러 지역에서 시행 중인 규제를 다음과 같이 요약했습니다:

• EU AI Act: 훈련 데이터 출처 공개 및 기술 문서 유지 의무화.
• 미국 캘리포니아 AB 2013 법안: 생성형 AI 훈련 데이터 투명성 요구.
• 일본 METI 가이드라인: 데이터 출처 추적 가능성 확보 권장.

5.2 글로벌 협력 가능성

GDPR처럼 EU AI Act가 글로벌 표준으로 자리 잡을 가능성을 논의했지만, 각 지역별로 상이한 접근 방식이 존재함을 강조했습니다.

6. 기업을 위한 전략 및 액션 아이템

6.1 오픈소스 관리 담당자를 위한 의미

오픈소스 및 공개 데이터를 사용하는 기업은 다음 사항을 고려해야 합니다:

• 공개된 라이선스 조건 준수 여부 확인.
• 훈련 데이터 및 모델 사용 내역 투명하게 기록.
• 새로운 규제에 대비해 내부 프로세스 정비.

6.2 고려해야 할 Action Item

1. 데이터 및 모델 카탈로그 구축:
   • 사용 중인 모든 데이터셋과 모델의 출처, 라이선스 조건 등을 기록.
2. 투명성 보고서 작성 프로세스 마련:
   • 규제가 요구하는 정보를 포함한 표준화된 보고서 작성 체계 수립.
3. 리스크 관리 방안 개발:
   • 저작권 침해나 기타 법적 문제 발생 시 대응 절차 마련.
4. 내부 승인 프로세스 강화:
   • 안전한 프로파일(예: 오픈소스 라이선스 준수)을 정의하고 빠른 승인 절차 제공.

이번 웨비나는 AI 공급망 관리에서 데이터를 중심으로 한 복잡한 문제들을 심도 있게 다루며 기업들이 직면할 수 있는 도전 과제를 명확히 했습니다. Nick Schifano는 기술적·법적 전문성을 바탕으로 실질적인 조언을 제공하며, 참석자들에게 큰 통찰을 안겨주었습니다.

7.14 - 2024-09-27 AI: 현재의 법적 환경

source: https://openchainproject.org/featured/2024/09/27/webinar-ai-the-current-legal-landscape

목차

1. 소개
2. AI와 오픈소스의 교차점
3. 소송 개요
4. 법규/입법 개요
5. 데이터 보호와 AI
6. Q&A

1. 소개

제목

AI: 현재의 법적 환경

발표자 소개

• Tony: GTC Law Group의 IP 전문 변호사. AI, 오픈소스, 특허 전략, 거래 분야 전문.
• Well: 기계학습 박사 학위 소지자. AI 제품 연구 과학자 및 프로그래머 경력.
• Stas: 전 Amazon Kindle 팀 멤버, Audible 전 법무 자문, Netflix AI 법무 담당. GTC의 AI 그룹 공동 리더.
• Shay: 데이터 프라이버시 및 사이버 보안 전문가. 신흥 기술 관련 자문 경험 풍부.

웨비나 소개와 목적

이 웨비나는 OpenChain 커뮤니티에서 주최하는 AI 관련 법적 환경에 대한 논의의 연장선상에 있습니다. 지난해에 이어 GTC Law 팀이 생성형 AI를 둘러싼 현재의 법적 환경에 대해 포괄적으로 설명합니다. 이 웨비나의 목적은 AI 기술의 발전에 따른 법적 문제들을 살펴보고, 기업과 개발자들이 알아야 할 주요 사항들을 제공하는 것입니다.

2. AI와 오픈소스의 교차점

AI의 발전 과정

• AGI(Artificial General Intelligence): 인간 수준의 지능을 가진 기계
• AI(Artificial Intelligence): 특정 작업에 대한 인간 지능 모방
• Machine Learning: AI의 한 기법, 데이터셋으로부터 학습하여 모델 생성
• Deep Learning: 대량의 데이터와 연산력 필요, 신경망 기반
• Generative AI: 새로운 데이터 생성 능력

Generative AI 응용

• 텍스트 생성
• 이미지 생성
• 코드 생성
• 비디오 생성
• 음악 생성
• 합성 데이터 생성

AI와 오픈소스 라이선스

많은 AI 도구들이 오픈소스 라이선스로 제공됩니다. 예를 들어:

• PyTorch
• TensorFlow
• OpenCV
• Keras
• Transformers

Meta의 LLaMA 모델은 “오픈소스"라고 불리지만, 실제로는 상업적 라이선스에 가깝습니다. 특히 7억 명 이상의 활성 사용자를 가진 경우 별도의 라이선스가 필요하며, LLaMA의 출력을 다른 언어 모델 개선에 사용할 수 없다는 제한이 있습니다.

Responsible AI Licenses (RAIL)

RAIL은 AI 기술의 비윤리적 사용을 제한하기 위해 만들어진 라이선스입니다. 주요 특징:

• 사용 제한 조항 포함
• 하위 사용자에게도 동일한 행동 제한 요구
• 감시, 딥페이크, 의료, 범죄 기록 등에 대한 사용 제한

RAIL은 최근 많은 주목을 받고 있으며, MIT나 Apache 라이선스보다 더 많은 AI 모델에 적용되고 있습니다.

3. 소송 개요

AI, 특히 생성형 AI 제공업체들을 상대로 한 소송이 증가하고 있습니다. 주요 소송 분야:

컴퓨터 코드 관련

• GitHub Copilot 관련 집단 소송
• 주요 쟁점: DMCA 위반, 계약 위반, 과실, 사기

이미지 관련

• Stability AI의 Stable Diffusion 관련 소송
• 주요 쟁점: 저작권 침해, DMCA 위반, 불공정 경쟁

문서 관련

• 저자들의 저작권 침해 소송
• 주요 쟁점: 직접 및 간접 저작권 침해, DMCA 위반, 불공정 경쟁

음악 관련

• 실제 녹음물 및 가사 관련 소송
• 주요 쟁점: 저작권 침해, DMCA 위반

GitHub Copilot 소송 사례

• 주요 쟁점: DMCA 위반, 오픈소스 라이선스 위반, GitHub 이용약관 위반
• 최근 법원은 원고의 일부 주장을 기각

Getty Images vs Stability AI 소송 사례

• 주요 쟁점: 저작권 침해, 저작권 관리 정보 위반, 상표 희석
• Stable Diffusion이 Getty Images의 워터마크를 변형하여 사용한 점이 쟁점

4. 법규/입법 개요

AI 규제는 크게 네 가지 유형으로 분류할 수 있습니다:

1. 기존 법률 적용

   • 소비자 보호, 차별 금지, 프라이버시 등

2. 일반 AI 규제

   • EU AI Act
   • Colorado Consumer Protections for AI
   • Utah Artificial Intelligence Policy Act

3. 산업 또는 사용 사례별 AI 규제

   • 보험사의 AI 사용
   • 고용 결정에서의 AI 사용
   • 정부의 AI 조달 및 사용

4. 정책 수립 중심

   • AI 규제 제안을 위한 태스크포스 설립
   • AI 기술의 중요성을 인식하는 선언
   • AI 채택을 촉진하기 위한 정부 지출 프로그램 수립

5. 데이터 보호와 AI

2024년 프라이버시 법 요약

• 20개의 포괄적 프라이버시 법
• 2020년부터 2026년 사이에 발효
• 대부분 “소비자"의 “개인 데이터"에 적용
• 캘리포니아 법은 더 광범위한 적용 범위

AI와 데이터 보호의 교차점

• 보안 문제와 데이터 유출
• 복잡한 프라이버시 준수 의무
• 자동화된 의사 결정 시스템에 대한 소비자 옵트아웃 권리
• 고위험 AI 시스템에 대한 추가 요구사항
• 편향과 차별 방지에 중점

사례 연구: AI 훈련을 위한 데이터 스크래핑

• 중요한 결정, 프로파일링, AI/LLM 훈련 등의 사용 사례
• 개인 데이터, 민감 데이터, 이미지, 사용자 생성 콘텐츠 등의 데이터 사용
• 인간 개입, 신뢰성, 투명성, 정확성, 편향/차별 등의 출력 관련 고려사항

6. Q&A

Q: LLAMA 모델의 “다른 모델 개선에 사용 불가” 조항에 대해 설명해주세요. A: 라이선스 조항에 따르면, LLAMA 자료나 그 결과물을 LLAMA 2나 그 파생물을 제외한 다른 대규모 언어 모델을 개선하는 데 사용할 수 없습니다. 이는 Meta가 경쟁을 제한하고 자사의 모델 우위를 유지하려는 의도로 보입니다.

Q: RAIL 라이선스가 모든 라이선스를 “스노우플레이크"로 만드는 것 아닌가요? A: RAIL의 기본 아이디어는 사용 제한과 하위 사용자 준수를 요구하는 것이지만, 실제로는 몇 가지 표준화된 버전으로 수렴하고 있습니다. 예를 들어, Hugging Face에서는 “Creative ML OpenRAIL-M” 라이선스가 23,000개 이상의 모델에 사용되고 있습니다.

Q: 소송의 타임라인은 어떻게 되나요? A: 정확한 타임라인은 없지만, 유사한 소송 사례를 보면 최종 결정까지 5-10년이 걸릴 수 있습니다. 법률은 종종 새로운 기술을 따라가는 데 시간이 걸리므로, 판례법보다는 법규를 통한 지침이 먼저 나올 가능성이 높습니다.

Q: 교육 분야에서 AI 사용 감지 도구의 편향성 문제는 어떻게 해결해야 하나요? A: 이는 중요한 문제입니다. 도구 자체에만 의존하지 말고 인간의 판단을 병행해야 합니다. 캘리포니아의 새로운 규정은 자동화된 의사결정이 중요한 요소인 경우에도 규제 범위에 포함시키려 하고 있습니다. 이는 교육자가 도구에 과도하게 의존하는 경우에도 규제 대상이 될 수 있음을 의미합니다.

요약 보고서

기업의 오픈소스 관리 담당자에게 갖는 의미

1. AI 기술과 오픈소스의 융합: 많은 AI 도구들이 오픈소스로 제공되고 있어, 오픈소스 관리의 중요성이 더욱 커지고 있습니다.

2. 새로운 라이선스 유형 등장: RAIL과 같은 새로운 라이선스 유형이 등장하고 있어, 이에 대한 이해와 관리가 필요합니다.

3. 법적 리스크 증가: AI 관련 소송이 증가하고 있어, 오픈소스 사용 시 법적 리스크에 대한 주의가 필요합니다.

4. 데이터 보호 의무 강화: AI 사용에 따른 데이터 보호 의무가 강화되고 있어, 오픈소스 AI 도구 사용 시에도 이를 고려해야 합니다.

5. 규제 환경 변화: AI 관련 규제가 빠르게 변화하고 있어, 이에 대한 지속적인 모니터링이 필요합니다.

고려해야 할 Action Item

1. AI 관련 오픈소스 라이선스 검토: 사용 중인 AI 도구들의 라이선스를 철저히 검토하고, 특히 RAIL과 같은 새로운 라이선스 유형에 주의를 기울입니다.

2. 데이터 사용 정책 수립: AI 훈련에 사용되는 데이터의 출처와 사용 권한을 명확히 하는 정책을 수립합니다.

3. AI 사용 가이드라인 제정: 회사 내 AI 도구 사용에 대한 가이드라인을 만들어 법적 리스크를 최소화합니다.

4. 정기적인 컴플라이언스 검토: AI 관련 법규 준수 여부를 정기적으로 검토하고 필요한 조치를 취합니다.

5. AI 윤리 정책 수립: