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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

우리 회사가 허용하는 AI 도구는 무엇인가?
AI가 생성한 코드를 상용 제품에 포함시킬 때의 검수 절차는 무엇인가?
입력 데이터(프롬프트)에 회사 기밀을 넣지 않도록 하는 보안 지침은 무엇인가?
이처럼 구체적인 정책(Policy)과 허용 범위(Scope)를 먼저 합의하고 정의하는 것이 첫걸음입니다.

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

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

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

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

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

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

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

3줄 요약

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

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

by Gemini 3.0

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

2025-12-03 Software Hash ID you will not be able to live without it

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

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

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

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

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

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

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

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

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

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

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

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

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

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

textswh:1:cnt:94a9ed024d3859793618152ea559a168bbcbb5e2

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

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

Merkle DAG (머클 트리) 구조

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

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

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

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

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

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

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

3. 과학적 재현성 (Reproducibility)

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

4. ISO 표준화와 거버넌스

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

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

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

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

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

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

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

2025-11-07 Containers and Compliance

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

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

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

웨비나 개요

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2025-09-16 Introduction to the Cyber Resilience Act (CRA)

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

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

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

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

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

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

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

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

전 세계가 영향권입니다

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

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

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

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

Manufacturer (제조업체)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

보안 교육 이수

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

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

표준 준수

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

결론: 규제를 기회로

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

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

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

2025-09-12 Compliant containers with the OSADL Base Image

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

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

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

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

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

복잡한 계층(Layered) 구조

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

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

컴플라이언스 자료의 부재

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

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

2. 해결책: OSADL Base Image란?

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

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

주요 특징

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

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

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

최소화된 환경 구축 (Minimal Setup):
debootstrap(Debian/Ubuntu)이나 apk static(Alpine) 같은 도구를 사용해 꼭 필요한 패키지만 포함된 최소한의 파일 시스템(chroot 환경)을 만듭니다. 불필요한 패키지를 줄여 이미지 크기를 최소화합니다.
라이선스 스캔 및 큐레이션 (Scan & Curation):
이미지에 포함된 모든 소스 패키지를 다운로드한 뒤, FOSSology와 같은 스캐너를 돌립니다. 이때 OSADL이 관리하는 큐레이션 데이터베이스(OSSelot)를 활용해 스캔 결과의 정확도를 높이고 오탐(False Positive)을 제거합니다.
컴플라이언스 자료 생성 (Compliance Material):
스캔 결과를 바탕으로 SPDX 리포트, 라이선스 고지문(Legal Notices)을 생성합니다. 사용자가 컨테이너를 실행할 때 법적 정보를 확인할 수 있도록 시작 메시지 등에 포함시킵니다.
이미지 빌드 (Build):
최종적으로 이 모든 정보가 담긴 파일 시스템을 컨테이너 이미지로 빌드하여 배포합니다.

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

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

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

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

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

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

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

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

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

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

2024-12-20 DeviceCode - A Crowdsourced Device Data Parser

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

1. 발표자 소개

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

2. 웨비나 소개와 목적

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

3. DeviceCode 프로젝트 배경

3.1 시장의 현실

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

3.2 취약점 보고의 문제점

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

3.3 정보 접근의 어려움

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

4. DeviceCode의 구현 및 기능

4.1 데이터 소스

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

4.2 주요 기능

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

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

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

5.1 위키 데이터 처리

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

5.2 FCC 문서 분석

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

5.3 데이터 통합

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

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

6.1 데이터의 완전성

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

6.2 상업화 가능성

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

6.3 통합 및 확장

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

7. 질의응답

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

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

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

요약 보고서

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

공급망 투명성 향상: DeviceCode는 기업이 사용하는 디바이스의 실제 구성 요소와 소프트웨어를 더 잘 이해할 수 있게 해줍니다. 이는 SBOM(Software Bill of Materials) 관리에 도움이 될 수 있습니다.
취약점 관리 개선: 특정 디바이스의 취약점이 발견되었을 때, 유사한 다른 디바이스들에도 같은 취약점이 있을 가능성을 쉽게 파악할 수 있습니다. 이는 보안 관리를 더욱 효과적으로 만들어줍니다.
규제 준수 지원: EU의 CRA(Cyber Resilience Act)나 제품 책임 지침 등의 규제 준수를 위한 기초 자료로 활용될 수 있습니다.
비용 절감: 동일한 하드웨어나 소프트웨어를 사용하는 디바이스들을 파악함으로써, 중복 투자를 줄이고 효율적인 관리가 가능해집니다.

고려해야 할 Action Item

DeviceCode 프로젝트 모니터링: 이 프로젝트의 발전 상황을 지속적으로 모니터링하고, 기업에 적용 가능한 시점을 파악합니다.
데이터 기여 검토: 기업이 보유한 디바이스 정보를 DeviceCode 프로젝트에 기여할 수 있는지 검토합니다. 이는 전체 생태계의 발전에 도움이 될 수 있습니다.
내부 디바이스 인벤토리 구축: DeviceCode의 접근 방식을 참고하여, 기업 내부에서 사용 중인 디바이스들의 상세 정보를 체계적으로 관리하는 시스템을 구축합니다.
보안 팀과의 협력: DeviceCode에서 제공하는 정보를 활용하여, 보안 팀과 협력하여 잠재적 취약점을 사전에 파악하고 대응 방안을 마련합니다.
공급업체 관리 강화: DeviceCode를 통해 얻은 정보를 바탕으로, 공급업체들에게 더 상세한 디바이스 정보를 요구하고, 이를 계약 조건에 반영하는 것을 고려합니다.
오픈소스 컴플라이언스 프로세스 개선: DeviceCode가 제공하는 정보를 활용하여, 사용 중인 디바이스들의 오픈소스 소프트웨어 현황을 더 정확히 파악하고, 이에 따른 컴플라이언스 프로세스를 개선합니다.
정책 입안자들과의 소통: DeviceCode와 같은 프로젝트의 중요성을 정책 입안자들에게 알리고, 디바이스 정보의 투명성을 높이기 위한 정책적 지원을 요청합니다.

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

2024-12-16 Creating Standards – From Writing a Spec to Obtaining ISO Status

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

1. 발표자 소개

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

2. 웨비나 소개와 목적

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

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

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

3. OpenChain 프로젝트란?

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

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

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

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

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

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

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

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

4.2 사양 초안 작성

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

4.3 시장 피드백 반영

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

4.4 JTC-1 PAS Transposition Process 참여

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

4.5 ISO 인증 획득

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

5. 표준 개발의 핵심 원칙

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

5.1 명확한 목표 설정

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

5.2 커뮤니티 중심 접근

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

5.3 기존 이해관계자와 협력

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

5.4 실질적 피드백 반영

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

6. 청중 질의응답

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

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

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

7. 결론 및 주요 시사점

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

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

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

요약 보고서

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

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

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

고려해야 할 Action Items

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

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

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

2024-12-13, The Ramifications of ISO 5230 (Licensing) and ISO 18974 (Security) for Legal Professionals in 2024

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

1. 발표자 소개

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

2. 웨비나 소개와 목적

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

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

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

ISO/IEC 5230:2020

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

ISO/IEC 18974:2023

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

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

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

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

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

5. 청중과의 질의응답

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

ISO 인증 프로세스는 얼마나 복잡한가요?
- 발표자는 인증 프로세스가 체계적으로 설계되어 있으며, OpenChain 커뮤니티와 같은 지원 네트워크를 활용하면 쉽게 접근할 수 있다고 설명했습니다.
AI 관련 연구 그룹은 어떤 역할을 하나요?
- AI 컴플라이언스 연구 그룹은 AI 기술이 오픈소스 소프트웨어 및 라이선스를 준수하는 방식에 대해 연구하며, 향후 새로운 가이드라인을 제시할 예정입니다.

6. 앞으로의 전망

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

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

요약 보고서

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

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

고려해야 할 Action Item

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

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

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

2024-12-12, CHAOSS Practitioner Guides for Healthy & Sustainable OSS Projects

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

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

1. 발표자 소개

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

2. 웨비나 소개와 목적

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

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

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

3. CHAOSS 프로젝트 개요

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

주요 특징:

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

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

4. Practitioner Guide 주요 내용

4.1 Responsiveness (응답성)

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

중요성:

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

개선 방안:

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

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

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

중요성:

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

개선 방안:

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

4.3 Organizational Participation (조직 참여)

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

중요성:

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

개선 방안:

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

4.4 Security (보안)

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

중요성:

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

개선 방안:

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

5. 청중 질문과 답변

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

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

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

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

6. 결론 및 주요 시사점

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

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

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

Action Items:

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

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

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

2024-12-05, Enabling SBOMs Across The Linux Foundation

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

1. 발표자 소개

Gary O’Neall

Gary O’Neall은 SPDX 표준에 기여한 전문가로, 오픈소스 소프트웨어의 구성요소, 라이선스, 저작권, 보안 참조 정보를 전달하는 데 중점을 둔 표준을 개발해왔습니다. 그는 Source Auditor Inc.에서 제품 개발 및 기술을 담당하며, 오픈소스 소프트웨어의 기술적 및 법적 위험 관리를 돕는 도구를 개발하고 있습니다.

Jeff Shapiro

Jeff Shapiro는 리눅스 재단의 라이선스 스캐닝 디렉터로, 30년 이상의 소프트웨어 산업 경험을 보유하고 있습니다. 그는 오픈소스 스캐닝 및 OSS(오픈소스 소프트웨어) 라이선스 준수 교육에 전문성이 있으며, 현재 리눅스 재단에서 중요한 프로젝트들의 코드 관리와 SBOM 생성에 기여하고 있습니다.

2. 웨비나 소개와 목적

이번 웨비나는 리눅스 재단(Linux Foundation)에서 **SBOM(Software Bill of Materials)**을 활성화하는 과정을 설명하고, 이를 통해 오픈소스 프로젝트의 라이선스 준수 및 보안 관리 방안을 제시하는 것을 목표로 합니다.

리눅스 재단은 기존의 소스 코드 레벨 라이선스 스캐닝 경험을 바탕으로 SBOM을 생성하며, 정부 규제 기준(CISA NTIA Minimum Specification)을 충족하거나 초과하는 SBOM을 제공하고자 합니다.
SBOM은 소프트웨어 구성요소와 의존성을 추적하여 보안 취약점과 라이선스를 관리하는 데 필수적인 도구로, 이번 웨비나는 다음과 같은 내용을 다룹니다:

SBOM 생성 과정과 사용 도구
직면한 도전 과제와 해결 방안
향후 계획 및 커뮤니티 참여 방법

3. SBOM의 개념과 중요성

SBOM은 소프트웨어 구성요소를 추적하여 보안 취약점과 라이선스 준수를 관리하는 데 사용됩니다. 이는 소프트웨어의 “재료 목록"으로 비유되며, 다음과 같은 특징을 가집니다:

구성요소와 관계를 명확히 식별: 각 구성요소 간의 관계를 명확히 정의.
기계 판독 가능: 표준 형식(SPDX 등)을 사용하여 자동화 가능.
보안 및 라이선스 관리: 다운스트림 사용자에게 구성요소 정보 제공.

리눅스 재단은 1,000개 이상의 프로젝트를 호스팅하며, 이들 프로젝트가 중요한 인프라를 지원하기 때문에 SBOM은 특히 중요합니다.

4. 리눅스 재단의 SBOM 생성 과정

리눅스 재단은 개발 단계에서 “Source-level SBOM"을 생성합니다. 이는 빌드 단계에서 생성되는 “Build-level SBOM"과는 차이가 있지만, 다음과 같은 장점이 있습니다:

소스 코드와 메타데이터를 기반으로 구성요소 정보를 수집.
의존성 분석을 통해 라이선스 정보와 보안 취약점 데이터를 통합.

리눅스 재단은 Trivy, Scaffold, Parlay 등의 오픈소스 도구를 활용하여 자동화된 SBOM 생성을 진행하며, 이를 통해 정부 규제 기준을 충족하는 결과물을 제공합니다.

5. 주요 도구와 프로세스

주요 도구

Trivy: 의존성 분석 및 SPDX 파일 생성.
Scaffold: 스캔 작업 자동화 및 메타데이터 통합.
Parlay: 외부 메타데이터 추가(예: 보안 정보).
SPDX Tools: 최종 검증 및 표준 준수 확인.

프로세스 단계

생성(Generation): Trivy로 초기 SPDX 파일 생성.
증강(Augmentation): Scaffold로 프로젝트 메타데이터 추가.
강화(Enrichment): Parlay로 외부 데이터 추가.
검증(Validation): SPDX Tools로 표준 준수 확인.

6. SBOM 통합과 향후 계획

리눅스 재단은 현재 소스 코드와 의존성 데이터를 통합하여 “Unified SBOM"을 개발 중입니다. 이는 다음 단계를 포함합니다:

파일 수준 정보 추가: 파일 체크섬, 선언/결론된 라이선스, 저작권 텍스트 등.
SPDX 3.x 지원: 최신 표준 적용.
LFX 플랫폼 통합: GitHub 외에도 LFX 플랫폼에서 SBOM 제공.

향후 모든 리눅스 재단 프로젝트에 대해 자동화된 SBOM 생성을 목표로 하고 있습니다.

7. 청중 질의응답

주요 질문과 답변

LF Minimum SBOM Spec에 기여하려면?
- GitHub 이슈 또는 PR 제출 가능.
- 직접 이메일로 의견 전달도 환영.
SPDX 3.x 전환 계획?
- 현재 SPDX 2.3 사용 중이며, 도구가 업데이트되면 즉시 전환 예정.
도구 체인을 SDLC에 어떻게 매핑하나요?
- 리눅스 재단의 도구 체인은 개발 단계에서 정적 분석을 수행하며, 빌드 단계 이전에 라이선스 및 보안 상태를 사전 점검하는 역할을 합니다.

요약 보고서

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

라이선스 준수 강화: SBOM은 오픈소스를 사용하는 기업이 법적 위험을 줄이고 규정을 준수하도록 돕습니다.
보안 취약점 관리: 의존성 정보를 통해 잠재적 보안 위협을 사전에 식별 가능.
정부 규제 대응: CISA NTIA Minimum Specification 등 글로벌 규제를 충족할 수 있는 기반 마련.

고려해야 할 Action Items

SBOM 도입 계획 수립:
- 내부 소프트웨어 개발 프로세스를 분석하고 적절한 도구 선택.
- Trivy, Scaffold 등 오픈소스를 활용한 초기 테스트 권장.
빌드 단계 통합 검토:
- Build-level SBOM 생성을 위한 CI/CD 시스템 연계 방안 마련.
커뮤니티 참여:
- LF Minimum Spec 개선 작업에 기여하거나 관련 논의를 적극적으로 모니터링.
규제 변화 모니터링:
- 미국 CISA 외에도 EU 및 일본 등 글로벌 규제를 지속적으로 추적하여 대응 전략 수립.

SBOM은 단순한 기술 트렌드를 넘어 기업의 법적/보안적 안정성을 강화하는 핵심 요소로 자리잡고 있습니다.

11 - 2024-12-04 OpenChain ISO 표준이 InnerSource를 지원하는 방법 이해하기

2024-12-04, Understanding How OpenChain ISO/IEC 5230 and ISO/IEC 18974 Support InnerSource

source: https://openchainproject.org/news/2024/12/04/full-recording-understanding-how-openchain-iso-iec-5230-and-iso-iec-18974-support-innersource-innersource-commons-summit-2024

1. 발표자 소개

Shane Coughlan은 OpenChain Project의 General Manager로, 오픈소스 표준화와 관련된 글로벌 리더십을 제공하고 있습니다. 그는 오픈소스 생태계에서의 라이선스 준수 및 보안 보증을 위한 국제 표준 개발에 주력하며, InnerSource와 같은 새로운 소프트웨어 개발 방식에도 이를 적용하는 방법을 모색하고 있습니다.

2. 웨비나 소개와 목적

이번 웨비나는 InnerSource Commons Summit 2024에서 진행된 세션으로, OpenChain ISO/IEC 5230(오픈소스 라이선스 준수 국제 표준)와 ISO/IEC 18974(오픈소스 보안 보증 국제 표준)가 InnerSource 프로그램에 어떻게 기여할 수 있는지를 다룹니다.

InnerSource는 내부 협업과 코드 공유를 통해 혁신을 촉진하는 소프트웨어 개발 접근법입니다. 본 발표는 내부 공급망 관리에서 ISO 표준을 활용해 효율성을 높이고, 외부 공급망과의 일관성을 유지하며, 프로세스 불일치로 인한 문제를 최소화하는 방법을 제시합니다.

3. OpenChain ISO/IEC 5230 및 ISO/IEC 18974의 개요

OpenChain ISO/IEC 5230

목적: 오픈소스 라이선스 준수를 위한 프로세스 관리 표준 제공.
특징: 조직 규모에 관계없이 유연하게 적용 가능하며, 자체 인증(self-certification) 또는 제3자 인증(third-party certification)을 통해 준수 여부를 확인할 수 있음.
활용: 조직 내 라이선스 준수 정책 수립 및 실행에 필요한 기본 프레임워크 제공.

ISO/IEC 18974

목적: 오픈소스 보안 보증을 위한 프로세스 관리 표준 제공.
특징: 코드베이스의 보안 취약점을 식별하고 이를 관리하기 위한 정책과 절차를 포함.
활용: 내부 및 외부 공급망에서 보안 위험을 줄이고, 대응 속도를 높이는 데 기여.

4. InnerSource와의 연관성

InnerSource는 조직 내부에서 오픈소스 개발 방식을 채택하여 협업과 혁신을 촉진합니다. 그러나 내부 공급망 관리에서도 외부 공급망과 동일한 수준의 프로세스 관리가 필요합니다.

공급망 관리의 확장: 내부 팀 간 코드 공유도 하나의 공급망으로 간주되며, 이를 효과적으로 관리하기 위해 OpenChain ISO 표준이 적용될 수 있음.
프로세스 일관성: 내부에서 사용된 프로세스가 외부 공급망으로 확장될 때 번역이나 재구축 없이 그대로 활용될 수 있음.
InnerSource Program Office 지원: ISO 표준은 InnerSource Program Office가 효율적인 프로세스를 구축하고 운영하는 데 필요한 지침을 제공합니다.

5. ISO 표준의 실제 적용 사례

Adoption 사례

전 세계적으로 약 121개 기업이 OpenChain ISO/IEC 5230를 공식 채택했으며, 대표적으로 KT, 삼성 SDS 등이 포함됩니다.
독일에서는 PwC가 진행한 연구에 따르면, 대규모 기업(2,000명 이상) 중 약 31%가 해당 표준을 이미 사용하거나 도입 계획 중임.

인증 방식

자체 인증(Self-Certification):
- 체크리스트를 기반으로 기업이 자체적으로 준수 여부를 확인.
- 비용이 적고 빠르게 도입 가능.
제3자 인증(Third-Party Certification):
- 외부 인증 기관이 검증하여 신뢰도를 높임.
- 규제가 많은 산업에서 선호됨.

성공 사례

Bosch는 전체 기업 차원에서 OpenChain ISO/IEC 5230를 준수하며, 자체 인증 방식을 통해 효과적인 결과를 얻음.

6. 커뮤니티와 지원 자료

OpenChain 프로젝트는 글로벌 커뮤니티 중심으로 운영되며, 다양한 지원 자료를 제공합니다:

교육 자료: 오픈소스 교육 슬라이드 및 체크리스트 제공.
정책 템플릿: 조직별 요구사항에 맞춘 정책 작성 지원.
산업별 워크그룹: 자동차, 통신 등 특정 산업에 특화된 그룹 운영.
공식 파트너 프로그램: 도메인 전문성을 가진 파트너들과 협력하여 표준 채택 지원.

7. 결론 및 제안

ISO 표준은 InnerSource 프로그램이 내부 및 외부 공급망 모두에서 일관성과 효율성을 유지할 수 있도록 돕습니다. 이를 통해 조직은 다음과 같은 이점을 얻을 수 있습니다:

프로세스 최적화: 공급망 전반에 걸쳐 프로세스를 통합하여 중복 작업 제거.
리스크 감소: 라이선스 준수 및 보안 문제를 사전에 예방.
시장 출시 시간 단축: 문제 해결 시간을 줄이고 혁신 속도를 높임.

기업 담당자를 위한 Action Items:

조직 내 InnerSource Program Office 설립 또는 강화.
OpenChain ISO/IEC 5230 및 ISO/IEC 18974 도입 검토.
자체 인증 또는 제3자 인증 방식 선택 후 실행 계획 수립.
커뮤니티 활동 참여를 통해 최신 정보와 모범 사례 공유.

ISO 표준은 단순히 규정을 따르는 것을 넘어, 조직이 지속 가능한 소프트웨어 개발 문화를 구축하는 데 핵심적인 역할을 합니다.

12 - 2024-10-29 SBOM 시각화 - SBOM 검토를 위한 대안적 접근법

2024-10-29, SBOM Visualization – An Alternative Approach to Reviewing SBOMs

source: https://openchainproject.org/news/2024/10/29/webinar-sbom-visualization

1. 소개

발표자 소개

이번 웨비나의 발표자는 Bitsea GmbH의 창립자이자 CEO인 Andreas Kotulla 박사입니다. Andreas 박사는 소프트웨어 시스템 감사와 기업의 숨겨진 위험 식별 분야의 전문가입니다. 그는 기술 실사를 지원하고 주요 기반 시설(KRITIS) 운영자들에게 조언을 제공합니다. 또한 오픈소스 전략, 거버넌스, 프로세스, 툴체인에 대해 고객들에게 자문을 제공하며, 오픈소스 프로그램 오피스(OSPO) 및 스캐닝 관리 서비스를 제공합니다.

웨비나 소개와 목적

이 웨비나는 OpenChain Project 웨비나 시리즈의 일환으로 진행되었습니다. 이번 세션에서는 Software Build of Materials(SBOM)의 시각화에 대해 다룹니다. SBOM은 계층 구조, 연결, 수정, 수출 제한, 보안 취약점, 배포 유형, 버전 등 다차원적인 정보를 포함하고 있습니다. 이러한 복잡한 정보를 빠르고 이해하기 쉬운 방식으로 표시하기 위해 메타 정보의 시각화를 구현한 방법에 대해 논의합니다. 이 연구 프로젝트는 독일 연방 경제기후보호부(BMWi)의 지원을 받아 Bonn-Rhein-Sieg University of Applied Sciences와 Bitsea가 공동으로 수행했습니다.

2. SBOM의 중요성과 과제

오늘날 소프트웨어 개발에서 오픈소스는 필수적인 요소가 되었습니다. 2012년경에는 일반적인 프로젝트에서 약 200개의 오픈소스 컴포넌트를 사용했지만, 최근에는 그 수가 3,000개 이상으로 증가했습니다. 이러한 증가는 패키지 관리자의 발전, 작은 컴포넌트들의 사용 증가, 새로운 생태계(npm, Ruby gems, pip 등)의 등장 등 여러 요인에 기인합니다.

이렇게 많은 컴포넌트를 관리하는 것은 복잡한 작업입니다. 라이선스 의무, 보안 취약점, 수출 제한, 운영 위험 등 다양한 측면을 고려해야 합니다. 기존의 리스트 형태의 SBOM으로는 이러한 복잡성을 효과적으로 관리하기 어렵습니다.

3. SBOM 시각화 도구 소개

이러한 문제를 해결하기 위해 SBOM 시각화 도구가 개발되었습니다. 이 도구는 SBOM의 복잡한 정보를 직관적이고 이해하기 쉬운 그래픽으로 표현합니다. 마치 지리적 요소를 보여주는 지도처럼, SBOM 시각화는 소프트웨어의 다양한 컴포넌트와 그들 간의 관계, 특성을 보여줍니다.

시각화의 장점

빠른 개요 및 명확성: 소프트웨어 컴포넌트와 의존성을 시각적으로 표현하여 전체 구조를 직관적으로 이해할 수 있습니다.
간단한 탐색: 개발자와 프로젝트 관리자가 컴포넌트 간의 연결을 인식하고, 잠재적 약점을 식별하며, 변경의 영향을 이해하는 데 도움을 줍니다.
의존성 식별: 컴포넌트 간의 의존 관계, 잠재적 병목 현상이나 위험, 소프트웨어의 중요 부분을 쉽게 파악할 수 있습니다.
커뮤니케이션 및 협력 강화: 팀 전체가 동일한 SBOM 뷰를 공유함으로써 의사소통이 개선됩니다.
명확한 계획 수립: SBOM의 그래픽 표현은 소프트웨어 환경을 상세하고 포괄적으로 보여주는 지도 역할을 합니다.

4. 시각화 요소 및 기능

SBOM 시각화 도구는 다양한 시각적 요소를 사용하여 복잡한 정보를 표현합니다:

컴포넌트 표현

기본 형태: 컴포넌트는 이름과 제목이 있는 직사각형으로 표시됩니다.
스니펫 표시: 전체 컴포넌트가 아닌 일부만 사용된 경우, 직사각형의 일부가 잘린 형태로 표시됩니다.

라이선스 정보

색상 스키마: 신호등 체계를 사용하여 라이선스 의무를 표시합니다.
- 빨간색: 카피레프트 라이선스 (강한 카피레프트는 진한 빨간색, 약한 카피레프트는 연한 빨간색)
- 노란색: 특별한 특징이 있는 라이선스, 상업적 라이선스, 수정된 라이선스 등
- 초록색: 허용적 라이선스

보안 취약점

빨간색 정지 표지판: 알려진 보안 취약점이 있는 경우 표시됩니다.
숫자 표시: 알려진 취약점의 수를 표시합니다.

기타 정보

수출 제한: 느낌표가 있는 주의 표지로 표시
수정 여부: 작은 펜 아이콘으로 표시
법적 승인 여부: 파란색 물음표로 표시
특허 영향: 망치 아이콘으로 표시
운영 위험: 별 모양의 느낌표로 표시
AI 생성 코드: 상단의 파란색 막대로 표시

의존성 표현

정적 링킹: 실선으로 연결
동적 링킹: 점선으로 연결
Linux 시스템 콜: 노란색 느낌표로 표시

추가 정보

5. Chromium 프로젝트 사례 분석

발표자는 Google Chromium 프로젝트를 예로 들어 SBOM 시각화 도구의 실제 적용을 보여주었습니다. Chromium은 수많은 컴포넌트로 구성된 대규모 프로젝트입니다.

시각화 예시

전체 뷰: 처음에는 복잡해 보이지만, 필터링과 검색, 확대/축소 기능을 통해 쉽게 탐색할 수 있습니다.
확대 뷰: 개별 컴포넌트, 라이선스, 의존성 등을 자세히 볼 수 있습니다.
디렉토리 뷰: 컴포넌트의 계층 구조를 더 쉽게 이해할 수 있습니다.

필터링 및 시뮬레이션 기능

검색 필터: 특정 라이선스, 이름, 특성 등으로 컴포넌트를 검색할 수 있습니다.
보안 취약점 필터: 보안 취약점이 있는 컴포넌트만 표시할 수 있습니다.
카피레프트 라이선스 필터: 카피레프트 라이선스를 사용하는 컴포넌트만 표시할 수 있습니다.
라이선스 영향 시뮬레이션: 특정 라이선스의 영향을 받는 컴포넌트를 시각적으로 확인할 수 있습니다.
라이선스 비호환성 시뮬레이션: 호환되지 않는 라이선스 간의 충돌을 식별할 수 있습니다.

6. Q&A 세션

Q: 이 도구를 직접 테스트해볼 수 있나요? A: 현재 도구는 오픈소스로 공개되지 않았지만, 11월이나 12월경에 공개할 예정입니다. 그 전에 테스트해보고 싶으신 분들은 개인적으로 연락 주시면 도와드리겠습니다.

Q: AI로 생성된 코드를 어떻게 식별하나요? A: 현재로서는 자동으로 식별하는 메커니즘은 없습니다. 이 정보가 제공되면 표시할 수 있습니다.

Q: 특허 영향은 어떻게 정의되나요? A: Apache 라이선스와 같이 특허에 대한 조항이 있는 라이선스를 사용할 때 특허 영향이 있다고 표시합니다. 사용자가 직접 설정할 수도 있습니다.

Q: SPDX나 CycloneDX와 같은 표준 SBOM 형식에서 어떤 정보를 추출하나요? A: 시각화에 표시된 모든 정보와 팝업에 표시되는 추가 정보를 추출합니다. 일부 정보는 다른 도구를 통해 얻어야 할 수도 있습니다.

Q: 라이선스 분류는 어떻게 이루어지나요? A: 기본적인 분류를 제공하지만, 사용자가 직접 설정할 수 있습니다. 예를 들어, AGPL이나 GPL은 강한 카피레프트로, 다른 공개 라이선스는 약한 카피레프트로 분류합니다.

Q: 현재 데이터베이스에는 몇 개의 라이선스가 분석되어 있나요? A: 약 1,000개의 다른 라이선스가 데이터베이스에 있습니다.

7. 결론

SBOM 시각화 도구는 복잡한 소프트웨어 구성을 쉽게 이해하고 관리할 수 있게 해줍니다. 이는 마치 최신 내비게이션 시스템처럼 SBOM의 복잡한 “거리와 동네"를 탐색하는 데 도움을 줍니다. 이 도구의 주요 장점은 복잡한 정보를 명확하고 포괄적으로 제시하며, 상호작용이 가능하다는 것입니다.

소프트웨어 환경을 쉽게 탐색할 수 있게 해주며, 잠재적 위험을 빠르게 식별할 수 있습니다. 특히 내부 사용, SaaS, 제품 배포 등 다양한 사용 모델에 따라 오픈소스 사용의 영향이 다를 수 있는데, 이 도구를 통해 각 상황에 맞는 위험을 쉽게 파악할 수 있습니다.

이 SBOM 시각화 도구는 오픈소스로 공개될 예정이며, 향후 유럽 사이버 복원력 법(Cyber Resilience Act)에 대응하기 위한 프로젝트의 일부로 포함될 예정입니다.

13 - 2024-10-10 데이터가 AI 공급망에서 차지하는 역할

2024-10-10, The Role of Data in the Supply Chain of AI

source: https://openchainproject.org/news/2024/10/10/webinar-the-role-of-data-in-the-supply-chain-of-ai

1. 발표자 소개

Nick Schifano는 FastCatalog.ai의 CEO이자 창립자로, AI와 법적 프레임워크 분야의 전문가입니다. Microsoft에서 11년간 근무하며 기술 규제 및 AI/ML 법적 검토를 주도했으며, 특히 AI 모델 훈련에 필요한 데이터 사용 검토 시스템을 설계했습니다. 현재 FastCatalog.ai를 통해 AI 공급망 관리 기술과 서비스를 제공하고 있습니다.

2. 웨비나 소개와 목적

이번 웨비나는 AI 공급망에서 데이터가 차지하는 역할과 관련된 주요 이슈를 다루며, 다음과 같은 주제를 중심으로 논의되었습니다:

모델 계보와 훈련 데이터에 숨겨진 리스크
데이터 투명성의 중요성과 기업에 미치는 영향
AI 및 데이터 공급망 관리 전략
EU AI Act 등 새로운 규제에 대비하는 방법

Nick Schifano는 이러한 주제를 통해 기업들이 새로운 규제 환경에 대비하고 AI 공급망을 효과적으로 관리할 수 있도록 실질적인 가이드를 제공했습니다.

3. AI 공급망과 데이터의 중요성

3.1 AI 시스템 구축 과정

AI 시스템은 크게 네 단계로 나뉩니다:

소싱(Source): 훈련 데이터, 기존 모델, 훈련 프레임워크 등 필요한 자원을 확보.
구축(Build): 데이터를 사용해 모델을 훈련하거나 기존 모델을 미세 조정.
배포(Deploy): 완성된 모델을 클라우드, 온프레미스 또는 디바이스에 배포.
관리(Manage): 전체 프로세스를 지속적으로 모니터링하고 규제 준수 여부를 확인.

3.2 데이터의 역할

AI 모델 훈련에는 다양한 형태의 데이터가 필요합니다:

공개 데이터셋 (예: Common Crawl, Red Pajama)
오픈소스 모델 (예: Meta Llama)
훈련 프레임워크 (예: PyTorch, TensorFlow)

Nick은 특히 공개 데이터셋과 오픈소스 모델이 제공하는 기회와 위험 요소를 강조하며, 각 구성 요소가 어떻게 AI 제품에 영향을 미치는지를 설명했습니다.

4. 공개 데이터셋 및 AI 모델의 활용과 리스크

4.1 주요 공개 데이터셋

Common Crawl: 인터넷 전반을 크롤링한 텍스트 데이터를 포함하며, OpenAI 및 Meta 등의 대규모 언어 모델 훈련에 활용됨.
Red Pajama: Apache 2.0 라이선스를 따르지만 Common Crawl 기반으로 생성되어 법적 복잡성이 존재.

4.2 오픈소스 모델

Llama 3.1 (Meta): 특정 라이선스 조건(예: “Built with Llama” 표시 의무) 포함.
Black Forest FLUX: 비상업적 사용만 허용하는 라이선스를 따름.

4.3 주요 과제

Nick은 다음과 같은 문제들을 지적했습니다:

데이터 출처 불명확성으로 인한 법적 리스크.
특정 지역(예: EU)에서 요구되는 투명성 기준 충족 여부.

5. AI 규제와 데이터 투명성의 미래

5.1 주요 규제 동향

Nick은 여러 지역에서 시행 중인 규제를 다음과 같이 요약했습니다:

EU AI Act: 훈련 데이터 출처 공개 및 기술 문서 유지 의무화.
미국 캘리포니아 AB 2013 법안: 생성형 AI 훈련 데이터 투명성 요구.
일본 METI 가이드라인: 데이터 출처 추적 가능성 확보 권장.

5.2 글로벌 협력 가능성

GDPR처럼 EU AI Act가 글로벌 표준으로 자리 잡을 가능성을 논의했지만, 각 지역별로 상이한 접근 방식이 존재함을 강조했습니다.

6. 기업을 위한 전략 및 액션 아이템

6.1 오픈소스 관리 담당자를 위한 의미

오픈소스 및 공개 데이터를 사용하는 기업은 다음 사항을 고려해야 합니다:

공개된 라이선스 조건 준수 여부 확인.
훈련 데이터 및 모델 사용 내역 투명하게 기록.
새로운 규제에 대비해 내부 프로세스 정비.

6.2 고려해야 할 Action Item

데이터 및 모델 카탈로그 구축:
- 사용 중인 모든 데이터셋과 모델의 출처, 라이선스 조건 등을 기록.
투명성 보고서 작성 프로세스 마련:
- 규제가 요구하는 정보를 포함한 표준화된 보고서 작성 체계 수립.
내부 승인 프로세스 강화:
- 안전한 프로파일(예: 오픈소스 라이선스 준수)을 정의하고 빠른 승인 절차 제공.

이번 웨비나는 AI 공급망 관리에서 데이터를 중심으로 한 복잡한 문제들을 심도 있게 다루며 기업들이 직면할 수 있는 도전 과제를 명확히 했습니다. Nick Schifano는 기술적·법적 전문성을 바탕으로 실질적인 조언을 제공하며, 참석자들에게 큰 통찰을 안겨주었습니다.

14 - 2024-09-27 AI: 현재의 법적 환경

2024-09-27, AI, The Current Legal Landscape

source: https://openchainproject.org/featured/2024/09/27/webinar-ai-the-current-legal-landscape

1. 소개

제목

AI: 현재의 법적 환경

발표자 소개

Tony: GTC Law Group의 IP 전문 변호사. AI, 오픈소스, 특허 전략, 거래 분야 전문.
Well: 기계학습 박사 학위 소지자. AI 제품 연구 과학자 및 프로그래머 경력.
Stas: 전 Amazon Kindle 팀 멤버, Audible 전 법무 자문, Netflix AI 법무 담당. GTC의 AI 그룹 공동 리더.
Shay: 데이터 프라이버시 및 사이버 보안 전문가. 신흥 기술 관련 자문 경험 풍부.

웨비나 소개와 목적

이 웨비나는 OpenChain 커뮤니티에서 주최하는 AI 관련 법적 환경에 대한 논의의 연장선상에 있습니다. 지난해에 이어 GTC Law 팀이 생성형 AI를 둘러싼 현재의 법적 환경에 대해 포괄적으로 설명합니다. 이 웨비나의 목적은 AI 기술의 발전에 따른 법적 문제들을 살펴보고, 기업과 개발자들이 알아야 할 주요 사항들을 제공하는 것입니다.

2. AI와 오픈소스의 교차점

AI의 발전 과정

AGI(Artificial General Intelligence): 인간 수준의 지능을 가진 기계
AI(Artificial Intelligence): 특정 작업에 대한 인간 지능 모방
Machine Learning: AI의 한 기법, 데이터셋으로부터 학습하여 모델 생성
Deep Learning: 대량의 데이터와 연산력 필요, 신경망 기반
Generative AI: 새로운 데이터 생성 능력

Generative AI 응용

텍스트 생성
이미지 생성
코드 생성
비디오 생성
음악 생성
합성 데이터 생성

AI와 오픈소스 라이선스

많은 AI 도구들이 오픈소스 라이선스로 제공됩니다. 예를 들어:

Meta의 LLaMA 모델은 “오픈소스"라고 불리지만, 실제로는 상업적 라이선스에 가깝습니다. 특히 7억 명 이상의 활성 사용자를 가진 경우 별도의 라이선스가 필요하며, LLaMA의 출력을 다른 언어 모델 개선에 사용할 수 없다는 제한이 있습니다.

Responsible AI Licenses (RAIL)

RAIL은 AI 기술의 비윤리적 사용을 제한하기 위해 만들어진 라이선스입니다. 주요 특징:

사용 제한 조항 포함
하위 사용자에게도 동일한 행동 제한 요구
감시, 딥페이크, 의료, 범죄 기록 등에 대한 사용 제한

RAIL은 최근 많은 주목을 받고 있으며, MIT나 Apache 라이선스보다 더 많은 AI 모델에 적용되고 있습니다.

3. 소송 개요

AI, 특히 생성형 AI 제공업체들을 상대로 한 소송이 증가하고 있습니다. 주요 소송 분야:

컴퓨터 코드 관련

GitHub Copilot 관련 집단 소송
주요 쟁점: DMCA 위반, 계약 위반, 과실, 사기

이미지 관련

Stability AI의 Stable Diffusion 관련 소송

문서 관련

저자들의 저작권 침해 소송

음악 관련

실제 녹음물 및 가사 관련 소송

GitHub Copilot 소송 사례

주요 쟁점: DMCA 위반, 오픈소스 라이선스 위반, GitHub 이용약관 위반
최근 법원은 원고의 일부 주장을 기각

Getty Images vs Stability AI 소송 사례

Stable Diffusion이 Getty Images의 워터마크를 변형하여 사용한 점이 쟁점

4. 법규/입법 개요

AI 규제는 크게 네 가지 유형으로 분류할 수 있습니다:

기존 법률 적용
- 소비자 보호, 차별 금지, 프라이버시 등
일반 AI 규제
산업 또는 사용 사례별 AI 규제
- 보험사의 AI 사용
- 고용 결정에서의 AI 사용
- 정부의 AI 조달 및 사용
정책 수립 중심
- AI 규제 제안을 위한 태스크포스 설립
- AI 기술의 중요성을 인식하는 선언
- AI 채택을 촉진하기 위한 정부 지출 프로그램 수립

5. 데이터 보호와 AI

2024년 프라이버시 법 요약

20개의 포괄적 프라이버시 법
2020년부터 2026년 사이에 발효
대부분 “소비자"의 “개인 데이터"에 적용
캘리포니아 법은 더 광범위한 적용 범위

AI와 데이터 보호의 교차점

보안 문제와 데이터 유출
복잡한 프라이버시 준수 의무
자동화된 의사 결정 시스템에 대한 소비자 옵트아웃 권리
고위험 AI 시스템에 대한 추가 요구사항
편향과 차별 방지에 중점

사례 연구: AI 훈련을 위한 데이터 스크래핑

중요한 결정, 프로파일링, AI/LLM 훈련 등의 사용 사례
개인 데이터, 민감 데이터, 이미지, 사용자 생성 콘텐츠 등의 데이터 사용
인간 개입, 신뢰성, 투명성, 정확성, 편향/차별 등의 출력 관련 고려사항

6. Q&A

Q: LLAMA 모델의 “다른 모델 개선에 사용 불가” 조항에 대해 설명해주세요. A: 라이선스 조항에 따르면, LLAMA 자료나 그 결과물을 LLAMA 2나 그 파생물을 제외한 다른 대규모 언어 모델을 개선하는 데 사용할 수 없습니다. 이는 Meta가 경쟁을 제한하고 자사의 모델 우위를 유지하려는 의도로 보입니다.

Q: RAIL 라이선스가 모든 라이선스를 “스노우플레이크"로 만드는 것 아닌가요? A: RAIL의 기본 아이디어는 사용 제한과 하위 사용자 준수를 요구하는 것이지만, 실제로는 몇 가지 표준화된 버전으로 수렴하고 있습니다. 예를 들어, Hugging Face에서는 “Creative ML OpenRAIL-M” 라이선스가 23,000개 이상의 모델에 사용되고 있습니다.

Q: 소송의 타임라인은 어떻게 되나요? A: 정확한 타임라인은 없지만, 유사한 소송 사례를 보면 최종 결정까지 5-10년이 걸릴 수 있습니다. 법률은 종종 새로운 기술을 따라가는 데 시간이 걸리므로, 판례법보다는 법규를 통한 지침이 먼저 나올 가능성이 높습니다.

Q: 교육 분야에서 AI 사용 감지 도구의 편향성 문제는 어떻게 해결해야 하나요? A: 이는 중요한 문제입니다. 도구 자체에만 의존하지 말고 인간의 판단을 병행해야 합니다. 캘리포니아의 새로운 규정은 자동화된 의사결정이 중요한 요소인 경우에도 규제 범위에 포함시키려 하고 있습니다. 이는 교육자가 도구에 과도하게 의존하는 경우에도 규제 대상이 될 수 있음을 의미합니다.

요약 보고서

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

AI 기술과 오픈소스의 융합: 많은 AI 도구들이 오픈소스로 제공되고 있어, 오픈소스 관리의 중요성이 더욱 커지고 있습니다.
새로운 라이선스 유형 등장: RAIL과 같은 새로운 라이선스 유형이 등장하고 있어, 이에 대한 이해와 관리가 필요합니다.
법적 리스크 증가: AI 관련 소송이 증가하고 있어, 오픈소스 사용 시 법적 리스크에 대한 주의가 필요합니다.
데이터 보호 의무 강화: AI 사용에 따른 데이터 보호 의무가 강화되고 있어, 오픈소스 AI 도구 사용 시에도 이를 고려해야 합니다.
규제 환경 변화: AI 관련 규제가 빠르게 변화하고 있어, 이에 대한 지속적인 모니터링이 필요합니다.

고려해야 할 Action Item

AI 관련 오픈소스 라이선스 검토: 사용 중인 AI 도구들의 라이선스를 철저히 검토하고, 특히 RAIL과 같은 새로운 라이선스 유형에 주의를 기울입니다.
데이터 사용 정책 수립: AI 훈련에 사용되는 데이터의 출처와 사용 권한을 명확히 하는 정책을 수립합니다.
AI 사용 가이드라인 제정: 회사 내 AI 도구 사용에 대한 가이드라인을 만들어 법적 리스크를 최소화합니다.
정기적인 컴플라이언스 검토: AI 관련 법규 준수 여부를 정기적으로 검토하고 필요한 조치를 취합니다.
AI 윤리 정책 수립:

Webinars

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

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

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

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

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

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

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

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

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

3줄 요약

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

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

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

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

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

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

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

3. 과학적 재현성 (Reproducibility)

4. ISO 표준화와 거버넌스

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

관련 링크

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

웨비나 개요

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

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

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

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

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

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

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

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

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

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

관련 자료

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

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

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

전 세계가 영향권입니다

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

Manufacturer (제조업체)

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

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

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

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

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

보안 교육 이수

표준 준수

결론: 규제를 기회로

관련 링크

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

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

복잡한 계층(Layered) 구조

컴플라이언스 자료의 부재

2. 해결책: OSADL Base Image란?

주요 특징

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

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

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

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

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

관련 링크

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

목차

1. 발표자 소개

2. 웨비나 소개와 목적

3. DeviceCode 프로젝트 배경

3.1 시장의 현실

3.2 취약점 보고의 문제점

3.3 정보 접근의 어려움

4. DeviceCode의 구현 및 기능

4.1 데이터 소스

4.2 주요 기능

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

5.1 위키 데이터 처리

5.2 FCC 문서 분석

5.3 데이터 통합

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

6.1 데이터의 완전성

6.2 상업화 가능성