이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.
OpenChain Project에서는 Compliance Program을 구축하는 데 필요한 정책 문서 템플릿, 교육 자료 등 다양한 참고자료를 제공합니다. 이 자료들은 OpenChain Specification 및 일반적인 Open Source Compliance 활동을 지원하기 위해 고안되었습니다.
OpenChain KWG의 주요 활동 중 하나는 OpenChain Project의 문서 자료를 한국어로 번역하여 공개하는 것입니다. 이와 같이 OpenChain KWG는 협업을 통해 문서를 번역하거나 교육자료를 만들어서 공개하고 있습니다.
자세한 사항은 다음 페이지를 참고하세요.
OpenChain 규격은 오픈소스 컴플라이언스를 위한 핵심 요구사항을 정의한 12페이지 분량의 표준 규격으로, 기업의 규모나 업종과 관계없이 모든 분야의 회사에 적합하도록 고안되었습니다. 2020년 12월에는 OpenChain Specification 2.1이 배포됐으며, 기업이 오픈소스 컴플라이언스 달성을 위해 꼭 수행해야 할 여섯 가지 요건에 대한 설명과 기업이 이를 수행하고 있음을 입증할 수 있는 검증 자료 목록을 정의하고 있습니다.
오픈소스 컴플라이언스를 처음 시작하는 기업이라면 이와 같은 OpenChain 규격의 요건을 하나씩 충족해나가면서 수준을 향상시킬 수 있습니다.
OpenChain Project는 한 개인이 작업한 번역물은 공식 버전으로 채택하지 않고 있습니다. 최소 2곳 이상의 개인 혹은 단체에서 번역하고 감수해야 한다는 등의 방침을 두어서 올바른 번역물이 배포될 수 있도록 하고 있습니다.
OpenChain의 규격에 대한 자세한 번역 정책은 다음 페이지를 참고하세요. : https://www.openchainproject.org/contribute-to-the-standard
OpenChain 규격의 한국어 번역은 버전 2.1까지 번역이 완료된 상태이며 다음 페이지에서 다운로드 받을 수 있습니다. : https://github.com/OpenChain-KWG/Specification-Translation-KR/tree/master/release/2.1
OpenChain 규격 한국어 번역의 주요 기여자 현황은 다음과 같습니다.
| Name | Company | Role | |
|---|---|---|---|
| 장학성 | SK텔레콤 | haksung@sk.com | Maintainer |
| 박종백 | 법무법인 태평양 | jb.park@bkl.co.kr | Contributor |
| 황서영 | 삼성전자 | seoyoung.hwang@samsung.com | Contributor |
| 김경애 | LG전자 | kyoungae.kim@lge.com | Contributor |
| 홍종호 | LG전자 | jjongho.hong@lge.com | Contributor |
OpenChain 규격 한국어 번역은 GitHub에서 공동으로 수행하며 누구나 참여할 수 있습니다. 많은 참여 바랍니다!
OpenChain Project에서는 컴플라이언스 프로그램을 구축하는 데 필요한 교육 자료를 만들어서 공개하였습니다. : https://github.com/OpenChain-Project/Curriculum
CC-0로 공개하였기 때문에 기업에서는 이를 활용하여 기업 내 교육 자료를 만들 수 있으며, 가장 최근 자료는 다음 링크에서 다운로드 받을 수 있습니다.
OpenChain Curriculum의 한국어 번역은 1.2까지 번역이 완료된 상태이며 다음 페이지에서 다운로드 받을 수 있습니다.
OpenChain Curriculum 한국어 번역의 주요 기여자 현황은 다음과 같습니다.
| Name | Company | Role | |
|---|---|---|---|
| Haksung Jang | SK telecom | haksung@sk.com | 공동번역 |
| Jongbaek Park | BKL | jb.park@bkl.co.kr | 공동번역 |
OpenChain Curriculum 한국어 번역은 GitHub에서 공동으로 수행하며 누구나 참여할 수 있습니다. 많은 참여 바랍니다!
NCSOFT에서는 이 책의 주요 내용을 한글로 요약하였고 저자인 Ibrahim으로부터 허가를 받은 후 국내 기업의 오픈소스 담당자들이 참고할 수 있도록 GitHub에 공개하였습니다.
자세한 내용은 다음 링크를 참고하세요 : LINK
OpenChain AI 워크그룹은 오픈 소스 컴플라이언스의 국제 표준인 OpenChain(ISO/IEC 5230)의 원칙을 인공지능(AI) 영역으로 확장하여, 신뢰할 수 있는 AI 공급망 구축을 목표로 매월 워크숍을 진행하고 있습니다. 이번 12월 2일 북미/유럽 세션은 Matthew Crawford(Arm) 와 Dave Marr(Qualcomm) 의 주재로 진행되었으며, 주로 AI 시스템 자재명세서(AI SBOM) 컴플라이언스 가이드의 세부 문구 조정과 AI 조달(Procurement)을 위한 표준 설문지 개발 필요성에 대한 논의가 이루어졌습니다.
이번 워크숍의 핵심 아젠다는 크게 두 가지로 요약됩니다.
미팅의 전반부는 현재 마무리 단계에 있는 ‘AI SBOM 컴플라이언스 가이드’의 특정 섹션을 검토하고 수정하는 데 할애되었습니다. 단순한 오타 수정이 아닌, 실제 현업에서 적용 가능한 ‘프로세스’와 ‘정책’의 정의를 명확히 하는 토론이 주를 이루었습니다.
참석자들은 AI 컴플라이언스 프로그램의 성패가 결국 ‘사람’에게 달려 있다는 점에 동의하며, 가이드 내에 “프로그램 참여자의 역량(Competence)” 을 규정하는 문구를 다듬었습니다.
논의 중 가장 흥미로웠던 부분은 ‘정책’과 ‘프로세스’를 구분하여 기술하는 방식에 대한 것이었습니다.
AI SBOM 생성 및 관리에 대한 조항도 구체화되었습니다.
미팅 후반부에는 Matthew Crawford가 제안한 새로운 이니셔티브인 ‘조달 목적의 AI 설문지(AI Questionnaire for Procurement Purposes)’ 가 논의되었습니다.
현재 많은 기업이 외부 공급업체로부터 AI 도구나 서비스를 도입할 때, 각자의 기준대로 수많은 질문을 던지고 있습니다.
이로 인해 공급업체는 고객사마다 다른 양식의 질문에 답변해야 하는 비효율이 발생하고, 구매사는 필요한 정보를 누락할 위험이 있습니다.
OpenChain 프로젝트 차원에서 이러한 질문들을 표준화하자는 제안이 나왔습니다. 기존의 프로세스 점검을 넘어, 모델(Model), 데이터셋(Dataset), 데이터 카드(Data Cards), 모델 카드(Model Cards) 와 관련된 구체적인 스펙을 묻는 공통 질문지를 만들자는 것입니다.
다음 달(2026년 1월) 미팅은 일반적인 워크숍 형식이 아닌, 대중을 위한 웨비나(Webinar) 형태로 진행될 예정입니다.
워크그룹은 AI 전문가들(Practitioners)과의 교류를 강조했습니다. 법무팀이나 컴플라이언스팀뿐만 아니라, 실제 AI를 개발하고 운영하는 엔지니어들의 피드백이 가이드의 현실성을 높이는 데 필수적이기 때문입니다. 학회나 컨퍼런스에서 AI 개발자들을 만난다면 OpenChain의 활동을 알리고 피드백을 받아달라는 요청이 있었습니다.
이번 12월 워크숍은 AI 컴플라이언스 가이드의 완성도를 높이는 작업과 시장의 비효율을 해결할 새로운 도구(표준 설문지)를 구상하는 단계로 요약할 수 있습니다. 특히 ‘사람의 역량’과 ‘인바운드 자재 관리’를 강조한 점은 AI 거버넌스가 단순한 서류 작업을 넘어 실질적인 리스크 관리로 진화하고 있음을 보여줍니다.
OpenChain 프로젝트는 누구나 참여할 수 있는 개방형 커뮤니티입니다. 이번 논의 내용에 대해 의견이 있거나, 1월 웨비나에 참여하고 싶으신 분들은 아래 채널을 참고해 주시기 바랍니다.
by Gemini 3.0
안녕하세요! OpenChain 프로젝트에서 새롭게 공개한 AI System Bill of Materials (AI SBOM) Compliance Guide를 블로그 포스팅 형태로 소개해 드리겠습니다.
이 가이드는 AI 기술이 급격히 확산되는 공급망 환경에서, 조직 간의 신뢰를 구축하고 투명성을 확보하기 위해 만들어진 중요한 자료입니다.
인공지능(AI) 기술이 소프트웨어 공급망의 핵심 요소로 자리 잡으면서, AI 시스템을 구성하는 데이터, 모델, 라이선스 등을 투명하게 관리하는 것이 그 어느 때보다 중요해졌습니다. 리눅스 재단(Linux Foundation) 산하의 OpenChain Project는 이러한 요구에 발맞춰 “AI 시스템 자재 명세서(AI SBOM) 컴플라이언스 관리 가이드"를 공식 발표했습니다.
이 가이드는 AI 솔루션을 주고받는 조직들이 신뢰할 수 있는 컴플라이언스 프로그램을 구축하는 데 필요한 핵심 기준을 제시합니다.
이 가이드의 가장 큰 목적은 AI 솔루션을 교환하는 조직 간의 신뢰 구축입니다.
AI 시스템은 코드뿐만 아니라 학습 데이터(Data), 가중치(Weights), 모델(Model) 등 복합적인 요소로 이루어져 있어, 기존의 소프트웨어보다 관리가 까다롭습니다. 이 가이드는 조직이 고품질의 ‘AI SBOM 컴플라이언스 프로그램’을 갖추기 위해 충족해야 할 주요 요구사항을 정의하여, 일종의 벤치마크(Benchmark) 역할을 합니다.
이 문서는 구체적인 기술적 구현 방법(“How"나 “When”)보다는 프로그램이 무엇을 갖춰야 하고(What), 왜 필요한지(Why)에 집중합니다.
본 번역은 독자의 이해를 돕기 위해 원문을 바탕으로 작성되었습니다. 공식적인 법적 효력은 원문(Version 1.0)에 있습니다.
이 문서는 공급망 내에서 AI 컴플라이언스를 관리하기 위한 주요 요구사항을 명시합니다. 특히 이 목표를 달성하기 위해 AI SBOM(AI 시스템 자재 명세서)을 사용하는 데 중점을 둡니다.
조직이 AI 관련 컴플라이언스를 달성하는 방법은 조직의 규모, 산업, 사법권, AI 시스템의 형태(서비스, 모델, 데이터 등)에 따라 달라질 수 있습니다. 본 가이드는 대부분의 조직에 적용할 수 있는 핵심 프로세스 포인트를 다음과 같이 식별합니다.
AI SBOM 컴플라이언스를 관할하는 서면 정책이 존재해야 합니다.
조직은 프로그램의 효과성에 영향을 미치는 역할과 책임을 식별해야 합니다.
조직은 프로그램 참여자들이 다음 사항을 인지하도록 보장해야 합니다.
프로그램이 적용되는 범위를 명확히 선언해야 합니다. (예: 단일 제품 라인, 전체 부서 또는 전체 조직)
AI 시스템의 코드, 가중치(Weights), 데이터셋(학습, 테스트, 검증 데이터 포함) 및 AI 시스템 자체에 대해 식별된 라이선스를 검토하는 프로세스가 존재해야 합니다.
학습, 테스트, 검증 데이터셋 등을 포함하여 규제로부터 발생하는 투명성 의무가 있는지 검토하는 프로세스가 존재해야 합니다.
외부의 AI SBOM 컴플라이언스 문의에 효과적으로 대응하는 프로세스를 유지해야 합니다.
AI SBOM을 생성하고 관리하는 프로세스가 존재해야 합니다.
조직은 AI 시스템이 책임감 있게 개발, 배포, 관리되도록 보장하는 AI 거버넌스 프레임워크를 갖추어야 합니다.
이 가이드는 현재 버전 1.0이며, 빠르게 변화하는 AI 생태계에 맞춰 지속적으로 업데이트될 예정입니다. 더 자세한 내용이나 원문(PDF)은 OpenChain 프로젝트 공식 웹사이트를 참고하시기 바랍니다.
by Gemini 3.0
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)와 어떻게 협력하고 있는지에 대한 중요한 로드맵이 제시되었습니다.
이번 미팅의 가장 큰 뉴스는 단연 AI SBOM 규정 준수 관리 가이드(AI SBOM Compliance Management Guide)의 완성 소식입니다.
OpenChain 프로젝트팀은 지난 2024년 1월부터 AI 공급망 내에서 규정 준수(Compliance)를 어떻게 관리할 것인지에 대해 치열하게 고민해 왔습니다. 이번에 완성된 가이드는 그 결과물로서, AI 시스템을 구성하는 모델, 데이터셋, 코드, 그리고 각종 종속성(Dependencies)을 투명하게 관리하기 위한 실질적인 프레임워크를 제공합니다.
이 가이드는 미팅 직후인 10월 20일에 공식적으로 라이브(Go-Live) 되었습니다. 워크그룹은 이 가이드가 단순한 문서로 남지 않고 업계의 표준 레퍼런스로 자리 잡을 수 있도록 커뮤니티 차원의 적극적인 홍보와 확산을 요청했습니다. 이는 기업들이 다가오는 AI 규제(EU AI Act 등)에 선제적으로 대응할 수 있는 강력한 도구가 될 것입니다.
단순히 가이드를 만드는 것을 넘어, 이 가이드가 실제 법적 효력이나 국제 표준으로서의 위상을 갖출 수 있도록 고위급 레벨의 조율이 시작되었습니다.
이번 미팅에서는 Lord Clement-Jones와의 협력 논의가 중요하게 다뤄졌습니다. Lord Clement-Jones는 영국 상원의 AI 특별위원회 위원장이자 OECD AI 의회 그룹의 창립 멤버로서, 국제 AI 규제 및 정책 수립에 막대한 영향력을 가진 인물입니다.
OpenChain AI 워크그룹이 그와 직접적인 코디네이션을 시작했다는 것은, 우리가 만든 AI SBOM 가이드가 영국의 AI 규제 프레임워크나 향후 정책 방향과 정합성을 맞추고 있음을 의미합니다. 이는 향후 이 가이드가 글로벌 표준으로 채택될 가능성을 높이는 전략적 행보입니다.
또한, 리눅스 재단(LF)의 법률 컨퍼런스(Legal Conference) 및 파이토치(PyTorch) 컨퍼런스와의 연계도 진행 중입니다. 기술적인 구현(PyTorch)과 법적인 해석(LF Legal) 양쪽을 모두 아우르며, AI 거버넌스의 사각지대를 없애겠다는 의지입니다.
금융 산업은 AI 도입에 있어 가장 보수적이면서도 규제가 강력한 분야입니다. 이번 미팅에서는 금융 오픈소스 재단인 FINOS(Fintech Open Source Foundation)와의 협력 모델이 구체적으로 논의되었습니다.
FINOS는 현재 자체적인 ‘AI 거버넌스 프레임워크’를 개발 중이며, 이를 ISO 표준으로 발전시키려는 계획을 가지고 있습니다. OpenChain 워크그룹은 FINOS와 경쟁하는 것이 아니라, 상호 보완적인 관계를 맺기로 했습니다.
이는 AI 거버넌스 분야에서 파편화된 표준이 난립하는 것을 막고, 산업계가 신뢰할 수 있는 단일한 기준점을 만들기 위한 노력입니다.
가이드 1.0 버전의 완성은 끝이 아니라 시작입니다. 미팅에서는 ‘초기 시장 피드백(Early Market Feedback)‘의 중요성이 강조되었습니다.
이번 10월 9일 Asia Sync 미팅은 “AI SBOM 가이드의 완성"이라는 결실을 확인하고, 이를 “글로벌 규제(UK)” 및 “특화 산업(FINOS)“과 연결하는 거대한 로드맵을 공유하는 자리였습니다.
AI 거버넌스는 혼자서 해결할 수 있는 문제가 아닙니다. 여러분의 조직이 AI를 도입하고 있거나 도입할 예정이라면, 지금 바로 OpenChain AI 워크그룹에 합류하여 글로벌 표준 수립 과정에 목소리를 내주시기 바랍니다.
미팅 녹화본은 아래 유튜브 링크를 통해 다시 보실 수 있습니다.
이 블로그 포스트는 OpenChain AI Work Group의 공개된 미팅 기록과 자료를 바탕으로 작성되었습니다.
by Gemini 3.0
OpenChain AI Work Group: AI Compliance BOM 가이드 웨비나
이 웨비나는 OpenChain Project의 AI Work Group에서 주최한 것으로, AI Compliance BOM(Bill of Materials) 가이드 작성을 위한 첫 번째 공식 미팅입니다. 이전의 AI Study Group에서 AI Work Group으로 전환되어 AI BOM 컴플라이언스에 대한 실질적인 가이드라인을 만드는 것을 목표로 하고 있습니다.
AI 시스템의 복잡성이 증가함에 따라 전통적인 소프트웨어 BOM(SBOM)을 넘어서는 새로운 형태의 BOM이 필요해졌습니다. AI BOM은 AI 컴포넌트와 데이터셋을 포함한 전체 시스템을 표현할 수 있어야 합니다.
SPDX 3.0에서는 이러한 요구사항을 반영하여 AI와 데이터셋 프로파일을 추가했습니다. 이를 통해 AI 시스템의 핵심 요소들을 효과적으로 기술할 수 있게 되었습니다.
SPDX 3.0은 다음과 같은 특징을 가지고 있습니다:
AI 프로파일은 모델 유형, 준수 표준, 운영 도메인, 자율성 수준 등을 캡처합니다. 데이터셋 프로파일은 데이터의 유형, 크기, 노이즈, 기밀성 수준, 수집 프로세스 등을 기술합니다.
Gopi는 실제 Simple HTR 프로젝트를 예로 들어 AI BOM 작성 과정에서 겪은 어려움을 공유했습니다:
이러한 문제들로 인해 간단한 프로젝트의 AI BOM 작성에도 상당한 시간과 전문성이 요구되었습니다.
AI 시스템에서는 데이터셋과 모델의 라이선스가 복잡한 문제를 야기할 수 있습니다. 예를 들어:
이러한 복잡한 라이선스 이슈에 대해 아직 명확한 법적 해석이나 가이드라인이 부족한 상황입니다.
AI 시스템에 대한 규제가 증가하면서 (예: EU AI Act), AI BOM은 규제 준수를 입증하는 중요한 도구가 될 수 있습니다. 그러나 현재의 규제는 “충분한 투명성"이나 “적절한 인간 감독” 등 모호한 표현을 사용하고 있어, 이를 구체적으로 해석하고 구현하는 것이 과제입니다.
OpenChain의 프로세스 거버넌스 경험과 SPDX의 기술적 표준화 노력을 결합하여 AI BOM에 대한 포괄적인 가이드라인을 만들 수 있을 것으로 기대됩니다. 구체적인 협력 방안으로는:
Q: 데이터셋 출처 추적이 모델 출처 추적보다 더 어려운 문제 아닌가요? A: 네, 데이터셋의 출처와 계보를 추적하는 것이 더 어려운 문제입니다. 하지만 모델의 프로세스와 출처도 여전히 중요한 이슈입니다.
Q: 오픈소스와 클로즈드 소스 모델에 대한 BOM 작성에 차이가 있나요? A: 클로즈드 소스 모델의 경우 상세 정보를 얻기 어려울 수 있지만, BOM 표준 자체는 동일하게 적용될 수 있습니다. 다만, 공개 범위에 차이가 있을 수 있습니다.
Q: AI 시스템 전체에 대한 BOM이 필요하지 않을까요? A: 네, SPDX 3.0은 시스템 전체를 기술할 수 있는 능력을 갖추고 있습니다. 모델과 다른 소프트웨어 컴포넌트 간의 관계도 캡처할 수 있습니다.
AI 시스템 도입 증가: AI와 머신러닝 기술의 도입이 늘어남에 따라, 기존 SBOM을 넘어서는 AI BOM의 필요성이 커지고 있습니다.
컴플라이언스 복잡성 증가: AI 컴포넌트와 데이터셋을 포함한 전체 시스템의 라이선스 및 규제 준수 문제가 더욱 복잡해지고 있습니다.
새로운 표준 등장: SPDX 3.0과 같은 새로운 표준이 등장하여 AI 시스템의 BOM을 더 효과적으로 관리할 수 있게 되었습니다.
법적 불확실성: AI 시스템, 특히 생성형 AI와 관련된 라이선스 및 저작권 문제에 대한 법적 해석이 아직 명확하지 않습니다.
규제 대응 필요성: EU AI Act 등 새로운 AI 규제에 대응하기 위해 AI BOM이 중요한 도구가 될 수 있습니다.
AI BOM 도입 준비: SPDX 3.0 등 AI BOM 표준을 학습하고, 조직 내 도입 계획을 수립합니다.
메타데이터 관리 강화: AI 모델과 데이터셋에 대한 상세한 메타데이터를 체계적으로 관리하는 프로세스를 구축합니다.
라이선스 관리 체계 개선: AI 컴포넌트, 데이터셋, 생성된 데이터 등에 대한 복잡한 라이선스 관계를 추적하고 관리할 수 있는 체계를 마련합니다.
자동화 도구 개발/도입: AI BOM 생성과 관리를 자동화할 수 있는 도구의 개발이나 도입을 검토합니다.
거버넌스 프로세스 수립: AI 시스템의 개발, 배포, 운영 전반에 걸친 거버넌스 프로세스를 수립합니다.
규제 모니터링: AI 관련 규제 동향을 지속적으로 모니터링하고, 대응 전략을 수립합니다.
협업 강화: 법무팀, 데이터 과학팀, 개발팀 간의 협업을 강화하여 AI BOM 관리에 대한 통합적 접근을 추진합니다.
교육 및 인식 제고: 조직 내 AI BOM의 중요성과 관리 방법에 대한 교육을 실시합니다.
업계 표준화 활동 참여: OpenChain, SPDX 등의 표준화 활동에 참여하여 AI BOM 관련 best practice를 공유하고 학습합니다.
듀 딜리전스 문서화: AI 시스템 개발 및 도입 과정에서의 모든 준수 노력을 상세히 문서화합니다.
source: https://openchainproject.org/news/2024/11/06/ai-study-group-2024-11-05-recording
OpenChain AI 스터디 그룹: 북미 및 유럽을 위한 월간 워크샵 - 2024년 11월 5일
이번 웨비나는 OpenChain Project의 AI 스터디 그룹에 의해 진행되었습니다. 특정 발표자의 이름은 제공된 정보에 명시되어 있지 않습니다.
이 워크샵은 OpenChain AI 스터디 그룹의 정기 모임으로, 2024년 11월 5일에 개최되었습니다. 주요 목적은 두 가지였습니다:
이 세션에서는 AI BOM 관리를 위한 초안 스크래치패드에 대해 심도 있는 논의가 이루어졌습니다. AI BOM은 AI 시스템의 구성 요소를 문서화하는 중요한 도구로, 이를 효과적으로 관리하기 위한 방법론과 best practice에 대해 참가자들이 의견을 나누었습니다.
주요 논의 사항:
스터디 그룹을 정식 OpenChain 워킹그룹으로 전환하는 방안에 대해 논의가 이루어졌습니다. 이는 AI 관련 오픈소스 관리에 대한 중요성이 증가함에 따라 더욱 체계적이고 공식적인 접근이 필요하다는 인식에서 비롯되었습니다.
전환 시 고려사항:
참가자들의 질문과 그에 대한 답변이 이어졌습니다. 주요 질문들은 AI BOM의 실제 적용 사례, 법적 고려사항, 그리고 워킹그룹 전환 후의 활동 계획 등에 집중되었습니다.
이번 워크샵은 AI 기술의 오픈소스 관리에 대한 중요한 논의의 장을 제공했으며, 향후 더욱 체계적인 접근을 위한 기반을 마련했습니다.
AI 기술 관리의 중요성 인식: AI 기술이 기업 환경에 빠르게 도입됨에 따라, 오픈소스 관리 담당자들은 AI 관련 오픈소스 컴포넌트의 관리에 대한 중요성을 인식해야 합니다.
AI BOM의 도입 필요성: AI Bill of Materials (BOM)는 AI 시스템의 구성 요소를 추적하고 관리하는 데 필수적인 도구가 될 것입니다. 이는 기존의 소프트웨어 BOM 관리 경험을 AI 영역으로 확장하는 것을 의미합니다.
규제 대비: AI 기술에 대한 규제가 강화될 것으로 예상되므로, 오픈소스 관리 담당자들은 이에 대비하여 AI 관련 오픈소스 사용을 더욱 철저히 관리해야 합니다.
협업의 중요성: AI 기술의 복잡성을 고려할 때, 오픈소스 관리 담당자는 AI 개발팀, 법무팀, 보안팀 등과의 긴밀한 협력이 필요합니다.
지속적인 학습과 적응: AI 기술과 관련 오픈소스 생태계가 빠르게 변화하고 있으므로, 지속적인 학습과 적응이 필요합니다.
AI BOM 관리 체계 구축: AI 프로젝트에 사용되는 모든 오픈소스 컴포넌트를 식별하고 문서화하는 체계를 구축합니다.
AI 관련 오픈소스 정책 수립: 기존의 오픈소스 정책을 AI 기술의 특성에 맞게 업데이트합니다.
교육 및 인식 제고: 개발자와 관리자를 대상으로 AI 관련 오픈소스 사용의 특징과 주의사항에 대한 교육을 실시합니다.
AI 오픈소스 컴플라이언스 점검: AI 프로젝트에 대한 정기적인 오픈소스 컴플라이언스 점검을 실시합니다.
OpenChain AI 워킹그룹 참여: OpenChain AI 워킹그룹의 활동에 적극적으로 참여하여 최신 동향을 파악하고 best practice를 공유합니다.
AI 공급망 관리 강화: AI 모델, 데이터셋, 알고리즘 등의 출처와 라이선스를 철저히 관리합니다.
법적 리스크 평가: AI 관련 오픈소스 사용에 따른 잠재적 법적 리스크를 평가하고 대응 방안을 마련합니다.
보안 강화: AI 시스템의 보안 취약점을 식별하고 관리하는 프로세스를 구축합니다.
성과 측정 체계 수립: AI 관련 오픈소스 관리의 효과성을 측정할 수 있는 KPI를 설정하고 정기적으로 평가합니다.
이러한 action item들을 실행함으로써, 기업의 오픈소스 관리 담당자들은 AI 기술의 도입과 확산에 따른 새로운 도전에 효과적으로 대응할 수 있을 것입니다.
본 문서는 인도 컴퓨터 비상대응팀(CERT-In)이 2023년 10월에 발표한 “Technical Guidelines on Software Bill of Materials (SBOM)“의 한국어 번역본입니다.
원문은 인도의 공공 부문, 정부, 필수 서비스, 소프트웨어 수출 및 서비스 산업 관련 조직을 대상으로 SBOM 도입에 대한 기술적 지침을 제공하며, SBOM의 가치와 모범 사례를 중점적으로 다루고 있습니다.: DOWNLOAD
이 가이드라인은 한국 기업에도 다음과 같은 시사점을 제공합니다:
이 번역본이 한국의 소프트웨어 개발 및 보안 전략 수립에 실질적인 도움이 되기를 기대합니다.
Author : 장학성 (Haksung Jang) / CC BY 4.0
소프트웨어 제품은 다양한 구성 요소로 이루어져 있으며, 이 중 일부는 외부 소스에서 가져옵니다. 이러한 외부 구성 요소와 의존성에는 취약점이 있을 수 있어, 공격자가 이를 악용해 보안 사고나 침해로 이어질 수 있습니다. 주요 위협으로는 악성 코드 삽입, 오래된 구성 요소의 취약점 이용, 공급업체 침해 등이 있습니다. 이로 인해 데이터 유출, 운영 중단, 평판 손상 등의 문제가 발생할 수 있습니다. 이러한 위협에 대응하려면 소프트웨어 구축이나 개발에 사용되는 구성 요소에 대한 가시성과 투명성을 확보해야 합니다. 소프트웨어 부품 명세서(Software Bill of Materials, SBOM)는 조직이 소프트웨어나 자산에 포함된 구성 요소를 정확히 파악하여 취약점을 식별하고 수정하는 데 도움을 줍니다. SBOM을 활용하면 조직은 소프트웨어 보안을 개선하고 잠재적 위협으로부터 보호할 수 있습니다.
소프트웨어 부품 명세서(SBOM) 는 소프트웨어를 구성하는 모든 요소, 라이브러리, 모듈의 목록으로, 소프트웨어 구성에 대한 투명성을 제공합니다. 소프트웨어가 더욱 복잡해지고 외부 구성 요소에 대한 의존도가 높아짐에 따라 소프트웨어 구성을 이해하는 것이 중요해졌습니다. 사이버 보안 측면에서 소프트웨어를 공격으로부터 보호하려면 소프트웨어 구축에 사용된 의존성과 구성 요소를 파악해야 합니다. 따라서 SBOM은 현대 사이버 보안 절차에서 핵심적인 도구입니다.
SBOM은 소프트웨어 보안 유지에 필수적입니다. 이를 통해 조직은 소프트웨어의 구성 요소를 이해하고, 잠재적 위험을 관리하며, 보안 문제에 대응하고, 규정을 준수할 수 있습니다. 다음은 조직이 SBOM을 구현함으로써 얻을 수 있는 주요 이점입니다:
인도 컴퓨터 비상 대응팀(CERT-In)은 특히 공공 부문, 정부, 필수 서비스, 소프트웨어 수출 및 서비스 산업 관련 조직을 위한 기술적 SBOM 지침을 발표했습니다. 부서와 조직은 보안을 강화하고 사이버 위협의 위험을 줄이기 위해 소프트웨어 조달 및 개발 과정에서 SBOM의 생성과 제공을 의무적인 표준 관행으로 삼도록 권장됩니다.
다음 장에서는 SBOM의 다양한 기술적 측면을 살펴보고 그 목적과 소프트웨어 공급망 생태계에서의 중요성이 증가하는 이유를 설명합니다. 두 번째 장에서는 SBOM의 개요와 범위 및 구현에 대해 논의하고, 이어서 SBOM 생태계에 대한 장에서는 SBOM의 다양한 수준과 분류에 대해 설명합니다. 그 다음 장에서는 SBOM 정보를 표현하는 데 사용되는 다양한 표준과 데이터 형식을 살펴보고, 최소 요소, 데이터 필드 및 자동화 지원에 대해 자세히 설명합니다. SBOM과 관련된 모든 프로세스와 관행의 목표, 안전한 SBOM 공유 및 배포에 대해 이 문서에서 상세히 다루며, SBOM의 취약점 추적 및 분석을 위한 접근 방식도 포함됩니다. 마지막으로, 문서의 마지막 장에서는 SBOM 구현을 위한 권장 사항과 모범 사례를 소개합니다.
소프트웨어가 점점 복잡해짐에 따라 SBOM의 필요성이 더욱 커지고 있습니다. SBOM은 소프트웨어 구성 분석(SCA) 도구의 기반이 되며, 취약점 탐지, 라이선스 준수 지원, 공급업체 위험 관리에 중요한 역할을 합니다.
소프트웨어 정의 시스템의 증가로 사이버 위협 환경이 크게 확대되었습니다. 공격자들은 민감한 시스템과 데이터에 침투하기 위해 소프트웨어 공급망을 점점 더 많이 노리고 있습니다.
부서와 조직은 소프트웨어 개발 및 조달 과정에서 소프트웨어 부품 명세서(SBOM)의 생성과 제공을 표준 관행으로 삼도록 권장됩니다. 이를 통해 보안, 규정 준수, 위험 관리, 공급망 투명성, 품질 보증, 상호 운용성, 공급업체 관리를 개선할 수 있습니다.
조직은 소프트웨어 수명 주기의 모든 단계(설계, 개발, 분석, 배포, 유지 관리, 업데이트 포함)와 관련된 중요 구성 요소를 철저히 분석하고 SBOM 사용을 의무화해야 합니다.
SBOM은 다음 세 가지 주요 목적을 달성하는 데 도움을 줍니다:
모든 정부, 공공 부문, 필수 서비스 조직은 소프트웨어와 솔루션 구매/조달 요구 사항에 SBOM을 포함해야 합니다. 또한 사용자 조직의 보안 팀은 취약점 관리 작업 과정에 SBOM 목록을 반드시 포함해야 합니다.
이 가이드라인은 인도 컴퓨터 비상 대응팀(CERT-In)에서 다음과 같은 기관, 특히 정부, 공공 부문, 필수 서비스 조직 및 소프트웨어 수출과 서비스 산업 관련 조직을 위해 발행되었습니다:
SBOM은 가시성 확보, 취약점 패치, 노출 감소, 신속한 대응을 위한 필수 도구가 되고 있습니다. 예를 들어, 일반적인 조직은 상호 연결된 시스템, 엔드포인트, 제어 시스템, 자동화 소프트웨어, 운영 기술(OT) 구성 요소의 방대한 네트워크에 의존합니다. 이러한 복잡한 IT 및 OT 환경에 대한 정확한 SBOM을 유지하면 보안 팀이 공격 표면을 더 잘 이해하고 취약점에 더 효과적으로 대응할 수 있습니다. 이러한 사전 예방적 접근 방식은 조직이 운영을 보호하고 사이버 위협에 대한 복원력을 확보하는 데 도움이 됩니다.
예를 들어, 금융 기관에서 SBOM은 사이버 보안 관점에서 매우 중요합니다. 은행과 핀테크 기업은 디지털 서비스와 백엔드 시스템을 운영하기 위해 다양한 상용 제품(COTS) 소프트웨어, 오픈 소스 라이브러리, 맞춤 개발 구성 요소를 활용합니다. 이러한 다양한 소프트웨어 환경에 대해 최신 SBOM을 유지하면 보안 팀이 취약점을 신속하게 식별하고 완화하며, 산업 규정을 준수하고, 공급망 위험을 더 잘 관리할 수 있습니다.
소프트웨어 개발, 공급망 관리, 사이버 보안, 규제 준수와 관련된 SBOM의 사용 사례는 다음과 같습니다:
SBOM은 소프트웨어 시스템을 구성하는 요소와 의존성의 상세한 목록을 제공합니다. 이 정보를 통해 개발자는 취약점을 더 효과적으로 관리하고, 라이선스를 추적하며, 소프트웨어의 출처를 모니터링할 수 있습니다. 정확하고 최신 상태의 SBOM을 유지하는 것은 조직이 소프트웨어 공급망 위험을 이해하고 애플리케이션의 보안과 무결성을 보장하기 위한 사전 조치를 취하는 데 중요합니다.
SBOM은 소프트웨어 공급망에 대한 투명성을 제공하여 조직이 외부 구성 요소의 보안과 신뢰성을 평가할 수 있게 합니다. 이는 외부 라이브러리나 구성 요소 사용과 관련된 잠재적 위험을 식별하는 데 도움이 되며 조달 및 공급업체 관리에 대한 정보에 기반한 의사 결정을 용이하게 합니다.
SBOM은 기존 보안 도구와의 통합, 자동화된 취약점 탐지, 복구를 지원하며 사이버 보안 관행에서 중요한 역할을 합니다. SBOM은 소프트웨어 구성 요소와 그 의존성에 대한 가시성을 제공하여 조직이 보안 취약점을 효과적으로 식별하고 완화할 수 있게 합니다. 소프트웨어 구성에 대한 포괄적인 이해를 통해 조직은 보안 사고에 신속하게 대응하고, 취약점을 패치하며, 소프트웨어 시스템의 무결성과 보안을 보장할 수 있습니다.
SBOM은 특히 의료, 금융, 정부와 같은 필수 서비스를 다루는 산업에서 규제 준수를 위한 요구 사항이 되고 있습니다. 전 세계적으로 규제 기관들은 SBOM을 유망한 도구로 인식하고 있으며 EU 사이버 복원력 법(Cyber Resilience Act)과 같은 규정을 통해 SBOM 채택을 강조하고 있습니다.
SBOM은 소프트웨어 공급망에 대한 통찰력을 제공함으로써 위험 관리 노력을 지원합니다. 조직은 알려진 취약점, 라이선스 충돌, 더 이상 사용되지 않는 라이브러리와 같은 특정 소프트웨어 구성 요소와 관련된 잠재적 위험을 평가할 수 있습니다. 이러한 위험을 사전에 관리함으로써 조직은 소프트웨어 시스템의 복원력을 향상시키고 보안 침해나 규정 준수 문제의 가능성을 최소화할 수 있습니다.
SBOM은 소프트웨어 구성 요소와 그 버전에 대한 상세한 정보를 제공함으로써 상호 운용성 및 호환성 테스트를 용이하게 합니다. 이는 서로 다른 소프트웨어 시스템이 호환성 문제 없이 원활하게 작동할 수 있도록 보장하는 데 도움이 되며, 따라서 소프트웨어 제품의 전반적인 품질과 신뢰성을 향상시킵니다.
SBOM은 모든 새로운 소프트웨어 구성 요소 출시에 대해 구현되어야 하며, 업데이트, 업그레이드, 출시, 패치 등 변경 사항이 있을 때마다 신속하게 갱신되어야 합니다. SBOM의 정확성은 구성 요소 자체가 변경되지 않았더라도 포함된 구성 요소에 대한 새로운 정보가 있을 때마다 업데이트하여 유지됩니다. 기존 구성 요소를 수정할 때는 일관된 접근 방식을 선택하세요. 변경 사항을 새로운 구성 요소로 취급하거나 기존 구성 요소를 업데이트하는 방식 중 하나를 선택하세요. 명확성을 위해 전체적으로 표준화된 버전 관리 방법을 사용하세요.
다음과 같은 조직의 시나리오를 고려해 보겠습니다:
A. 정부 조직 GovInsights는 소프트웨어 개발 회사 TechGenius를 고용하여 데이터 분석 애플리케이션 DataAnalyzer를 개발합니다.
B. DataAnalyzer 제품을 개발하기 위해 TechGenius 회사는 다음 구성 요소를 사용합니다:
앞서 언급한 시나리오의 다양한 구성 요소/소프트웨어와 해당 SBOM 유형 및 상태는 아래 표에 제공되어 있습니다:
Table 1: 소프트웨어 구성 요소와 SBOM 작성자 현황
| 번호 | 이름 | SBOM 작성자 현황 |
|---|---|---|
| 1 | DataAnalyzer 애플리케이션에 대한 SBOM | TechGenius 회사에서 개발하여 제품/애플리케이션인 DataAnalyzer와 함께 GovInsights 조직에 제공될 예정 |
| 2 | PostgreSQL에 대한 SBOM | DataVault가 이 구성 요소에 대한 SBOM을 생성하지 않았기 때문에 TechGenius가 최상위 수준 SBOM을 개발 |
| 3 | Apache Tomcat Server 플랫폼에 대한 SBOM | ServerSolutions 회사가 배포 SBOM을 생성하여 TechGenius가 플랫폼을 조달했을 때 TechGenius와 공유 |
| 4 | Postfix & Twilio SDK에 대한 SBOM | MessageMaster가 SBOM을 제공하지 않았기 때문에 TechGenius 회사가 전이적 SBOM을 생성 |
이 시나리오에서 이해관계자와 구성 요소 간의 상호 관계는 Figure 1에 시각적으로 표현되어 있습니다. 묘사된 바와 같이, SBOM 생태계 내의 수많은 주체는 소프트웨어의 제공자와 소비자 역할을 모두 수행합니다. 이는 다른 주체가 제공한 SBOM의 정보를 활용할 뿐만 아니라 새로 개발된 구성 요소에 대한 SBOM을 생성하고 이를 다른 주체와 공유하는 것을 포함합니다. 이상적으로는 소프트웨어 구성 요소의 제작자가 해당 SBOM의 작성자가 되어야 합니다.
Figure 1: 시나리오 흐름도
SBOM 생태계는 소프트웨어 공급망 전반에 걸쳐 SBOM의 생성, 배포, 분석, 활용에 관여하는 이해관계자, 도구, 표준, 프로세스의 네트워크를 포함합니다. 이 섹션에서는 소프트웨어 소비자/개발자/시스템 통합업체 조직이 조직 수준에서 SBOM 생태계를 개발하기 위한 접근 방식을 설명합니다. 또한 SBOM의 다양한 분류에 대해 설명합니다.
SBOM의 다양한 수준은 각각 다른 정도의 세부성과 복잡성을 제공하며, 특정 요구 사항과 각 소프트웨어 환경의 복잡성을 반영합니다. 조직은 투명성, 위험 관리, 운영 효율성의 효과적인 균형을 달성하기 위해 하나 이상의 SBOM 수준을 구현하도록 선택해야 합니다.
| SBOM 수준 | 설명 |
|---|---|
| Top-Level SBOM | 제품에 통합되거나 직접 사용되는 소프트웨어 요소의 일반적인 요약을 제공합니다. 구성 요소 이름, 버전, 소프트웨어 내 상호 작용과 같은 필수 세부 정보를 포함합니다. |
| n-Level SBOM | 최상위 개요를 넘어 더 깊은 세부사항과 복잡성을 포함합니다. “N"은 임의의 깊이 수준을 나타내며, SBOM이 여러 계층 또는 세분화 수준에서 정보를 포함함을 의미합니다. |
| Delivery SBOM | 소프트웨어 출시 또는 배포 패키지의 일부인 모든 부분, 라이브러리, 의존성을 설명합니다. 이는 공급되는 소프트웨어의 구성에 대한 명확성을 제공합니다. |
| Transitive SBOM | 소프트웨어 구성 요소의 직접적인 의존성뿐만 아니라 간접적이거나 전이적인 의존성도 포함합니다. |
| Complete SBOM | 소프트웨어 시스템에 존재하는 모든 부분, 의존성, 관련 메타데이터의 완전하고 철저한 목록을 제공합니다. |
Figure 2: SBOM 수준
다중 SBOM 접근 방식을 채택하면 조직의 사이버 복원력을 크게 향상시킬 수 있습니다. 조직은 민감한 데이터를 노출하지 않고 보안 요구 사항을 해결하는 맞춤형 SBOM을 소비자를 위해 생성해야 합니다. 동시에 “완전한” 수준의 내부 SBOM을 유지하여 해당 소프트웨어와 관련된 취약점 업데이트를 식별하고 주기적으로 의무적으로 소비자와 상세히 공유해야 합니다. 이 접근 방식은 특히 조직이 완전한 소프트웨어 및 의존성 세부 정보를 공유함으로써 발생하는 데이터 유출 및 지적 재산 도용에 대한 제약이나 우려에 직면한 상황에서 생태계 전반에 걸쳐 사이버 복원력, 데이터 기밀성, 협력적 보안의 균형을 맞춥니다.
Table 2: SBOM을 작성한 조직의 시나리오에 따른 수준 매핑
| 번호 | 이름 | SBOM 수준 | SBOM 작성자 현황 |
|---|---|---|---|
| 1 | DataAnalyzer 애플리케이션에 대한 SBOM | Complete SBOM | TechGenius 회사에서 개발하여 제품/애플리케이션인 DataAnalyzer와 함께 GovInsights 조직에 제공될 예정 |
| 2 | PostgreSQL에 대한 SBOM | Top-Level SBOM | DataVault가 이 구성 요소에 대한 SBOM을 생성하지 않았기 때문에 TechGenius가 최상위 수준 SBOM을 개발 |
| 3 | Apache Tomcat Server 플랫폼에 대한 SBOM | Delivery SBOM | ServerSolutions 회사가 배포 SBOM을 생성하여 TechGenius가 플랫폼을 조달했을 때 TechGenius와 공유 |
| 4 | Postfix & Twilio SDK에 대한 SBOM | Transitive SBOM | MessageMaster가 SBOM을 제공하지 않았기 때문에 TechGenius 회사가 Transitive SBOM을 생성 |
SBOM 분류는 소프트웨어 개발 생명주기 단계와 일치하며, 각각 고유한 데이터와 통찰력을 제공합니다. SBOM의 다양한 분류는 다음과 같습니다:
Figure 3: SDLC 단계와 일치하는 SBOM 분류
조직 내 SBOM 생태계 구축은 단계적 접근이 필요합니다. 기본 토대(START)를 시작으로 발전(PROGRESS)시키고 최종적으로 성숙하고 확장 가능한 SBOM 구현(ADVANCE)에 도달해야 합니다. 활동 순서는 예시일 뿐이며, 조직의 보안 요구사항, 프로젝트 일정, 리소스 가용성에 따라 조정할 수 있습니다.
| 단계 | 활동 |
|---|---|
| START (기초 활동) | • 중요 자산 식별 및 프로젝트 계획 수립 • SBOM 형식 및 최소 요구사항 결정 • 보안 요구사항, 안전한 저장소 및 도구 식별 • 조달 과정의 일부로 SBOM 획득 |
| PROGRESS (발전) | • 안전한 설치 및 운영 지침 개발 • 각 구성 요소에 고유 식별자 할당 • 공급업체의 SBOM과 소비자의 내부 SBOM 매핑 • SBOM 준비 • 보안 소프트웨어 개발 수명주기의 각 단계에 SBOM 통합 • 안전한 구성 관리 수립 |
| ADVANCE (성숙 & 확장 가능한 SBOM) | • 취약점 추적 프로세스 강화 • 사고 대응 프로세스 강화 • 기존 SBOM의 주기적 분석 및 검토 업데이트 • 새로운 소프트웨어 구성 요소 및 산업 발전에 대한 인식 유지 |
| Figure 4: Steps & its Activities for Developing SBOM Ecosystem at Organizational Level |
이 단계의 기초 활동들은 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 통합 프로세스를 용이하게 합니다.
이 단계는 안전한 설치 및 구성 관리를 확립하고, 공급업체 및 구성 요소 네임스페이스 문제를 해결하기 위해 고유한 구성 요소 식별을 통합하는 지속적인 활동을 포함합니다. 소프트웨어 개발 조직에 의한 보안 소프트웨어 개발 수명주기(SSDLC)와의 통합은 빌드 단계에서 소프트웨어를 보호하기 위한 실행 가능한 보안 정보를 제공하기 시작할 것입니다.
3.3.2.1 안전한 설치 및 운영 지침 개발: 공급업체는 소비자 조직과 협력하여 대상 소비자의 기술 분야와 사용 요구에 맞춘 포괄적인 안전한 소프트웨어 설치 및 운영 체크리스트를 작성해야 합니다. 안전한 운영을 보장하기 위해 안전한 애플리케이션 설계, 개발, 구현 및 운영 지침에서 핵심 체크리스트 항목을 도출할 수 있으며, 이는 애플리케이션 수명 주기의 배포 및 운영 단계에서 다루어야 할 필수 고려 사항을 강조합니다.
3.3.2.2 각 구성 요소에 고유 식별자 할당: 소비자가 리브랜딩을 인식하지 못하면 보안 업데이트나 취약점을 간과할 수 있어 악용에 취약해질 수 있습니다. 이로 인해 소비자가 자체 SBOM에 포함할 정확한 데이터 필드(예: 현재 공급업체 및 구성 요소 이름)를 조사하기 어려워집니다. 공급업체 및 구성 요소 이름 변경은 SBOM 수정과 이전 SBOM에서 후속 버전으로의 링크를 통해 수정 이력을 유지해야 합니다. 이를 해결하기 위해 고유 식별자를 생성해야 합니다.
Table 3: 고유 식별자의 구문 및 예시
| 필드 | 설명 | 예시 |
|---|---|---|
| scheme | 식별자의 형식을 나타냄, 이 경우 Package URL (PURL) 형식의 pkg | pkg |
| type | 식별자의 유형을 지정, 이 경우 소프트웨어 구성 요소의 공급업체를 나타내는 supplier | supplier |
| namespace | 소프트웨어 구성 요소의 공급업체인 조직 또는 주체의 이름을 식별 | Apache Software Foundation |
| name | 소프트웨어 구성 요소 자체의 이름을 제공 | Apache Tomcat |
| version | 소프트웨어 구성 요소의 특정 버전을 나타냄 | 9.0.71 |
| qualifiers (선택사항) | 아키텍처, 운영 체제 또는 기타 메타데이터와 같은 소프트웨어 구성 요소에 대한 추가 맥락 정보 포함 가능 | arch=x86_64&os=linux |
| subpath (선택사항) | 해당되는 경우 소프트웨어 구성 요소 내의 하위 경로 또는 위치를 지정하는 데 사용 가능 | #server/webapps |
위 시나리오에 대한 고유 식별자는 다음과 같습니다: pkg:supplier/ApacheSoftwareFoundation/ApacheTomcat@9.0.71?arch=x86_64&os=linux#server/webapps
Table 4: 고유 식별자의 유용성
| 문제 | Apache Tomcat 예시 | 고유 식별자가 도움이 되는 방법 |
|---|---|---|
| 소유권 및 브랜딩 변경 | • 초기에 Apache Tomcat은 Apache Software Foundation에서 개발 및 유지 관리했습니다. • 시간이 지나면서 소유권이 변경될 수 있고, 새 소유자가 프로젝트를 리브랜딩할 수 있습니다(예: “TomcatX” 또는 “Acme Tomcat”). | • pkg:supplier/Apache Software Foundation/Apache Tomcat@9.0.71?arch=x86_64&os=linux 식별자는 소유권 및 브랜딩 변경에도 여전히 유효합니다. • 소비자는 SBOM을 새 식별자 pkg:supplier/Acme Corp/TomcatX@9.0.71?arch=x86_64&os=linux로 업데이트하여 이전 및 새 구성 요소 이름 간의 연결을 유지할 수 있습니다. |
| 버전 모호성 | • 공급업체가 Apache Tomcat의 새 버전(예: 10.0.0)을 출시하지만 동일한 구성 요소 이름을 유지합니다. | • 고유 식별자 pkg:supplier/Apache Software Foundation/Apache Tomcat@9.0.71?arch=x86_64&os=linux는 특정 버전(9.0.71)을 명확히 나타냅니다. • 새 버전이 출시되면 소비자는 SBOM을 pkg:supplier/Apache Software Foundation/Apache Tomcat@10.0.0?arch=x86_64&os=linux로 업데이트하여 버전 모호성을 제거할 수 있습니다. |
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의 안전한 구성 관리를 보장하기 위해 엄격한 접근 제어, 암호화, 주기적인 소프트웨어 감사 및 보안 프레임워크와의 통합을 구현합니다.
취약점 모니터링과 취약점 관리 및 사고 대응을 위한 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 인식 프로그램을 유지하도록 권장됩니다.
라이선스 관리는 SBOM의 초기 활용 사례 중 하나입니다. 이는 복잡한 소프트웨어 포트폴리오를 가진 큰 조직이 다양한 소프트웨어 구성 요소의 라이선스와 조건을 추적하는 데 도움을 줍니다. 특히 오픈 소스 소프트웨어에 대해 중요합니다. SBOM은 각 구성 요소의 라이선스 정보를 제공할 수 있어, 사용자가 법적 위험 없이 해당 소프트웨어를 다른 애플리케이션의 구성 요소로 사용할 수 있는지 판단할 수 있게 합니다. 소프트웨어에 포함된 구성 요소의 라이선스 정보를 확인하면 규정 준수 실수를 방지하고, 라이선스 위반 위험과 관리에 필요한 노력을 줄일 수 있습니다.
다음은 라이선스 관리 과정을 간소화하고 규정 미준수 위험을 줄이는 데 도움이 되는 방법들입니다:
사용자가 평가 중인 제품의 라이선스와 모든 개별 구성 요소의 라이선스를 볼 수 있어야 합니다. 이를 통해 사용자는 제품 선택과 비즈니스 요구에 맞는 라이선스 계약 결정에 더 나은 판단을 할 수 있습니다.
SPDX 식별자와 같은 식별자로 각 소프트웨어 라이선스를 구분합니다. 이 식별자들은 특정 라이선스 조건을 나타내는 고유 코드 역할을 합니다. 조직은 이를 활용해 소프트웨어 자산의 라이선스 의무를 효과적으로 관리하고 이해해야 합니다.
주요 데이터베이스에서 라이선스 식별자를 찾을 수 없다면, Scancode, LicenseDB, AboutCode 같은 다른 라이선스 데이터베이스를 살펴봐야 합니다. 이런 대체 식별자에는 출처를 나타내는 접두사(예: “LicenseRef-scancode-")를 붙여 쉽게 파악하고 이해할 수 있게 해야 합니다.
SPDX 같은 잘 알려진 목록에 없는 라이선스를 만나면, 조직은 고유한 식별자를 부여해야 합니다. 이렇게 하면 시스템 내에서 알려지지 않은 라이선스를 제대로 식별하고 추적할 수 있습니다.
라이선스를 자리 표시자나 템플릿으로 수정할 때는 기본 조건이 바뀌지 않도록 주의해야 합니다. 대신 SPDX 라이선스 표현 같은 고유 식별자로 구분되는 원본 라이선스의 일부로 봐야 합니다. 이는 라이선스 관리의 명확성과 일관성을 유지하는 데 도움이 됩니다.
소프트웨어에 여러 라이선스가 적용될 때는 연산자(예: SPDX 연산자)를 사용해 올바르게 조합하는 것이 중요합니다. 이 연산자들은 서로 다른 라이선스 식별자를 연결해 라이선스 표현의 명확성과 일관성을 보장합니다. 이를 통해 소프트웨어에 적용되는 라이선스 조건을 정확히 나타낼 수 있습니다.
라이선스 관리 시 라이선스 텍스트에 붙은 예외 조항은 “WITH” 같은 적절한 연산자를 써서 주 라이선스 식별자와 연결해야 합니다. 또한 예외 조항 이름은 라이선스 식별에 대한 정해진 요구 사항에 따라 식별자로 설명되어야 합니다.
라이선스 텍스트를 조금 바꿀 때, 수정 내용이 원본 라이선스의 의미를 크게 바꾸지 않는다면 원본 라이선스와 같은 식별자를 쓰는 것이 좋습니다.
SBOM의 최소 요소는 소프트웨어 구성 요소와 관련된 필수 정보인 “Data Fields"를 규정합니다. “Automation Support” 탐지 및 관리는 보안 오케스트레이션 도구와 조직의 SBOM 구현을 위한 “Process 및 Practice"와 통합하여 개선될 수 있습니다. “Minimum Elements"의 범주와 정의는 다음과 같습니다.
Table 5: SBOM의 최소 요소
| 최소 요소 | 개요 | 정의 |
|---|---|---|
| Data Fields | 추적해야 할 각 구성 요소에 대한 기본 정보를 문서화 | 이 기본 구성 요소 정보는 다음을 포함합니다: • Component Name • Component Version • Component Description • Component Supplier • Component License • Component Origin • Component Dependencies • Vulnerabilities • Patch Status • Release Date • End-of-Life (EOL) Date • Criticality • Usage Restrictions • Checksums or Hashes • Comments or Notes • Author of SBOM Data • Timestamp • Executable Property • Archive Property • Structured Property • Unique Identifier |
| Automation Support | 소프트웨어 생태계 전반에 걸쳐 확장할 수 있도록 자동 생성 및 기계 판독성을 포함한 자동화 지원 | SBOM을 생성하고 사용하는 데 활용되는 데이터 형식은 다음을 포함합니다: • Software Package Data Exchange (SPDX) • CycloneDX |
| Practices and Processes | SBOM 요청, 생성 및 사용의 운영을 정의 | 조직의 SBOM 운영 절차 정의는 다음을 기반으로 해야 합니다: • Frequency • Depth • Known Unknowns • Distribution and Delivery • Access Control • Accommodation of Mistakes |
Data fields는 추적하고 유지해야 하는 각 구성 요소에 대한 기본 정보를 포함합니다. 조직은 소프트웨어 구성 요소, dependency, 관련 메타데이터의 포괄적인 목록을 만들어 소프트웨어 개발 수명 주기 전반에 걸쳐 더 나은 투명성, 보안 및 위험 관리를 가능하게 할 수 있습니다.
Data fields의 목적은 이러한 구성 요소를 적절히 식별하는 것입니다. 이를 통해 소프트웨어 공급망 전반에 걸쳐 추적이 쉬워지고 취약점이나 라이선스 데이터베이스 같은 다른 유용한 데이터 소스와 연결할 수 있습니다. 기본 구성 요소 정보는 다음을 포함합니다:
Table 6: 조직별 시나리오에서 활용된 Component의 Data Fields
| Component Name | Apache Tomcat | PostgreSQL | Postfix | Twilio SDK |
|---|---|---|---|---|
| Version | 9.0.41 | 13.3 | 3.5.6 | 7.17.0 |
| Description | 오픈소스 Java 웹 서버 | 오픈소스 관계형 데이터베이스 관리 시스템 | 오픈소스 메일 전송 에이전트(MTA) | SMS 송수신을 위한 Twilio API SDK |
| Supplier | Apache Software Foundation | PostgreSQL Global Development Group | Postfix Development Team | Twilio Inc. |
| License | Apache Software Foundation | PostgreSQL License | IBM Public License v1.0 | Apache License 2.0 |
| Origin | Apache License 2.0 | Open-source community | Open-source community | Vendor |
| Dependencies | Open-source community | None | None | None |
| Vulnerabilities | Java Runtime Environment (JRE) | None reported | None reported | None reported |
| Patch Status | None reported | Up to date | Up to date | Up to date |
| Release Date | Up to date | May 7, 2021 | October 15, 2020 | January 10, 2022 |
| End of Life Date | March 22, 2021 | May 7, 2026 | October 15, 2025 | January 10, 2027 |
| Criticality | March 22, 2025 | High | High | Medium |
| Usage Restrictions | High | None | None | Twilio 계정이 필요한 API 접근 |
| Checksums | None | SHA-256: d7f5a6b198e75c1f38d0fa158a9bc92 | SHA-256: 3bd5a7f02a81022a47a7e6cb9cb5e2b8 | SHA-256: 9f3b2e5ab24a5e68a3bda6a12c1febd1 |
| Hashes | SHA-256: 7f87a8b8ed5c23546789b8d758621 9a1 | MD5: b8c78139eef440fb3cb074e199b1e923 | MD5: e57cb8d0ae875fda9d60291f10689e4b | MD5: 6a8c4db98ce5f0c3a92416727bc80a5e |
| Comments | MD5: 8937d8b1a947f45d79e457b91c2e6543 | SQL 쿼리와 ACID 트랜잭션을 지원 | 메일 서버 간 이메일 전송을 용이하게 함 | Twilio의 클라우드 통신 플랫폼을 통해 애플리케이션에 SMS 기능을 통합 |
| Executable Property | Yes - catalina.sh와 startup.bat 같은 실행 가능한 바이너리 포함 | No - postgres와 같은 바이너리는 직접 실행할 수 없음 | No - postfix와 같은 바이너리는 직접 실행할 수 없음 | No - SDK 자체는 직접 실행할 수 없으나, 애플리케이션에서 사용할 수 있는 library와 module 포함 |
| Archive Property | No - 디렉토리 구조로 배포 | No - postgresql.conf를 포함한 설치 파일 세트로 배포 | No - main.cf를 포함한 설치 파일 세트로 배포 | Yes - twilio-python.tar.gz 또는 twilio-java.jar와 같은 패키지나 library 아카이브 파일로 배포 |
| Structured Property | Yes - server.xml과 같은 설정 파일에 정의된 요소 있음 | Yes - schema.sql과 같은 파일에 구조화된 데이터베이스 스키마 포함 | Yes - main.cf와 master.cf와 같은 설정 파일에 구조화된 형식 포함 | Yes - twilio.py 또는 twilio.xml과 같은 API 메소드와 설정을 정의하는 구조화된 파일 포함 |
| Unique Identifier | pkg:supplier/ApacheSoftwareFoundation/ApacheTomcat@9.0.71?arch=x86_64&os=linux#server/webapps | pkg:supplier/PostgreSQLGlobalDevelopmentGroup/PostgreSQL@13.5?arch=x86_64&os=linux | pkg:supplier/PostfixFoundation/Postfix@3.6.2?arch=x86_64&os=linux | supplier/TwilioInc/TwilioSDK@1.20.0?arch=x86_64&os=linux |
자동 생성 및 기계 판독성과 같은 자동화 지원은 소프트웨어 생태계와 조직 경계를 넘어 확장을 가능하게 합니다. SBOM 데이터를 다양한 도구와 프로세스에 원활하게 통합하여 소프트웨어 공급망 전반에 걸친 협업과 가시성을 촉진합니다.
| 자동화 기능 | 설명 |
|---|---|
| Component Discovery | 자동화된 도구는 소프트웨어 패키지, repository 및 소스 코드를 스캔하여 구성 요소를 식별하고 카탈로그화할 수 있습니다. 이는 수동 개입 없이 구성 요소의 초기 목록을 생성하는 데 도움이 됩니다. |
| Version Tracking | 자동화 도구는 소프트웨어 repository와 패키지 관리자를 모니터링하여 소프트웨어 구성 요소의 변경 사항과 업데이트를 추적할 수 있습니다. 이는 SBOM이 구성 요소의 최신 버전으로 유지되도록 보장하여 오래되거나 취약한 소프트웨어를 사용할 위험을 줄입니다. |
| Dependency Analysis | 자동화된 dependency 분석 도구는 소프트웨어 구성 요소 간의 dependency를 자동으로 식별하고 문서화할 수 있습니다. 이는 복잡한 관계를 이해하고 변경이나 취약점의 잠재적 영향을 평가하는 데 도움이 됩니다. |
| Vulnerability Assessment | 자동화된 취약점 스캐닝 도구는 소프트웨어 구성 요소를 NVD(National Vulnerability Database) 또는 CVE(Common Vulnerabilities and Exposures)와 같은 알려진 취약점 데이터베이스와 대조하여 분석할 수 있습니다. |
| License Compliance | 자동화된 라이선스 스캐닝 도구는 소프트웨어 구성 요소를 분석하여 배포되는 라이선스를 식별할 수 있습니다. 이는 라이선스 요구사항 compliance를 보장하고 독점 또는 오픈소스 소프트웨어의 무단 사용과 관련된 법적 문제를 방지하는 데 도움이 됩니다. |
| SBOM Generation | 자동화된 SBOM 생성 도구는 소프트웨어 repository, 패키지 매니페스트 및 취약점 데이터베이스와 같은 다양한 소스에서 정보를 수집하여 포괄적인 SBOM을 자동으로 생성할 수 있습니다. 이는 SBOM 생성 과정을 간소화하고 여러 프로젝트에 걸쳐 일관성과 정확성을 보장합니다. |
| Integration with DevOps Pipelines | 자동화 도구는 SBOM 생성과 분석을 DevOps pipeline에 통합하여 개발 수명 주기 전반에 걸쳐 소프트웨어 구성 요소의 지속적인 모니터링과 평가를 가능하게 할 수 있습니다. 이를 통해 보안 위험과 compliance 문제를 사전에 식별하고 완화할 수 있습니다. |
| Reporting and Visualization | 자동화된 보고 및 시각화 도구는 SBOM 데이터에서 실행 가능한 통찰력을 생성할 수 있습니다. 예를 들어 고위험 구성 요소 식별, compliance 상태 추적 및 dependency 그래프 시각화가 있습니다. 이는 이해관계자가 위험 완화 및 개선을 위한 정보에 입각한 결정을 내리고 우선순위를 정하는 데 도움이 됩니다. |
| Integration with Security Orchestration Platforms | 자동화 도구는 보안 오케스트레이션 플랫폼과 통합하여 SBOM 분석 결과를 기반으로 수정 워크플로우를 자동화할 수 있습니다. 이를 통해 보안 취약점을 완화하기 위한 패치, 업데이트 또는 구성 변경의 자동 배포가 가능합니다. |
| Monitoring and Maintenance | 자동화 도구는 구성 요소 정보 업데이트, 변경 사항 추적 및 이상이나 compliance 위반에 대한 경고 생성을 통해 SBOM의 지속적인 모니터링과 유지 관리를 용이하게 할 수 있습니다. |
Figure 5: SBOM의 Automation Support 이점
SBOM 데이터를 활용하기 위해서는 일관된 데이터 형식과 구현이 필요한 도구가 필요합니다. 자동화는 SBOM의 생성, 유지 관리 및 활용의 여러 측면을 지원할 수 있습니다. 이는 일관성 있는 변경 사항 구현, 시간 절약, 취약점 관리 개선 등 다양한 이점을 제공합니다. 자동화된 SBOM 생성은 감사 및 규정 준수 절차를 간소화하고 보안 취약점에 대한 대응 시간을 단축시킵니다. 조직은 이 기능을 현재의 취약점 관리 절차와 보안 정책의 실시간 감사 compliance에 포함할 수 있습니다. 두 가지 모두 표준화된 기계 판독 가능한 데이터 형식을 필요로 하는 자동화에 크게 의존합니다. SBOM을 생성하고 사용하는 데 사용되는 표준 형식은 다음과 같습니다:
이 섹션에서는 실무자들이 SBOM을 어떻게 인식해야 하며, 실제로 이를 다루기 위해 어떤 프로세스를 수립해야 하는지 논의합니다. 이 장에서 언급된 주제들은 SBOM 생성, 배포 및 공유, 검증 및 확인, 취약점 및 악용 가능성 관리와 같은 SBOM 관행의 분석에서 도출되었습니다.
SBOM을 구현하기 위해서는 필요한 역할과 책임을 식별해야 합니다. 여기에는 관리 후원자, 프로젝트 리더, 시스템 엔지니어, 설계 엔지니어, 조달 전문가 및 운영 담당자가 포함되어야 합니다. 프로젝트 일정과 보안 요구사항에 따라 IT, 사이버보안 및 유지보수 인력과 같은 추가 지원을 포함시켜야 합니다. 이러한 역할들 간의 명확한 소유권과 협력을 보장하여 SBOM 구현과 기존 프로세스와의 통합을 추진해야 합니다.
Figure 6: 역할 및 책임 수립 단계
주요 이해관계자 식별: SBOM 프로그램의 주요 이해관계자를 식별하기 위해 조직은 소프트웨어 개발, IT 운영, 보안, 조달, 비즈니스 리더십, compliance 팀 및 규제 기관의 대표자를 고려해야 합니다. 보안 데이터 처리, 취약점 관리 및 위험 평가에 대한 전문 지식을 제공하기 위해 사이버보안 전문가를 포함해야 합니다.
SBOM 관련 책임 정의: SBOM 생성, 소비, 취약점 모니터링, supplier 참여 및 보안 데이터 관리와 같은 작업을 설명합니다. 다음과 같은 사이버보안 중심의 책임을 할당합니다: 민감도와 위험에 따른 SBOM 데이터 분류, 보안 SBOM 저장소 및 접근 제어 구현, 취약점 관리 및 사고 대응 프로세스와 SBOM 데이터 통합.
역할 및 소유권 할당: 사이버보안 전문가를 SBOM 프로그램 소유자 또는 공동 소유자로 지정하여 전반적인 보안이 보장되도록 합니다. 사이버보안 팀이 핵심 역할을 수행하면서 이해관계자의 전문성을 기반으로 SBOM 책임을 할당합니다.
거버넌스 수립: 거버넌스 구조는 첫 번째 포인트에서 논의된 대로 조직 전반의 주요 이해관계자를 포함해야 합니다. 이 거버넌스 기구는 SBOM 관련 정책, 표준, 프로세스를 개발하고 명확한 책임을 할당하며, SBOM 데이터를 보호하기 위한 통제를 구현합니다.
협업 활성화: 소프트웨어, IT 및 사이버보안 팀 간의 부서 간 협업을 촉진하여 SBOM 보안 과제를 해결합니다. 보안 SBOM 관행, 새로운 위협 및 최고 수준의 보안 통제에 대한 지식 공유를 장려합니다.
교육 및 리소스 제공: SBOM 보안 요구사항, 보안 데이터 처리 및 SSDLC의 각 단계와 SBOM 통합에 대한 전문 교육을 제공합니다. 팀에 보안 SBOM 생성, 저장 및 소비 도구와 취약점 관리 및 위협 인텔리전스 리소스를 제공합니다.
모니터링 및 개선: 조직은 정기적인 감사와 평가를 수행해야 합니다. 여기에는 SBOM 프로그램의 보안 태세를 지속적으로 평가하고 진화하는 위협과 compliance 요구사항을 해결하기 위한 조정이 포함되어야 합니다.
이 섹션에서는 SBOM의 세 가지 주요 측면인 관행, 도구 지원 및 관련 문제의 목표를 탐구합니다. 이를 통해 소프트웨어 Developer/Consumer/Integrator 조직에게 다양한 기능을 탐색하고 SBOM의 특정 측면에서 실제로 달성해야 할 사항에 대한 로드맵을 제공합니다.
Table 7: SBOM 개념의 목표
| SBOM Functions | 목표 |
|---|---|
| Benefits | • SBOM의 주요 이점은 소프트웨어 제품에 대한 향상된 투명성과 가시성이어야 하며, 이는 잠재적인 SBOM 중심 생태계의 기반이 됩니다. • SBOM의 장점은 SBOM과 지원 도구의 학습 및 관리와 관련된 비용보다 커야 합니다. |
| Adoption | • third-party(오픈소스 또는 독점) component에는 SBOM이 갖춰져 있어야 합니다. • 조직 내의 모든 소프트웨어 제품(생산/사용)에 대해 SBOM이 생성되어야 합니다. |
| Generation Points | • SBOM은 소프트웨어 개발 수명 주기의 다양한 단계에서 생성되어야 합니다. • 소프트웨어 산출물에 변경이 있을 때마다 새로운 SBOM이 항상 재생성되어야 합니다. |
| Data Fields & standardization | • SBOM은 기존의 최소 요소 수와 표준 형식 외에도 데이터 필드와 형식 측면에서 조직별 특정 사용 사례로 사용자 정의되어야 합니다. |
| Distribution | • 내부 사용을 위한 SBOM을 생성하고 적절한 접근 제어를 보장하며, 독점 소프트웨어나 component를 배포할 때는 부분 SBOM 공유를 위한 콘텐츠 조정을 고려합니다. |
| Validation | • supplier는 SBOM의 무결성을 보장하기 위해 검증해야 합니다. |
| Vulnerability & Exploitability | • supplier는 consumer 조직에 Vulnerability Exchange Document를 제공해야 합니다. |
| Tools | • SBOM 소비를 취약점 또는 구성 관리 시스템과 같은 현재 도구와 통합합니다. |
SBOM 데이터를 안전하게 통합하고 관리하려면 명확한 조건이 정의되어야 합니다. 이러한 조건은 라이선싱, 계약, 또는 소프트웨어 사용 및 권한 관리를 위한 기존 메커니즘을 통해 수립될 수 있습니다. supplier(오픈소스 관리자 포함)는 public SBOM 데이터를 선호할 수 있지만, 일부는 기밀성을 유지하며 특정 사용자에게만 접근을 제한할 수 있습니다. 이러한 단계를 통해 조직은 SBOM의 안전하고 통제된 배포를 구현하여 민감한 정보가 승인된 당사자에게만 접근 가능하도록 하면서도 소프트웨어 공급망의 투명성과 신뢰를 유지할 수 있습니다.
소프트웨어 공급망의 투명성, 보안 및 compliance를 높이기 위해서는 supplier와 사용자 간에 SBOM을 공유하는 것이 필요합니다.
조직 내부에서 SBOM 문서를 공유하면 development, security, operations 및 법률 팀이 프로젝트에서 사용되는 소프트웨어 구성 요소와 dependency에 대한 통찰력을 얻을 수 있습니다. 이는 투명성을 촉진하고 협업을 강화하며 라이선싱 및 보안 요구사항의 compliance를 용이하게 합니다.
SBOM 문서 공유는 외부 partner, supplier 및 vendor 간의 신뢰를 높이는 데도 기여하며, 소프트웨어 제품이나 시스템 내에서 구현된 구성 요소, 라이선싱, 보안 조치에 대한 감사 가능한 증거를 제공합니다.
SBOM 문서 공유는 다음과 같은 채널과 형식을 통해 촉진됩니다:
문서를 공유할 때는 클라이언트가 진위성을 확인하고 변조 여부를 검증할 수 있도록 디지털 서명을 첨부하는 것이 권장됩니다. 또한, 어떤 정보를 public 또는 private으로 설정해야 하는지 명확히 식별하는 것이 중요합니다.
이 챕터에서는 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는 특정 소프트웨어 제품의 취약점 상태에 대해 다음 사항을 포함해야 합니다:
b) Common Security Advisory Framework (CSAF) 채택: VEX document 이후에 supplier는 취약점에 대한 설명, 영향을 받는 제품 버전, 심각도 평가 및 권장되는 완화 단계와 같은 자세한 정보가 포함된 CSAF 권고사항을 제공해야 합니다. 이는 다음 예시를 통해 이해할 수 있습니다:
Figure 7: SBOM의 취약점 추적 및 분석 단계 시퀀스 예시
Log4j 취약점은 위 그림에 설명된 개념을 매핑하고 설명하는 예시로 사용됩니다:
c) 다양한 취약점 데이터베이스 및 권고사항과의 통합: supplier와 consumer는 SBOM 데이터를 취약점 데이터베이스, CERT-In 취약점 노트, 경고, 위협 인텔리전스 플랫폼 및 vendor별 권고사항과 통합하여 소프트웨어의 보안 상태에 대한 포괄적인 가시성을 확보할 수 있습니다. supplier는 SBOM 데이터를 직접 통합하여 구성 요소를 알려진 취약점에 매핑한 다음 향상된 SBOM을 customer에게 제공합니다. consumer는 API, 데이터 피드 또는 수동 프로세스를 활용하여 SBOM을 취약점 데이터와 통합함으로써 수정 작업을 식별하고 우선순위를 정할 수 있습니다.
d) Shift-left 접근 방식 및 취약점 스캐닝 구현: supplier는 보안 도구를 소프트웨어 개발 pipeline에 통합하여 shift-left 취약점 스캐닝을 구현해야 합니다. 이는 빌드 및 패키징 단계와 같은 SDLC의 초기 단계에서 소프트웨어 구성 요소의 취약점을 식별하기 위해 SBOM 데이터를 자동으로 분석하는 것을 포함합니다.
이 챕터에서는 소프트웨어 공급망 보안을 강화하기 위해 SBOM을 효과적으로 관리하기 위한 실용적인 권장사항과 모범 사례를 다룹니다.
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는 특정 소프트웨어 제품의 취약점 상태에 대해 다음을 포함해야 합니다:
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.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 주요 구성 요소가 서로 다른 메타 정보를 가진 여러 인스턴스에 의존하는 경우, 각 인스턴스는 개별 메타 정보와 함께 별도로 나열되어야 합니다.
일시: 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 도입을 고민하는 실무자들에게 실질적인 인사이트를 제공하고자 합니다.
이번 미팅의 하이라이트는 단연 Thomas Graf의 발표였습니다. 지멘스는 수만 개의 소프트웨어 컴포넌트와 하드웨어 제품을 다루는 복잡한 공급망을 가진 기업입니다. 그들이 어떻게 SBOM을 표준화하고 관리하는지에 대한 내용은 대규모 조직에게 훌륭한 레퍼런스가 됩니다.
지멘스는 거대한 조직 특성상 수많은 부서가 각기 다른 도구와 언어를 사용합니다. 이를 통합하기 위해 그들은 ‘지멘스 표준 BOM’이라는 개념을 도입했습니다.
Thomas Graf는 SBOM을 하나의 거대한 퍼즐에 비유했습니다. 하나의 완벽한 SBOM이 뚝딱 만들어지는 것이 아니라, 여러 출처의 데이터를 조립해야 비로소 전체 그림이 보인다는 것입니다.
“모든 팀은 다르다(Nearly every team is different).“라는 현실적인 문제 앞에서 지멘스는 ‘중앙집중식 강제’보다는 ‘도구 제공’에 초점을 맞춥니다.
발표 이후 이어진 Q&A 세션에서는 전 세계 실무자들의 날카로운 질문들이 이어졌습니다. (미팅 영상 참조: YouTube 링크)
주요 논의 주제는 다음과 같았습니다:
이러한 논의들은 SBOM이 단순한 ‘문서’가 아니라, 보안 및 컴플라이언스 대응을 위한 ‘살아있는 데이터’로 다뤄져야 함을 재확인시켜 주었습니다.
미팅의 마지막 순서로 의장(Chair)의 업데이트가 있었습니다. OpenChain SBOM Work Group은 현재 “대규모 공급망에서의 SBOM 운영"이라는 난제를 해결하기 위해 스터디 그룹을 운영하고 있습니다.openchainproject
이 스터디 그룹은 단순히 이론을 공부하는 것이 아니라, 실제 기업들이 겪는 문제를 공유하고 해결책을 모색하는 실무 중심의 모임입니다. 누구나 참여할 수 있으며, 여러분의 경험이 생태계의 표준이 될 수 있습니다.
관심 있는 분들은 아래 채널을 통해 지난 자료를 확인하거나 향후 미팅에 참여할 수 있습니다.
2025년 11월 미팅은 SBOM이 규제 준수를 위한 ‘숙제’에서, 소프트웨어 공급망 투명성을 확보하는 ‘핵심 인프라’로 진화하고 있음을 보여주었습니다. 지멘스의 사례처럼, 이제는 “어떻게 표준화된 포맷으로, 자동화된 파이프라인 안에서 SBOM을 굴릴 것인가"를 고민해야 할 때입니다.
by Gemini 3.0
작성일: 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을 만들고 규제에 대응할 것인가?“에 대한 구체적인 가이드라인 작업 현황이 공개되었습니다.
미팅에 직접 참석하지 못하셨더라도 이 글을 통해 현재 논의되고 있는 핵심 아젠다와 향후 방향성을 충분히 이해하실 수 있도록 상세히 정리했습니다.
이번 10월 미팅의 핵심은 단연 ‘SBOM 품질 가이드(Guide to SBOM Quality)‘의 구체화였습니다. 단순히 이론적인 논의에 그치지 않고, 실제 법적 규제와 SBOM 데이터 요소를 매핑(Mapping)하는 실무적인 작업이 진행되고 있음을 확인할 수 있었습니다.
미팅의 대부분은 현재 작성 중인 ‘OpenChain SBOM Document Quality Guide’의 진척 상황을 공유하고 토론하는 데 할애되었습니다. 현재 이 문서는 구글 닥스(Google Docs)를 통해 공동 편집되고 있으며, 추후 마크다운(Markdown) 포맷으로 변환되어 GitHub에 공식 배포될 예정입니다.
이번 미팅에서 가장 주목해야 할 부분은 Chapter 6의 업데이트입니다. 워크 그룹은 전 세계적으로 강화되고 있는 사이버 보안 규제와 가이드라인을 실제 SBOM 데이터 필드와 연결하는 작업을 진행했습니다.
단순한 텍스트 나열을 넘어, 시각적인 이해를 돕기 위한 부록(Appendix 1) 업데이트도 있었습니다.
지난 9월, OpenChain 이사회(Board)는 기존의 SBOM 스터디 그룹을 ‘워크 그룹(Working Group)‘으로 승격시켰습니다. 이는 해당 모임이 단순한 학습이나 정보 공유를 넘어, 실질적인 표준과 가이드라인을 생산하는 조직으로 인정받았음을 의미합니다. 이에 따라 10월 미팅부터는 공식적으로 변경된 그룹 명칭이 사용되었습니다.
워크 그룹의 활동을 외부에 더 널리 알리고 참여를 독려하기 위해, OpenChain 프로젝트는 앰배서더 프로그램을 도입했습니다. 이번 미팅에서는 SBOM 워크 그룹을 위해 두 명의 앰배서더가 활동하게 되었음을 공지했습니다. 이들은 향후 메일링 리스트와 소셜 미디어를 통해 워크 그룹의 성과를 전파하는 역할을 맡게 됩니다.
다가오는 11월 중순에는 자동차 산업에 특화된 별도의 미팅이 예정되어 있습니다.
OpenChain SBOM 워크 그룹은 모든 과정이 투명하게 공개되며, 누구나 참여할 수 있습니다. “대규모 공급망에서 SBOM을 어떻게 실제로 운영(Production)할 것인가?“라는 난제를 함께 풀어나가고 싶다면 아래 채널을 참고해 주세요.
이번 10월 미팅은 SBOM 논의가 ‘생성(Generation)‘의 단계를 지나 ‘품질(Quality)과 규제 준수(Compliance)‘의 단계로 깊어지고 있음을 보여주었습니다.
단순히 SBOM 파일을 만들어내는 것만으로는 충분하지 않습니다. 그 SBOM이 “규제가 요구하는 필수 요소를 포함하고 있는가?”, “누가 그 데이터의 정확성을 책임지는가?“에 대한 답을 내릴 수 있어야 합니다. 현재 워크 그룹이 작성 중인 ‘품질 가이드’는 바로 이 질문에 대한 해답이 될 것입니다.
by Gemini 3.0
source: https://openchainproject.org/news/2024/12/04/sbom-study-group-2024-11-27
이 블로그 포스트는 OpenChain Project의 SBOM Study Group 웨비나에서 발표된 “취약점과 미래 - 다층적 소프트웨어 취약점과 대응 전략"에 대한 내용을 다룹니다. 이 웨비나는 소프트웨어 공급망 보안과 취약점 관리의 중요성을 강조하며, 현재의 도전과제와 미래의 전략을 탐구합니다.
발표자인 Okada San은 OWASP Japan의 전문가로, 일본 기업에서 애플리케이션 보안 강화와 소프트웨어 생산성 팀을 지원하는 보안 연구원입니다. OWASP 재단의 평생 회원으로, 20년 이상 다양한 문서 번역 작업에 참여해 왔습니다.
이 웨비나는 소프트웨어 취약점의 다층적 특성과 이에 대한 효과적인 대응 전략을 다룹니다. 특히 Software Bill of Materials (SBOM)의 중요성과 CycloneDX와 같은 표준의 역할에 초점을 맞춥니다. 또한 오픈소스 소프트웨어의 보안 성숙도와 공급망 위험에 대해 심도 있게 논의합니다.
SBOM은 소프트웨어 구성 요소의 투명성을 제공하는 중요한 도구입니다. Okada San은 SBOM이 단순히 형식이 아닌 소프트웨어 구성과 투명성에 대한 정보를 교환하는 방법이라고 강조합니다. CycloneDX와 SPDX와 같은 표준은 이러한 정보 교환을 위한 프레임워크를 제공합니다.
Okada San은 소프트웨어 공급망의 세 가지 주요 위험 지점을 설명합니다:
이러한 위험은 typosquatting과 같은 공격 기법을 통해 악용될 수 있으며, 이는 오픈소스 저장소의 보안 중요성을 강조합니다.
Open Source Security Foundation (OpenSSF)의 보고서에 따르면, 전문가의 약 3분의 1이 안전한 소프트웨어 개발 관행에 익숙하지 않다고 합니다. 이는 오픈소스 프로젝트의 보안 성숙도 향상이 시급함을 시사합니다.
Okada San은 취약점 해결을 위한 여러 전략을 제시합니다:
Software Heritage 프로젝트는 다양한 저장소의 아카이브를 제공합니다. 이 프로젝트를 통해 개발자의 기여 이력과 패치의 품질을 추적할 수 있어, 프로젝트나 개발자의 신뢰성을 평가하는 데 유용합니다.
Okada San은 CycloneDX의 주요 도전과제를 다음과 같이 설명합니다:
Q: 일본 외 다른 지역의 OWASP 지부가 있나요? A: 네, 전 세계에 많은 OWASP 지부가 있습니다. 월간 또는 분기별 모임을 통해 애플리케이션 보안 전문가들과 쉽게 교류할 수 있습니다.
Q: Software Heritage를 어떻게 활용하고 있나요? A: 저는 주로 Protestware와 관련된 개발자를 추적하고, 그들이 다른 프로젝트에 기여하는지 확인하는 데 사용했습니다. 이를 통해 다른 위험 요소들도 발견할 수 있었습니다.
Okada San은 소프트웨어 투명성과 보안의 중요성을 강조하며 발표를 마무리합니다. 그는 모든 참가자들에게 CycloneDX 커뮤니티에 참여하고, 소프트웨어 투명성에 대한 논의에 기여할 것을 권장합니다.
이러한 액션 아이템을 실행함으로써, 기업은 소프트웨어 공급망 보안을 강화하고 잠재적인 취약점에 대한 대응 능력을 향상시킬 수 있습니다.
OpenChain SBOM 스터디 그룹 - 2024년 10월 세미나
이번 세미나의 발표자는 도시바의 Ninjouji-san입니다. 도시바는 일본의 대표적인 다국적 전자 기업으로, 오픈소스 및 SBOM 관련 분야에서 풍부한 경험을 보유하고 있습니다.
이번 OpenChain SBOM 스터디 그룹 세미나는 다양한 규제와 가이드라인에 대한 개요를 제공하고, 향후 미팅에서 필요한 사항들에 대해 논의하는 것을 목적으로 합니다. SBOM(Software Bill of Materials)은 소프트웨어 구성 요소를 투명하게 관리하고 보안 취약점을 효과적으로 대응하기 위한 중요한 도구로 주목받고 있습니다.
Ninjouji-san은 SBOM과 관련된 주요 규제 및 가이드라인에 대해 상세히 설명했습니다. 이는 다음과 같은 내용을 포함합니다:
각 규제와 가이드라인의 주요 특징, 적용 범위, 기업에 미치는 영향 등을 자세히 다루었습니다.
발표자는 SBOM 생성 및 관리를 위한 다양한 도구들을 소개했습니다:
각 도구의 특징, 장단점, 적용 사례 등을 비교 분석하여 참가자들의 이해를 도왔습니다.
Ninjouji-san은 기업이 SBOM을 효과적으로 구현하기 위한 전략을 제시했습니다:
이러한 전략을 통해 기업은 규제 준수뿐만 아니라 소프트웨어 품질 및 보안 향상을 도모할 수 있습니다.
세미나 참가자들로부터 다양한 질문이 제기되었습니다:
Q: SBOM 구현 시 가장 큰 도전 과제는 무엇인가요? A: Ninjouji-san은 레거시 시스템에 대한 SBOM 생성과 서드파티 소프트웨어 컴포넌트의 정확한 추적이 주요 과제라고 답변했습니다.
Q: 중소기업도 SBOM을 도입해야 하나요? A: 발표자는 기업 규모와 관계없이 SBOM 도입이 중요하며, 오픈소스 도구를 활용하여 비용 효율적으로 시작할 수 있다고 조언했습니다.
Q: SBOM과 DevSecOps의 연계 방안은? A: SBOM을 CI/CD 파이프라인에 통합하여 지속적인 보안 검증을 수행할 수 있다고 설명했습니다.
Ninjouji-san은 SBOM이 소프트웨어 공급망 보안의 핵심 요소로 자리잡고 있음을 강조하며 세미나를 마무리했습니다. 향후 스터디 그룹 미팅에서는 다음과 같은 주제를 다룰 예정입니다:
참가자들은 이번 세미나를 통해 SBOM의 중요성과 실제 구현 방안에 대한 깊이 있는 이해를 얻을 수 있었습니다.
규제 대응 필요성: SBOM은 미국, EU, 일본 등 주요국의 사이버보안 규제 대응에 필수적인 요소로 자리잡고 있습니다. 오픈소스 관리 담당자는 이러한 규제 동향을 주시하고 선제적으로 대응해야 합니다.
소프트웨어 품질 향상: SBOM을 통해 사용 중인 오픈소스 컴포넌트를 정확히 파악하고 관리함으로써 전반적인 소프트웨어 품질을 향상시킬 수 있습니다.
보안 취약점 관리 강화: SBOM은 사용 중인 오픈소스 컴포넌트의 취약점을 신속하게 식별하고 대응할 수 있게 해줍니다. 이는 기업의 사이버보안 태세를 강화하는 데 크게 기여합니다.
공급망 투명성 확보: SBOM을 통해 소프트웨어 공급망의 투명성을 높일 수 있어, 고객 신뢰도 향상 및 리스크 관리에 도움이 됩니다.
DevSecOps 통합: SBOM을 개발 및 운영 프로세스에 통합함으로써 보안을 개발 초기 단계부터 고려하는 DevSecOps 문화를 촉진할 수 있습니다.
SBOM 생성 도구 평가 및 선택: SPDX, CycloneDX 등 다양한 SBOM 표준과 도구를 평가하고, 기업의 환경에 가장 적합한 솔루션을 선택합니다.
자동화 프로세스 구축: CI/CD 파이프라인에 SBOM 생성 및 검증 과정을 자동화하여 통합합니다.
교육 및 인식 제고: 개발자, 보안 팀, 법무 팀 등 관련 부서 직원들에게 SBOM의 중요성과 활용 방법에 대한 교육을 실시합니다.
정책 및 가이드라인 수립: SBOM 관리에 대한 조직 내 정책과 가이드라인을 수립하고 이를 문서화합니다.
취약점 관리 프로세스 개선: SBOM 정보를 활용하여 취약점 스캐닝 및 패치 관리 프로세스를 개선합니다.
공급업체 관리 강화: 서드파티 소프트웨어 공급업체에 SBOM 제공을 요구하고, 이를 평가 기준에 포함시킵니다.
규제 준수 모니터링: SBOM 관련 국내외 규제 동향을 지속적으로 모니터링하고, 필요시 신속히 대응합니다.
SBOM 공유 체계 구축: 고객 및 파트너사와 SBOM을 안전하게 공유할 수 있는 체계를 구축합니다.
이러한 액션 아이템을 체계적으로 이행함으로써, 기업은 SBOM을 효과적으로 도입하고 활용하여 소프트웨어 공급망 보안을 강화할 수 있을 것입니다.
source: https://www.slideshare.net/slideshow/openchain-sbom-study-group-kick-off-call-2024-07-30/270623321
OpenChain SBOM Study Group 킥오프 웨비나
이 웨비나는 OpenChain 프로젝트의 새로운 SBOM Study Group의 킥오프 미팅입니다. 주요 목적은 대규모 및 복잡한 공급망에서 SBOM(Software Bill of Materials)을 실제로 어떻게 활용할 수 있는지에 대한 논의를 시작하는 것입니다. 이를 통해 SBOM의 실용적인 적용 방안과 공급망 내에서의 신뢰 구축 방법을 모색하고자 합니다.
OpenChain 프로젝트는 2026년 설립 이후 지속적으로 컴플라이언스 및 보안 표준의 일환으로 SBOM을 요구해왔습니다. 프로젝트는 SBOM 분야에 다양한 방식으로 기여해왔으며, 특히 공급업체를 위한 간단한 SBOM 형식인 SPDX Lite의 개발과 SBOM 품질 평가 가이드 제작 등을 수행했습니다.
Shane Coughlan은 SBOM의 중요성을 강조하며, 이는 단순한 기술적 도구가 아닌 비즈니스 프로세스의 핵심 요소라고 설명합니다. SBOM은 소프트웨어 구성 요소의 투명성을 제공하여 보안, 라이선스 준수, 품질 관리 등 다양한 영역에서 중요한 역할을 합니다.
Kate Stewart는 SBOM 활용에 있어 실제적인 고려사항들을 제시합니다:
Kate Stewart는 SPDX Lite에 대해 상세히 설명합니다. SPDX Lite는 전체 SPDX 규격의 간소화된 버전으로, SBOM 생성의 진입 장벽을 낮추고자 개발되었습니다.
Shane Coughlan은 SBOM Study Group의 향후 계획과 참여 방법에 대해 안내합니다:
SBOM, 공급망에서의 SBOM 활용, 그리고 공급망 신뢰 증진에 관심 있는 모든 분들의 참여를 환영합니다. 특히 Sony의 Kobota San이 2024년 study group의 의장을 맡아 활동을 이끌어갈 예정입니다.
SBOM의 전략적 중요성 인식: SBOM은 단순한 기술적 도구를 넘어 비즈니스 프로세스의 핵심 요소로 자리잡고 있습니다. 오픈소스 관리 담당자는 SBOM을 통해 소프트웨어 공급망의 투명성을 확보하고, 보안 및 컴플라이언스 리스크를 효과적으로 관리할 수 있습니다.
다양한 이해관계자와의 협업: SBOM은 개발자, 보안 전문가, 법무팀, 구매 담당자 등 다양한 부서와의 협업을 필요로 합니다. 오픈소스 관리자는 이러한 협업을 주도하여 조직 전체의 SBOM 활용을 촉진할 수 있습니다.
SBOM 표준 및 도구에 대한 이해: SPDX, CycloneDX 등 다양한 SBOM 표준과 관련 도구에 대한 이해가 필요합니다. 특히 SPDX Lite와 같은 간소화된 접근 방식은 SBOM 도입의 진입 장벽을 낮출 수 있습니다.
공급망 관리 강화: SBOM을 통해 소프트웨어 구성 요소의 출처와 라이선스 정보를 명확히 파악할 수 있어, 공급망 리스크 관리와 라이선스 컴플라이언스를 강화할 수 있습니다.
SBOM 생성 및 관리 프로세스 수립: 조직 내 SBOM 생성, 유지보수, 공유를 위한 표준화된 프로세스를 개발하고 구현합니다.
SBOM 도구 선정 및 도입: 조직의 needs에 맞는 SBOM 생성 및 분석 도구를 선정하고 도입합니다. SPDX Lite와 같은 간소화된 접근부터 시작할 수 있습니다.
교육 및 인식 제고: 개발자, 관리자, 법무팀 등 관련 부서 직원들을 대상으로 SBOM의 중요성과 활용 방법에 대한 교육을 실시합니다.
공급업체 관리 정책 수립: 외부 공급업체로부터 SBOM을 요구하고 평가하는 정책을 수립합니다. 이를 통해 전체 소프트웨어 공급망의 투명성을 확보합니다.
SBOM 데이터 통합 및 분석: SBOM 데이터를 기존의 보안 및 컴플라이언스 도구와 통합하여 종합적인 리스크 분석을 수행합니다.
지속적인 모니터링 및 개선: SBOM 관련 기술과 표준의 발전을 지속적으로 모니터링하고, 조직의 SBOM 프로세스를 지속적으로 개선합니다.
커뮤니티 참여: OpenChain SBOM Study Group과 같은 커뮤니티에 참여하여 최신 동향을 파악하고 다른 조직의 best practices를 학습합니다.
이러한 action item들을 체계적으로 실행함으로써, 기업의 오픈소스 관리 담당자는 SBOM을 효과적으로 활용하여 조직의 소프트웨어 관리 및 보안 체계를 강화할 수 있을 것입니다.
본 안내서는 통신(Telco) 산업의 기업들이 ‘OpenChain Telco SBOM 가이드’를 실제 업무에 성공적으로 적용할 수 있도록, 단계별 실행 계획과 주체별 활용 시나리오 등 구체적인 세부 사항을 제시합니다.
이 안내서를 통해 조직의 SBOM 관리 체계를 효율적으로 구축하고, 나아가 소프트웨어 공급망 보안을 한층 더 강화할 수 있습니다.
Author : OpenChain Korea Work Group / CC BY 4.0
통신 산업은 현재 전례 없는 디지털 혁신의 물결을 맞고 있습니다. 5G 네트워크 구축, 클라우드 네이티브 기술 도입, IoT 기기의 폭발적 증가로 인해 소프트웨어의 복잡성과 상호 의존성이 기하급수적으로 늘어나고 있습니다.
현재 90% 이상의 소프트웨어 개발 과정에서 오픈소스 소프트웨어가 활용되고 있으며, 특히 통신 인프라에서는 OPC UA, MQTT와 같은 오픈소스 통신 프로토콜이 실시간 데이터 교환의 핵심 역할을 담당하고 있습니다. 5G 네트워크의 복잡한 아키텍처는 수천 개의 소프트웨어 컴포넌트로 구성되며, 이들 간의 의존성 관계는 더욱 복잡해지고 있습니다.
2021년 12월 공개된 Log4Shell(Log4j 취약점)은 통신 산업을 포함한 전 세계 소프트웨어 생태계에 엄청난 충격을 주었습니다. 이 취약점은 다음과 같은 심각한 문제점들을 드러냈습니다:
Log4j 사태는 소프트웨어 구성요소에 대한 가시성 부족이 얼마나 위험한지를 명확히 보여주었습니다. 이를 계기로 전 세계 각국 정부와 산업계는 소프트웨어 공급망의 투명성 확보를 위한 SBOM(Software Bill of Materials) 도입을 적극 검토하기 시작했습니다.
미국 바이든 행정부는 2021년 5월 사이버 보안 강화를 위한 행정명령을 통해 SW 공급망 보안 강화를 지시했으며, 우리나라 정부도 같은 해 2월 발표한 K-사이버 방역 추진 전략에서 SW 개발·공급망 보안 강화 계획을 밝혔습니다.
통신 산업은 여러 층위로 구성된 복잡한 공급망 구조를 가지고 있습니다:
이러한 다층적 구조에서 하나의 취약점이 전체 네트워크에 미치는 파급효과는 매우 클 수 있습니다.
통신 인프라는 국가 핵심 인프라로 분류되어 매우 높은 수준의 보안과 안정성이 요구됩니다. 특히 5G 네트워크는 다음과 같은 새로운 보안 도전에 직면하고 있습니다:
최근 국내외에서 SBOM 제공을 요구하는 사례가 급격히 증가하고 있습니다:
이러한 변화는 단순한 추세가 아니라, 통신 산업의 소프트웨어 공급망 보안을 근본적으로 혁신해야 할 필요성을 보여주는 명확한 신호입니다. 더 이상 SBOM은 선택사항이 아니라, 통신 산업에서 생존하고 경쟁력을 유지하기 위한 필수 요건이 되었습니다.
통신 산업은 전 세계적으로 가장 복잡하고 상호 연결된 소프트웨어 생태계 중 하나입니다. 5G 인프라, 클라우드 네이티브 솔루션, 네트워크 가상화 기술 등이 융합되면서, 각 조직마다 서로 다른 SBOM 작성 방식과 요구사항을 적용하게 되었습니다.
이러한 파편화는 다음과 같은 심각한 문제들을 야기했습니다:
OpenChain 프로젝트는 이러한 문제를 해결하기 위해 2023년 Telco 워킹 그룹을 구성하고, 통신 산업 특화 SBOM 가이드 개발에 착수했습니다.
OpenChain Telco SBOM 가이드는 통신 산업의 특수성을 반영하면서도 글로벌 표준과의 호환성을 보장하는 실용적 접근방식을 제시합니다. 가이드의 핵심 목적은 다음과 같습니다:
OpenChain Telco SBOM 가이드는 ISO/IEC 5962:2021로 공식 인증받은 SPDX(Software Package Data Exchange)표준을 데이터 포맷의 기반으로 채택했습니다 이는 다음과 같은 전략적 이유에서 비롯됩니다:
가이드는 SPDX 2.2 또는 2.3 버전을 준수하도록 요구하며, Tag:Value 또는 JSON 포맷으로 SBOM을 제공할 것을 명시합니다.
OpenChain Telco SBOM 가이드는 NTIA(미국 통신정보관리청)의 최소 요구사항을 기반으로 하되, 통신 산업의 실무 요구를 반영한 명확한 기준을 제시합니다:
필수 SPDX 요소 명시:
제공 시점과 방식 구체화:
SBOM 생성 정보 의무화:
현대 소프트웨어는 수많은 간접 의존성을 가지며, 이는 보안 취약점의 주요 경로가 됩니다. Log4j 사태에서 볼 수 있듯이, 간접 의존성을 통한 취약점 전파는 예측하기 어렵고 광범위한 피해를 야기할 수 있습니다.
OpenChain Telco SBOM 가이드는 이러한 현실을 반영하여 포괄적 범위를 요구합니다:
다음 표는 OpenChain Telco SBOM 가이드의 핵심 요구사항을 요약한 것입니다:
| 구분 | 요구사항 | 세부 내용 |
|---|---|---|
| 데이터 포맷 | SPDX 2.2/2.3 필수 | Tag:Value 또는 JSON 포맷 |
| 필수 요소 | NTIA 최소 요구사항 + α | 문서생성정보, 패키지정보, 관계정보 |
| 제공 시점 | 소프트웨어 제공과 동시 | 늦어도 소프트웨어 제공 시점까지 |
| 제공 방식 | 패키지 내 임베딩 원칙 | 불가능 시 웹호스팅(18개월 보장) |
| SBOM 범위 | 오픈소스 + 간접의존성 | 상용 컴포넌트 권장, 미포함시 known unknowns 명시 |
| 생성 정보 | 조직명, 도구명/버전 | CISA SBOM Type 포함 |
| 검증 | 디지털 서명 권장 | Sigstore 등 활용 |
이러한 체계적이고 실무 중심적인 접근방식을 통해 OpenChain Telco SBOM 가이드는 통신 산업의 소프트웨어 공급망 관리 수준을 한 단계 끌어올리는 든든한 기반을 제공합니다. Nokia와 같은 글로벌 통신 장비사가 이미 이 가이드를 내부 프레임워크의 기초로 채택한 것은, 가이드의 실용성과 효과성을 입증하는 사례라 할 수 있습니다.
OpenChain Telco SBOM 가이드를 준수하면 취약점 대응 시간을 획기적으로 단축할 수 있습니다. 최근 연구에 따르면, SBOM을 활용한 성숙한 취약점 관리 체계를 갖춘 조직은 취약점 대응 시간을 30% 단축하는 것으로 나타났습니다.
Log4j 사태가 발생했을 때, SBOM을 보유한 조직은 영향받는 시스템을 수십 분 내에 식별할 수 있었던 반면, SBOM이 없던 조직은 수주에서 수개월이 소요되었습니다. 한 소프트웨어 벤더는 “SBOM 기능만으로도 240시간을 쉽게 절약할 수 있었을 것"이라고 증언했습니다.
일본 METI의 실증 연구에서는 의료기기 부문에서 SBOM을 활용한 취약점 관리가 수동 관리 대비 약 70%의 관리 업무량을 절감했다고 보고했습니다.
표준화된 SPDX 포맷을 통해 각 컴포넌트의 라이선스 정보를 명확히 관리함으로써, 라이선스 위반으로 인한 소송 및 과징금 리스크를 선제적으로 차단할 수 있습니다.
SBOM 도구를 활용하면 라이선스 관리의 효율성이 크게 향상됩니다. 각 라이선스의 내용 표시, 주의가 필요한 라이선스에 대한 경고 등 컴플라이언스 기능을 자동화하여 관리 비용을 대폭 줄일 수 있습니다.
현재 많은 SI(System Integrator) 및 SV(Software Vendor) 기업이 ‘SBOM 도입을 통한 규제·산업표준 준수’와 ‘신뢰 향상’을 주요 인센티브로 인식하고 있습니다.
SBOM 제공 역량을 갖춘 조직은 다음과 같은 명확한 경쟁 우위를 확보할 수 있습니다:
이미 다수의 통신사와 공공기관이 SBOM 제출을 입찰 필수 조건으로 명시하고 있습니다. 한 API 관리 벤더 CEO는 “대화 초기에 SBOM을 제시할 수 있다는 것은 완전히 다른 차원의 대화를 가능하게 하며, CISO들이 ‘이것을 시도해보자’고 말할 수 있게 해준다"고 증언했습니다.
표준화된 SBOM 제공 능력은 가시적인 가산점 요소가 되어, 보안과 투명성을 중시하는 고객들과의 판매 주기를 단축시키는 효과를 가져옵니다.
OpenChain Telco SBOM 가이드는 ISO/IEC 5962:2021(SPDX) 기반으로 작성되어, 국제 조달 및 수출 시 별도 형식 변환 없이 그대로 제출 가능합니다. 이는 글로벌 벤더 및 고객사와의 비즈니스에서 호환성과 신뢰성을 동시에 확보하는 중요한 자산이 됩니다.
표준화된 포맷(SPDX 2.2/2.3)과 명확한 필수 항목 정의로 인해 SBOM 생성·검증·제공 프로세스의 자동화와 반복성을 확보할 수 있습니다.
총 주당 5시간 이상의 엔지니어링 시간을 절약하여, 이를 핵심 개발 업무에 재투자할 수 있습니다.
일관된 SBOM 작성 기준을 통해 조직 내 모든 부서가 동일한 컴포넌트 정보를 공유함으로써, 중복 스캔과 수작업 관리의 비효율을 제거할 수 있습니다. 이는 반복 업무의 자동화와 CI/CD 파이프라인과의 연동을 통해 더욱 가속화됩니다.
소프트웨어 공급망 공격의 평균 비용은 사고당 435만 달러에 달하며, 2026년에는 연간 806억 달러 규모로 확대될 것으로 예측됩니다. OpenChain Telco SBOM 가이드를 통한 체계적 관리는 이러한 수백만 달러 규모의 잠재적 손실을 사전에 방지할 수 있습니다.
취약점 분석과 패치 검증에 투입되는 수백 시간을 SBOM으로 절감할 수 있다는 실제 사례가 다수 보고되고 있습니다. 한 조직은 “취약점 검토 시간을 하루에서 1시간 미만으로 단축했으며, 오픈소스 프로젝트당 약 500시간의 취약점 분석 및 우선순위 결정 시간을 절약했다"고 보고했습니다.
OpenChain Telco SBOM 가이드는 NTIA, CISA, ISO 등 글로벌 컴플라이언스 요구사항에 효과적으로 대응할 수 있는 실질적 기반을 제공합니다.
현재 진행 중인 주요 규제들:
표준화된 SBOM 교환은 주요 글로벌 과제로 부상하고 있으며, 가이드를 준수하면 타사 SBOM과의 호환성이 보장되어 협업 장벽이 사라집니다.
Nokia와 같은 글로벌 통신 장비사가 이미 이 가이드를 내부 프레임워크의 기초로 채택한 것은, 가이드의 실용성과 비즈니스 가치를 입증하는 대표적 사례입니다.
OpenChain Telco SBOM 가이드는 통신 산업 생태계를 구성하는 각 주체의 역할과 필요에 따라 다르게 활용될 수 있습니다. 본 장에서는 이동통신사(소비자), 통신장비 제조사(생산자), 네트워크 솔루션 공급사(생산자), 그리고 실무 담당자의 입장에서 가이드를 어떻게 전략적으로 활용할 수 있는지 구체적인 시나리오와 함께 제시합니다.
이동통신사는 수많은 공급업체로부터 장비와 솔루션을 도입하여 최종 서비스를 제공하는 공급망의 최종 책임자이자, SBOM의 핵심 소비자입니다. 이들의 주된 관심사는 도입하는 소프트웨어의 보안 리스크를 사전에 식별하고, 공급망 전체의 투명성을 확보하는 데 있습니다.
한 이동통신사가 5G 네트워크 슬라이싱 관리를 위한 새로운 Orchestration 솔루션을 도입하고자 합니다. 여러 글로벌 벤더로부터 제안서를 받았지만, 일부는 SBOM을 제공하지 않거나, 제공하더라도 포맷과 내용이 제각각이라 객관적인 리스크 평가가 어려운 상황입니다.
PackageLicenseConcluded, PackageLicenseDeclared)를 분석하여, 내부 정책과 충돌하거나 상업적 이용에 제약이 있는 라이선스가 포함되었는지 자동으로 검증합니다.known unknowns 항목을 검토하여, 벤더가 자사의 소프트웨어 구성요소를 얼마나 투명하게 파악하고 있는지를 평가 지표로 활용합니다.SBOM 요구를 명문화하는 것은 공급업체의 책임감 있는 참여를 유도하는 가장 효과적인 방법입니다.
“제안하는 모든 소프트웨어 제품에 대해, ‘OpenChain Telco SBOM Guide v1.1’을 준수하는 SBOM을 반드시 제출해야 합니다. SBOM은 SPDX 2.2 또는 2.3 버전의 Tag:Value 또는 JSON 형식이어야 하며, 제품에 포함된 모든 오픈소스 및 상용 컴포넌트, 그리고 모든 간접 의존성을 포함해야 합니다. SBOM 제출 여부 및 품질은 제안 평가의 주요 항목으로 고려됩니다.”
통신장비 제조사는 펌웨어, 임베디드 OS 등 하드웨어와 깊게 결합된 소프트웨어를 개발하며, SBOM의 핵심 생산자입니다. 이들의 목표는 고객사(이동통신사)의 다양한 요구사항을 효율적으로 충족시키고, 제품의 신뢰성과 글로벌 경쟁력을 입증하는 것입니다.
한 통신장비 제조사가 국내외 여러 통신사에 5G 라우터를 납품하고 있습니다. 하지만 각 통신사마다 요구하는 SBOM의 형식과 내용이 달라, 제품 출시 때마다 수작업으로 SBOM을 변환하고 검증하는 데 많은 시간과 비용이 소모되고 있습니다.
Creator 필드에 조직명, 사용된 SCA 도구명과 버전을 자동으로 기록하고, 빌드 시점에 맞춰 SBOM Type: Build를 명시합니다. 이를 통해 SBOM 생성의 추적성과 일관성을 확보합니다.임베디드 환경의 특수성을 고려한 SBOM 관리가 중요합니다.
네트워크 솔루션/서비스 공급사는 클라우드 네이티브, SaaS, 컨테이너 등 현대적인 소프트웨어 배포 방식에 가장 밀접하게 연관된 SBOM의 핵심 생산자입니다. 이들의 목표는 빠르게 변화하는 기술 환경에 맞춰 유연한 SBOM 제공 전략을 수립하고, 이를 차별화된 서비스 경쟁력으로 전환하는 데 있습니다.
국내 한 네트워크 보안 솔루션 기업이 클라우드 기반의 DDoS 방어 솔루션(SaaS)과 데이터센터용 방화벽 솔루션(온프레미스)을 함께 제공하고 있습니다. 최근 대형 통신사 고객으로부터 두 솔루션 모두에 대해 상세한 SBOM을 요구받았으며, 특히 지속적으로 업데이트되는 SaaS 환경의 SBOM 관리에 어려움을 겪고 있습니다.
각 솔루션의 배포 방식과 고객의 요구 수준에 맞춰 SBOM 제공 전략을 다르게 설계합니다.
온프레미스 솔루션 (설치형 소프트웨어):
SaaS 솔루션 (서비스형 소프트웨어):
SBOM은 제품 판매 이후의 고객 지원과 유지보수 단계에서 더욱 강력한 가치를 발휘합니다.
오픈소스 및 컴플라이언스 담당자는 조직의 SBOM 정책을 수립하고, 전사적으로 일관된 품질을 유지하도록 관리하는 SBOM 거버넌스의 핵심 두뇌입니다. 이들의 목표는 명확하고 실행 가능한 정책을 수립하고, 이를 통해 개발팀의 업무 부담을 줄이면서도 조직의 리스크를 최소화하는 것입니다.
한 통신사의 오픈소스 프로그램을 총괄하는 담당자가 전사 차원의 SBOM 정책 수립을 맡게 되었습니다. 개발, 보안, 조달, 법무 등 각 부서의 요구사항이 달라, 모두를 만족시키는 표준 정책을 만드는 데 어려움을 겪고 있습니다.
객관적인 국제 표준 기반의 가이드를 정책의 근간으로 삼아, 부서 간의 이견을 조율하고 설득의 근거로 활용합니다.
가이드의 핵심 요구사항을 반영하여, 명확하고 간결한 정책 문서를 작성합니다.
[사내 SBOM 관리 정책]
제1조 (목적)
본 정책은 'OpenChain Telco SBOM Guide v1.1'을 준수하여, 당사의 소프트웨어 공급망 투명성을 확보하고 관련 리스크를 체계적으로 관리하는 것을 목적으로 한다.
제2조 (적용 대상)
당사가 개발, 구매, 배포하는 모든 소프트웨어에 적용된다.
1. 외부 구매 소프트웨어: 계약 시 가이드 준수 SBOM 제공을 필수 조건으로 한다.
2. 내부 개발 소프트웨어: 외부 고객에게 배포 시, 가이드 준수 SBOM 생성을 의무화한다.
제3조 (SBOM 품질 요구사항)
모든 SBOM은 'OpenChain Telco SBOM 가이드' 제3장의 요구사항(데이터 포맷, 필수 필드, 제공 방식 등)을 충족해야 한다.
정책의 실행력을 높이기 위해, 각 부서의 역할을 구체적으로 정의합니다.
전사적으로 일관된 품질을 유지하기 위한 표준을 제시합니다.
sbomqs와 같은 오픈소스 도구를 활용하여 품질 점수를 자동으로 측정하고, 일정 점수 이하일 경우 빌드를 실패시키는 정책을 도입합니다.성공적인 SBOM 관리의 핵심은 조직에 맞는 올바른 도구를 선택하는 것입니다.
궁극적으로 SBOM의 가치는 개별 조직을 넘어, 공급망 생태계 전체가 연결될 때 극대화됩니다.
대한민국 5G 특화망 구축 프로젝트에서 이동통신사(소비자), 장비 제조사(1차 공급사), 솔루션 공급사(2차 공급사)가 OpenChain Telco SBOM 가이드를 공통의 언어(Common Language)로 사용하여 협업하는 사례입니다.
OpenChain Telco SBOM 가이드의 성공적인 도입은 일회성 프로젝트가 아닌, 조직의 문화와 프로세스에 내재화되는 지속적인 여정입니다. 본 장에서는 조직이 SBOM 관리 체계를 효과적으로 구축하고 운영할 수 있도록, ‘분석(Assess) → 실행(Implement) → 확산(Scale)’ 의 3단계로 구성된 실질적인 실행 계획을 제시합니다.
이 단계는 성공적인 SBOM 도입의 초석을 다지는 과정입니다. 정확한 현황 진단 없이 무작정 도구를 도입하거나 정책을 수립하면, 현장과 괴리된 비효율적인 결과를 낳을 수 있습니다. 조직의 현재 역량과 마주한 과제를 명확히 파악하는 것이 무엇보다 중요합니다.
우선, 조직의 소프트웨어 공급망 관리 현황을 객관적으로 파악해야 합니다. 이는 단순히 현재 상태를 기록하는 것을 넘어, 잠재적 리스크와 개선 기회를 발견하는 과정입니다.
현재 소프트웨어 공급망 관리 현황 파악
SBOM 성숙도 자가 진단 조직의 현재 위치를 파악하기 위해 아래 3단계 모델을 활용하여 성숙도를 진단합니다.
| 성숙도 단계 | 특징 | 주요 과제 |
|---|---|---|
| 초보자 (Procrastinators) | SBOM의 필요성은 인지하나, 구체적 계획이나 실행이 없음. 수동 관리 의존. | SBOM 도입의 필요성과 가치를 조직 내에 전파하고, 경영진의 지원 확보. |
| 초기 도입자 (Early Adopters) | 일부 팀이나 프로젝트에서 SBOM을 시범적으로 도입. 표준화된 프로세스 부재. | 파일럿 프로젝트의 성공 사례를 기반으로 전사적 표준 프로세스 및 정책 수립. |
| 혁신자 (Innovators) | 전사적으로 표준화된 SBOM 프로세스를 운영. CI/CD 파이프라인에 자동화 통합. | SBOM 데이터를 활용한 공급망 위협 예측 및 사전 대응 등 고도화 전략 추진. |
SBOM 도입은 특정 부서의 과제가 아닌, 전사적 협력이 필요한 프로젝트입니다. 성공적인 추진을 위해 명확한 역할과 책임을 가진 전담 조직을 구성해야 합니다.
핵심 이해관계자 참여 확보
SBOM 도입 TF(태스크포스) 구성 단순한 협의체가 아닌, 명확한 R&R(Role & Responsibility)을 가진 실행 조직을 구성합니다.
진단 결과를 바탕으로, 현실적이고 측정 가능한 목표를 설정합니다. 이는 조직의 자원을 효율적으로 집중시키고, 프로젝트의 성공 여부를 객관적으로 판단하는 기준이 됩니다.
SMART 목표 설정 막연한 목표 대신, SMART 원칙에 따라 구체적이고 실행 가능한 목표를 설정합니다.
우선순위 기반 적용 범위 선정 모든 제품에 한 번에 적용하기보다는, 비즈니스 중요도와 리스크 수준을 고려하여 단계적으로 범위를 확대합니다.
이 단계에서는 1단계에서 수립한 계획을 바탕으로 실제 시스템과 프로세스를 구축합니다. 핵심은 일회성 작업이 아닌, 개발 라이프사이클에 자연스럽게 통합되어 지속적으로 운영될 수 있는 자동화된 체계를 만드는 것입니다.
조직의 기술 스택, 예산, 목표에 맞는 최적의 도구를 선정하는 과정입니다.
| 평가 항목 | 세부 내용 |
|---|---|
| 포맷 지원 | SPDX 2.2/2.3 포맷 생성 및 파싱 기능 지원 여부 |
| 언어/프레임워크 지원 | 조직 내에서 사용하는 주요 개발 언어 및 프레임워크 지원 범위 |
| 통합성 | Jenkins, GitHub Actions 등 CI/CD 파이프라인과의 연동 용이성 |
| 정확성 | 간접 의존성 탐지 정확도, 오탐(False Positive) 비율 |
| 확장성/성능 | 대규모 프로젝트 스캔 시 성능, 조직 성장에 따른 확장 가능성 |
| 비용 효율성 | 라이선스 비용, 유지보수 비용 대비 기능의 적절성 |
선정된 도구를 활용하여, 조직의 개발 문화에 맞는 표준화된 SBOM 관리 프로세스를 설계합니다.
CI/CD 통합 워크플로우 설계 SBOM 생성을 개발자의 추가적인 업무가 아닌, 자동화된 프로세스의 일부로 만듭니다.
정책 및 가이드라인 문서화 조직의 모든 구성원이 따를 수 있는 명확한 기준을 문서로 제공합니다.
새로운 도구와 프로세스는 충분한 교육과 지원 없이는 현장에 안착하기 어렵습니다.
이 단계에서는 실제 프로젝트에 SBOM 프로세스를 적용하여 그 효과를 검증하고, 이를 바탕으로 전사적인 도입을 추진합니다.
‘작게 시작해서, 빠르게 성공하고, 널리 전파한다’는 원칙으로 파일럿을 진행합니다.
파일럿 프로젝트 선정 기준
파일럿 실행 및 성과 측정 정의된 기간(예: 8주) 동안 파일럿을 실행하고, 사전에 정의한 성공 지표(KPI)를 통해 성과를 객관적으로 측정합니다.
| KPI 영역 | 측정 지표 | 목표값 (예시) |
|---|---|---|
| 품질 | SBOM의 가이드 필수 필드 포함률 | 95% 이상 |
| 효율성 | SBOM 생성 및 검증 자동화율 | 90% 이상 |
| 보안 | 신규 취약점 식별 및 분석 소요 시간 | 기존 대비 50% 단축 |
| 만족도 | 참여 개발팀 만족도 설문 점수 | 5점 만점에 4점 이상 |
파일럿의 성공 경험과 교훈을 바탕으로, 전사 확산을 위한 체계적인 로드맵을 수립합니다.
확산 로드맵 수립 “빅뱅” 방식이 아닌, 제품군별, 사업부별로 단계적으로 적용 범위를 넓혀갑니다.
변화 관리 및 저항 극복 새로운 프로세스 도입에 따른 구성원의 저항을 최소화하고, 변화를 성공적으로 이끌기 위한 전략이 필요합니다.
SBOM 관리가 일회성으로 끝나지 않고, 조직의 핵심 역량으로 자리 잡기 위한 지속적인 관리 체계를 구축합니다.
이러한 체계적인 3단계 접근을 통해 조직은 OpenChain Telco SBOM 가이드를 성공적으로 도입하고, 소프트웨어 공급망 보안을 비즈니스 경쟁력으로 전환시킬 수 있습니다.
OpenChain Telco SBOM 가이드는 통신 산업이 맞이한 소프트웨어 공급망 보안 혁명의 시발점입니다. Log4Shell과 SolarWinds 같은 대규모 공급망 공격이 전 세계 디지털 인프라를 위협한 현실에서, 이 가이드는 통신 산업 특화 SBOM 표준화라는 명확한 해답을 제시했습니다.
지난 18개월간 가이드의 개발과 Version 1.1 발표, 그리고 Nokia와 같은 글로벌 리더의 내부 프레임워크 채택은 이 가이드가 단순한 문서가 아니라 실질적 변화를 이끄는 산업 표준임을 입증했습니다.
가이드의 가장 큰 의의는 상호운용성과 표준화를 통해 통신 산업 전반의 효율성을 극대화한다는 점입니다. Nokia의 Gergely Csatári가 언급했듯이, “내부적으로나 외부 인터페이스에서 SBOM의 상호운용성을 보장하기 위해서는 완전성, 품질, 콘텐츠의 조화가 필요하다"는 현실을 이 가이드가 해결하고 있습니다.
특히 SCANOSS의 상용 도구 지원 발표는 가이드가 이론적 지침에서 실무적 자동화 솔루션으로 진화하고 있음을 보여주는 중요한 이정표입니다.
2025-2026년은 SBOM 의무화의 결정적 시점입니다. 주요 규제 동향을 살펴보면:
이미 많은 전문가들이 “2026년이 진정한 SBOM 도입 시점“이라고 전망하고 있으며, 늦은 대응은 곧 시장에서의 도태를 의미합니다.
최신 보안 위협 데이터는 더 이상 대기할 수 없는 현실을 보여줍니다:
Log4Shell 이후 2년이 지났지만 여전히 38%의 애플리케이션이 취약점을 보유하고 있다는 현실은 체계적인 SBOM 관리의 시급성을 보여줍니다.
2025년은 SBOM 관리가 수동 작업에서 자동화 체계로 전환되는 전환점입니다. OpenChain Telco SBOM 가이드를 지원하는 자동화 도구들이 속속 등장하고 있어:
우리는 소프트웨어 공급망 보안 역사에서 결정적 전환점에 서 있습니다.
거창한 변화보다는 작지만 확실한 첫걸음이 중요합니다. OpenChain Telco SBOM 가이드와 함께 조직의 소프트웨어 공급망 관리 역량을 한 단계씩 발전시켜 나가시기 바랍니다.
| 용어 | 정의 |
|---|---|
| SBOM | Software Bill of Materials. 소프트웨어를 구성하는 모든 컴포넌트와 그 관계를 기록한 문서. |
| SPDX | Software Package Data Exchange. ISO/IEC 5962:2021 표준 기반 SBOM 데이터 포맷. |
| PURL | Package URL. 소프트웨어 패키지를 고유하게 식별하기 위한 사실상의 표준 URL. |
| Transitive dependency | 간접 의존성. 직접 의존성이 아닌, 소프트웨어 실행에 필요한 모든 연쇄적 의존성. |
| NTIA minimum elements | 미국 통신정보관리청이 정의한 SBOM 최소 요소 집합. |
| CreatorComment | SPDX 필드 중 하나로, 도구 정보 또는 SBOM Type 등 추가 메타데이터를 기록하는 자유 텍스트 필드. |
| Known unknowns | SBOM 작성 시 미포함된 컴포넌트를 “알려진 미포함 항목”으로 명시하여, 실제 누락 여부를 투명하게 표기하는 방식. |
| Tag:Value | 사람이 읽을 수 있는 SPDX 데이터 포맷 형식 중 하나. “키:값” 형태의 텍스트 포맷. |
| JSON | 기계 판독 가능 형식 중 하나로, 구조화된 데이터 표현을 위한 JavaScript Object Notation. |
| Digital signature | SBOM 무결성 보장을 위해 SBOM 파일에 적용하는 디지털 서명. Sigstore 등 도구를 활용. |
| Container SBOM | 컨테이너 이미지에 포함된 패키지, 복사/다운로드된 컴포넌트, 빌드 의존성 등을 모두 문서화한 SBOM. |
| SaaS SBOM | 서비스형 소프트웨어(SaaS)에 적용하는 SBOM. 현 가이드에서는 선택 적용 가능. |
Q1. SBOM 작성에 특정 도구를 반드시 사용해야 하나요?
A. 아니요. 가이드는 SPDX 2.2/2.3 포맷 요건만 정의하며, 이를 생성할 수 있는 모든 도구를 허용합니다. Syft, FOSSA, SCANOSS, Black Duck 등 다양한 SCA 도구를 평가해 조직 환경에 맞는 도구를 선택하세요.
Q2. SaaS 제공에도 SBOM을 반드시 적용해야 하나요?
A. 본 가이드는 SBOM 단위(specification) 적용을 전제로 하므로, SaaS에는 선택 적용(MAY)입니다. 필요 시 가이드 준수 SBOM을 SaaS 서비스 포털 또는 API를 통해 제공할 수 있습니다.
Q3. 가이드 준수 여부는 어떻게 검증하나요?
A. SBOM이 아래 요건을 충족하는지 확인합니다.
Q4. 기존 SBOM을 가이드에 맞춰 업데이트하려면?
A.
Q5. 레거시(구형) 제품에도 SBOM을 어떻게 적용할 수 있나요?
A.
Q6. SBOM 파일 병합은 어떻게 하나요?
A. SPDX의 Relationship 기능을 활용해 여러 개의 SBOM 파일을 통합할 수 있습니다. sbomasm 등의 도구를 활용해 자동 병합을 수행하세요.
이 부록을 통해 가이드 전문, 핵심 용어, 실무자가 자주 묻는 질문까지 한눈에 확인할 수 있습니다. 필요에 따라 조직 내부 안내 자료에 그대로 활용하십시오.
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 전환 이슈
OpenChain 프로젝트의 핵심 인물이었던 Shane이 General Manager직을 내려놓게 되었습니다. 그의 마지막 근무일은 12월 12일이며, 현재 후임자는 정해지지 않은 상태입니다. 프로젝트 측에서는 적합한 후보자 추천을 환영하고 있으며, 리더십 공백을 최소화하기 위해 노력하고 있습니다.
미팅은 언제나처럼 OpenChain의 반독점 정책 고지를 확인하며 시작되었습니다. 이는 오픈 소스 컴플라이언스 활동이 공정한 경쟁 환경을 저해하지 않도록 하기 위한 필수적인 절차입니다.
최근 릴리스된 CycloneDX v1.7 표준에 대해 Ericsson의 Jimmy Ahlberg가 중요한 우려를 제기했습니다. 이번 버전부터 특허(Patents) 및 특허 패밀리(Patent Families)에 대한 지원이 공식적으로 포함되었는데, 이 필드들이 자칫 ‘특허 괴물(Patent Trolls)‘들에게 악용될 소지가 있다는 점입니다.
미국 사이버보안 및 인프라 보안국(CISA)의 ‘Minimum Elements’ 문서에 대한 업데이트가 지연되고 있습니다. Nokia 측에서 의견을 제출했으나 아직 공식 사이트(regulations.gov)에 반영되지 않았으며, 최종 버전의 발행 시점 또한 불투명한 상황입니다. 이는 관련 기업들의 컴플라이언스 준비에 불확실성을 더하고 있습니다.
Honda의 Takashi Ninjouji는 독일 연방정보기술보안청(BSI)의 최신 문서가 SPDX 3.0 사용을 요구하고 있다는 점을 지적했습니다.
spdx-tools-java와 같은 변환 도구를 사용하여 SPDX 2.0 데이터를 3.0으로 변환하는 것이 가장 현실적인 해결책으로 논의되었습니다.이번 미팅에서는 실무자들에게 도움이 될 만한 구체적인 툴 업데이트 소식이 다수 공유되었습니다.
ntia-conformance-checker 업데이트NTIA 적합성 검사 도구가 업데이트되어 이제 CISA 문서에 대한 적합성 검사도 지원합니다.
openchain-telco-sbom-validator에는 아직 직접적인 영향이 없습니다.openchain-telco-sbom-validator 0.3.3 릴리스Telco 가이드라인 준수 여부를 확인하는 검증기의 새 버전이 배포되었습니다.
pypispdxNokia에서 PyPI(Python Package Index)에 등록된 패키지들을 위한 SBOM 생성 도구인 pypispdx를 공개했습니다.
Automotive 워킹 그룹에서는 이미 Yocto 프로젝트에서 생성된 SPDX 3.0 데이터를 Telco 가이드 기준으로 검증하려는 시도가 있었습니다. 하지만 현재 검증기가 사용하는 Python 라이브러리가 SPDX 3.0을 파싱하지 못하는 한계가 있습니다.
Jimmy Ahlberg는 암호화(Encryption) 관련 단락의 문구를 더 명확하게 개선하여 업데이트할 예정입니다.
이번 12월 미팅은 기술적 표준의 변화(SPDX 3, CycloneDX 1.7)와 규제 기관의 요구사항(CISA, BSI) 사이에서 실무적인 대응 방안을 모색하는 자리였습니다. 특히 툴링 생태계가 표준의 진화 속도를 따라가지 못하는 상황에서, pypispdx와 같은 새로운 도구의 등장은 환영할 만한 소식입니다.
OpenChain Telco Work Group은 누구나 참여할 수 있는 열린 공간입니다. 관심 있는 분들은 언제든 메일링 리스트나 GitHub을 통해 참여해 주시기 바랍니다.
by Gemini 3.0
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)에 대한 심도 있는 기술적 검토가 이루어졌습니다.
미팅에 직접 참여하지 못하신 분들을 위해 핵심 내용을 상세히 요약해 드립니다.
이번 미팅의 서두는 현재 미국 정부의 셧다운 사태가 공급망 보안 규제 기관인 CISA에 미치는 영향에 대한 논의로 시작되었습니다.
CISA 문서에 대한 업계의 피드백은 엇갈리고 있습니다.
Telco WG의 대응 방향:
현재 Telco Guide v1.0 및 1.1에서는 라이선스 정보가 필수지만, 값을
NOASSERTION(정보 없음)으로 표기하는 것을 허용하고 있습니다.하지만 Draft v1.2에서는
NOASSERTION을 허용하지 않고 실제 라이선스 정보를 기입하도록 강화할 예정이었습니다. WG는 CISA가 최종적으로 라이선스 정보를 필수 요소로 확정할지 여부를 지켜본 후, 이 방침을 유지할지 결정하기로 했습니다.
Ericsson의 Jimmy Ahlberg가 제안했던 ‘암호화 관련 챕터’ 추가는 문구 수정이 더 필요한 상황입니다. 제안자가 현재 아시아 출장 및 한국 행사 참석 일정으로 인해 수정안을 제출하지 못해, 다음 미팅에서 다시 논의하기로 했습니다.
tools-python)가 SPDX 3.0을 지원하지 않아 구현이 어렵습니다.미팅의 대부분은 현재 작성 중인 SBOM Quality Guide 문서를 검토하는 데 할애되었습니다.
독일 BSI의 최신 가이드라인(TR-03183-2 v2.1.0) 내용이 공유되었는데, 이 내용이 상당히 파격적이라 우려의 목소리가 나왔습니다.
가이드 문서의 섹션 3.5인 “SBOM Build information"이라는 용어가 혼란을 줄 수 있다는 지적이 있었습니다.
문서에서는 SWHID, PURL, CPE 등 다양한 식별자를 나열하고 있습니다.
공급망 내에서 일부 종속성 정보가 누락되었음을 인지하고 있지만, 그 내용이 무엇인지 모르는 경우(Known Unknowns)를 SPDX로 표현하는 것이 기술적으로 까다롭다는 논의가 있었습니다.
이번에 논의된 문서들은 오는 12월 일본에서 열리는 Open Compliance Summit에서 발표될 예정입니다. 따라서 WG 멤버들은 그전까지 문서에 대한 코멘트를 적극적으로 제출해 줄 것을 요청받았습니다.
OpenChain Telco WG는 모든 이에게 열려 있습니다. 관심 있는 분들은 아래 채널을 통해 참여하실 수 있습니다.
by Gemini 3.0
source: https://openchainproject.org/news/2024/12/12/telco-work-group-2024-12-06
이번 웨비나는 OpenChain Telco Work Group의 정기 미팅으로, Nokia의 오픈소스 전문가가 진행을 맡았습니다.
SBOM 관련 최신 기술 가이드라인을 검토하고 OpenChain Telco SBOM 가이드의 개선 방안을 논의하기 위해 개최되었습니다.
Indian Computer Emergency Response Team (CERT-In)에서 2023년 10월에 발표한 SBOM 기술 가이드라인에 대해 논의했습니다. 이 가이드라인은 주로 공공 부문의 보안 관점에 초점을 맞추고 있습니다.
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를 “사용한다/안 한다"의 이분법을 넘어, “어떻게 안전하게 관리하며 활용할 것인가"에 대한 실질적인 해답을 논의했습니다.
웨비나의 서두는 생성형 AI가 가져온 압도적인 효율성에 대한 인정으로 시작되었습니다. 패널들은 현장의 목소리를 빌려, AI 도구 도입 후 개발 속도가 25%에서 50%, 심지어 그 이상 빨라졌다는 보고가 잇따르고 있다고 전했습니다.
하지만 이러한 속도 뒤에는 반드시 해결해야 할 과제가 있습니다. 바로 ‘검증되지 않은 코드의 유입’입니다. 개발자가 AI가 짜준 코드를 그대로 복사해서 붙여넣을 때, 그 코드가 어디서 왔는지, 어떤 라이선스를 가지고 있는지, 보안 취약점은 없는지 확인하는 과정이 생략되기 쉽다는 점이 지적되었습니다.
이날 논의에서 가장 인상 깊었고, 청중들의 이목을 집중시켰던 사례는 바로 SCANOSS의 경험담이었습니다.
소프트웨어 구성 분석(SCA) 및 컴플라이언스 전문 기업인 SCANOSS는 어느 날 황당한 사실을 발견했습니다. 생성형 AI가 자신들의 독자적인(Proprietary) 코드 혹은 특정 오픈소스 코드를 토씨 하나 틀리지 않고 그대로 생성해낸 것입니다.
이는 생성형 AI가 단순히 코딩 문법을 학습해서 새로운 코드를 ‘창작’하는 것이 아니라, 학습 데이터에 포함된 코드를 ‘암기’했다가 그대로 ‘반복(Regurgitate)‘할 수 있음을 보여주는 결정적인 증거였습니다. 만약 기업이 이 코드를 그대로 제품에 사용한다면? 본의 아니게 타사의 지식재산권을 침해하거나, 강력한 카피레프트(Copyleft) 라이선스 의무를 위반하게 될 수도 있는 것입니다. 이 사례는 AI가 생성한 코드가 결코 ‘저작권 청정 구역’이 아니라는 점을 시사합니다.
이러한 위험성에도 불구하고, 패널들의 결론은 “AI를 쓰지 말자"가 아니었습니다. 오히려 FossID의 전문가는 이렇게 강조했습니다.
“우리는 생성형 AI를 두려워해서는 안 됩니다. 솔직히 말해서, 이건 환상적인 도구입니다. 우리의 역할은 위험을 과장해서 겁을 주는 게 아니라, 개발자들이 이 도구를 안전하고 효율적으로 활용할 수 있도록 필요한 도구와 프로세스를 제공하는 것입니다.”
즉, 무조건적인 금지보다는 ‘관리 가능한 위험(Manageable Risk)‘으로 접근해야 한다는 것입니다. 웨비나 진행자 역시 자신도 Copilot, ChatGPT, Claude 등 다양한 AI 도구를 매일 사용하고 있음을 밝히며, 핵심은 “어떻게 관리(Manage)하느냐"에 달려 있다고 역설했습니다.
그렇다면 구체적으로 기업은 어떤 준비를 해야 할까요? 패널들은 크게 세 가지 측면에서 실무적인 조언을 제시했습니다.
AI 리스크는 법무팀 혼자서, 혹은 보안팀 혼자서 해결할 수 있는 문제가 아닙니다. 패널들은 법무(Legal), 제품(Product), 그리고 오픈소스 전담 조직(OSPO)이 반드시 함께 움직여야 한다고 강조했습니다.
단순히 “라이선스를 확인해라” 정도의 모호한 지침은 부족합니다.
우리 회사가 허용하는 AI 도구는 무엇인가?
AI가 생성한 코드를 상용 제품에 포함시킬 때의 검수 절차는 무엇인가?
입력 데이터(프롬프트)에 회사 기밀을 넣지 않도록 하는 보안 지침은 무엇인가?
이처럼 구체적인 정책(Policy)과 허용 범위(Scope)를 먼저 합의하고 정의하는 것이 첫걸음입니다.
웨비나 중 진행된 실시간 설문조사에서 “AI가 생성한 코드가 법적으로 안전한지 확인하고 있는가?“라는 질문에 대해, “그렇다"는 응답은 8명에 불과했고, “모른다"는 답변도 5명이나 되었습니다.
개발자들이 보안 절차를 귀찮아하거나 거부감을 느끼는 경우에 대해, 패널들은 “강요가 아닌 이해"를 해법으로 제시했습니다.
웨비나는 참석자들에게 긍정적인 비전을 제시하며 마무리되었습니다. 과거 오픈소스가 처음 등장했을 때도 기업들은 보안과 라이선스 문제로 두려움에 떨었습니다. 하지만 지금 오픈소스는 IT 산업의 표준이 되었습니다.
생성형 AI도 마찬가지입니다. 지금의 혼란과 리스크 관리 과정은 우리에게 새로운 프로세스 전문가, 변화 관리자(Change Manager)가 될 기회를 제공합니다. AI라는 거대한 파도를 두려워만 할 것이 아니라, 그 파도 위에 올라타는 법을 익히는 조직만이 다음 단계로 도약할 수 있을 것입니다.
이 포스팅은 2025년 12월 4일 진행된 OpenChain 웨비나 내용을 바탕으로 재구성되었습니다. 원본 영상은 여기에서 확인하실 수 있습니다.
by Gemini 3.0
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의 기술적 원리와 거버넌스, 그리고 우리가 왜 이것 없이는 살 수 없게 될 것인지에 대해 심도 깊은 이야기를 나누었습니다. 웨비나를 놓치신 분들을 위해 핵심 내용을 상세히 정리해 드립니다.
우리는 매일 수많은 오픈소스와 라이브러리에 의존해 소프트웨어를 개발합니다. 하지만 우리가 의존하는 그 코드를 식별하는 방식은 생각보다 불안정합니다.
v1.0이라는 태그는 개발자가 덮어쓰기 나름입니다. 어제 다운로드한 v1.0과 오늘 다운로드한 v1.0이 100% 같다고 보장할 수 있을까요?Thomas Aynaud는 이 문제를 해결하기 위해 ‘고유 식별자(Intrinsic Identifier)‘의 개념을 소개했습니다.
이것이 이번 웨비나의 핵심 개념입니다.
SWHID는 바로 이 ‘내재적 식별자’입니다. 중앙 관리 기구 없이도 소프트웨어 아티팩트의 무결성을 수학적으로 보장합니다.
SWHID는 단순한 난수가 아닙니다. 체계적인 구조를 가진 문자열입니다. 웨비나에서 소개된 SWHID의 표준 구조를 살펴보겠습니다.
textswh:1:cnt:94a9ed024d3859793618152ea559a168bbcbb5e2
이 식별자는 다음과 같이 3부분으로 나뉩니다.
swh:1): 이것이 SWHID이며 버전 1이라는 뜻입니다.cnt (Content): 파일 내용 그 자체 (Blob)dir (Directory): 파일과 하위 디렉토리 구조rev (Revision): 특정 시점의 커밋 (작성자, 날짜 정보 포함)rel (Release): 특정 릴리즈 (태그 등)snp (Snapshot): 저장소의 전체 상태 (모든 브랜치와 태그 포함)Merkle DAG (머클 트리) 구조
SWHID는 파일 하나만 식별하는 게 아닙니다. 파일들이 모여 디렉토리가 되고, 디렉토리가 모여 커밋이 되는 전체 구조를 수학적으로 연결합니다. 파일 하나라도 내용이 1비트만 바뀌면, 상위 디렉토리와 커밋의 SWHID 값도 연쇄적으로 완전히 달라집니다. 이것이 바로 완벽한 무결성(Integrity)입니다.
Thomas Aynaud는 SWHID가 단순한 아카이빙 도구를 넘어, 산업계의 핵심 인프라가 되고 있음을 강조했습니다.
SBOM(Software Bill of Materials)이 중요해지면서, “정확히 어떤 코드가 들어갔는가?“를 증명해야 합니다. SWHID를 사용하면 외부 저장소가 해킹당해 코드가 변조되더라도, 해시값이 달라지므로 즉시 탐지할 수 있습니다. EU Cyber Resilience Act (CRA)와 같은 규제 대응에 있어 SWHID는 가장 강력한 무기입니다.
오픈소스 프로젝트가 사라져도(폐기되더라도), Software Heritage는 전 세계의 코드를 크롤링하여 보관합니다(현재 260억 개 이상의 소스 파일 보관 중). SWHID만 있다면 원본 저장소가 사라져도 아카이브에서 정확히 그 코드를 찾아낼 수 있습니다. “깨지지 않는 링크"가 생기는 셈입니다
연구 논문에서 “GitHub의 X 프로젝트를 사용했다"라고 쓰는 것만으로는 부족합니다. 코드가 업데이트되면 연구 결과를 재현할 수 없기 때문입니다. SWHID를 사용하면 “정확히 이 버전의, 이 파일들을 사용했다"고 명시할 수 있어 연구의 신뢰도를 높일 수 있습니다.
2025년 4월, SWHID는 ISO/IEC 18670:2025라는 국제 표준이 되었습니다. 이것이 주는 의미는 큽니다.
웨비나의 제목인 “You will not be able to live without it"은 과장이 아니었습니다.
소프트웨어가 세상을 먹어치우고 있는 지금, 그 소프트웨어를 ‘정확하게 지칭하고’, ‘변조되지 않았음을 증명하고’, ‘영구적으로 보존하는’ 유일한 방법이 바로 SWHID이기 때문입니다.
더 이상 깨질 수 있는 URL에 의존하지 마세요. 이제는 코드의 지문, SWHID를 사용할 때입니다.
본 포스팅은 2025년 12월 3일 진행된 OpenChain 웨비나 내용을 바탕으로 작성되었습니다.
by Gemini 3.0
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가지와 전문가들의 제언을 상세히 정리해 드립니다.
개발자들은 npm, pip, maven 같은 패키지 매니저를 믿고 의존성을 설치합니다. 하지만 전문가들은 이 과정에 심각한 “투명성 부족” 문제가 있다고 지적했습니다.
패널들은 패키지 매니저가 제공하는 정보가 불완전하거나, 오래되었거나, 심지어 틀린 경우가 많다고 입을 모았습니다.
Mary Hardy는 ClearlyDefined와 같은 공공 데이터베이스의 활용을 제안했습니다. 이는 오픈소스 패키지의 실제 라이선스 정보를 스캔하고 사람이 검증한(Curated) 데이터를 제공하므로, 불확실한 패키지 매니저 정보보다 신뢰할 수 있는 기준점이 될 수 있습니다.
컨테이너는 기본적으로 이미 빌드된 ‘바이너리(Binary)’ 형태의 이미지입니다. 소스 코드가 없는 상태에서 바이너리만 보고 라이선스를 판별하는 것은 기술적으로 매우 어렵습니다.
Heather Meeker와 Mary Hardy는 AI 코딩 도구의 발전이 오히려 스캐닝 기술의 부활을 이끌 수 있다고 전망했습니다. AI가 코드의 출처를 추적하는 기술이 발전함에 따라, 바이너리의 기원을 찾아내는 기술도 함께 고도화될 것이라는 긍정적인 예측이 나왔습니다.
가장 근본적인 문제는 결국 “사람"에 있습니다. 개발자들이 컨테이너를 만들 때 라이선스 정보를 제대로 기입하지 않거나, 베이스 이미지(Base Image)의 법적 리스크를 고려하지 않는 관행이 지적되었습니다.
default로 설정된 라이선스(예: Apache)를 개발자가 의도치 않게 그대로 사용하는 경우가 많다. 실제로는 다른 라이선스를 써야 함에도 설정을 바꾸지 않아 잘못된 정보가 퍼진다.”이번 웨비나의 결론은 명확했습니다. “자동화 도구(Tooling)만으로는 아직 충분하지 않다"는 것입니다.
컨테이너는 편리하지만, 그 편리함 뒤에 숨겨진 ‘법적 부채’를 무시해서는 안 됩니다. 이번 웨비나는 그 부채를 어떻게 관리 가능한 수준으로 만들 것인가에 대한 중요한 이정표를 제시해주었습니다.
본 포스팅은 2025년 11월 7일 진행된 OpenChain 웨비나의 요약 및 패널 토의 내용을 바탕으로 재구성되었습니다.
by Gemini 3.0
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로 상세히 정리해 드립니다.
CRA는 단순한 권고 사항이 아닙니다. EU 시장에 출시되는 “디지털 요소가 포함된 모든 제품(Products with Digital Elements, PDE)“에 적용되는 강력한 규제입니다.
David Wheeler는 강조했습니다. “CRA는 EU 법이지만 사실상 글로벌 법이다.”
소프트웨어 시장은 국경이 없습니다. 당신이 한국이나 미국에서 개발했더라도, 그 결과물이 유럽 시장에 배포된다면 CRA 준수 의무가 발생합니다.
CRA에서 가장 헷갈리면서도 중요한 부분은 “내가 어떤 역할로 정의되는가"입니다. 역할에 따라 의무가 천지 차이이기 때문입니다.
가장 무거운 책임을 지는 주체입니다.
이번 최종 법안에 새로 추가된 중요한 개념입니다.
만약 당신이 Manufacturer로 분류된다면, 다음의 의무를 반드시 지켜야 합니다.
David Wheeler는 “지금 당장 준비하지 않으면 나중에 패닉에 빠질 것"이라고 경고하며 3가지 액션 플랜을 제시했습니다.
Linux Foundation과 OpenSSF가 만든 무료 교육 코스가 있습니다. 이 코스를 듣고 수료 배지를 따세요. 팀원들에게도 듣게 하세요.
개발자들이 보안 코딩을 할 줄 알아야 합니다.
CRA는 매우 높은 수준의 요구사항만 명시하고, 구체적인 기술적 방법은 “표준(Standards)“을 따르라고 합니다. 현재 CEN/CENELEC이 표준을 만들고 있습니다. 이 표준을 준수하면 법을 준수한 것으로 간주(Presumption of Conformity)되므로, 관련 표준 동향을 예의주시해야 합니다.
CRA는 귀찮은 규제일 수 있지만, 반대로 생각하면 “보안이 검증된 소프트웨어"라는 품질 보증 마크가 될 수 있습니다.
2027년은 멀어 보이지만, 제품 개발 사이클을 고려하면 내일부터 당장 준비해야 합니다. 지금 바로 팀 내에서 “우리는 Manufacturer인가?“라는 질문부터 시작해 보세요.
본 포스팅은 2025년 9월 16일 진행된 OpenChain 웨비나 내용을 바탕으로 재구성되었습니다.
by Gemini 3.0
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이 제시하는 명쾌한 해답을 정리해 드립니다.
컨테이너 기술(Docker 등)은 소프트웨어 배포를 단순화시켰지만, 라이선스 관리 측면에서는 새로운 난관을 만들었습니다. Caren Kresse는 크게 두 가지 핵심 문제를 지적했습니다.
컨테이너는 여러 개의 레이어가 쌓여서 하나의 이미지를 만듭니다. 우리는 보통 FROM ubuntu:latest 처럼 베이스 이미지를 가져다 쓰고, 그 위에 우리만의 애플리케이션을 얹습니다.
Docker Hub 등에서 쉽게 다운로드할 수 있는 대부분의 베이스 이미지들은 ‘실행’을 위한 바이너리만 제공할 뿐, 라이선스 고지문이나 소스 코드(GPL 의무 등)와 같은 컴플라이언스 자료는 포함하고 있지 않습니다.
OSADL은 “모두가 공통으로 쓰는 베이스 이미지라면, 컴플라이언스 작업도 한 번만 해서 공유하면 되지 않을까?“라는 아이디어로 이 프로젝트를 시작했습니다.
OSADL Base Image는 단순한 OS 이미지가 아닙니다. “모든 법적 정보와 컴플라이언스 자료가 이미 완벽하게 포함된” 컨테이너 베이스 이미지입니다.
웨비나에서는 OSADL Base Image가 생성되는 4단계 기술적 프로세스가 상세히 공개되었습니다.youtube
최소화된 환경 구축 (Minimal Setup):
debootstrap(Debian/Ubuntu)이나 apk static(Alpine) 같은 도구를 사용해 꼭 필요한 패키지만 포함된 최소한의 파일 시스템(chroot 환경)을 만듭니다. 불필요한 패키지를 줄여 이미지 크기를 최소화합니다.
라이선스 스캔 및 큐레이션 (Scan & Curation):
이미지에 포함된 모든 소스 패키지를 다운로드한 뒤, FOSSology와 같은 스캐너를 돌립니다. 이때 OSADL이 관리하는 큐레이션 데이터베이스(OSSelot)를 활용해 스캔 결과의 정확도를 높이고 오탐(False Positive)을 제거합니다.
컴플라이언스 자료 생성 (Compliance Material):
스캔 결과를 바탕으로 SPDX 리포트, 라이선스 고지문(Legal Notices)을 생성합니다. 사용자가 컨테이너를 실행할 때 법적 정보를 확인할 수 있도록 시작 메시지 등에 포함시킵니다.
이미지 빌드 (Build):
최종적으로 이 모든 정보가 담긴 파일 시스템을 컨테이너 이미지로 빌드하여 배포합니다.
OSADL Base Image는 사용자의 상황에 맞춰 두 가지 버전을 제공합니다.
여러분의 회사가 컨테이너를 배포한다면, 베이스 이미지의 라이선스 분석에 시간을 낭비하지 마세요. 이미 OSADL이 법적으로 검토를 마친 OSADL Base Image를 FROM으로 불러와 사용하면 됩니다. 여러분은 그 위에 얹는 여러분의 애플리케이션에 대한 컴플라이언스만 신경 쓰면 됩니다.
이것이 바로 오픈소스의 정신인 “공유와 협력"을 컴플라이언스 영역에 적용한 모범 사례입니다.
본 포스팅은 2025년 9월 12일 진행된 OpenChain 웨비나 내용을 바탕으로 작성되었습니다.
이번 웨비나의 발표자는 Armijn Hemel입니다. 그는 Tjaldur Software Governance Solutions의 소유주로, 오픈소스 라이선스 컴플라이언스 엔지니어링과 출처 연구 분야의 전문 컨설팅 회사를 운영하고 있습니다. Hemel은 오픈소스 라이선스 컴플라이언스 분야에서 오랜 경험을 가지고 있으며, GPL-violations.org 프로젝트와 Binary Analysis Tool 및 Binary Analysis Next Generation 도구 개발에 참여한 바 있습니다.
이번 웨비나는 OpenChain Project의 14번째 웨비나로, 지난 4년간 90회 이상의 웨비나를 진행해왔습니다. 이번 세션에서는 Armijn Hemel이 개발 중인 ‘DeviceCode’라는 프로젝트에 대해 소개합니다. DeviceCode는 다양한 위키에서 크라우드소싱된 디바이스 데이터를 파싱하고 정리하는 도구입니다.
전자제품 시장에서 많은 소비자들은 브랜드에 따라 제품의 품질이 다르다고 생각합니다. 하지만 실제로는 여러 브랜드의 제품들이 동일한 ODM(Original Design Manufacturer)에서 생산되거나 같은 칩셋 제조업체의 소프트웨어를 사용하는 경우가 많습니다. 이는 마치 주유소에서 판매하는 휘발유가 실제로는 같은 정제소에서 생산된 것과 비슷한 상황입니다.
현재 CVE(Common Vulnerabilities and Exposures)는 개별 디바이스에 초점을 맞추고 있어, 동일한 취약점을 가진 다른 제품들이 간과되는 경우가 많습니다. 예를 들어, CVE-2006-2560과 CVE-2006-2561은 서로 다른 벤더의 제품에 대한 동일한 취약점을 설명하고 있지만, 실제로는 같은 ODM에서 생산된 제품일 가능성이 높습니다.
디바이스의 하드웨어 정보, 특히 사용된 ODM이나 칩셋에 대한 정보는 쉽게 접근할 수 없습니다. 기업들은 이러한 정보를 공개하지 않는 경향이 있어, 제품의 실제 내부 구성을 파악하기 어렵습니다.
DeviceCode는 다음과 같은 다양한 소스에서 데이터를 수집합니다:
DeviceCode는 다음과 같은 기능을 제공합니다:
Hemel은 위키의 덤프 파일을 다운로드하여 파이썬 스크립트로 처리합니다. 이 과정에서 데이터 정리와 통합 작업이 이루어집니다. 위키 사용자들이 데이터를 일관성 없이 입력하는 경우가 많아 이를 정리하는 작업이 필요합니다.
FCC 웹사이트에서 제공하는 문서들을 다운로드하여 분석합니다. 이 문서들에는 사용자 매뉴얼 등이 포함되어 있어, GPL 라이선스 제안 등의 정보를 추출할 수 있습니다.
위키 데이터와 FCC 문서에서 얻은 정보를 통합하여 하나의 JSON 파일로 출력합니다. 이 과정에서 서로 다른 소스의 정보를 비교하고 통합하는 작업이 이루어집니다.
현재 DeviceCode의 데이터는 주로 위키와 FCC 문서에 의존하고 있어 완전하지 않습니다. 향후 더 많은 데이터 소스를 통합하고, 기업들이 자발적으로 정보를 제공할 수 있도록 하는 것이 과제입니다.
Hemel은 현재 이 프로젝트의 상업적 가치에 대해 확신하지 못하고 있습니다. 하지만 inlets foundation의 지원을 받아 개발을 진행 중이며, 향후 더 많은 투자를 유치할 방안을 모색 중입니다.
DeviceCode는 AboutCode 프로젝트의 일부로 통합될 예정입니다. 이를 통해 ScanCode, VulnerableCode 등 다른 오픈소스 도구들과의 연계가 가능해질 것으로 기대됩니다.
Q: 위키에 정보를 입력하는 사람들의 동기는 무엇인가요? A: 일부 사람들은 데이터 수집에 대한 강박적인 취미를 가지고 있습니다. 또한 자신의 디바이스 내부를 알고 싶어 하거나, 대체 펌웨어를 만들고자 하는 사람들도 있습니다.
Q: 이 데이터를 상업적으로 활용할 수 있는 방안이 있나요? A: 현재로서는 상업적 가치에 대해 확신하지 못하고 있습니다. 하지만 수리 업체들이 이러한 정보에 관심을 가질 수 있을 것 같습니다.
Q: JSON 형식의 데이터 구조는 문서화되어 있나요? A: GitHub 저장소에 문서화가 되어 있어 쉽게 통합할 수 있을 것입니다. 또한 데이터셋도 제공하고 있어 바로 사용해볼 수 있습니다.
공급망 투명성 향상: DeviceCode는 기업이 사용하는 디바이스의 실제 구성 요소와 소프트웨어를 더 잘 이해할 수 있게 해줍니다. 이는 SBOM(Software Bill of Materials) 관리에 도움이 될 수 있습니다.
취약점 관리 개선: 특정 디바이스의 취약점이 발견되었을 때, 유사한 다른 디바이스들도 같은 취약점을 가지고 있을 가능성을 쉽게 파악할 수 있습니다. 이는 보안 관리를 더욱 효과적으로 만들어줍니다.
규제 준수 지원: EU의 CRA(Cyber Resilience Act)나 제품 책임 지침 등의 규제 준수를 위한 기초 자료로 활용될 수 있습니다.
비용 절감: 동일한 하드웨어나 소프트웨어를 사용하는 디바이스들을 파악함으로써, 중복 투자를 줄이고 효율적인 관리가 가능해집니다.
DeviceCode 프로젝트 모니터링: 이 프로젝트의 발전 상황을 지속적으로 모니터링하고, 기업에 적용 가능한 시점을 파악합니다.
데이터 기여 검토: 기업이 보유한 디바이스 정보를 DeviceCode 프로젝트에 기여할 수 있는지 검토합니다. 이는 전체 생태계의 발전에 도움이 될 수 있습니다.
내부 디바이스 인벤토리 구축: DeviceCode의 접근 방식을 참고하여, 기업 내부에서 사용 중인 디바이스들의 상세 정보를 체계적으로 관리하는 시스템을 구축합니다.
보안 팀과의 협력: DeviceCode에서 제공하는 정보를 활용하여, 보안 팀과 협력하여 잠재적 취약점을 사전에 파악하고 대응 방안을 마련합니다.
공급업체 관리 강화: DeviceCode를 통해 얻은 정보를 바탕으로, 공급업체들에게 더 상세한 디바이스 정보를 요구하고, 이를 계약 조건에 반영하는 것을 고려합니다.
오픈소스 컴플라이언스 프로세스 개선: DeviceCode가 제공하는 정보를 활용하여, 사용 중인 디바이스들의 오픈소스 소프트웨어 현황을 더 정확히 파악하고, 이에 따른 컴플라이언스 프로세스를 개선합니다.
정책 입안자들과의 소통: DeviceCode와 같은 프로젝트의 중요성을 정책 입안자들에게 알리고, 디바이스 정보의 투명성을 높이기 위한 정책적 지원을 요청합니다.
이 웨비나의 발표자는 Shane Coughlan으로, OpenChain 프로젝트의 총괄 매니저이자 오픈소스 및 표준화 분야에서 오랜 경력을 가진 전문가입니다. 그는 Free Software Foundation Europe의 법률 네트워크 창립자였으며, 오픈소스 라이선스 준수 및 지적재산권 관리에 깊은 전문성을 보유하고 있습니다. 또한, OpenChain 프로젝트를 통해 오픈소스 공급망 신뢰성을 높이는 데 기여하며 ISO/IEC 5230:2020 표준화를 성공적으로 이끌었습니다.
이번 웨비나는 “Creating Standards – From Writing a Spec to Obtaining ISO Status"라는 주제로 진행되었습니다. OpenChain ISO/IEC 5230:2020을 사례로 삼아, 빈 페이지에서 시작해 국제 표준으로 자리 잡기까지의 과정을 상세히 다룹니다. 특히, 다음과 같은 질문에 답을 제시합니다:
참석자들은 이 웨비나를 통해 자신만의 표준을 정의하고, 구축하며, 배포하는 방법을 배우게 됩니다.
OpenChain 프로젝트는 오픈소스 공급망에서 신뢰를 구축하기 위한 프로세스 관리 표준을 개발하는 글로벌 커뮤니티입니다. 이 프로젝트는 다음과 같은 문제를 해결하기 위해 시작되었습니다:
OpenChain은 이러한 문제를 해결하기 위해 간단하고 명확한 프로세스를 제시합니다:
OpenChain 프로젝트가 ISO 표준으로 발전한 과정은 다음과 같습니다:
2015년 Qualcomm 등 주요 기업들이 모여 공급망 내 공통 문제를 논의하며 시작되었습니다. 초기 목표는 기업들이 이미 보유한 경험과 지식을 바탕으로 간단하면서도 효과적인 프로세스를 정의하는 것이었습니다.
Wind River의 Mark Gisi가 초안 작성 책임자로 나서며 핵심 프로세스를 정리했습니다. 여러 기업이 제공한 교육 자료와 정책 템플릿을 분석하고 이를 최소 요구사항으로 압축하여 첫 번째 사양 초안을 완성했습니다.
2016년 첫 사양이 공개된 이후, 시장 피드백을 수집하며 지속적으로 개선했습니다. 이를 통해 언어적 명확성과 범위 조정을 거쳐 더욱 실용적인 문서로 발전시켰습니다.
Joint Development Foundation(JDF)의 지원을 받아 JTC-1 PAS Transposition Process를 통해 ISO 표준화를 추진했습니다. 이 과정에서 사양 포맷 조정, 제출 절차 이해 등 JDF와 협력하며 순조롭게 진행되었습니다.
2020년 OpenChain 사양은 ISO/IEC 5230으로 공식 인증받았습니다. 이는 오픈소스 라이선스 준수를 위한 최초의 국제 표준으로, 현재 다양한 산업에서 채택되고 있습니다.
Shane Coughlan은 성공적인 표준 개발을 위해 다음과 같은 원칙을 강조했습니다:
표준은 특정 문제를 해결하기 위한 도구여야 하며, 범위를 좁게 설정해야 합니다(OpenChain은 “What"에만 집중).
사용자 커뮤니티가 직접 참여하여 사양을 개발하고 개선하도록 유도해야 합니다.
기존 표준화 기구(BSI, DIN 등)와 협력하여 중복이나 충돌을 방지하고 상호 보완적인 관계를 구축해야 합니다.
시장 요구사항에 따라 지속적으로 사양을 업데이트하고 개선해야 합니다.
웨비나 말미에는 청중들의 질문이 이어졌습니다:
Q1: 기존 산업 표준과 충돌하지 않으면서 새로운 표준을 만드는 방법은?
A1: 기존 이해관계자와 협력하여 중복이나 충돌 가능성을 최소화해야 합니다. 예를 들어 OpenChain은 SC27(정보 기술 보안)과 협력하여 기존 작업과 겹치지 않도록 조율했습니다.
Q2: 에너지 산업처럼 보수적인 분야에서 혁신적 접근법을 도입하려면?
A2: 기존 이해관계자와 대화하며 신뢰를 구축하고, 새로운 아이디어를 점진적으로 도입해야 합니다. 또한, 초기에는 참고 구현(reference implementation)을 통해 실질적 효과를 입증하는 것이 중요합니다.
OpenChain 프로젝트는 오픈소스 커뮤니티와 전통적인 표준화 기구 간 협력을 통해 성공적으로 ISO 표준화를 달성했습니다. 이 사례는 다음과 같은 교훈을 제공합니다:
오픈소스 관리 담당자는 이러한 원칙을 바탕으로 자신만의 조직적 요구사항에 맞는 프로세스를 설계하고 실행할 수 있습니다.
ISO/IEC 5230은 복잡한 공급망 내에서 오픈소스 라이선스 준수를 간소화하고 신뢰성을 높이는 데 중요한 도구입니다. 이를 통해 기업은 다음과 같은 이점을 얻을 수 있습니다:
이를 통해 기업은 더욱 체계적이고 효율적인 오픈소스 관리 체계를 구축할 수 있을 것입니다!
source: https://openchainproject.org/news/2024/12/04/webinar-enabling-sboms-across-the-linux-foundation
이번 웨비나의 발표자는 OpenChain 프로젝트의 주요 멤버로, 오픈소스 라이선스 준수 및 보안 표준화에 깊은 전문성을 가진 전문가입니다. 그는 ISO/IEC 5230:2020 및 ISO/IEC 18974:2023 표준 개발 과정에 직접 참여했으며, 관련 법률 및 산업적 적용에 대한 풍부한 경험을 보유하고 있습니다.
이 웨비나는 ISO/IEC 5230(오픈소스 라이선스 준수)와 ISO/IEC 18974(오픈소스 보안 보증)가 법률 전문가들에게 미칠 영향을 중심으로 진행되었습니다. 특히, 2024년을 기준으로 이 표준들이 기업의 조달 협상, 인수합병(M&A), 공급망 관리에 어떤 변화를 가져올지에 대해 다루었습니다.
또한, 최근 CRA(Cyber Resilience Act)와 SPDX ISO/IEC 5962와 같은 인접 표준의 발전이 이들 표준에 어떤 영향을 미칠지 설명하며, 기존 자료와 커뮤니티 지원, 상업적 제공자들의 도움을 활용하는 방법도 제시했습니다. 마지막으로 AI 컴플라이언스(OpenChain Study Group)와 같은 새로운 연구 그룹의 등장도 논의되었습니다.
ISO/IEC 5230은 오픈소스 소프트웨어 사용 시 라이선스 준수를 위한 국제 표준입니다. 이 표준은 기업이 오픈소스를 사용할 때 발생할 수 있는 법적 리스크를 줄이고, 체계적인 관리 시스템을 구축하도록 돕습니다. 특히, 조달 프로세스에서 명확한 라이선스 조건을 확인하고 준수하는 데 중요한 역할을 합니다.
ISO/IEC 18974는 오픈소스 소프트웨어의 보안 보증을 다룬 새로운 국제 표준입니다. 이 표준은 공급망 전반에서 오픈소스 소프트웨어의 보안 상태를 평가하고 관리하는 데 초점을 맞추고 있습니다. 특히, 최근 증가하는 사이버 공격 위협 속에서 기업이 안전한 소프트웨어를 제공받고 유지할 수 있도록 돕습니다.
이 두 표준은 법률 전문가들에게 여러 가지 중요한 영향을 미칩니다:
CRA와 같은 규제 변화는 이러한 표준 준수를 더욱 중요하게 만들고 있으며, SPDX와 같은 다른 표준들과 함께 적용될 가능성이 높습니다.
웨비나 중 청중들은 다음과 같은 질문을 했습니다:
ISO 인증 프로세스는 얼마나 복잡한가요?
AI 관련 연구 그룹은 어떤 역할을 하나요?
발표자는 ISO/IEC 5230과 ISO/IEC 18974가 점차 더 많은 기업에서 필수적인 기준으로 자리 잡을 것이라고 전망했습니다. 특히, AI 기술 및 자동화 도구가 이러한 표준 준수를 지원하면서 더 많은 기업들이 이를 채택할 것으로 예상됩니다.
또한, OpenChain 프로젝트는 지속적으로 새로운 참고 자료와 가이드를 제공하며, 기업들이 변화하는 규제 환경에 적응하도록 도울 것입니다.
ISO/IEC 5230과 ISO/IEC 18974는 오픈소스를 사용하는 모든 기업에게 필수적인 가이드라인을 제공합니다. 이를 통해 법적 리스크를 줄이고, 보안 수준을 강화하며, 공급망 전체에서 투명성과 신뢰성을 확보할 수 있습니다.
이를 통해 변화하는 규제 환경에 효과적으로 대응하고 경쟁력을 유지할 수 있을 것입니다.
source: https://openchainproject.org/news/2024/12/12/webinar-chaoss-practitioner-guides
이번 웨비나의 발표자는 Dawn Foster로, 오픈소스 커뮤니티와 데이터 과학 분야에서 오랜 경력을 쌓아온 전문가입니다. Dawn은 CHAOSS 프로젝트의 데이터 과학 리더이자 이사회 멤버로 활동 중이며, CNCF Contributor Strategy Technical Advisory Group의 공동 의장 및 OpenUK 이사로도 활약하고 있습니다. 그녀는 오픈소스 프로젝트의 건강성과 지속 가능성을 개선하기 위해 데이터 기반 접근 방식을 제안하며, CHAOSS 프로젝트 내 다양한 활동을 이끌고 있습니다.
이번 웨비나는 CHAOSS 프로젝트가 개발한 Practitioner Guides를 중심으로 진행되었습니다. 이 가이드는 오픈소스 소프트웨어(OSS) 프로젝트와 커뮤니티의 지속 가능성을 개선하기 위해 설계된 자료로, MIT 라이선스로 제공됩니다. 특히, 데이터 분석 경험이 많지 않은 사람들도 커뮤니티 메트릭을 활용해 의미 있는 통찰을 얻고 실행 가능한 개선 방안을 도출할 수 있도록 돕는 것을 목표로 합니다.
웨비나에서는 다음과 같은 핵심 주제를 다뤘습니다:
CHAOSS는 Community Health Analytics for Open Source Software의 약자로, 오픈소스 소프트웨어 커뮤니티의 건강성을 측정하고 개선하기 위한 메트릭과 도구를 개발하는 Linux Foundation 산하 프로젝트입니다.
CHAOSS는 단순히 코드 기여만이 아니라 문서화, 커뮤니티 관리 등 다양한 기여 형태를 중요하게 생각하며, 이를 통해 OSS 프로젝트의 건강성과 지속 가능성을 강화하려고 합니다.
응답성은 OSS 프로젝트가 기여자들의 요청(예: Pull Request)에 얼마나 신속하게 대응하는지를 측정합니다.
기여자 지속 가능성은 프로젝트가 장기적으로 충분한 기여자를 확보하고 유지할 수 있는 능력을 측정합니다.
조직별 참여 데이터를 분석해 특정 회사에 지나치게 의존하지 않도록 하는 것이 중요합니다.
보안은 OSS 프로젝트의 지속 가능성과 신뢰도를 결정짓는 중요한 요소입니다.
security.md 파일에 취약점 보고 절차 명시.초기에는 메트릭보다 기본적인 인프라 구축(예: 컨트리뷰팅 가이드 작성)에 집중하는 것이 좋습니다. 다만, 데이터를 꾸준히 수집해 3~6개월 후부터 트렌드를 분석하는 것이 효과적입니다.
CHAOSS의 Augur와 GrimoireLab 외에도 GitHub Insights, OpenSauced 등 다양한 도구가 있습니다. 간단한 분석에는 GitHub API를 활용하는 것도 추천됩니다.
CHAOSS Practitioner Guides는 OSS 프로젝트와 커뮤니티가 직면한 다양한 문제를 해결하기 위한 실질적인 지침을 제공합니다.
CHAOSS는 단순히 데이터를 제공하는 것을 넘어, 이를 통해 실질적인 변화를 이끌어내는 데 초점을 맞추고 있습니다. 기업과 개인 모두 이러한 접근법을 활용해 OSS 생태계를 더욱 건강하고 지속 가능하게 만들 수 있을 것입니다!
source: https://openchainproject.org/news/2024/12/04/webinar-enabling-sboms-across-the-linux-foundation
Gary O’Neall은 SPDX 표준에 기여한 전문가로, 오픈소스 소프트웨어의 구성요소, 라이선스, 저작권, 보안 참조 정보를 전달하는 데 중점을 둔 표준을 개발해왔습니다. 그는 Source Auditor Inc.에서 제품 개발 및 기술을 담당하며, 오픈소스 소프트웨어의 기술적 및 법적 위험 관리를 돕는 도구를 개발하고 있습니다.
Jeff Shapiro는 리눅스 재단의 라이선스 스캐닝 디렉터로, 30년 이상의 소프트웨어 산업 경험을 보유하고 있습니다. 그는 오픈소스 스캐닝 및 OSS(오픈소스 소프트웨어) 라이선스 준수 교육에 전문성을 가지고 있으며, 현재 리눅스 재단에서 중요한 프로젝트들의 코드 관리와 SBOM 생성에 기여하고 있습니다.
이번 웨비나는 리눅스 재단(Linux Foundation)에서 **SBOM(Software Bill of Materials)**을 활성화하는 과정을 설명하고, 이를 통해 오픈소스 프로젝트의 라이선스 준수 및 보안 관리 방안을 제시하는 것을 목표로 합니다.
리눅스 재단은 기존의 소스 코드 레벨 라이선스 스캐닝 경험을 바탕으로 SBOM을 생성하며, 정부 규제 기준(CISA NTIA Minimum Specification)을 충족하거나 초과하는 SBOM을 제공하고자 합니다.
SBOM은 소프트웨어 구성요소와 의존성을 추적하여 보안 취약점과 라이선스를 관리하는 데 필수적인 도구로, 이번 웨비나는 다음과 같은 내용을 다룹니다:
SBOM은 소프트웨어 구성요소를 추적하여 보안 취약점과 라이선스 준수를 관리하는 데 사용됩니다. 이는 소프트웨어의 “재료 목록"으로 비유되며, 다음과 같은 특징을 가집니다:
리눅스 재단은 1,000개 이상의 프로젝트를 호스팅하며, 이들 프로젝트가 중요한 인프라를 지원하기 때문에 SBOM은 특히 중요합니다.
리눅스 재단은 개발 단계에서 “Source-level SBOM"을 생성합니다. 이는 빌드 단계에서 생성되는 “Build-level SBOM"과는 차이가 있지만, 다음과 같은 장점이 있습니다:
리눅스 재단은 Trivy, Scaffold, Parlay 등의 오픈소스 도구를 활용하여 자동화된 SBOM 생성을 진행하며, 이를 통해 정부 규제 기준을 충족하는 결과물을 제공합니다.
리눅스 재단은 현재 소스 코드와 의존성 데이터를 통합하여 “Unified SBOM"을 개발 중입니다. 이는 다음 단계를 포함합니다:
향후 모든 리눅스 재단 프로젝트에 대해 자동화된 SBOM 생성을 목표로 하고 있습니다.
LF Minimum SBOM Spec에 기여하려면?
SPDX 3.x 전환 계획?
도구 체인을 SDLC에 어떻게 매핑하나요?
SBOM 도입 계획 수립:
빌드 단계 통합 검토:
커뮤니티 참여:
규제 변화 모니터링:
SBOM은 단순한 기술 트렌드를 넘어 기업의 법적/보안적 안정성을 강화하는 핵심 요소로 자리잡고 있습니다.
Shane Coughlan은 OpenChain Project의 General Manager로, 오픈소스 표준화와 관련된 글로벌 리더십을 제공하고 있습니다. 그는 오픈소스 생태계에서의 라이선스 준수 및 보안 보증을 위한 국제 표준 개발에 주력하며, InnerSource와 같은 새로운 소프트웨어 개발 방식에도 이를 적용하는 방법을 모색하고 있습니다.
이번 웨비나는 InnerSource Commons Summit 2024에서 진행된 세션으로, OpenChain ISO/IEC 5230(오픈소스 라이선스 준수 국제 표준)와 ISO/IEC 18974(오픈소스 보안 보증 국제 표준)가 InnerSource 프로그램에 어떻게 기여할 수 있는지를 다룹니다.
InnerSource는 내부 협업과 코드 공유를 통해 혁신을 촉진하는 소프트웨어 개발 접근법입니다. 본 발표는 내부 공급망 관리에서 ISO 표준을 활용해 효율성을 높이고, 외부 공급망과의 일관성을 유지하며, 프로세스 불일치로 인한 문제를 최소화하는 방법을 제시합니다.
InnerSource는 조직 내부에서 오픈소스 개발 방식을 채택하여 협업과 혁신을 촉진합니다. 그러나 내부 공급망 관리에서도 외부 공급망과 동일한 수준의 프로세스 관리가 필요합니다.
OpenChain 프로젝트는 글로벌 커뮤니티 중심으로 운영되며, 다양한 지원 자료를 제공합니다:
ISO 표준은 InnerSource 프로그램이 내부 및 외부 공급망 모두에서 일관성과 효율성을 유지할 수 있도록 돕습니다. 이를 통해 조직은 다음과 같은 이점을 얻을 수 있습니다:
ISO 표준은 단순히 규정을 따르는 것을 넘어, 조직이 지속 가능한 소프트웨어 개발 문화를 구축하는 데 핵심적인 역할을 합니다.
source: https://openchainproject.org/news/2024/10/29/webinar-sbom-visualization
이번 웨비나의 발표자는 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가 공동으로 수행했습니다.
오늘날 소프트웨어 개발에서 오픈소스는 필수적인 요소가 되었습니다. 2012년경에는 일반적인 프로젝트에서 약 200개의 오픈소스 컴포넌트를 사용했지만, 최근에는 그 수가 3,000개 이상으로 증가했습니다. 이러한 증가는 패키지 관리자의 발전, 작은 컴포넌트들의 사용 증가, 새로운 생태계(npm, Ruby gems, pip 등)의 등장 등 여러 요인에 기인합니다.
이렇게 많은 컴포넌트를 관리하는 것은 매우 복잡한 작업입니다. 라이선스 의무, 보안 취약점, 수출 제한, 운영 위험 등 다양한 측면을 고려해야 합니다. 기존의 리스트 형태의 SBOM으로는 이러한 복잡성을 효과적으로 관리하기 어렵습니다.
이러한 문제를 해결하기 위해 SBOM 시각화 도구가 개발되었습니다. 이 도구는 SBOM의 복잡한 정보를 직관적이고 이해하기 쉬운 그래픽으로 표현합니다. 마치 지리적 요소를 보여주는 지도처럼, SBOM 시각화는 소프트웨어의 다양한 컴포넌트와 그들 간의 관계, 특성을 보여줍니다.
SBOM 시각화 도구는 다양한 시각적 요소를 사용하여 복잡한 정보를 표현합니다:
팝업 메뉴를 통해 소프트웨어 이름, 계층 구조, 라이선스 유형, 전체 라이선스 텍스트, URL, 취약점 목록, 영향을 받는 파일, 저작권 정보 등 추가 정보를 제공합니다.
발표자는 Google Chromium 프로젝트를 예로 들어 SBOM 시각화 도구의 실제 적용을 보여주었습니다. Chromium은 매우 큰 프로젝트로, 수많은 컴포넌트로 구성되어 있습니다.
Q: 이 도구를 직접 테스트해볼 수 있나요? A: 현재 도구는 오픈소스로 공개되지 않았지만, 11월이나 12월경에 공개할 예정입니다. 그 전에 테스트해보고 싶으신 분들은 개인적으로 연락 주시면 도와드리겠습니다.
Q: AI로 생성된 코드를 어떻게 식별하나요? A: 현재로서는 자동으로 식별하는 메커니즘은 없습니다. 이 정보가 제공되면 표시할 수 있습니다.
Q: 특허 영향은 어떻게 정의되나요? A: Apache 라이선스와 같이 특허에 대한 조항이 있는 라이선스를 사용할 때 특허 영향이 있다고 표시합니다. 사용자가 직접 설정할 수도 있습니다.
Q: SPDX나 CycloneDX와 같은 표준 SBOM 형식에서 어떤 정보를 추출하나요? A: 시각화에 표시된 모든 정보와 팝업에 표시되는 추가 정보를 추출합니다. 일부 정보는 다른 도구를 통해 얻어야 할 수도 있습니다.
Q: 라이선스 분류는 어떻게 이루어지나요? A: 기본적인 분류를 제공하지만, 사용자가 직접 설정할 수 있습니다. 예를 들어, AGPL이나 GPL은 강한 카피레프트로, 다른 공개 라이선스는 약한 카피레프트로 분류합니다.
Q: 현재 데이터베이스에는 몇 개의 라이선스가 분석되어 있나요? A: 약 1,000개의 다른 라이선스가 데이터베이스에 있습니다.
SBOM 시각화 도구는 복잡한 소프트웨어 구성을 쉽게 이해하고 관리할 수 있게 해줍니다. 이는 마치 최신 내비게이션 시스템처럼 SBOM의 복잡한 “거리와 동네"를 탐색하는 데 도움을 줍니다. 이 도구의 주요 장점은 복잡한 정보를 명확하고 포괄적으로 제시하며, 상호작용이 가능하다는 것입니다.
소프트웨어 환경을 쉽게 탐색할 수 있게 해주며, 잠재적 위험을 빠르게 식별할 수 있습니다. 특히 내부 사용, SaaS, 제품 배포 등 다양한 사용 모델에 따라 오픈소스 사용의 영향이 다를 수 있는데, 이 도구를 통해 각 상황에 맞는 위험을 쉽게 파악할 수 있습니다.
이 SBOM 시각화 도구는 오픈소스로 공개될 예정이며, 향후 유럽 사이버 복원력 법(Cyber Resilience Act)에 대응하기 위한 프로젝트의 일부로 포함될 예정입니다.
source: https://openchainproject.org/news/2024/10/10/webinar-the-role-of-data-in-the-supply-chain-of-ai
Nick Schifano는 FastCatalog.ai의 CEO이자 창립자로, AI와 법적 프레임워크 분야의 전문가입니다. Microsoft에서 11년간 근무하며 기술 규제 및 AI/ML 법적 검토를 주도했으며, 특히 AI 모델 훈련에 필요한 데이터 사용 검토 시스템을 설계했습니다. 현재 FastCatalog.ai를 통해 AI 공급망 관리 기술과 서비스를 제공하고 있습니다.
이번 웨비나는 AI 공급망에서 데이터가 차지하는 역할과 관련된 주요 이슈를 다루며, 다음과 같은 주제를 중심으로 논의되었습니다:
Nick Schifano는 이러한 주제를 통해 기업들이 새로운 규제 환경에 대비하고 AI 공급망을 효과적으로 관리할 수 있도록 실질적인 가이드를 제공했습니다.
AI 시스템은 크게 네 단계로 나뉩니다:
AI 모델 훈련에는 다양한 형태의 데이터가 필요합니다:
Nick은 특히 공개 데이터셋과 오픈소스 모델이 제공하는 기회와 위험 요소를 강조하며, 각 구성 요소가 어떻게 AI 제품에 영향을 미치는지를 설명했습니다.
Nick은 다음과 같은 문제들을 지적했습니다:
Nick은 여러 지역에서 시행 중인 규제를 다음과 같이 요약했습니다:
GDPR처럼 EU AI Act가 글로벌 표준으로 자리 잡을 가능성을 논의했지만, 각 지역별로 상이한 접근 방식이 존재함을 강조했습니다.
오픈소스 및 공개 데이터를 사용하는 기업은 다음 사항을 고려해야 합니다:
이번 웨비나는 AI 공급망 관리에서 데이터를 중심으로 한 복잡한 문제들을 심도 있게 다루며 기업들이 직면할 수 있는 도전 과제를 명확히 했습니다. Nick Schifano는 기술적·법적 전문성을 바탕으로 실질적인 조언을 제공하며, 참석자들에게 큰 통찰을 안겨주었습니다.
source: https://openchainproject.org/featured/2024/09/27/webinar-ai-the-current-legal-landscape
AI: 현재의 법적 환경
이 웨비나는 OpenChain 커뮤니티에서 주최하는 AI 관련 법적 환경에 대한 논의의 연장선상에 있습니다. 지난해에 이어 GTC Law 팀이 생성형 AI를 둘러싼 현재의 법적 환경에 대해 포괄적으로 설명합니다. 이 웨비나의 목적은 AI 기술의 발전에 따른 법적 문제들을 살펴보고, 기업과 개발자들이 알아야 할 주요 사항들을 제공하는 것입니다.
많은 AI 도구들이 오픈소스 라이선스로 제공됩니다. 예를 들어:
Meta의 LLaMA 모델은 “오픈소스"라고 불리지만, 실제로는 상업적 라이선스에 가깝습니다. 특히 7억 명 이상의 활성 사용자를 가진 경우 별도의 라이선스가 필요하며, LLaMA의 출력을 다른 언어 모델 개선에 사용할 수 없다는 제한이 있습니다.
RAIL은 AI 기술의 비윤리적 사용을 제한하기 위해 만들어진 라이선스입니다. 주요 특징:
RAIL은 최근 많은 주목을 받고 있으며, MIT나 Apache 라이선스보다 더 많은 AI 모델에 적용되고 있습니다.
AI, 특히 생성형 AI 제공업체들을 상대로 한 소송이 증가하고 있습니다. 주요 소송 분야:
AI 규제는 크게 네 가지 유형으로 분류할 수 있습니다:
기존 법률 적용
일반 AI 규제
산업 또는 사용 사례별 AI 규제
정책 수립 중심
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: 이는 중요한 문제입니다. 도구 자체에만 의존하지 말고 인간의 판단을 병행해야 합니다. 캘리포니아의 새로운 규정은 자동화된 의사결정이 중요한 요소인 경우에도 규제 범위에 포함시키려 하고 있습니다. 이는 교육자가 도구에 과도하게 의존하는 경우에도 규제 대상이 될 수 있음을 의미합니다.
AI 기술과 오픈소스의 융합: 많은 AI 도구들이 오픈소스로 제공되고 있어, 오픈소스 관리의 중요성이 더욱 커지고 있습니다.
새로운 라이선스 유형 등장: RAIL과 같은 새로운 라이선스 유형이 등장하고 있어, 이에 대한 이해와 관리가 필요합니다.
법적 리스크 증가: AI 관련 소송이 증가하고 있어, 오픈소스 사용 시 법적 리스크에 대한 주의가 필요합니다.
데이터 보호 의무 강화: AI 사용에 따른 데이터 보호 의무가 강화되고 있어, 오픈소스 AI 도구 사용 시에도 이를 고려해야 합니다.
규제 환경 변화: AI 관련 규제가 빠르게 변화하고 있어, 이에 대한 지속적인 모니터링이 필요합니다.
AI 관련 오픈소스 라이선스 검토: 사용 중인 AI 도구들의 라이선스를 철저히 검토하고, 특히 RAIL과 같은 새로운 라이선스 유형에 주의를 기울입니다.
데이터 사용 정책 수립: AI 훈련에 사용되는 데이터의 출처와 사용 권한을 명확히 하는 정책을 수립합니다.
AI 사용 가이드라인 제정: 회사 내 AI 도구 사용에 대한 가이드라인을 만들어 법적 리스크를 최소화합니다.
정기적인 컴플라이언스 검토: AI 관련 법규 준수 여부를 정기적으로 검토하고 필요한 조치를 취합니다.
AI 윤리 정책 수립: