From ad8bc9453751d9515bdd667c6282582752811ee8 Mon Sep 17 00:00:00 2001 From: Haksung Jang Date: Thu, 26 Mar 2026 09:13:15 +0900 Subject: [PATCH] =?UTF-8?q?docs(guide):=20complete=20phase2=20=E2=80=94=20?= =?UTF-8?q?contribution=20policy,=20CVD,=20new=20processes,=20and=20tool?= =?UTF-8?q?=20links?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 1-policy: add contribution policy awareness procedure (§7.5), license use-case matrix (§4.2.1), and assessment evidence retention procedure (§6.4) - 2-process-template: add external inquiry record retention (§3 step 8), CVD disclosure timing (§2 step 9), open source contribution process (§4), internal project release process (§5), and training/evaluation execution process (§6) - 4-tool: add cdxgen, Syft, Dependency-Track, OSV-SCALIBR introductions and links to tools/ pages Co-Authored-By: Claude Sonnet 4.6 --- content/ko/guide/TODO.md | 24 +-- .../4-tool/_index.md | 48 +++++ content/ko/guide/templates/1-policy/_index.md | 27 ++- .../templates/2-process-template/_index.md | 174 +++++++++++++++++- 4 files changed, 259 insertions(+), 14 deletions(-) diff --git a/content/ko/guide/TODO.md b/content/ko/guide/TODO.md index b9e72d50d..f82396b37 100644 --- a/content/ko/guide/TODO.md +++ b/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 소개 및 링크 추가 --- diff --git a/content/ko/guide/opensource_for_enterprise/4-tool/_index.md b/content/ko/guide/opensource_for_enterprise/4-tool/_index.md index 680530956..ced379eda 100644 --- a/content/ko/guide/opensource_for_enterprise/4-tool/_index.md +++ b/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
https://fosslight.org/
{{< /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의 요구사항을 충족하면서 효과적으로 오픈소스 보안 취약점을 관리할 수 있습니다. diff --git a/content/ko/guide/templates/1-policy/_index.md b/content/ko/guide/templates/1-policy/_index.md index d56b8ca0b..ec5ca1b84 100644 --- a/content/ko/guide/templates/1-policy/_index.md +++ b/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. 사내 프로젝트 오픈소스로 공개 이 섹션에서는 사내 프로젝트를 오픈소스로 공개하는 절차와 원칙을 설명합니다. 이를 통해 회사는 오픈소스 커뮤니티와의 협력을 증진시키고, 지식재산을 보호하며, 법적 위험을 최소화할 수 있습니다. diff --git a/content/ko/guide/templates/2-process-template/_index.md b/content/ko/guide/templates/2-process-template/_index.md index 2952edbb7..ea97629ac 100644 --- a/content/ko/guide/templates/2-process-template/_index.md +++ b/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 미팅을 통해 사례를 검토하고 문제 발생 경위를 파악하여 재발 방지를 위한 프로세스 개선 방안을 수립합니다. \ No newline at end of file +라이선스 컴플라이언스나 보안 문제가 있었던 경우, 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회 이상 교육 내용과 평가 방식을 검토하고, 다음 사항을 반영하여 업데이트합니다: + +- 오픈소스 관련 법·규제 변화 +- 새로운 취약점 트렌드 및 사례 +- 사내 정책 및 프로세스 변경 사항 \ No newline at end of file