이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.
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 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 기술의 도입과 확산에 따른 새로운 도전에 효과적으로 대응할 수 있을 것입니다.
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을 효과적으로 활용하여 조직의 소프트웨어 관리 및 보안 체계를 강화할 수 있을 것입니다.
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 기술 가이드라인에 대해 논의했습니다. 이 가이드라인은 주로 공공 부문의 보안 관점에 초점을 맞추고 있습니다.
이번 웨비나의 발표자는 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 윤리 정책 수립: