Merge pull request #254 from OpenChain-Project/guide/2026-enterprise-oss-guide-phase2

docs(guide): 2026 기업 오픈소스 관리 가이드 개선 (2차)

Author: haksungjang

content/ko/guide/TODO.md

@@ -43,16 +43,16 @@ draft: true
 ---
 ## 2차 작업 (별도 브랜치 예정 — 지금은 작업하지 않음)
 
-- [ ] #4  기여 정책 인식 절차 선언 추가
-- [ ] #11 라이선스 사용 사례별 처리 방침 선언
-- [ ] #12 인식 평가 증거 보관 절차 명시
-- [ ] #13 외부 문의 기록 보관 기간 추가 (2-process)
-- [ ] #14 CVD 공개 타이밍 절차 추가
-- [ ] #15 오픈소스 기여 프로세스 신규 작성
-- [ ] #16 사내 오픈소스 공개 프로세스 신규 작성
-- [ ] #17 교육·평가 실행 프로세스 신규 작성
-- [ ] #21 4-tool에 OSV-SCALIBR 소개 및 링크 추가
-- [ ] #22 4-tool에 Dependency-Track 소개 및 링크 추가
-- [ ] #23 4-tool에 cdxgen 소개 및 링크 추가
-- [ ] #24 4-tool에 Syft 소개 및 링크 추가
+- [x] #4  기여 정책 인식 절차 선언 추가
+- [x] #11 라이선스 사용 사례별 처리 방침 선언
+- [x] #12 인식 평가 증거 보관 절차 명시
+- [x] #13 외부 문의 기록 보관 기간 추가 (2-process)
+- [x] #14 CVD 공개 타이밍 절차 추가
+- [x] #15 오픈소스 기여 프로세스 신규 작성
+- [x] #16 사내 오픈소스 공개 프로세스 신규 작성
+- [x] #17 교육·평가 실행 프로세스 신규 작성
+- [x] #21 4-tool에 OSV-SCALIBR 소개 및 링크 추가
+- [x] #22 4-tool에 Dependency-Track 소개 및 링크 추가
+- [x] #23 4-tool에 cdxgen 소개 및 링크 추가
+- [x] #24 4-tool에 Syft 소개 및 링크 추가
 ---

content/ko/guide/opensource_for_enterprise/4-tool/_index.md

@@ -80,6 +80,30 @@ Analyzer의 주요 기능:
 {{< /imgproc >}}
 
 
+### (3) cdxgen
+
+[cdxgen](https://github.com/CycloneDX/cdxgen)은 OWASP CycloneDX 프로젝트의 일환으로 개발된 오픈소스 SBOM 생성 도구입니다. 다양한 언어와 패키지 관리자를 지원하며, CI/CD 파이프라인에 쉽게 통합할 수 있습니다.
+
+주요 기능:
+- Java, JavaScript, Python, Go, Rust 등 20여 개 언어 및 패키지 생태계 지원
+- CycloneDX 및 SPDX 형식의 SBOM 생성
+- 컨테이너 이미지 및 바이너리 분석 지원
+- GitHub Actions, Jenkins 등 CI/CD 통합
+
+cdxgen의 설치 및 사용 방법은 [cdxgen 가이드](../../tools/5-cdxgen/)를 참조하시기 바랍니다.
+
+### (4) Syft
+
+[Syft](https://github.com/anchore/syft)는 Anchore에서 개발한 오픈소스 SBOM 생성 도구로, 컨테이너 이미지와 파일시스템을 분석하여 SBOM을 생성합니다.
+
+주요 기능:
+- 컨테이너 이미지, 파일시스템, 아카이브 등 다양한 소스 분석
+- SPDX, CycloneDX, Syft JSON 등 다양한 SBOM 형식 출력
+- Grype(취약점 스캐너)와 연동하여 취약점 분석 가능
+- Kubernetes, CI/CD 파이프라인 통합 지원
+
+Syft의 설치 및 사용 방법은 [Syft 가이드](../../tools/6-syft/)를 참조하시기 바랍니다.
+
 이러한 Dependency 분석 도구를 활용하여 공급 소프트웨어에 포함된 오픈소스 컴포넌트를 정확히 식별하고, SBOM을 생성할 수 있습니다. 이는 ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 충족하는 데 도움이 됩니다.
 
 ## 3. 오픈소스 거버넌스 / SBOM 관리 도구
@@ -139,6 +163,18 @@ FOSSLight의 설치 및 사용 방법은 [FOSSLight 가이드](../../tools/3-fos
 <center><i>https://fosslight.org/</i></center>
 {{< /imgproc >}}
 
+### (3) Dependency-Track
+
+[Dependency-Track](https://dependencytrack.org/)은 OWASP에서 관리하는 오픈소스 SBOM 관리 및 취약점 분석 플랫폼입니다. SBOM을 수집·관리하고, 각 컴포넌트의 취약점을 지속적으로 모니터링합니다.
+
+주요 기능:
+- CycloneDX 및 SPDX 형식의 SBOM 수집 및 관리
+- NVD, OSV 등 취약점 데이터베이스와 연동한 자동 취약점 탐지
+- 프로젝트별 컴포넌트 및 라이선스 현황 대시보드
+- REST API 및 CI/CD 파이프라인 통합
+
+Dependency-Track의 설치 및 사용 방법은 [Dependency-Track 가이드](../../tools/7-dependency-track/)를 참조하시기 바랍니다.
+
 이러한 도구들을 활용하여 기업은 효과적으로 오픈소스 거버넌스를 수행하고 SBOM을 관리할 수 있으며, ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 충족할 수 있습니다.
 
 ## 4. 오픈소스 보안취약점 관리 도구
@@ -172,6 +208,18 @@ SW360으로 보안취약점을 관리하는 방법은 [SW360 가이드](../../to
 [FOSSLight](https://fosslight.org/ko/)도 이와 유사하게 보안취약점 정보를 자동으로 취득하고, 보안취약점이 검출된 프로젝트 정보를 자동으로 확인하여 필요 시 메일 등 알림을 제공합니다.
 
 
+### (4) OSV-SCALIBR
+
+[OSV-SCALIBR](https://github.com/google/osv-scalibr)은 Google에서 개발한 오픈소스 소프트웨어 컴포지션 분석(SCA) 라이브러리로, 파일시스템과 컨테이너 이미지에서 오픈소스 컴포넌트를 추출하고 OSV(Open Source Vulnerabilities) 데이터베이스와 연동하여 취약점을 탐지합니다.
+
+주요 기능:
+- 파일시스템, 컨테이너 이미지, 아카이브에서 패키지 추출
+- OSV 데이터베이스 기반 취약점 탐지
+- Python, Go, Java, npm 등 주요 패키지 생태계 지원
+- 라이브러리 형태로 기존 도구에 통합 가능
+
+OSV-SCALIBR의 설치 및 사용 방법은 [OSV-SCALIBR 가이드](../../tools/4-osvscalibr/)를 참조하시기 바랍니다.
+
 이러한 도구들을 활용하여 기업은 ISO/IEC 18974의 요구사항을 충족하면서 효과적으로 오픈소스 보안 취약점을 관리할 수 있습니다.
 
 

content/ko/guide/templates/1-policy/_index.md

@@ -210,6 +210,17 @@ This sample open source policy was written with reference to the following two m
     - 여러 오픈소스 컴포넌트의 라이선스가 서로 호환되는지 검토합니다.
     - 호환되지 않는 라이선스를 사용하는 경우, 대체 가능한 컴포넌트를 제안하거나 적절한 조치를 취합니다.
 
+### 4.2.1 라이선스 사용 사례별 처리 방침
+
+오픈소스 컴포넌트의 사용 형태에 따라 다음 기준을 적용합니다:
+
+1. **내부 사용**: 외부 배포 없이 사내에서만 사용하는 경우, 별도 컴플라이언스 산출물 생성 의무는 없으나 SBOM 기록은 유지합니다.
+2. **외부 배포 (바이너리)**: GPL 등 소스 공개 의무 라이선스가 포함된 경우, 소스 코드 패키지를 함께 제공하거나 서면 청약을 포함합니다.
+3. **외부 배포 (SaaS/네트워크 서비스)**: AGPL 등 네트워크 사용을 배포로 간주하는 라이선스가 포함된 경우, 법무팀의 별도 검토를 거칩니다.
+4. **오픈소스 프로젝트에 기여**: 기여 코드에 적용되는 라이선스가 프로젝트 라이선스와 호환되는지 확인합니다.
+
+각 사용 사례에 해당하는 오픈소스 컴포넌트는 §4.3의 절차에 따라 컴플라이언스 산출물을 생성·관리합니다.
+
 ### 4.3 컴플라이언스 산출물 생성 및 관리
 
 1. **오픈소스 고지문 생성**:
@@ -331,6 +342,7 @@ This sample open source policy was written with reference to the following two m
         - 라이선스 의무 사항 및 컴플라이언스 절차.
         - SBOM 생성 및 활용 방법.
         - 알려진 취약점 및 새로 발견된 취약점 관리 절차.
+        - 외부 오픈소스 기여 정책 및 사내 프로젝트 공개 절차.
 2. **교육 방법**:
     - [Learning Portal]에서 제공하는 온라인 강의를 통해 이수합니다.
     - 필요 시 워크숍 또는 세미나 형식의 추가 교육을 제공합니다.
@@ -362,7 +374,11 @@ This sample open source policy was written with reference to the following two m
 1. **교육 및 평가 기록**:
     - 모든 교육 이수 기록과 평가 결과는 최소 3년간 보관됩니다.
     - 이를 통해 프로그램 참여자가 정책과 프로세스를 충분히 이해하고 있음을 입증할 수 있습니다.
-2. **정기적인 검토 및 업데이트**:
+2. **인식 평가 증거 보관 절차**:
+    - 역량 평가의 증거는 다음 형태 중 하나 이상으로 수집하고 보관합니다: 테스트 점수, 교육 이수 확인서, 정책 인식 확인 서명. (ISO/IEC 5230 §3.1.3, ISO/IEC 18974 §3.1.3)
+    - 증거는 사내 문서 관리 시스템(예: Learning Portal, HR 시스템)에 등록하여 감사 시 즉시 제출 가능한 상태로 유지합니다.
+    - 보관 기간 만료 후에는 개인정보 보호 정책에 따라 파기합니다.
+3. **정기적인 검토 및 업데이트**:
     - 오픈소스 프로그램 매니저는 연 1회 이상 교육 내용과 평가 방식을 검토하고 필요 시 업데이트하여 최신의 오픈소스 동향과 조직의 요구사항을 반영합니다.
 
 ### 6.5 전문 지식 식별 및 활용
@@ -426,6 +442,15 @@ This sample open source policy was written with reference to the following two m
     - 외부 오픈소스 프로젝트로의 기여 활동은 프로그램 참여자의 성과 평가에 반영됩니다.
     - OSPO는 정기적으로 기여 활동의 효과성을 평가하고, 필요 시 개선 방안을 제안합니다.
 
+### 7.5 기여 정책 인식 절차
+
+1. **정책 인식 의무화**:
+    - 모든 프로그램 참여자는 외부 오픈소스 기여 정책(제7조) 및 사내 프로젝트 공개 정책(제8조)의 존재와 내용을 인식해야 합니다.
+    - OSPO는 신규 참여자 온보딩 시 기여 정책을 고지하고, 연간 교육을 통해 재확인합니다. (ISO/IEC 5230 §3.1.3)
+2. **인식 확인 및 기록**:
+    - OSPO는 기여 정책 인식 여부를 확인하고, 그 결과를 기록으로 관리합니다.
+    - 인식 확인 기록은 최소 3년간 보관됩니다.
+
 ## 8. 사내 프로젝트 오픈소스로 공개
 
 이 섹션에서는 사내 프로젝트를 오픈소스로 공개하는 절차와 원칙을 설명합니다. 이를 통해 회사는 오픈소스 커뮤니티와의 협력을 증진시키고, 지식재산을 보호하며, 법적 위험을 최소화할 수 있습니다.

content/ko/guide/templates/2-process-template/_index.md

@@ -282,6 +282,21 @@ IT 담당은 취약점이 해결된 SBOM(Software Bill of Materials)을 시스
     - 패치 또는 업데이트 가용성 및 적용 방법
     - 추가 정보를 얻을 수 있는 연락처
 
+### (9) 취약점 공개 타이밍 절차 (CVD)
+
+새로 발견된 취약점(회사 내부 발견 또는 외부 연구자 보고)에 대해서는 조정된 취약점 공개(Coordinated Vulnerability Disclosure, CVD) 절차를 따릅니다.
+
+1. **공개 전 조율**:
+    - 취약점 발견 즉시 영향받는 오픈소스 프로젝트 메인테이너에게 비공개로 통보합니다.
+    - 패치 개발 및 배포에 충분한 시간을 부여하기 위해 원칙적으로 최초 통보 후 90일 이내에 공개합니다.
+    - 메인테이너와 협의하여 공개 일정을 조정할 수 있으며, 합의된 일정은 문서화합니다.
+2. **즉시 공개 예외**:
+    - 취약점이 이미 외부에 알려져 악용되고 있거나 즉각적인 위협이 있는 경우, 조율 기간 없이 즉시 공개할 수 있습니다.
+    - 즉시 공개 결정은 보안 담당과 오픈소스 프로그램 매니저가 공동으로 승인합니다.
+3. **공개 내용 및 채널**:
+    - 공개 시 CVE ID 발급 신청(MITRE 또는 CNA)을 병행합니다.
+    - 취약점 정보, 영향 범위, 패치 또는 완화 방법을 회사 보안 공지 페이지 및 관련 공개 데이터베이스(NVD 등)에 게시합니다.
+
 
 ## 3. 외부 문의 대응 프로세스
 
@@ -332,4 +347,161 @@ IT 담당은 취약점이 해결된 SBOM(Software Bill of Materials)을 시스
 
 ### (7) 프로세스 개선
 
-라이선스 컴플라이언스나 보안 문제가 있었던 경우, OSRB 미팅을 통해 사례를 검토하고 문제 발생 경위를 파악하여 재발 방지를 위한 프로세스 개선 방안을 수립합니다.
+라이선스 컴플라이언스나 보안 문제가 있었던 경우, OSRB 미팅을 통해 사례를 검토하고 문제 발생 경위를 파악하여 재발 방지를 위한 프로세스 개선 방안을 수립합니다.
+
+### (8) 기록 보관
+
+오픈소스 프로그램 매니저는 외부 문의 대응의 전 과정(접수, 조사, 대응, 해결)을 이슈 추적 시스템에 기록합니다. 이 기록은 해당 문의가 종결된 날로부터 최소 3년간 보관합니다. (ISO/IEC 18974 §3.2.1.2)
+
+보관 기록에는 다음 내용이 포함되어야 합니다:
+
+- 문의 접수 일시 및 요청자 정보
+- 문의 내용 및 분류 (라이선스 컴플라이언스 / 보안 취약점)
+- 내부 조사 결과 및 대응 조치
+- 최종 처리 결과 및 완료 일시
+
+## 4. 오픈소스 기여 프로세스
+
+프로그램 참여자가 외부 오픈소스 프로젝트에 기여할 때는 회사의 지식재산 보호와 라이선스 호환성을 확보하기 위해 다음 절차를 준수합니다. 자세한 정책은 [오픈소스 정책 §7](../1-policy/)을 참조하십시오.
+
+### (1) 기여 의사 확인 및 사전 검토 요청
+
+프로그램 참여자는 외부 오픈소스 프로젝트에 기여하기 전에 OSPO에 기여 검토를 요청합니다.
+
+요청 시 포함할 정보:
+- 기여 대상 프로젝트명 및 저장소 URL
+- 기여 내용 개요 (버그 수정, 기능 추가 등)
+- 기여 코드의 출처 (자체 작성 여부, 회사 소유 여부)
+- 관련 특허 포함 여부
+
+### (2) OSPO 검토 및 승인
+
+OSPO는 기여 요청을 검토하고 다음 사항을 확인합니다:
+
+1. **라이선스 호환성**: 기여 코드의 라이선스와 대상 프로젝트 라이선스의 호환 여부 확인.
+2. **지식재산 검토**: 기여 코드에 회사의 특허 또는 민감 정보가 포함되지 않았는지 확인. 필요 시 법무팀 자문을 요청합니다.
+3. **CLA 검토**: 대상 프로젝트가 CLA(Contributor License Agreement) 서명을 요구하는 경우, 조건을 검토하고 저작권 양도 조항이 없는지 확인합니다.
+
+검토 완료 후 OSPO는 승인 또는 반려 결정을 요청자에게 통보합니다.
+
+### (3) 기여 수행
+
+승인된 기여에 대해 프로그램 참여자는 다음 사항을 준수하며 기여합니다:
+
+- 파일 상단에 회사 저작권 표시 및 SPDX 라이선스 식별자를 명기합니다.
+- 회사 이메일을 사용하여 기여합니다.
+- 직접 작성한 코드 또는 회사가 권리를 보유한 코드만 기여합니다.
+
+### (4) 기여 이력 기록 및 보관
+
+OSPO는 모든 승인된 기여를 내부 시스템에 기록합니다.
+
+기록 항목:
+- 기여 대상 프로젝트 및 기여 일시
+- 기여 내용 요약
+- 승인자 및 승인 일시
+- CLA 서명 여부
+
+기여 이력은 최소 3년간 보관합니다.
+
+## 5. 사내 프로젝트 공개 프로세스
+
+사내에서 개발한 프로젝트를 오픈소스로 공개할 때는 회사의 지식재산 보호와 라이선스 선택의 적절성을 확보하기 위해 다음 절차를 준수합니다. 자세한 정책은 [오픈소스 정책 §8](../1-policy/)을 참조하십시오.
+
+### (1) 공개 검토 요청
+
+공개를 희망하는 부서는 OSPO에 공개 검토를 요청합니다.
+
+요청 시 포함할 정보:
+- 프로젝트 개요 및 공개 목적
+- 공개 범위 (코드, 문서 등)
+- 특허 포함 여부
+- 의존하는 서드파티 라이브러리 목록
+
+### (2) OSPO 검토 및 승인
+
+OSPO는 다음 사항을 검토합니다:
+
+1. **지식재산 검토**: 공개 코드에 회사 특허, 영업 비밀, 민감 정보가 포함되지 않았는지 확인합니다. 필요 시 법무팀 자문을 요청합니다.
+2. **라이선스 선택**: 공개 목적(커뮤니티 육성, 표준화 기여 등)과 지식재산 보호를 고려하여 적절한 오픈소스 라이선스를 선택합니다.
+3. **의존성 라이선스 호환성**: 포함된 서드파티 컴포넌트의 라이선스가 선택한 공개 라이선스와 호환되는지 확인합니다.
+
+### (3) 공개 준비
+
+승인 후 담당 부서는 다음 작업을 수행합니다:
+
+- 코드에서 민감 정보(API 키, 내부 서버 주소 등)를 제거합니다.
+- 파일 상단에 저작권 표시 및 SPDX 라이선스 식별자를 명기합니다.
+- README, 기여 가이드(CONTRIBUTING.md), 라이선스 파일(LICENSE)을 작성합니다.
+- GitHub 등 공개 저장소에 프로젝트를 등록합니다.
+
+### (4) 공개 후 관리
+
+OSPO와 담당 부서는 공개된 프로젝트의 지속적인 유지보수를 위해 다음을 수행합니다:
+
+- 외부 기여(Pull Request, Issue)를 주기적으로 검토하고 대응합니다.
+- 보안 취약점 보고 시 §2 보안 취약점 관리 프로세스에 따라 대응합니다.
+- 프로젝트 상태(활성/유지보수/아카이브)를 정기적으로 검토하고 README에 명시합니다.
+
+### (5) 공개 기록 보관
+
+OSPO는 공개 승인 내역과 관련 검토 기록을 최소 3년간 보관합니다.
+
+보관 항목:
+- 공개 요청 및 승인 일시, 승인자
+- 선택한 라이선스 및 선택 근거
+- 지식재산 검토 결과
+- 공개 저장소 URL
+
+## 6. 교육·평가 실행 프로세스
+
+오픈소스 프로그램 참여자가 정책과 프로세스를 충분히 이해하고 역량을 유지할 수 있도록, 다음 절차에 따라 교육과 역량 평가를 실행합니다. 자세한 정책은 [오픈소스 정책 §6](../1-policy/)을 참조하십시오.
+
+### (1) 교육 대상 및 주기 결정
+
+오픈소스 프로그램 매니저는 연 1회 이상 교육 대상을 확인하고 교육 계획을 수립합니다.
+
+- **신규 참여자**: 온보딩 시 필수 교육을 이수합니다.
+- **기존 참여자**: 연 1회 이상 정기 교육을 이수합니다.
+- **역할 변경자**: 새로운 역할에 맞는 추가 교육을 이수합니다.
+
+### (2) 교육 실시
+
+오픈소스 프로그램 매니저는 다음 방법으로 교육을 제공합니다:
+
+1. **온라인 교육**: Learning Portal의 필수 과목을 이수하고, 이수 완료를 시스템에서 자동 기록합니다.
+2. **오프라인 교육**: 필요 시 워크숍 또는 세미나를 개최하고, 참석자 명단과 교육 자료를 기록합니다.
+
+교육 내용에는 다음 주제가 포함되어야 합니다:
+- 오픈소스 정책의 목적과 원칙
+- 라이선스 의무 및 컴플라이언스 절차
+- SBOM 생성 및 활용
+- 취약점 관리 절차
+- 외부 오픈소스 기여 정책 및 사내 프로젝트 공개 절차
+
+### (3) 역량 평가 실시
+
+교육 이수 후 오픈소스 프로그램 매니저는 참여자의 역량을 평가합니다.
+
+- 온라인 테스트 또는 실무 과제를 통해 평가를 수행합니다.
+- 평가 기준(합격 점수 등)은 교육 계획 수립 시 사전에 정의합니다.
+- 평가 미통과자에게는 보충 교육 기회를 제공하고 재평가를 실시합니다.
+
+### (4) 평가 결과 기록 및 보관
+
+오픈소스 프로그램 매니저는 교육 이수 및 평가 결과를 기록합니다.
+
+기록 항목:
+- 교육 이수자 이름, 역할, 이수 일시
+- 평가 결과 (점수 또는 합격/불합격)
+- 보충 교육 이력 (해당 시)
+
+기록은 사내 문서 관리 시스템 또는 Learning Portal에 등록하며, 최소 3년간 보관합니다. (ISO/IEC 5230 §3.1.3, ISO/IEC 18974 §3.1.3)
+
+### (5) 교육 내용 검토 및 개선
+
+오픈소스 프로그램 매니저는 연 1회 이상 교육 내용과 평가 방식을 검토하고, 다음 사항을 반영하여 업데이트합니다:
+
+- 오픈소스 관련 법·규제 변화
+- 새로운 취약점 트렌드 및 사례
+- 사내 정책 및 프로세스 변경 사항