From d85fdd51884da29e92535601076cb4f0fabe1ca5 Mon Sep 17 00:00:00 2001 From: Haksung Jang Date: Thu, 26 Mar 2026 16:28:32 +0900 Subject: [PATCH 1/2] =?UTF-8?q?docs(guide):=20add=20ISO/IEC=205230=20?= =?UTF-8?q?=EC=A4=80=EC=88=98=20=EA=B0=80=EC=9D=B4=EB=93=9C=20=EC=A0=84?= =?UTF-8?q?=EC=B2=B4=20=EC=A1=B0=ED=95=AD=20=ED=8E=98=EC=9D=B4=EC=A7=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ISO/IEC 5230:2020(버전 2.1)의 13개 조항·24개 입증자료 항목을 모두 작성. 각 조항 페이지는 조항 개요·해야 할 활동·요구사항 표·준수 방법 및 샘플·참고 의 5섹션 표준 템플릿으로 구성되며, 영문 원문 보기(details) 및 실무 샘플을 포함. - §3.1 프로그램 기반: 정책·역량·인식·범위·라이선스 의무 - §3.2 관련 업무: 외부 문의 대응·효과적 리소스 - §3.3 콘텐츠 검토: SBOM·라이선스 컴플라이언스 - §3.4 컴플라이언스 산출물 - §3.5 커뮤니티 참여: 기여 - §3.6 규격 준수: 적합성·지속 기간 Co-Authored-By: Claude Sonnet 4.6 --- content/ko/guide/TODO.md | 31 ++ .../1-program-foundation/1-policy/_index.md | 179 ++++++++++++ .../2-competence/_index.md | 188 ++++++++++++ .../3-awareness/_index.md | 118 ++++++++ .../1-program-foundation/4-scope/_index.md | 114 ++++++++ .../5-license-obligations/_index.md | 128 +++++++++ .../1-program-foundation/_index.md | 8 + .../2-relevant-tasks/1-access/_index.md | 154 ++++++++++ .../2-relevant-tasks/2-resourced/_index.md | 268 ++++++++++++++++++ .../iso5230_guide/2-relevant-tasks/_index.md | 8 + .../3-content-review/1-sbom/_index.md | 178 ++++++++++++ .../2-license-compliance/_index.md | 130 +++++++++ .../iso5230_guide/3-content-review/_index.md | 8 + .../1-compliance-artifacts/_index.md | 150 ++++++++++ .../guide/iso5230_guide/4-artifacts/_index.md | 8 + .../5-community/1-contributions/_index.md | 216 ++++++++++++++ .../guide/iso5230_guide/5-community/_index.md | 8 + .../6-conformance/1-conformance/_index.md | 104 +++++++ .../6-conformance/2-duration/_index.md | 117 ++++++++ .../iso5230_guide/6-conformance/_index.md | 8 + content/ko/guide/iso5230_guide/_index.md | 131 +++++++++ 21 files changed, 2254 insertions(+) create mode 100644 content/ko/guide/iso5230_guide/1-program-foundation/1-policy/_index.md create mode 100644 content/ko/guide/iso5230_guide/1-program-foundation/2-competence/_index.md create mode 100644 content/ko/guide/iso5230_guide/1-program-foundation/3-awareness/_index.md create mode 100644 content/ko/guide/iso5230_guide/1-program-foundation/4-scope/_index.md create mode 100644 content/ko/guide/iso5230_guide/1-program-foundation/5-license-obligations/_index.md create mode 100644 content/ko/guide/iso5230_guide/1-program-foundation/_index.md create mode 100644 content/ko/guide/iso5230_guide/2-relevant-tasks/1-access/_index.md create mode 100644 content/ko/guide/iso5230_guide/2-relevant-tasks/2-resourced/_index.md create mode 100644 content/ko/guide/iso5230_guide/2-relevant-tasks/_index.md create mode 100644 content/ko/guide/iso5230_guide/3-content-review/1-sbom/_index.md create mode 100644 content/ko/guide/iso5230_guide/3-content-review/2-license-compliance/_index.md create mode 100644 content/ko/guide/iso5230_guide/3-content-review/_index.md create mode 100644 content/ko/guide/iso5230_guide/4-artifacts/1-compliance-artifacts/_index.md create mode 100644 content/ko/guide/iso5230_guide/4-artifacts/_index.md create mode 100644 content/ko/guide/iso5230_guide/5-community/1-contributions/_index.md create mode 100644 content/ko/guide/iso5230_guide/5-community/_index.md create mode 100644 content/ko/guide/iso5230_guide/6-conformance/1-conformance/_index.md create mode 100644 content/ko/guide/iso5230_guide/6-conformance/2-duration/_index.md create mode 100644 content/ko/guide/iso5230_guide/6-conformance/_index.md create mode 100644 content/ko/guide/iso5230_guide/_index.md diff --git a/content/ko/guide/TODO.md b/content/ko/guide/TODO.md index f82396b37..a025e5129 100644 --- a/content/ko/guide/TODO.md +++ b/content/ko/guide/TODO.md @@ -55,4 +55,35 @@ draft: true - [x] #22 4-tool에 Dependency-Track 소개 및 링크 추가 - [x] #23 4-tool에 cdxgen 소개 및 링크 추가 - [x] #24 4-tool에 Syft 소개 및 링크 추가 + +--- +## iso5230_guide 작성 작업 (브랜치: guide/iso-compliance-guides) + +### 루트 +- [x] _index.md (가이드 소개 / 체크리스트 / 인증 절차) + +### §3.1 프로그램 기반 +- [x] 1-policy/_index.md (§3.1.1 정책) +- [x] 2-competence/_index.md (§3.1.2 역량) +- [x] 3-awareness/_index.md (§3.1.3 인식) +- [x] 4-scope/_index.md (§3.1.4 프로그램 범위) +- [x] 5-license-obligations/_index.md (§3.1.5 라이선스 의무) + +### §3.2 관련 업무 +- [x] 1-access/_index.md (§3.2.1 외부 문의 대응) +- [x] 2-resourced/_index.md (§3.2.2 효과적 리소스) + +### §3.3 콘텐츠 검토 및 승인 +- [x] 1-sbom/_index.md (§3.3.1 SBOM) +- [x] 2-license-compliance/_index.md (§3.3.2 라이선스 컴플라이언스) + +### §3.4 컴플라이언스 산출물 +- [x] 1-compliance-artifacts/_index.md (§3.4.1 산출물) + +### §3.5 커뮤니티 참여 +- [x] 1-contributions/_index.md (§3.5.1 기여) + +### §3.6 규격 준수 +- [x] 1-conformance/_index.md (§3.6.1 적합성) +- [x] 2-duration/_index.md (§3.6.2 지속 기간) --- diff --git a/content/ko/guide/iso5230_guide/1-program-foundation/1-policy/_index.md b/content/ko/guide/iso5230_guide/1-program-foundation/1-policy/_index.md new file mode 100644 index 000000000..f7bb7d552 --- /dev/null +++ b/content/ko/guide/iso5230_guide/1-program-foundation/1-policy/_index.md @@ -0,0 +1,179 @@ +--- +title: "§3.1.1 정책" +weight: 10 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "정책"] +description: > +--- + +## 1. 조항 개요 + +오픈소스 정책이 없는 기업은 개발자가 오픈소스 라이선스 의무를 인지하지 못한 채 +소프트웨어를 배포하게 되며, 이는 저작권 침해 소송, 소스코드 강제 공개, 거래처 계약 +해지 등 심각한 법적·사업적 위험으로 이어질 수 있다. §3.1.1은 이러한 위험을 예방하기 +위해 오픈소스 라이선스 컴플라이언스를 관리하는 문서화된 정책을 수립하고, 조직 내 +모든 프로그램 참여자가 정책의 존재를 인식할 수 있도록 전파할 것을 요구한다. 이 조항은 +ISO/IEC 5230 프로그램 전체의 기반이 되며, 이후 모든 조항(역량·프로세스·산출물 등)은 +이 정책 위에서 작동한다. + +## 2. 해야 할 활동 + +- 오픈소스 라이선스 컴플라이언스를 관리하는 정책 문서를 작성하고 공식화한다. +- 정책에 적용 범위(외부 배포 소프트웨어, 기여 활동, 사내 공개 등)를 명확히 정의한다. +- 정책 내에 오픈소스 사용·기여·배포·SBOM 관리·보안 취약점 대응 원칙을 포함한다. +- 프로그램 참여자(개발자·법무·IT·보안 등)에게 정책을 전파하는 절차를 수립하고 문서화한다. +- 전파 사실을 증명할 수 있는 기록(교육 이수, 공지 이력 등)을 보관한다. +- 정기적으로 정책을 검토하고 변경 시 재전파하는 절차를 정책 내에 포함한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §3.1.1 | 공급 소프트웨어의 오픈소스 라이선스 컴플라이언스를 관리하는 문서화된 오픈소스 정책이 있어야 한다. 이 정책은 조직 내부에 전파되어야 한다. | **3.1.1.1** 문서화된 오픈소스 정책
**3.1.1.2** 프로그램 참여자가 오픈소스 정책의 존재를 알 수 있게 하는 문서화된 절차 (교육, 내부 위키, 혹은 기타 실질적인 전달 방법 등) | + +
영문 원문 보기 + +> **§3.1.1 Policy** +> A written open source policy shall exist that governs open source license compliance +> of the supplied software. The policy shall be internally communicated. +> +> **Verification Material(s):** +> 3.1.1.1 A documented open source policy. +> 3.1.1.2 A documented procedure that makes program participants aware of the existence +> of the open source policy (e.g., via training, internal wiki, or other practical +> communication method). + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 3.1.1.1 문서화된 오픈소스 정책 + +**준수 방법** + +오픈소스 정책은 기업이 오픈소스 소프트웨어를 안전하고 효과적으로 활용하기 위한 +원칙과 절차를 담은 공식 문서다. 정책 문서에는 목적, 적용 범위, 역할과 책임, +오픈소스 사용·기여·배포 원칙, SBOM 관리, 보안 취약점 대응, 교육 및 검토 주기 등 +핵심 항목이 포함되어야 한다. 이 문서 자체가 입증자료 3.1.1.1에 해당하므로 반드시 +공식 문서로 관리해야 하며, 버전과 승인 이력을 기록해야 한다. + +정책 수립 시에는 회사의 비즈니스 환경과 소프트웨어 공급망 특성을 반영해야 한다. +예를 들어 외부에 소프트웨어를 배포하는 제품 기업과 서비스 기업은 컴플라이언스 산출물 +생성 의무 범위가 다를 수 있으므로, 적용 범위를 명확하게 정의한다. 정책은 법무팀 또는 +OSRB(Open Source Review Board)의 검토를 거쳐 최고 경영진 또는 권한 있는 부서장이 +승인하는 절차를 거쳐야 한다. + +정책은 한 번 수립한 뒤 방치하는 문서가 아니다. ISO/IEC 5230 요구사항 변경, 새로운 +라이선스 유형의 등장, 법적 환경 변화 등을 반영하여 최소 연 1회 정기 검토를 실시하고, +변경 이력을 문서에 기록해야 한다. + +**고려사항** + +- **포함 항목**: 오픈소스 사용, 외부 기여, 사내 프로젝트 공개, SBOM 관리, + 보안 취약점 대응 원칙을 정책에 모두 포함한다. +- **적용 범위 명시**: 외부 배포 소프트웨어, 내부 사용 소프트웨어, 기여 활동 등 + 정책이 적용되는 범위를 명확하게 구분한다. +- **승인 절차**: OSRB 또는 법무팀장 이상이 최종 승인하고, 승인 날짜와 승인자를 + 문서에 기록한다. +- **버전 관리**: 문서 버전 번호와 변경 이력을 유지하여 감사 시 이전 버전과 + 비교할 수 있도록 한다. +- **정기 검토**: 연 1회 이상 정책을 검토하며, 검토 완료 날짜와 검토자를 기록한다. + +**샘플** + +아래는 오픈소스 정책 문서의 목적 및 적용 범위 샘플이다. 이 텍스트 자체가 +입증자료 3.1.1.1(문서화된 오픈소스 정책)의 핵심 구성 요소가 된다. + +``` +## 1. 목적 및 적용 범위 + +### 1.1 목적 + +이 정책은 회사가 오픈소스 소프트웨어를 안전하고 효과적으로 활용하기 위한 원칙과 +절차를 제공합니다. 정책의 주요 목적은 다음과 같습니다: + +1. 오픈소스 라이선스 컴플라이언스: + 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 라이선스 의무를 준수하고, + 관련 법적 요구사항을 충족합니다. +2. 오픈소스 보안 보증: + 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안 취약점을 식별하고, + 적절한 대응 조치를 통해 보안 위험을 최소화합니다. + +이러한 원칙은 ISO/IEC 5230(오픈소스 라이선스 컴플라이언스) 및 +ISO/IEC 18974(오픈소스 보안 보증)의 요구사항을 충족하도록 설계되었습니다. + +### 1.4 적용 범위 + +이 정책은 회사가 개발, 배포, 또는 사용하는 모든 소프트웨어 프로젝트에 적용됩니다. + +- 외부로 제공하거나 배포하는 모든 공급 소프트웨어. +- 외부 오픈소스 프로젝트에 기여하는 활동. +- 내부 프로젝트를 오픈소스로 공개하는 활동. + +단, 내부 사용 목적으로만 사용되는 오픈소스는 별도의 검토 절차를 통해 +정책 적용 여부를 결정할 수 있습니다. + +정책의 적용 범위는 회사의 비즈니스 환경 변화에 따라 정기적으로 검토되고 갱신됩니다. +``` + +--- + +### 3.1.1.2 정책 인식 방법 문서화 + +**준수 방법** + +정책 문서를 작성하는 것만으로는 부족하다. 프로그램 참여자(소프트웨어 개발·배포·기여에 +관여하는 모든 직원)가 정책의 존재를 실제로 인식할 수 있도록 전파 절차를 수립하고 +문서화해야 한다. 전파 절차 문서에는 어떤 채널을 통해, 언제, 누구에게 정책을 전달하는지 +구체적으로 명시해야 한다. 이 전파 절차 문서 자체가 입증자료 3.1.1.2다. + +전파 방법은 복수의 채널을 조합하는 것이 효과적이다. 신규 입사자에게는 온보딩 과정에 +오픈소스 정책 안내를 포함하고, 기존 직원에게는 사내 위키 게시와 이메일 공지를 +활용한다. 정책 변경 시에는 변경 내용을 즉시 공지하는 절차도 포함해야 한다. 전파 +사실을 증명하기 위해 공지 발송 이력, 교육 이수 기록, 정책 인식 확인 서명 등의 증거를 +최소 3년간 보관한다. + +**고려사항** + +- **복수 채널 활용**: 사내 위키, 이메일 공지, 온보딩 교육 등 둘 이상의 채널을 + 활용하여 전파 효과를 높인다. +- **신규 입사자**: 온보딩 프로세스에 오픈소스 정책 안내를 필수 항목으로 포함한다. +- **정책 변경 시**: 변경 사항을 프로그램 참여자에게 즉시 공지하는 별도 절차를 수립한다. +- **증거 보관**: 공지 이력, 교육 이수 확인서, 정책 인식 확인 서명을 최소 3년간 보관한다. +- **접근성**: 정책 문서를 사내 포털이나 위키에 항시 게시하여 참여자가 언제든 + 확인할 수 있도록 한다. + +**샘플** + +아래는 정책 전파 공지 이메일 샘플이다. 전송 이력을 보관하면 입증자료 3.1.1.2의 +증거로 활용할 수 있다. + +``` +제목: [오픈소스] 오픈소스 정책 안내 및 숙지 요청 + +수신: 전체 개발/배포 관련 임직원 +발신: 오픈소스 프로그램 매니저 + +안녕하세요. + +당사의 오픈소스 정책이 제정(또는 개정)되었습니다. +오픈소스 소프트웨어를 사용, 기여, 또는 배포하는 업무에 관여하는 +모든 임직원은 아래 링크의 정책 문서를 확인하고 숙지해 주시기 바랍니다. + +- 정책 문서: [사내 포털 링크] +- 주요 내용: 오픈소스 사용 원칙, 라이선스 컴플라이언스 절차, + SBOM 관리, 보안 취약점 대응 원칙 +- 정책 버전: v1.0 (시행일: YYYY-MM-DD) + +정책 내용에 대한 문의는 오픈소스 프로그램 매니저(oss@company.com)에게 +연락해 주십시오. + +감사합니다. +오픈소스 프로그램 매니저 +``` + +## 5. 참고 + +- 관련 가이드: [기업 오픈소스 관리 가이드 — 2. 정책](../../../opensource_for_enterprise/2-policy/) +- 관련 템플릿: [오픈소스 정책 템플릿](../../../templates/1-policy/) diff --git a/content/ko/guide/iso5230_guide/1-program-foundation/2-competence/_index.md b/content/ko/guide/iso5230_guide/1-program-foundation/2-competence/_index.md new file mode 100644 index 000000000..721b8a80f --- /dev/null +++ b/content/ko/guide/iso5230_guide/1-program-foundation/2-competence/_index.md @@ -0,0 +1,188 @@ +--- +title: "§3.1.2 역량" +weight: 20 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "역량"] +description: > +--- + +## 1. 조항 개요 + +오픈소스 프로그램이 실제로 작동하려면 관련 역할을 맡은 사람들이 그 역할을 수행할 +역량을 갖추어야 한다. 역할과 책임이 문서에만 적혀 있고 담당자가 오픈소스 라이선스나 +보안 취약점 관리에 대한 기본 지식도 없다면, 정책과 프로세스는 유명무실해진다. +§3.1.2는 프로그램에 관여하는 역할을 식별하고 각 역할에 필요한 역량을 정의하며, +참여자가 실제로 그 역량을 갖추었는지 평가하고 기록하도록 요구한다. 이 조항은 +§3.1.1 정책에서 정의한 역할 구조를 구체적인 역량 체계로 발전시키는 단계다. + +## 2. 해야 할 활동 + +- 오픈소스 프로그램의 성과에 영향을 미치는 역할과 각 역할의 책임을 목록으로 작성한다. +- 각 역할을 수행하는 데 필요한 역량(지식·기술·경험)을 구체적으로 정의하고 문서화한다. +- 각 프로그램 참여자가 해당 역할에 필요한 역량을 갖추었는지 평가한다. +- 역량이 미흡한 경우 교육·훈련·멘토링 등 역량 확보 조치를 취한다. +- 역량 평가 결과와 후속 조치 이력을 문서화하여 보관한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §3.1.2 | 조직은 다음을 수행해야 한다:
- 프로그램의 성과와 효율에 영향을 미치는 역할과 그 책임을 확인한다
- 각 역할을 수행할 프로그램 참여자가 갖춰야 할 필요 역량을 결정한다
- 프로그램 참여자가 적절한 교육·훈련·경험을 바탕으로 자격을 갖춘 자임을 확인한다
- 해당되는 경우 필요한 역량을 확보하기 위해 조치한다
- 역량 보유를 증명하기 위한 정보를 문서화하여 유지한다 | **3.1.2.1** 프로그램의 여러 참여자에 대한 역할과 각 역할의 책임을 나열한 문서
**3.1.2.2** 각 역할을 위해 필요한 역량을 기술한 문서
**3.1.2.3** 각 프로그램 참여자의 역량을 평가한 문서화된 증거 | + +
영문 원문 보기 + +> **§3.1.2 Competence** +> The organization shall: +> - Identify the roles and responsibilities that impact the performance and effectiveness +> of the program; +> - Determine the necessary competence of program participants fulfilling each role; +> - Ensure that program participants are competent on the basis of appropriate education, +> training, and/or experience; +> - Where applicable, take actions to acquire the necessary competence; +> - Retain appropriate documented information as evidence of competence. +> +> **Verification Material(s):** +> 3.1.2.1 A documented list of roles with corresponding responsibilities for the +> different participants in the program. +> 3.1.2.2 A document that identifies the competencies for each role. +> 3.1.2.3 Documented evidence of assessed competence for each program participant. + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 3.1.2.1 역할과 책임 목록 문서 + +**준수 방법** + +프로그램에 관여하는 모든 역할을 열거하고, 각 역할이 어떤 책임을 지는지 명확하게 +정의한 문서를 작성해야 한다. 일반적으로 오픈소스 프로그램 매니저, 법무 담당, +IT 담당, 보안 담당, 개발 문화 담당, 사업 부서가 핵심 역할에 해당한다. 기업 규모나 +조직 구조에 따라 역할을 겸임하거나 OSRB(Open Source Review Board) 형태의 가상 +조직으로 운영하는 것도 가능하다. + +역할 정의 시 추상적인 서술보다 구체적인 책임 항목을 나열하는 것이 감사 시 입증에 +유리하다. 예를 들어 "오픈소스 관리"가 아니라 "공급 소프트웨어에 사용된 오픈소스 +컴포넌트의 라이선스 검토 및 SBOM 생성 감독"처럼 명확하게 기술한다. 이 문서는 +오픈소스 정책 문서(§3.1.1.1)의 역할 및 책임 섹션에 포함하거나 별도 Appendix로 +관리할 수 있다. + +**고려사항** + +- **역할 식별 범위**: 개발·법무·IT·보안·구매 등 소프트웨어 공급망에 관여하는 + 모든 조직의 역할을 포함하며, 외주 개발 및 벤더 관리 담당도 검토한다. +- **책임 구체화**: 역할별 책임은 추상적 서술이 아닌 구체적 활동 단위로 기술한다. +- **겸임 명시**: 한 사람이 여러 역할을 겸임하는 경우 해당 사실을 문서에 명기한다. +- **갱신 주기**: 조직 변경·인사 이동 발생 시 즉시 문서를 갱신하고 버전을 업데이트한다. + +**샘플** + +아래는 오픈소스 정책 Appendix의 역할·책임 목록 샘플이다. +[오픈소스 정책 템플릿 Appendix 1](../../../templates/1-policy/appendix/)에서 +전체 양식을 확인할 수 있다. + +``` +| 역할 | 책임 | +|------|------| +| 오픈소스 프로그램 매니저 | 회사의 오픈소스 프로그램 총괄 / SBOM 생성 감독 / + 외부 문의 대응 / 내부 모범 사례 관리 | +| 법무 담당 | 오픈소스 라이선스 의무 해석 및 검토 / + 라이선스 호환성 검토 / 법적 위험 평가 및 자문 | +| IT 담당 | 오픈소스 분석 도구 운영 및 CI/CD 파이프라인 통합 / + SBOM 생성 자동화 지원 | +| 보안 담당 | 알려진 취약점 및 새로 발견된 취약점 대응 / + DevSecOps 환경 통합 및 보안 조치 수행 | +| 개발 문화 담당 | 오픈소스 커뮤니티 참여 장려 / 교육 프로그램 운영 | +| 사업 부서 | 오픈소스 정책 및 프로세스 준수 / 오픈소스 식별 및 신고 | +``` + +--- + +### 3.1.2.2 역할별 필요 역량 문서 + +**준수 방법** + +각 역할을 수행하기 위해 필요한 지식·기술·경험을 구체적으로 정의하고 문서화해야 한다. +역량 정의는 해당 역할을 새로 맡은 사람이 "내가 무엇을 알아야 하는가"를 명확히 +파악할 수 있는 수준으로 작성한다. 단순히 "오픈소스 지식 필요"처럼 모호하게 쓰지 않고, +"주요 오픈소스 라이선스(MIT, Apache-2.0, GPL-2.0 등)의 의무 사항 및 호환성 이해"처럼 +구체적으로 기술한다. + +역량 수준을 "기본 이해", "실무 적용 가능", "전문가" 등으로 세분화하면 평가 기준이 +명확해지고 교육 계획을 수립하기 쉬워진다. 이 문서는 오픈소스 정책 문서에 포함하거나 +별도 역량 정의서로 관리할 수 있으며, 정기적으로 검토하여 기술 환경 변화를 반영해야 한다. + +**고려사항** + +- **구체성**: 역량 항목은 측정 가능한 수준으로 기술하여 평가 기준으로 활용할 수 있게 한다. +- **역량 수준 구분**: "기본 이해 / 실무 적용 / 전문가" 등 수준을 정의하면 + 평가와 교육 설계가 용이해진다. +- **갱신 주기**: 새로운 도구·라이선스·보안 기술 등장 시 역량 항목을 업데이트한다. +- **교육 연계**: 정의된 역량을 기반으로 역할별 교육 커리큘럼을 설계한다. + +**샘플** + +아래는 역할별 필요 역량 정의표 샘플이다. + +``` +| 역할 | 필요 역량 | +|------|-----------| +| 오픈소스 프로그램 매니저 | 주요 오픈소스 라이선스 의무 및 호환성 이해 / + 소프트웨어 개발 프로세스 이해 / + SBOM 생성·관리 지식 / 커뮤니케이션 스킬 | +| 법무 담당 | 소프트웨어 저작권법 전문 지식 / + 오픈소스 라이선스 해석 능력 / 법적 위험 평가 능력 | +| IT 담당 | 오픈소스 분석 도구(FOSSology, ORT, Syft 등) 운용 / + CI/CD 파이프라인 이해 / IT 인프라 전문 지식 | +| 보안 담당 | DevSecOps 이해 / 취약점 분석 도구 운용 / + CVSS 점수 해석 및 위험 평가 능력 | +| 개발 문화 담당 | 오픈소스 정책 이해 / 교육 설계 능력 / + 오픈소스 커뮤니티 참여 경험 | +| 사업 부서 | 오픈소스 컴플라이언스 기본 지식 / + 오픈소스 라이선스 기본 이해 / 오픈소스 정책 이해 | +``` + +--- + +### 3.1.2.3 역량 평가 증거 + +**준수 방법** + +각 프로그램 참여자가 정의된 역량을 실제로 갖추었는지 평가하고, 그 결과를 문서화하여 +보관해야 한다. 평가 방법은 온라인 교육 이수 확인, 자격증 보유 여부 확인, 필기·실기 +시험, 담당 업무 수행 실적 검토, 면담 등 다양한 방식을 조합할 수 있다. 중요한 것은 +평가 결과가 기록으로 남아야 한다는 점이다. 이 기록 자체가 입증자료 3.1.2.3이다. + +평가 결과 미흡한 역량이 발견되면 교육 수강, 외부 컨설팅, 멘토링 등 보완 조치를 취하고 +그 완료 기록도 함께 보관한다. 평가는 최소 연 1회 정기적으로 실시하고, 담당자 변경 +시에는 신규 담당자에 대해 즉시 초기 평가를 수행한다. 평가 기록은 사내 학습 관리 +시스템(LMS) 또는 문서 시스템에 저장하여 감사 시 즉시 제출 가능한 상태로 유지한다. + +**고려사항** + +- **평가 방법 다양화**: 온라인 교육 이수, 시험, 실무 수행 실적 등 복수의 방법을 + 조합하여 역량을 종합적으로 평가한다. +- **정기 평가 주기**: 최소 연 1회 실시하며, 담당자 변경 시 즉시 신규 평가를 수행한다. +- **미흡 역량 보완**: 평가 결과 미흡 항목에 대해 교육 계획을 수립하고 이수 후 + 재평가를 실시한다. +- **기록 보관 기간**: 평가 기록은 최소 해당 담당자 재직 기간 동안 보관하며, + 퇴직 후에도 감사 목적으로 일정 기간 유지한다. + +**샘플** + +아래는 역량 평가 기록부 샘플이다. 역할별로 작성하여 LMS 또는 문서 시스템에 보관한다. + +``` +| 이름 | 역할 | 평가 항목 | 평가 방법 | 평가 결과 | 평가일 | 비고 | +|------|------|-----------|-----------|-----------|--------|------| +| 홍길동 | 오픈소스 프로그램 매니저 | 라이선스 의무 이해 | 온라인 교육 이수 | 완료 (95점) | 2026-01-15 | - | +| 홍길동 | 오픈소스 프로그램 매니저 | SBOM 관리 지식 | 실무 평가 | 완료 | 2026-01-15 | - | +| 김철수 | 보안 담당 | DevSecOps 이해 | 외부 교육 이수 | 완료 | 2026-02-03 | 수료증 보관 | +| 이영희 | 법무 담당 | 오픈소스 라이선스 해석 | 면담 평가 | 완료 | 2026-01-20 | - | +``` + +## 5. 참고 + +- 관련 가이드: [기업 오픈소스 관리 가이드 — 1. 조직](../../../opensource_for_enterprise/1-teams/) +- 관련 템플릿: [오픈소스 정책 템플릿 — Appendix 1. 담당자 현황](../../../templates/1-policy/appendix/) diff --git a/content/ko/guide/iso5230_guide/1-program-foundation/3-awareness/_index.md b/content/ko/guide/iso5230_guide/1-program-foundation/3-awareness/_index.md new file mode 100644 index 000000000..49d3ca12e --- /dev/null +++ b/content/ko/guide/iso5230_guide/1-program-foundation/3-awareness/_index.md @@ -0,0 +1,118 @@ +--- +title: "§3.1.3 인식" +weight: 30 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "인식"] +description: > +--- + +## 1. 조항 개요 + +역할과 역량을 갖춘 참여자라도 오픈소스 프로그램의 목적과 자신의 기여가 전체 +컴플라이언스 체계에 어떤 의미를 갖는지 인식하지 못하면 형식적 참여에 그치게 된다. +§3.1.3은 프로그램 참여자가 프로그램의 목표, 자신의 기여 방법, 그리고 프로그램을 +준수하지 않을 경우 발생하는 결과를 실제로 인식하고 있음을 평가하고 기록할 것을 +요구한다. 이 조항은 §3.1.2 역량(지식·기술 보유)의 다음 단계로, 참여자가 보유한 +역량을 프로그램 목적과 연결하여 실질적 동기를 형성하는 단계다. + +## 2. 해야 할 활동 + +- 프로그램 참여자가 오픈소스 프로그램의 목표(라이선스 컴플라이언스, 보안 보증 등)를 + 이해하고 있는지 확인한다. +- 각 참여자가 자신의 역할이 전체 프로그램 운영에 어떻게 기여하는지 인식하고 있는지 + 평가한다. +- 프로그램 요구사항을 미준수할 경우 발생할 수 있는 법적·사업적 영향에 대해 + 참여자가 인식하고 있는지 확인한다. +- 인식 평가를 주기적으로 실시하고, 그 결과를 문서로 기록하여 보관한다. +- 인식이 미흡한 참여자에 대해서는 추가 교육을 실시하고 재평가 결과를 보관한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §3.1.3 | 조직은 프로그램 참여자가 다음 사항을 인식하도록 해야 한다: 오픈소스 정책의 존재와 위치 / 오픈소스 관련 목표 / 프로그램 효과에 대한 자신의 기여 방법 / 프로그램 요구사항을 따르지 않을 경우 발생하는 영향 | **3.1.3.1** 프로그램의 목표, 프로그램 내에서의 참여자 기여 방법 및 프로그램을 준수하지 않을 경우 미치는 영향에 대한 프로그램 참여자의 인식을 평가하였음을 나타내는 문서화된 증거 | + +
영문 원문 보기 + +> **§3.1.3 Awareness** +> The organization shall ensure that the program participants are aware of: +> - The open source policy and where to find it; +> - Relevant open source objectives; +> - Their contribution to the effectiveness of the program; and +> - The implications of not following the program's requirements. +> +> **Verification Material(s):** +> 3.1.3.1 Documented evidence of assessed awareness for the program +> participants - which should include the program's objectives, contributions +> within the program, and implications of failing to follow the program's +> requirements. + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 3.1.3.1 참여자 인식 평가 증거 + +**준수 방법** + +프로그램 참여자가 세 가지 핵심 내용을 인식하고 있음을 평가하고 그 결과를 기록해야 +한다. 세 가지 핵심 내용은 ①프로그램의 목표(오픈소스 라이선스 컴플라이언스 및 +보안 보증), ②자신의 역할이 프로그램에 기여하는 방법, ③프로그램을 준수하지 않을 +경우 발생하는 법적·사업적 영향이다. + +평가 방법은 온라인 퀴즈, 오프라인 설문, 교육 후 이수 확인, 인터뷰 등 다양하게 +조합할 수 있다. 중요한 것은 평가 결과가 문서로 남아야 한다는 점이다. 이 기록이 +입증자료 3.1.3.1에 해당한다. 평가는 최소 연 1회 정기적으로 실시하고, 신규 참여자는 +프로그램 합류 시 즉시 초기 평가를 수행한다. 인식이 미흡한 참여자에 대해서는 +추가 교육을 실시하고 재평가 결과를 함께 보관한다. + +**고려사항** + +- **평가 범위**: 세 가지 핵심 인식(목표·기여·영향)을 모두 포함하는 평가 문항을 + 설계한다. +- **평가 주기**: 최소 연 1회 정기 평가를 실시하고, 신규 참여자는 합류 즉시 + 초기 평가를 수행한다. +- **증거 형식**: 퀴즈 결과, 서명된 정책 인식 확인서, 교육 이수 증명 등 감사 시 + 제출 가능한 형식으로 보관한다. +- **미흡자 조치**: 평가 결과 미흡한 참여자에 대해 추가 교육을 실시하고 재평가 + 기록을 남긴다. +- **접근성**: 평가에 활용되는 정책 문서 및 교육 자료를 사내 포털에 항상 접근 + 가능한 상태로 유지한다. + +**샘플** + +아래는 참여자 인식 평가 기록부 샘플이다. 교육 이수 시 작성하여 LMS 또는 문서 +시스템에 보관한다. + +``` +| 이름 | 역할 | 평가 항목 | 평가 방법 | 결과 | 평가일 | 비고 | +|------|------|-----------|-----------|------|--------|------| +| 홍길동 | 오픈소스 프로그램 매니저 | 프로그램 목표 이해 | 온라인 퀴즈 | 완료 (90점) | 2026-01-15 | - | +| 홍길동 | 오픈소스 프로그램 매니저 | 미준수 영향 인식 | 온라인 퀴즈 | 완료 (90점) | 2026-01-15 | - | +| 김철수 | 개발자 | 프로그램 목표 이해 | 온라인 퀴즈 | 완료 (85점) | 2026-01-20 | - | +| 이영희 | 보안 담당 | 자신의 기여 방법 인식 | 인터뷰 | 완료 | 2026-01-22 | 면담 기록 보관 | +``` + +아래는 정책 인식 확인서 샘플이다. 교육 완료 후 서명을 받아 보관하면 입증자료로 +활용할 수 있다. + +``` +[오픈소스 정책 인식 확인서] + +본인은 다음 사항을 숙지하였음을 확인합니다: + +1. 당사 오픈소스 정책의 존재와 해당 문서의 위치 +2. 오픈소스 라이선스 컴플라이언스 및 보안 보증 프로그램의 목표 +3. 본인의 역할이 오픈소스 프로그램 운영에 기여하는 방법 +4. 오픈소스 정책 및 프로세스를 준수하지 않을 경우 발생할 수 있는 + 법적·사업적 위험 + +이름: ________________ 역할: ________________ +서명: ________________ 날짜: ________________ +``` + +## 5. 참고 + +- 관련 가이드: [기업 오픈소스 관리 가이드 — 5. 교육](../../../opensource_for_enterprise/5-training/) +- 관련 템플릿: [오픈소스 정책 템플릿 — §6 교육 및 인식 제고](../../../templates/1-policy/) diff --git a/content/ko/guide/iso5230_guide/1-program-foundation/4-scope/_index.md b/content/ko/guide/iso5230_guide/1-program-foundation/4-scope/_index.md new file mode 100644 index 000000000..6acb839a2 --- /dev/null +++ b/content/ko/guide/iso5230_guide/1-program-foundation/4-scope/_index.md @@ -0,0 +1,114 @@ +--- +title: "§3.1.4 프로그램 범위" +weight: 40 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "프로그램 범위"] +description: > +--- + +## 1. 조항 개요 + +오픈소스 프로그램이 조직 전체에 적용되는지, 특정 제품군이나 사업 단위에만 +적용되는지 명확하지 않으면 컴플라이언스 활동의 경계가 모호해지고 책임 소재가 +불분명해진다. §3.1.4는 오픈소스 프로그램이 어떤 소프트웨어·조직 단위·배포 +채널에 적용되는지, 그리고 어디까지가 적용 범위 밖인지를 명확하게 정의한 +문서화된 진술을 요구한다. 적용 범위는 조직의 규모와 비즈니스 모델에 따라 +다를 수 있으며, 이 조항은 그 선택을 명시적으로 기록하도록 한다. + +## 2. 해야 할 활동 + +- 오픈소스 프로그램이 적용되는 소프트웨어 유형(외부 배포 제품, 서비스, 내부 + 시스템 등)을 결정한다. +- 프로그램이 적용되는 조직 범위(전사, 특정 사업부, 특정 제품군 등)를 정의한다. +- 적용 범위에서 명시적으로 제외되는 항목이 있다면 해당 예외 사항과 그 근거를 + 함께 기록한다. +- 적용 범위 진술을 문서화하여 오픈소스 정책 또는 별도 문서로 공식 관리한다. +- 비즈니스 환경 변화(신규 사업 진출, 인수합병 등) 시 적용 범위를 재검토하고 + 갱신한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §3.1.4 | 공급자의 필요와 비즈니스 모델에 따라 프로그램의 적용 범위가 다를 수 있다. 범위는 전체 조직, 특정 사업 단위, 특정 제품군, 특정 제품, 또는 단일 오픈소스 컴포넌트가 될 수 있다. 범위의 정의는 명확해야 한다. | **3.1.4.1** 프로그램의 적용 범위와 한계를 명확하게 정의한 문서화된 진술 | + +
영문 원문 보기 + +> **§3.1.4 Program Scope** +> Different programs may be designed to address different scopes depending on +> the supplier's needs and business model. The scope might include the entire +> organization, a particular business unit, a particular product line, a +> specific product, or even a single open source component. The definition of +> the scope needs to be clear. +> +> **Verification Material(s):** +> 3.1.4.1 A written statement that clearly defines the scope and limits of +> the program. + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 3.1.4.1 프로그램 적용 범위 진술 + +**준수 방법** + +프로그램이 어디에 적용되고 어디에 적용되지 않는지를 명확하게 서술한 문서를 +작성해야 한다. 이 진술은 오픈소스 정책 문서(§3.1.1.1)의 적용 범위 섹션에 +포함하거나 별도 문서로 관리할 수 있다. 핵심은 경계가 명확해야 한다는 점이다. +예를 들어 "외부에 배포하는 모든 소프트웨어 제품"처럼 명확하게 기술하거나, +"A 사업부가 개발하는 임베디드 소프트웨어에 한정"처럼 범위를 구체적으로 +한정할 수 있다. + +적용 범위를 결정할 때는 소프트웨어 배포 형태(바이너리 제품, SaaS, 내부 도구), +오픈소스 사용 방식(직접 사용, 간접 의존성), 외부 기여 활동 등을 종합적으로 +고려한다. 내부 사용 목적 소프트웨어에 대한 처리 방침도 명시하는 것이 바람직하다. +적용 범위 진술은 비즈니스 환경 변화에 따라 정기적으로 검토하고 버전을 관리해야 한다. + +**고려사항** + +- **배포 형태 구분**: 외부 배포 제품, SaaS 서비스, 내부 시스템 등 소프트웨어 + 배포 유형별로 적용 여부를 명시한다. +- **조직 범위 명시**: 전사 적용인지, 특정 사업부·제품군에만 적용되는지 명확하게 + 기술한다. +- **예외 항목 기록**: 적용 범위에서 제외되는 항목이 있다면 예외 사유와 함께 + 문서에 명기한다. +- **갱신 주기**: 신규 사업 진출, 인수합병, 제품 포트폴리오 변경 시 즉시 재검토하고 + 버전을 업데이트한다. +- **정책 연계**: 적용 범위 진술은 오픈소스 정책 §1.4 적용 범위 섹션과 일관성을 + 유지한다. + +**샘플** + +아래는 오픈소스 정책 내 적용 범위 진술 샘플이다. 이 텍스트 자체가 입증자료 +3.1.4.1에 해당한다. + +``` +## 프로그램 적용 범위 + +본 오픈소스 프로그램은 다음 범위에 적용된다: + +**적용 대상** +- 회사가 외부에 배포하거나 판매하는 모든 소프트웨어 제품 (임베디드 소프트웨어 + 포함) +- 외부 오픈소스 프로젝트에 대한 기여 활동 +- 내부 프로젝트를 오픈소스로 공개하는 활동 + +**적용 제외** +- 외부에 배포되지 않고 사내에서만 사용되는 소프트웨어 (단, 별도 검토 절차 + 적용 가능) +- 제3자로부터 도입하는 상용 소프트웨어 (단, 오픈소스 포함 여부 검토 필요) + +**조직 범위** +본 프로그램은 [회사명] 전 사업부에 적용되며, 자회사 및 계열사는 별도 협의를 +통해 적용 여부를 결정한다. + +이 적용 범위는 비즈니스 환경 변화에 따라 연 1회 이상 검토하며, +변경 시 오픈소스 프로그램 매니저가 개정 버전을 공표한다. +``` + +## 5. 참고 + +- 관련 가이드: [기업 오픈소스 관리 가이드 — 2. 정책](../../../opensource_for_enterprise/2-policy/) +- 관련 템플릿: [오픈소스 정책 템플릿 — §1.4 적용 범위](../../../templates/1-policy/) diff --git a/content/ko/guide/iso5230_guide/1-program-foundation/5-license-obligations/_index.md b/content/ko/guide/iso5230_guide/1-program-foundation/5-license-obligations/_index.md new file mode 100644 index 000000000..5d8488758 --- /dev/null +++ b/content/ko/guide/iso5230_guide/1-program-foundation/5-license-obligations/_index.md @@ -0,0 +1,128 @@ +--- +title: "§3.1.5 라이선스 의무" +weight: 50 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "라이선스 의무"] +description: > +--- + +## 1. 조항 개요 + +오픈소스 컴포넌트를 소프트웨어에 포함할 때 가장 핵심적인 작업은 해당 컴포넌트에 +적용된 라이선스가 부과하는 의무·제한·권리를 정확히 파악하는 것이다. 라이선스 +의무를 검토하지 않고 배포하면 소스코드 강제 공개, 저작권 고지 누락, 특허 조항 +위반 등 심각한 법적 리스크가 발생할 수 있다. §3.1.5는 식별된 모든 라이선스에 +대해 의무·제한·권리를 검토하고 기록하는 절차를 수립하도록 요구한다. 이 절차는 +§3.3.2 라이선스 컴플라이언스 프로세스의 토대가 된다. + +## 2. 해야 할 활동 + +- 소프트웨어에 사용된 오픈소스 컴포넌트의 라이선스를 식별하고 목록화한다. +- 각 라이선스가 부과하는 의무(고지 의무, 소스코드 공개 의무 등), 제한(상업적 + 사용 제한, 특허 사용 제한 등), 권리(사용·수정·재배포 권리 등)를 검토한다. +- 검토 결과를 라이선스별로 문서화하고 기록을 유지한다. +- 라이선스 해석에 불확실성이 있는 경우 법무 담당에게 검토를 의뢰하는 절차를 + 수립한다. +- 신규 라이선스 등장 또는 기존 라이선스 해석 변경 시 절차를 갱신한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §3.1.5 | 식별된 라이선스가 부과하는 의무, 제한 및 권리를 결정하기 위해 식별된 라이선스를 검토하는 프로세스가 존재해야 한다. | **3.1.5.1** 각 식별된 라이선스에 의해 부여된 의무, 제한 및 권리를 검토하고 기록하기 위한 문서화된 절차 | + +
영문 원문 보기 + +> **§3.1.5 License Obligations** +> A process shall exist for reviewing the identified licenses to determine +> the obligations, restrictions and rights granted by each license. +> +> **Verification Material(s):** +> 3.1.5.1 A documented procedure to review and document the obligations, +> restrictions, and rights granted by each identified license. + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 3.1.5.1 라이선스 의무 검토 절차 + +**준수 방법** + +각 오픈소스 라이선스의 의무·제한·권리를 검토하고 기록하는 절차를 문서화해야 한다. +절차에는 ①라이선스 식별, ②의무·제한·권리 분석, ③검토 결과 기록, ④불확실 +사항에 대한 법무 검토 의뢰, ⑤기록 보관의 단계가 포함되어야 한다. 이 절차 문서 +자체가 입증자료 3.1.5.1이다. + +라이선스별 의무는 사전에 정리된 라이선스 데이터베이스(SPDX License List 등)를 +활용하면 효율적으로 관리할 수 있다. 주요 라이선스(MIT, Apache-2.0, GPL-2.0, +GPL-3.0, LGPL-2.1, AGPL-3.0 등)에 대한 의무 요약표를 미리 작성해 두고, 신규 +라이선스 발견 시 즉시 추가 검토하는 방식이 실무적으로 효과적이다. 복잡한 라이선스 +조합이나 법적 판단이 필요한 경우 법무 담당에게 에스컬레이션하는 기준도 절차에 +명시한다. + +**고려사항** + +- **SPDX 활용**: SPDX License List를 기준 라이선스 목록으로 사용하면 식별과 + 분류가 표준화된다. +- **의무 유형 구분**: 고지 의무, 소스코드 공개 의무, 특허 조항, 상표 제한 등 + 의무 유형을 구분하여 기록한다. +- **배포 형태별 검토**: 바이너리 배포, SaaS, 내부 사용 등 배포 형태에 따라 + 라이선스 의무가 달라질 수 있으므로 형태별로 검토한다. +- **에스컬레이션 기준**: 법무 검토가 필요한 상황(라이선스 충돌, 비표준 라이선스, + 상업적 제한 조항 등)을 절차에 명시한다. +- **갱신 주기**: 신규 라이선스 채택 또는 기존 라이선스 해석 변경 시 즉시 절차와 + 기록을 갱신한다. + +**샘플** + +아래는 주요 오픈소스 라이선스 의무 요약표 샘플이다. 라이선스 검토 절차의 일환으로 +작성하여 보관하면 입증자료로 활용할 수 있다. + +``` +| 라이선스 | 고지 의무 | 소스코드 공개 | 수정본 동일 라이선스 | 특허 조항 | 상업적 사용 | +|----------|-----------|--------------|----------------------|-----------|-------------| +| MIT | O | X | X | X | O | +| Apache-2.0 | O | X | X | O (특허 허여) | O | +| GPL-2.0 | O | O (배포 시) | O | X | O | +| GPL-3.0 | O | O (배포 시) | O | O (특허 허여) | O | +| LGPL-2.1 | O | O (라이브러리) | O (라이브러리) | X | O | +| AGPL-3.0 | O | O (네트워크 포함) | O | O (특허 허여) | O | +| MPL-2.0 | O | O (파일 단위) | O (파일 단위) | O (특허 허여) | O | +| BSD-2-Clause | O | X | X | X | O | +| BSD-3-Clause | O | X | X | X | O | +``` + +아래는 라이선스 의무 검토 절차 개요 샘플이다. + +``` +[라이선스 의무 검토 절차] + +1. 라이선스 식별 + - SBOM 생성 도구(FOSSology, ORT 등)를 통해 오픈소스 컴포넌트 및 + 라이선스를 식별한다. + +2. 의무·제한·권리 분석 + - 사전 작성된 라이선스 의무 요약표를 참조하여 해당 라이선스의 + 의무·제한·권리를 확인한다. + - 요약표에 없는 라이선스는 SPDX License List 및 라이선스 원문을 + 검토하여 신규 항목을 추가한다. + +3. 법무 검토 의뢰 (해당 시) + - 라이선스 충돌, 비표준 라이선스, 상업적 제한 조항이 포함된 경우 + 법무 담당에게 검토를 의뢰한다. + +4. 검토 결과 기록 + - 검토 결과를 SBOM 또는 라이선스 검토 기록서에 기록하고 + 오픈소스 관리 시스템에 보관한다. + +5. 의무 이행 확인 + - 배포 전 라이선스 의무(고지문 포함, 소스코드 공개 등)가 완료되었는지 + 확인한다. +``` + +## 5. 참고 + +- 관련 가이드: [기업 오픈소스 관리 가이드 — 3. 프로세스](../../../opensource_for_enterprise/3-process/) +- 관련 템플릿: [오픈소스 프로세스 템플릿](../../../templates/2-process-template/) diff --git a/content/ko/guide/iso5230_guide/1-program-foundation/_index.md b/content/ko/guide/iso5230_guide/1-program-foundation/_index.md new file mode 100644 index 000000000..a50e3e782 --- /dev/null +++ b/content/ko/guide/iso5230_guide/1-program-foundation/_index.md @@ -0,0 +1,8 @@ +--- +title: "§3.1 프로그램 기반" +weight: 10 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "프로그램 기반"] +description: > +--- diff --git a/content/ko/guide/iso5230_guide/2-relevant-tasks/1-access/_index.md b/content/ko/guide/iso5230_guide/2-relevant-tasks/1-access/_index.md new file mode 100644 index 000000000..d9199d3bc --- /dev/null +++ b/content/ko/guide/iso5230_guide/2-relevant-tasks/1-access/_index.md @@ -0,0 +1,154 @@ +--- +title: "§3.2.1 외부 문의 대응" +weight: 10 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "외부 문의"] +description: > +--- + +## 1. 조항 개요 + +소프트웨어를 배포하는 기업은 제3자(고객, 오픈소스 저작권자, 연구자 등)로부터 +오픈소스 라이선스 컴플라이언스에 관한 문의를 받을 수 있다. 이 문의에 제때 +응답하지 못하면 저작권 침해 분쟁으로 확대될 위험이 있다. §3.2.1은 외부 +문의를 접수할 수 있는 공개된 연락 수단을 마련하고, 내부적으로는 문의에 체계적으로 +대응하기 위한 절차를 문서화하도록 요구한다. 이 조항은 공개 채널(입증자료 3.2.1.1)과 +내부 대응 절차(입증자료 3.2.1.2) 두 가지를 모두 갖출 것을 요구한다. + +## 2. 해야 할 활동 + +- 제3자가 오픈소스 라이선스 컴플라이언스 문의를 보낼 수 있는 공개 연락처(이메일 + 주소, 웹폼 등)를 제품 또는 웹사이트에 명시한다. +- 외부 문의 접수부터 검토·답변·종결까지의 내부 대응 절차를 문서화한다. +- 문의 유형별 담당자(오픈소스 프로그램 매니저, 법무 담당 등)와 에스컬레이션 + 경로를 절차에 포함한다. +- 문의 접수 및 대응 이력을 기록하고 보관한다. +- 정기적으로 공개 연락처 유효성과 내부 절차의 최신성을 점검한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §3.2.1 | 외부의 오픈소스 문의에 효과적으로 대응하기 위한 프로세스를 유지해야 한다. 제3자가 오픈소스 컴플라이언스 문의를 할 수 있는 수단을 공개적으로 밝혀야 한다. | **3.2.1.1** 제3자가 오픈소스 라이선스 컴플라이언스에 대해 문의할 수 있는 공개된 방법
**3.2.1.2** 제3자의 오픈소스 라이선스 컴플라이언스 문의에 대응하기 위한 내부의 문서화된 절차 | + +
영문 원문 보기 + +> **§3.2.1 Access** +> Maintain a process to effectively respond to external open source inquiries. +> Publicly identify a means by which a third party can make an open source +> compliance inquiry. +> +> **Verification Material(s):** +> 3.2.1.1 Publicly visible method that allows any third party to make an open +> source license compliance inquiry (e.g., via a published contact email +> address, or the OpenChain Conformance website). +> 3.2.1.2 An internal documented procedure for responding to third party open +> source license compliance inquiries. + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 3.2.1.1 공개된 외부 문의 채널 + +**준수 방법** + +제3자가 오픈소스 라이선스 컴플라이언스에 관한 문의를 보낼 수 있는 수단을 +공개적으로 명시해야 한다. 가장 일반적인 방법은 전용 이메일 주소(예: +oss@company.com)를 제품 설명서, 소프트웨어 오픈소스 고지문, 또는 회사 웹사이트에 +게시하는 것이다. 이 공개 연락처 자체가 입증자료 3.2.1.1이다. + +연락처는 담당자 개인 이메일이 아닌 역할 기반 주소(role-based address)를 사용하는 +것이 좋다. 담당자가 변경되더라도 주소가 유지되며, 문의가 누락되지 않도록 팀 +메일함으로 관리하는 것이 바람직하다. OpenChain Conformance 웹사이트에 연락처를 +등록하는 방법도 활용할 수 있다. + +**고려사항** + +- **역할 기반 주소 사용**: 개인 이메일 대신 oss@company.com과 같은 역할 기반 + 주소를 사용하여 담당자 변경에 대비한다. +- **게시 위치**: 제품 매뉴얼, 오픈소스 고지문(NOTICES 파일), 회사 웹사이트 등 + 제3자가 쉽게 찾을 수 있는 위치에 게시한다. +- **응답 가능성 확인**: 게시된 연락처가 실제로 수신되고 모니터링되는지 정기적으로 + 점검한다. +- **다국어 고려**: 글로벌 제품의 경우 영문 연락처도 함께 제공한다. + +**샘플** + +아래는 제품 오픈소스 고지문 또는 웹사이트에 게시하는 공개 연락처 샘플이다. + +``` +오픈소스 라이선스 컴플라이언스 문의 + +이 소프트웨어에 포함된 오픈소스 컴포넌트의 라이선스 컴플라이언스에 관한 +문의는 아래 이메일로 연락해 주십시오. + +- 이메일: oss@company.com +- 응답 기간: 영업일 기준 14일 이내 + +Open Source License Compliance Inquiry + +For inquiries regarding open source license compliance of this software, +please contact: oss@company.com +``` + +--- + +### 3.2.1.2 내부 외부 문의 대응 절차 + +**준수 방법** + +외부 문의가 접수되었을 때 어떻게 처리할지를 정의한 내부 절차를 문서화해야 한다. +절차에는 ①문의 접수 및 분류, ②담당자 배정, ③검토 및 답변 작성, ④법무 검토 +(필요 시), ⑤답변 발송, ⑥기록 보관의 단계가 포함되어야 한다. 이 절차 문서가 +입증자료 3.2.1.2다. + +답변 기한은 합리적인 범위에서 설정하고 절차에 명시한다. 일반적으로 14일 이내 +초기 응답, 60일 이내 최종 답변을 기준으로 삼는 경우가 많다. 문의 접수·처리· +종결 이력은 사내 시스템에 기록하여 감사 시 제출할 수 있도록 보관한다. + +**고려사항** + +- **담당자 및 에스컬레이션**: 1차 담당자(오픈소스 프로그램 매니저)와 법무 검토 + 에스컬레이션 경로를 절차에 명시한다. +- **응답 기한**: 초기 응답과 최종 답변의 기한을 절차에 명시하고 준수한다. +- **기록 보관**: 문의 내용, 검토 과정, 최종 답변을 기록하고 최소 3년간 보관한다. +- **유형별 대응**: 라이선스 고지 요청, 소스코드 제공 요청, 저작권 침해 주장 등 + 문의 유형별 대응 방법을 절차에 포함한다. + +**샘플** + +아래는 외부 문의 대응 절차 개요 샘플이다. + +``` +[외부 오픈소스 문의 대응 절차] + +1. 접수 및 분류 (1영업일 이내) + - oss@company.com 수신함을 매일 확인한다. + - 문의를 유형별로 분류한다: + A. 오픈소스 고지문 또는 소스코드 제공 요청 + B. 라이선스 의무 준수 여부 확인 요청 + C. 저작권 침해 주장 또는 법적 경고 + +2. 담당자 배정 및 초기 응답 (3영업일 이내) + - 오픈소스 프로그램 매니저가 문의를 검토하고 수신 확인 답변을 발송한다. + - C유형(법적 경고)은 즉시 법무 담당에게 에스컬레이션한다. + +3. 검토 및 답변 작성 (14영업일 이내) + - 관련 SBOM, 라이선스 기록, 컴플라이언스 산출물을 검토한다. + - A유형: 고지문 또는 소스코드를 확인하여 제공한다. + - B유형: 컴플라이언스 이행 증거를 검토하여 답변한다. + - 필요 시 법무 담당에게 답변 초안 검토를 의뢰한다. + +4. 답변 발송 및 종결 + - 최종 답변을 발송하고 문의를 종결 처리한다. + +5. 기록 보관 + - 문의 내용, 검토 과정, 최종 답변을 문서화하여 최소 3년간 보관한다. +``` + +## 5. 참고 + +- 관련 가이드: [기업 오픈소스 관리 가이드 — 3. 프로세스](../../../opensource_for_enterprise/3-process/) +- 관련 템플릿: [오픈소스 정책 템플릿 — §9 외부 문의 대응](../../../templates/1-policy/) diff --git a/content/ko/guide/iso5230_guide/2-relevant-tasks/2-resourced/_index.md b/content/ko/guide/iso5230_guide/2-relevant-tasks/2-resourced/_index.md new file mode 100644 index 000000000..be695f576 --- /dev/null +++ b/content/ko/guide/iso5230_guide/2-relevant-tasks/2-resourced/_index.md @@ -0,0 +1,268 @@ +--- +title: "§3.2.2 효과적 리소스" +weight: 20 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "리소스"] +description: > +--- + +## 1. 조항 개요 + +오픈소스 프로그램이 실제로 작동하려면 역할을 정의하는 것만으로는 부족하다. +각 역할을 담당할 실제 인원이 배정되고, 업무 수행에 필요한 시간과 예산이 +충분히 지원되어야 한다. §3.2.2는 프로그램 역할별 담당자를 문서로 명시하고, +인원 배치와 예산이 적절히 이루어졌음을 확인하며, 법률 자문 접근 방법과 내부 +책임 할당 절차, 미준수 사례 처리 절차를 갖출 것을 요구한다. 이 조항은 5개의 +입증자료 항목으로 구성되어 §3.1 프로그램 기반에서 정의한 역할 구조를 실제 +운영 체계로 구현하는 단계다. + +## 2. 해야 할 활동 + +- 프로그램 내 각 역할(오픈소스 프로그램 매니저, 법무 담당, IT 담당 등)을 맡은 + 담당자의 이름 또는 직무를 문서에 기재한다. +- 각 역할 담당자가 업무를 수행할 수 있도록 충분한 시간과 예산이 배정되었음을 + 확인하고 기록한다. +- 오픈소스 라이선스 컴플라이언스 관련 법적 문제 발생 시 이용할 수 있는 내부 + 또는 외부 법률 자문 수단을 식별하고 문서화한다. +- 오픈소스 컴플라이언스 내부 책임을 각 역할에 할당하는 절차를 문서화한다. +- 컴플라이언스 미준수 사례를 발견했을 때 검토하고 시정하는 절차를 문서화한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §3.2.2 | 프로그램 업무를 식별하고 리소스를 제공한다: 프로그램 업무의 성공적 수행을 위한 책임을 할당한다 / 프로그램 업무에 충분한 리소스(시간·예산)를 제공한다 / 법적 전문성에 접근할 수 있는 방법을 확보한다 / 미준수 사례 검토 및 시정 프로세스를 마련한다 | **3.2.2.1** 프로그램 내 각 역할을 담당하는 인원, 그룹 또는 직무의 이름을 기재한 문서
**3.2.2.2** 프로그램 내 각 역할을 담당하는 인원이 적합하게 배치되고, 예산이 적절하게 지원되어야 함
**3.2.2.3** 오픈소스 라이선스 컴플라이언스 문제 해결을 위해 내부 또는 외부의 전문 법률 자문을 이용할 수 있는 방법
**3.2.2.4** 오픈소스 컴플라이언스에 대한 내부 책임을 할당하는 문서화된 절차
**3.2.2.5** 미준수 사례를 검토하고 이를 수정하기 위한 문서화된 절차 | + +
영문 원문 보기 + +> **§3.2.2 Effectively Resourced** +> Identify and Resource Program Task(s): +> - Assign accountability to ensure the successful execution of program tasks. +> - Program tasks are sufficiently resourced: +> - Time to perform the tasks has been allocated; +> - Adequate funding has been allocated; +> - A process exists for the review and resolution of open source license +> compliance failures; +> - Legal expertise pertaining to open source license compliance is +> accessible to those that may need such guidance; and +> - A process exists for the escalation of open source license compliance +> issues. +> +> **Verification Material(s):** +> 3.2.2.1 A document with the names of the persons, group or function in +> program role(s) identified. +> 3.2.2.2 The identified program roles have been properly staffed and adequate +> funding provided. +> 3.2.2.3 Identification of legal expertise available to address open source +> license compliance matters which could be internal or external. +> 3.2.2.4 A documented procedure that assigns internal responsibilities for +> open source compliance. +> 3.2.2.5 A documented procedure for handling the review and remediation of +> non-compliant cases. + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 3.2.2.1 역할 담당자 명시 문서 + +**준수 방법** + +프로그램의 각 역할을 실제로 담당하는 인원의 이름, 그룹명, 또는 직무명을 +기재한 문서를 작성해야 한다. 이 문서는 §3.1.2.1의 역할·책임 목록 문서에 +담당자 정보를 추가하는 형태로 관리하거나, 오픈소스 정책 Appendix에 담당자 +현황표로 포함할 수 있다. 특정 개인 이름 대신 직무명(오픈소스 프로그램 매니저, +법무팀장 등)을 사용해도 무방하며, 조직 변경 시 즉시 갱신해야 한다. + +**고려사항** + +- **개인명 또는 직무명**: 이름 대신 직무명을 사용하면 인사 변동 시에도 문서를 + 자주 갱신할 필요가 줄어든다. +- **겸임 명시**: 한 사람이 여러 역할을 담당하는 경우 모든 역할에 해당 사실을 + 기재한다. +- **갱신 관리**: 조직 변경·인사 이동 발생 시 즉시 문서를 업데이트하고 버전을 + 기록한다. + +**샘플** + +아래는 역할 담당자 현황표 샘플이다. +[오픈소스 정책 템플릿 Appendix 1](../../../templates/1-policy/appendix/)에서 +전체 양식을 확인할 수 있다. + +``` +| 역할 | 담당자 | 연락처 | +|------|--------|--------| +| 오픈소스 프로그램 매니저 | 홍길동 (개발팀장) | oss@company.com | +| 법무 담당 | 김법무 (법무팀장) | legal@company.com | +| IT 담당 | 이인프라 (인프라팀) | it-oss@company.com | +| 보안 담당 | 박보안 (보안팀) | security@company.com | +| 개발 문화 담당 | 최문화 (HR팀) | culture@company.com | +``` + +--- + +### 3.2.2.2 인원 배치 및 예산 지원 확인 + +**준수 방법** + +각 역할 담당자가 오픈소스 프로그램 업무를 수행할 수 있도록 충분한 시간과 +예산이 배정되었음을 확인하고 그 근거를 기록해야 한다. 별도의 전담 조직이 +없는 경우에도 겸임 담당자가 해당 업무에 투입할 수 있는 시간이 확보되었는지, +도구 구매나 교육비 등 필요 예산이 편성되었는지를 확인하는 내부 기록이 있어야 +한다. 경영진 승인이 포함된 예산 계획서나 업무 분장 문서가 이 입증자료에 해당할 +수 있다. + +**고려사항** + +- **전담 여부 명시**: 전담 인원인지 겸임인지를 기록하고, 겸임의 경우 투입 + 비율(예: 업무 시간의 20%)을 명시한다. +- **예산 근거 보관**: 도구 구매 계약서, 교육비 집행 내역, 외부 컨설팅 계약 등 + 예산 지원을 증명하는 기록을 보관한다. +- **경영진 확인**: 인원 배치와 예산 지원에 대한 경영진 승인 또는 확인 기록을 + 유지한다. + +**샘플** + +``` +[오픈소스 프로그램 리소스 배정 확인서] + +프로그램 연도: 2026년 +승인자: [임원명] / 승인일: 2026-01-10 + +| 역할 | 담당자 | 투입 비율 | 연간 예산 | +|------|--------|-----------|-----------| +| 오픈소스 프로그램 매니저 | 홍길동 | 50% | - | +| 법무 담당 | 김법무 | 20% | - | +| IT 담당 (도구 운영) | 이인프라 | 10% | 도구 라이선스 비용 포함 | +| 교육 예산 | - | - | 연간 OOO만 원 | +| 외부 법률 자문 예산 | - | - | 필요 시 집행 | +``` + +--- + +### 3.2.2.3 법률 자문 접근 방법 + +**준수 방법** + +오픈소스 라이선스 컴플라이언스와 관련된 법적 문제가 발생했을 때 전문 법률 +자문을 받을 수 있는 방법을 식별하고 문서화해야 한다. 내부 법무팀이 있는 경우 +해당 팀의 연락처와 에스컬레이션 절차를 기록하고, 내부 법무팀이 없거나 전문성이 +부족한 경우 외부 법무법인 또는 오픈소스 컨설팅 전문가를 활용하는 방법을 +문서에 명시한다. + +**고려사항** + +- **내부 vs. 외부**: 내부 법무팀 활용 방법과 외부 자문 의뢰 기준을 모두 명시한다. +- **에스컬레이션 기준**: 어떤 상황에서 법률 자문을 받아야 하는지(저작권 침해 + 주장, 비표준 라이선스, 특허 조항 등) 기준을 절차에 포함한다. +- **외부 자문 목록 관리**: 오픈소스 전문 외부 법무법인 또는 컨설턴트 정보를 + 최신 상태로 유지한다. + +**샘플** + +``` +[법률 자문 접근 방법] + +내부 법무팀: +- 담당: 법무팀 (legal@company.com) +- 에스컬레이션 기준: 저작권 침해 주장 접수, GPL 계열 라이선스 의무 + 해석 불확실, 비표준 라이선스 검토 필요 시 + +외부 법률 자문: +- 활용 기준: 내부 법무팀에서 판단이 어려운 복잡한 법적 분쟁 발생 시 +- 계약 현황: [외부 법무법인명] (연간 자문 계약 체결) +- 오픈소스 전문 컨설팅: OpenChain 파트너사 목록 참조 +``` + +--- + +### 3.2.2.4 내부 책임 할당 절차 + +**준수 방법** + +오픈소스 컴플라이언스와 관련된 내부 책임을 각 역할에 명확히 할당하는 절차를 +문서화해야 한다. 이 절차는 누가 무엇을 책임지는지를 정의하며, 오픈소스 사용 +승인, SBOM 생성, 라이선스 검토, 컴플라이언스 산출물 배포 등 각 업무 단계별 +책임자를 명시한다. 이 절차 문서는 오픈소스 정책 또는 프로세스 문서에 포함할 +수 있다. + +**고려사항** + +- **업무 단계별 책임 명시**: 오픈소스 도입, 검토, 승인, 배포 각 단계마다 + 책임자를 지정한다. +- **RACI 활용**: 역할별 책임(Responsible, Accountable, Consulted, Informed)을 + RACI 매트릭스로 정의하면 명확성이 높아진다. +- **갱신 주기**: 조직 변경 또는 프로세스 변경 시 절차를 즉시 갱신한다. + +**샘플** + +``` +| 업무 | 오픈소스 PM | 법무 담당 | IT 담당 | 보안 담당 | 개발자 | +|------|------------|-----------|---------|-----------|--------| +| 오픈소스 사용 승인 | A | C | - | C | R | +| 라이선스 의무 검토 | R | A | - | - | I | +| SBOM 생성 | A | - | R | - | C | +| 취약점 모니터링 | I | - | C | A/R | I | +| 컴플라이언스 산출물 배포 | A | C | R | - | I | +| 외부 문의 대응 | A/R | C | - | - | - | + +R: 실행 책임 / A: 최종 책임 / C: 협의 / I: 정보 공유 +``` + +--- + +### 3.2.2.5 미준수 사례 검토 및 시정 절차 + +**준수 방법** + +오픈소스 컴플라이언스 미준수 사례(라이선스 의무 불이행, SBOM 누락, 무승인 +오픈소스 사용 등)가 발견되었을 때 이를 검토하고 시정하는 절차를 문서화해야 +한다. 절차에는 ①미준수 사례 식별 및 보고, ②심각도 평가, ③원인 분석, +④시정 조치, ⑤재발 방지 대책, ⑥기록 보관이 포함되어야 한다. + +미준수 사례는 내부 감사, 외부 문의, 자동화 도구 알림 등 다양한 경로로 +발견될 수 있다. 심각도에 따라 긴급 조치(배포 중단, 소스코드 즉시 공개 등)와 +일반 조치를 구분하여 처리 기한을 다르게 설정하는 것이 효과적이다. + +**고려사항** + +- **심각도 분류**: 미준수 사례의 법적 리스크에 따라 심각도(높음/중간/낮음)를 + 분류하고 처리 기한을 다르게 설정한다. +- **에스컬레이션**: 심각도가 높은 사례는 경영진 보고 및 법무 검토를 의무화한다. +- **재발 방지**: 시정 조치 완료 후 동일 유형의 미준수가 재발하지 않도록 + 프로세스 개선 방안을 도출하고 기록한다. +- **기록 보관**: 미준수 사례 이력과 시정 완료 기록을 최소 3년간 보관한다. + +**샘플** + +``` +[미준수 사례 처리 절차] + +1. 식별 및 보고 + - 내부 감사, 외부 문의, CI/CD 도구 알림 등을 통해 미준수 사례를 식별한다. + - 오픈소스 프로그램 매니저에게 즉시 보고한다. + +2. 심각도 평가 + - 높음: 배포된 소프트웨어의 GPL 소스코드 미공개, 저작권 침해 주장 접수 + → 48시간 이내 긴급 검토 착수 + - 중간: SBOM 누락, 라이선스 고지문 불완전 + → 7영업일 이내 시정 조치 완료 + - 낮음: 내부 프로세스 미준수 (승인 절차 생략 등) + → 30일 이내 시정 조치 완료 + +3. 원인 분석 및 시정 조치 + - 미준수 원인을 파악하고 시정 방안을 수립한다. + - 높음·중간 사례는 법무 담당과 협의 후 조치한다. + +4. 재발 방지 + - 프로세스 또는 교육 개선 방안을 도출하고 이행한다. + +5. 기록 보관 + - 사례 내용, 조치 경과, 완료 일자를 기록하고 최소 3년간 보관한다. +``` + +## 5. 참고 + +- 관련 가이드: [기업 오픈소스 관리 가이드 — 1. 조직](../../../opensource_for_enterprise/1-teams/) +- 관련 템플릿: [오픈소스 정책 템플릿 — Appendix 1. 담당자 현황](../../../templates/1-policy/appendix/) diff --git a/content/ko/guide/iso5230_guide/2-relevant-tasks/_index.md b/content/ko/guide/iso5230_guide/2-relevant-tasks/_index.md new file mode 100644 index 000000000..fe5b71e65 --- /dev/null +++ b/content/ko/guide/iso5230_guide/2-relevant-tasks/_index.md @@ -0,0 +1,8 @@ +--- +title: "§3.2 관련 업무" +weight: 20 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "관련 업무"] +description: > +--- diff --git a/content/ko/guide/iso5230_guide/3-content-review/1-sbom/_index.md b/content/ko/guide/iso5230_guide/3-content-review/1-sbom/_index.md new file mode 100644 index 000000000..266bc18b1 --- /dev/null +++ b/content/ko/guide/iso5230_guide/3-content-review/1-sbom/_index.md @@ -0,0 +1,178 @@ +--- +title: "§3.3.1 SBOM" +weight: 10 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "SBOM"] +description: > +--- + +## 1. 조항 개요 + +공급 소프트웨어에 어떤 오픈소스 컴포넌트가 포함되어 있는지 파악하지 못하면 +라이선스 의무를 이행할 수 없고 보안 취약점 대응도 불가능하다. §3.3.1은 공급 +소프트웨어를 구성하는 오픈소스 컴포넌트를 식별·추적·검토·승인·보관하는 +절차를 수립하고, 그 절차가 실제로 이행되었음을 입증하는 컴포넌트 기록(SBOM)을 +유지하도록 요구한다. 이 조항은 오픈소스 라이선스 컴플라이언스와 보안 보증의 +핵심 인프라인 SBOM을 운영하는 기반이 된다. + +## 2. 해야 할 활동 + +- 공급 소프트웨어에 포함된 오픈소스 컴포넌트를 자동화 도구(FOSSology, ORT, + Syft, cdxgen 등)를 활용하여 식별하고 목록화한다. +- 오픈소스 컴포넌트 정보(컴포넌트명, 버전, 라이선스, 출처 등)를 추적하고 + 검토·승인·보관하는 절차를 문서화한다. +- 각 공급 소프트웨어 릴리스에 대한 SBOM을 생성하고 관리한다. +- SBOM 데이터를 SPDX 또는 CycloneDX 표준 형식으로 작성하여 상호 운용성을 + 확보한다. +- 소프트웨어 변경(신규 컴포넌트 추가, 버전 업그레이드, 컴포넌트 제거) 시 + SBOM을 즉시 갱신한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §3.3.1 | 공급 소프트웨어를 구성하는 각 오픈소스 컴포넌트(및 식별된 라이선스)를 포함하는 소프트웨어 구성 목록을 작성하고 관리하기 위한 프로세스가 존재해야 한다. | **3.3.1.1** 공급 소프트웨어를 구성하는 오픈소스 컴포넌트에 대한 정보를 식별, 추적, 검토, 승인 및 보관하는 문서화된 절차
**3.3.1.2** 문서화된 절차가 적절히 준수되었음을 보여주는 공급 소프트웨어에 대한 오픈소스 컴포넌트 기록 | + +
영문 원문 보기 + +> **§3.3.1 Bill of Materials** +> A process shall exist for creating and managing a bill of materials that +> includes each open source component (and its identified licenses) from +> which the supplied software is comprised. +> +> **Verification Material(s):** +> 3.3.1.1 A documented procedure for identifying, tracking, reviewing, +> approving, and archiving information about the collection of open source +> components from which the supplied software is comprised. +> 3.3.1.2 Open source component records for the supplied software that +> demonstrates the documented procedure was followed. + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 3.3.1.1 오픈소스 컴포넌트 관리 절차 + +**준수 방법** + +공급 소프트웨어에 포함된 오픈소스 컴포넌트를 식별·추적·검토·승인·보관하는 +일련의 절차를 문서화해야 한다. 절차는 소프트웨어 개발 주기 전반에 걸쳐 +오픈소스가 어떻게 관리되는지를 다루며, ①컴포넌트 식별, ②라이선스 확인, +③의무 검토, ④사용 승인, ⑤SBOM 생성 및 등록, ⑥배포 시 SBOM 제공, +⑦변경 시 SBOM 갱신, ⑧SBOM 보관의 단계를 포함해야 한다. 이 절차 문서 자체가 +입증자료 3.3.1.1이다. + +SBOM은 SPDX(ISO/IEC 5962) 또는 CycloneDX 형식을 채택하여 표준화하는 것을 +권장한다. 자동화 도구를 CI/CD 파이프라인에 통합하면 컴포넌트 변경 시 SBOM이 +자동으로 갱신되어 최신성을 유지하기 쉽다. + +**고려사항** + +- **자동화 도구 통합**: FOSSology, ORT, Syft, cdxgen 등을 CI/CD에 통합하여 + SBOM 생성을 자동화한다. +- **표준 형식 채택**: SPDX 또는 CycloneDX 형식으로 SBOM을 작성하여 공급망 + 파트너와의 상호 운용성을 확보한다. +- **갱신 트리거 정의**: 신규 컴포넌트 추가, 버전 업그레이드, 컴포넌트 제거, + 라이선스 변경 발생 시 SBOM 갱신을 의무화한다. +- **승인 절차 명시**: 새로운 오픈소스 컴포넌트 도입 시 오픈소스 프로그램 매니저 + 또는 OSRB의 승인 절차를 절차에 포함한다. +- **보관 기간**: SBOM은 해당 소프트웨어 배포 후 최소 [N]년간 보관한다. + +**샘플** + +아래는 오픈소스 컴포넌트 관리 절차 개요 샘플이다. +[오픈소스 프로세스 템플릿](../../../templates/2-process-template/)에서 +전체 프로세스 양식을 확인할 수 있다. + +``` +[오픈소스 컴포넌트 관리 절차 개요] + +(1) 식별 + - 개발자는 오픈소스 컴포넌트 도입 시 오픈소스 관리 시스템에 신고한다. + - CI/CD 파이프라인의 SCA 도구(Syft, ORT 등)가 컴포넌트를 자동 탐지한다. + +(2) 라이선스 확인 및 의무 검토 + - 식별된 컴포넌트의 라이선스를 SPDX License List 기준으로 확인한다. + - 라이선스 의무 요약표를 참조하여 배포 형태에 따른 의무를 검토한다. + - 불확실한 경우 법무 담당에게 검토를 의뢰한다. + +(3) 사용 승인 + - 오픈소스 프로그램 매니저가 검토 결과를 바탕으로 사용을 승인한다. + - 라이선스 정책에 반하는 컴포넌트는 대안 검토 후 반려한다. + +(4) SBOM 생성 및 등록 + - 승인된 컴포넌트를 SBOM에 등록한다 (형식: SPDX 또는 CycloneDX). + - SBOM에는 컴포넌트명, 버전, 라이선스, 출처(URL), 저작권 고지를 포함한다. + +(5) 배포 및 SBOM 제공 + - 소프트웨어 배포 시 SBOM을 함께 제공하거나 요청 시 제공한다. + +(6) 변경 시 갱신 + - 컴포넌트 추가·업그레이드·제거·라이선스 변경 발생 시 SBOM을 즉시 갱신한다. + +(7) 보관 + - SBOM은 소프트웨어 배포 후 최소 [N]년간 버전별로 보관한다. +``` + +--- + +### 3.3.1.2 오픈소스 컴포넌트 기록 (SBOM) + +**준수 방법** + +3.3.1.1에서 정의한 절차가 실제로 이행되었음을 보여주는 컴포넌트 기록을 +공급 소프트웨어별로 유지해야 한다. 이 기록이 SBOM(Software Bill of Materials)이며 +입증자료 3.3.1.2에 해당한다. SBOM에는 최소한 각 오픈소스 컴포넌트의 이름·버전· +라이선스·출처가 포함되어야 하며, SPDX 또는 CycloneDX 형식으로 작성하면 감사 +시 즉시 제출 가능한 형태가 된다. + +SBOM은 소프트웨어 릴리스 버전별로 관리하고, 과거 버전의 SBOM도 보관하여 +특정 시점의 컴포넌트 구성을 언제든 확인할 수 있어야 한다. SBOM 생성 도구의 +출력 결과를 그대로 활용하거나, 오픈소스 관리 시스템(SW360, Dependency-Track 등)에 +저장·관리하는 방식을 사용할 수 있다. + +**고려사항** + +- **필수 포함 항목**: 컴포넌트명, 버전, 라이선스 식별자(SPDX ID), 출처(패키지 + 레지스트리 URL 또는 소스 저장소), 저작권 고지를 포함한다. +- **버전별 관리**: 소프트웨어 릴리스 버전별로 SBOM을 별도 관리하고 과거 버전도 + 보관한다. +- **관리 도구 활용**: SW360, Dependency-Track 등 오픈소스 관리 시스템을 활용하면 + SBOM의 생성·추적·배포를 체계적으로 관리할 수 있다. +- **고객 제공**: 고객 또는 공급망 파트너가 SBOM을 요청하는 경우 즉시 제공할 수 + 있도록 접근 가능한 형태로 보관한다. + +**샘플** + +아래는 SPDX 형식 SBOM의 핵심 항목 샘플이다. + +``` +SPDXVersion: SPDX-2.3 +DataLicense: CC0-1.0 +SPDXID: SPDXRef-DOCUMENT +DocumentName: MyProduct-v1.2.0-sbom +DocumentNamespace: https://company.com/sbom/myproduct-1.2.0 + +PackageName: openssl +SPDXID: SPDXRef-openssl +PackageVersion: 3.0.8 +PackageDownloadLocation: https://www.openssl.org/source/openssl-3.0.8.tar.gz +PackageLicenseConcluded: Apache-2.0 +PackageLicenseDeclared: Apache-2.0 +PackageCopyrightText: Copyright (c) 1998-2023 The OpenSSL Project + +PackageName: zlib +SPDXID: SPDXRef-zlib +PackageVersion: 1.2.13 +PackageDownloadLocation: https://zlib.net/zlib-1.2.13.tar.gz +PackageLicenseConcluded: Zlib +PackageLicenseDeclared: Zlib +PackageCopyrightText: Copyright (C) 1995-2022 Jean-loup Gailly and Mark Adler +``` + +## 5. 참고 + +- 관련 가이드: [기업 오픈소스 관리 가이드 — 3. 프로세스](../../../opensource_for_enterprise/3-process/) +- 관련 템플릿: [오픈소스 프로세스 템플릿](../../../templates/2-process-template/) +- 관련 도구: [FOSSology](../../../tools/1-fossology/), [ORT](../../../tools/2-ort/), [Syft](../../../tools/6-syft/), [cdxgen](../../../tools/5-cdxgen/), [Dependency-Track](../../../tools/7-dependency-track/) diff --git a/content/ko/guide/iso5230_guide/3-content-review/2-license-compliance/_index.md b/content/ko/guide/iso5230_guide/3-content-review/2-license-compliance/_index.md new file mode 100644 index 000000000..dcfd6bebc --- /dev/null +++ b/content/ko/guide/iso5230_guide/3-content-review/2-license-compliance/_index.md @@ -0,0 +1,130 @@ +--- +title: "§3.3.2 라이선스 컴플라이언스" +weight: 20 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "라이선스 컴플라이언스"] +description: > +--- + +## 1. 조항 개요 + +오픈소스 컴포넌트는 배포 형태(바이너리·소스코드), 수정 여부, 다른 컴포넌트와의 +결합 방식에 따라 라이선스 의무가 달라진다. §3.3.2는 공급 소프트웨어에 포함된 +오픈소스 컴포넌트에 대해 자주 발생하는 라이선스 사용 사례들을 처리할 수 있는 +능력을 프로그램이 갖추도록 요구한다. 이 조항은 단순히 라이선스를 식별하는 것을 +넘어, 다양한 배포 시나리오별로 의무 이행 방법을 정의한 절차를 마련하도록 한다. + +## 2. 해야 할 활동 + +- 바이너리 형태 배포, 소스코드 형태 배포, 수정된 오픈소스 배포 등 주요 라이선스 + 사용 사례를 식별하고 각 사례별 처리 절차를 수립한다. +- 라이선스 충돌(비호환 라이선스 컴포넌트 결합)이 발생했을 때의 처리 방법을 + 절차에 포함한다. +- 고지 의무(저작권 고지문, 라이선스 전문 포함)가 필요한 라이선스에 대한 + 처리 방법을 정의한다. +- GPL 등 소스코드 공개 의무가 있는 라이선스가 포함된 소프트웨어의 배포 절차를 + 수립한다. +- 절차를 문서화하고 정기적으로 검토하여 새로운 라이선스 유형에 대응한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §3.3.2 | 프로그램은 공급 소프트웨어의 오픈소스 컴포넌트에 대한 일반적인 오픈소스 라이선스 사용 사례를 처리할 수 있어야 한다. 처리해야 할 사용 사례는 바이너리 형태 배포 / 소스코드 형태 배포 / 추가 라이선스 의무를 유발할 수 있는 다른 오픈소스와의 통합 / 수정된 오픈소스 포함 / 공급 소프트웨어 내 다른 컴포넌트와 비호환 라이선스 포함 / 저작권 고지 요건이 있는 오픈소스 포함 등을 포함할 수 있다. | **3.3.2.1** 공급 소프트웨어 내의 오픈소스 컴포넌트에 대해 일반적인 오픈소스 라이선스 사용 사례를 처리하기 위한 문서화된 절차 | + +
영문 원문 보기 + +> **§3.3.2 License Compliance** +> The program shall be capable of handling the common open source license use +> cases for the open source components of the supplied software, which may +> include the following use cases (note that the list is not exhaustive and +> some of the below use cases may not apply): +> - distributed in binary form; +> - distributed in source form; +> - integrated with other open source such that it may trigger additional +> licensing obligations; +> - contains modified open source; +> - contains open source or other software under an incompatible license +> interacting with other components within the supplied software; and/or +> - contains open source with attribution requirements. +> +> **Verification Material(s):** +> 3.3.2.1 A documented procedure for handling the common open source license +> use cases for the open source components of the supplied software. + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 3.3.2.1 라이선스 사용 사례별 처리 절차 + +**준수 방법** + +공급 소프트웨어에 오픈소스가 포함되는 다양한 시나리오별로 라이선스 의무를 +어떻게 이행하는지 정의한 절차를 문서화해야 한다. 이 절차 문서가 입증자료 +3.3.2.1이다. ISO/IEC 5230은 아래 6가지 주요 사용 사례를 예시로 제시하며, +조직의 비즈니스 환경에 따라 해당되는 사례를 선택하여 처리 절차를 수립한다. + +각 사용 사례별 절차에는 ①해당 사례 해당 여부 판단 기준, ②라이선스 의무 항목, +③의무 이행 방법, ④담당자, ⑤산출물(고지문, 소스코드 패키지 등)이 포함되어야 +한다. 라이선스 충돌이 발생하는 경우 법무 담당에게 에스컬레이션하는 경로도 +명시한다. + +**고려사항** + +- **사용 사례 범위 확정**: 조직의 소프트웨어 배포 방식에 맞는 사용 사례를 + 선택하여 절차를 수립한다 (모든 사례가 모든 조직에 해당되지 않을 수 있다). +- **라이선스 충돌 대응**: GPL과 Apache-2.0 등 비호환 라이선스 조합 발생 시 + 처리 방법을 미리 정의해 둔다. +- **고지문 관리**: 저작권 고지 의무가 있는 라이선스에 대해 NOTICES 파일 또는 + 제품 설명서 내 고지문 작성 절차를 수립한다. +- **소스코드 공개 절차**: GPL 계열 라이선스의 소스코드 공개 요청 대응 절차를 + 별도로 정의한다. +- **갱신 주기**: 신규 라이선스 유형 도입 또는 배포 형태 변경 시 절차를 갱신한다. + +**샘플** + +아래는 라이선스 사용 사례별 처리 절차 요약표 샘플이다. + +``` +| 사용 사례 | 라이선스 예시 | 주요 의무 | 처리 방법 | +|-----------|--------------|-----------|-----------| +| 바이너리 형태 배포 | MIT, Apache-2.0 | 저작권 고지문 포함 | NOTICES 파일 또는 앱 내 고지 화면에 고지문 포함 | +| 바이너리 형태 배포 | GPL-2.0, GPL-3.0 | 소스코드 공개 또는 제공 약정서 포함 | 소스코드 패키지 배포 또는 written offer 동봉 | +| 소스코드 형태 배포 | 모든 라이선스 | 원본 라이선스 파일 및 저작권 고지 보존 | 라이선스 파일과 저작권 고지를 그대로 유지 | +| 수정된 오픈소스 포함 | GPL-2.0, LGPL-2.1 | 수정 사항 명시, 수정본 동일 라이선스 적용 | 수정 내역 기록, 수정본 소스코드 공개 | +| 비호환 라이선스 결합 | GPL-2.0 + Apache-2.0 | 라이선스 충돌 해소 | 법무 검토 후 컴포넌트 대체 또는 구조 변경 | +| 저작권 고지 요건 | BSD-3-Clause, Apache-2.0 | 제품 문서 또는 UI에 저작권 고지 포함 | 제품 설명서 또는 About 화면에 고지문 추가 | +``` + +아래는 배포 형태별 라이선스 의무 처리 절차 개요 샘플이다. + +``` +[바이너리 배포 시 라이선스 의무 처리 절차] + +1. SBOM 확인 + - 배포 소프트웨어의 최신 SBOM을 기준으로 포함된 오픈소스 목록을 확인한다. + +2. 라이선스 의무 분류 + - 고지문 의무: MIT, Apache-2.0, BSD 등 → NOTICES 파일 작성 + - 소스코드 공개 의무: GPL-2.0, GPL-3.0 → 소스코드 패키지 준비 + - LGPL: 동적 링크 여부에 따라 의무 범위 판단 (필요 시 법무 검토) + +3. 컴플라이언스 산출물 준비 + - NOTICES 파일: 모든 오픈소스의 저작권 고지문 및 라이선스 전문 포함 + - 소스코드 패키지: GPL 컴포넌트의 수정된 소스코드 및 빌드 스크립트 포함 + +4. 검토 및 승인 + - 오픈소스 프로그램 매니저가 산출물의 완전성을 최종 검토한다. + - 라이선스 충돌 또는 불확실한 사항은 법무 담당에게 에스컬레이션한다. + +5. 배포 + - 컴플라이언스 산출물을 소프트웨어와 함께 제공한다. + - 산출물 사본을 보관한다 (§3.4.1 참조). +``` + +## 5. 참고 + +- 관련 가이드: [기업 오픈소스 관리 가이드 — 3. 프로세스](../../../opensource_for_enterprise/3-process/) +- 관련 템플릿: [오픈소스 프로세스 템플릿](../../../templates/2-process-template/) diff --git a/content/ko/guide/iso5230_guide/3-content-review/_index.md b/content/ko/guide/iso5230_guide/3-content-review/_index.md new file mode 100644 index 000000000..88165150d --- /dev/null +++ b/content/ko/guide/iso5230_guide/3-content-review/_index.md @@ -0,0 +1,8 @@ +--- +title: "§3.3 콘텐츠 검토 및 승인" +weight: 30 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "콘텐츠 검토"] +description: > +--- diff --git a/content/ko/guide/iso5230_guide/4-artifacts/1-compliance-artifacts/_index.md b/content/ko/guide/iso5230_guide/4-artifacts/1-compliance-artifacts/_index.md new file mode 100644 index 000000000..5ad27777d --- /dev/null +++ b/content/ko/guide/iso5230_guide/4-artifacts/1-compliance-artifacts/_index.md @@ -0,0 +1,150 @@ +--- +title: "§3.4.1 산출물" +weight: 10 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "컴플라이언스 산출물"] +description: > +--- + +## 1. 조항 개요 + +라이선스 의무를 이행하려면 실제로 고지문, 소스코드 패키지 등 컴플라이언스 +산출물을 준비하여 소프트웨어와 함께 제공해야 한다. §3.4.1은 식별된 라이선스가 +요구하는 컴플라이언스 산출물을 준비하고 공급 소프트웨어와 함께 배포하는 절차, +그리고 산출물 사본을 일정 기간 보관하는 절차를 수립하도록 요구한다. 이 조항은 +§3.3 검토·승인 단계의 결과물을 실제 배포와 보관으로 연결하는 단계다. + +## 2. 해야 할 활동 + +- 라이선스별로 요구되는 컴플라이언스 산출물(NOTICES 파일, 소스코드 패키지, + written offer 등)의 유형을 정의한다. +- 산출물을 준비하여 공급 소프트웨어와 함께 제공하는 절차를 문서화한다. +- 배포된 산출물의 사본을 일정 기간 보관하는 절차를 수립하고 문서화한다. +- 산출물 보관 기간을 정책에 명시한다 (업계 관행: 마지막 배포 후 최소 3년). +- 보관 절차가 올바르게 수행되었음을 입증하는 기록을 유지한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §3.4.1 | 공급 소프트웨어에 대해 식별된 컴플라이언스 산출물을 생성하기 위한 프로세스가 존재해야 한다. | **3.4.1.1** 식별된 라이선스가 요구하는 컴플라이언스 산출물을 준비하고, 이를 공급 소프트웨어와 함께 제공하기 위한 프로세스를 설명하는 문서화된 절차
**3.4.1.2** 공급 소프트웨어의 컴플라이언스 산출물 사본을 보관하기 위한 문서화된 절차. 이러한 절차가 올바르게 수행되었음을 입증하는 기록이 존재해야 함 | + +
영문 원문 보기 + +> **§3.4.1 Compliance Artifacts** +> A process shall exist for creating the identified compliance artifacts for +> the supplied software. +> +> **Verification Material(s):** +> 3.4.1.1 A documented procedure that describes the process under which the +> compliance artifacts are prepared and distributed with the supplied software +> as required by the identified licenses. +> 3.4.1.2 A documented procedure for archiving copies of the compliance +> artifacts of the supplied software - where the archive is planned to exist +> for a reasonable period of time since the last offer of the supplied +> software; at least 3 years is a common practice. + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 3.4.1.1 컴플라이언스 산출물 준비 및 배포 절차 + +**준수 방법** + +라이선스 의무에 따른 컴플라이언스 산출물을 준비하고 공급 소프트웨어와 함께 +제공하는 절차를 문서화해야 한다. 이 절차 문서가 입증자료 3.4.1.1이다. +절차에는 ①산출물 유형 결정, ②산출물 작성, ③검토 및 승인, ④소프트웨어와 +함께 제공, ⑤기록 보관의 단계가 포함되어야 한다. + +컴플라이언스 산출물의 유형은 배포하는 라이선스에 따라 달라진다. 일반적으로 +고지 의무 라이선스(MIT, Apache-2.0 등)는 NOTICES 파일이 필요하고, GPL 계열 +라이선스는 소스코드 패키지 또는 written offer가 필요하다. 산출물 형태는 +제품에 동봉, 패키지에 포함, 웹사이트 게시, 요청 시 제공 등 다양한 방식으로 +제공할 수 있다. + +**고려사항** + +- **산출물 유형 정의**: 라이선스별로 어떤 산출물이 필요한지 미리 정의하여 + 배포 준비 시 빠르게 대응할 수 있도록 한다. +- **NOTICES 파일 품질**: 모든 오픈소스 컴포넌트의 저작권 고지문과 라이선스 + 전문이 누락 없이 포함되었는지 검토한다. +- **소스코드 패키지**: GPL 컴포넌트의 경우 수정된 소스코드와 빌드 스크립트를 + 포함한 완전한 소스코드 패키지를 준비한다. +- **제공 방식**: 산출물을 소프트웨어에 동봉할지, 웹사이트에 게시할지, 요청 시 + 제공할지를 라이선스 요건에 맞게 결정한다. +- **최종 검토**: 배포 전 오픈소스 프로그램 매니저가 산출물의 완전성을 최종 + 확인한다. + +**샘플** + +아래는 컴플라이언스 산출물 준비 및 배포 절차 개요 샘플이다. + +``` +[컴플라이언스 산출물 준비 및 배포 절차] + +1. 산출물 유형 결정 + - SBOM을 기준으로 포함된 라이선스 목록을 확인한다. + - 라이선스별 의무에 따라 필요한 산출물을 결정한다: + · 고지 의무 라이선스 → NOTICES 파일 + · GPL-2.0/3.0 → 소스코드 패키지 또는 written offer + · LGPL → 동적 링크 구조 증명 문서 또는 소스코드 + +2. 산출물 작성 + - NOTICES 파일: 자동화 도구(FOSSology, ORT 등)로 생성하거나 수동 작성. + 컴포넌트명, 버전, 라이선스 전문, 저작권 고지문 포함. + - 소스코드 패키지: GPL 컴포넌트의 수정된 소스코드와 빌드 스크립트 포함. + +3. 검토 및 승인 + - 오픈소스 프로그램 매니저가 산출물의 완전성과 정확성을 검토한다. + - 불완전한 항목은 수정 후 재검토한다. + +4. 소프트웨어와 함께 제공 + - 제품 패키지에 동봉하거나 설치 시 표시되는 화면에 포함한다. + - 웹사이트 게시 또는 요청 시 제공하는 경우 해당 URL 또는 절차를 명시한다. + - written offer를 사용하는 경우 3년간 유효한 서면 약정을 포함한다. +``` + +--- + +### 3.4.1.2 컴플라이언스 산출물 보관 절차 + +**준수 방법** + +배포된 공급 소프트웨어의 컴플라이언스 산출물 사본을 일정 기간 보관하는 절차를 +문서화하고, 그 절차가 실제로 이행되었음을 입증하는 기록을 유지해야 한다. +이 절차 문서와 보관 기록이 입증자료 3.4.1.2다. + +보관 기간은 해당 소프트웨어의 마지막 배포 시점으로부터 합리적인 기간이어야 +하며, 업계 관행상 최소 3년을 권장한다. 보관 대상은 NOTICES 파일, 소스코드 +패키지, written offer 사본, SBOM 등 배포 시 제공한 모든 산출물이다. 소프트웨어 +버전별로 산출물을 체계적으로 관리하여 특정 버전의 산출물을 즉시 검색·제출할 +수 있어야 한다. + +**고려사항** + +- **보관 기간 명시**: 정책 또는 절차 문서에 보관 기간(최소 3년)을 명시한다. +- **버전별 관리**: 소프트웨어 릴리스 버전과 산출물을 연결하여 버전별로 보관한다. +- **보관 위치**: 사내 파일 서버, 문서 관리 시스템, 소스코드 저장소 등 접근 + 가능하고 안전한 위치에 보관한다. +- **보관 기록 유지**: 어떤 버전의 산출물을 언제 보관했는지 이력을 기록한다. +- **접근성**: 감사 또는 외부 문의 발생 시 즉시 산출물을 제출할 수 있도록 + 검색 가능한 형태로 보관한다. + +**샘플** + +아래는 컴플라이언스 산출물 보관 기록부 샘플이다. + +``` +| 소프트웨어명 | 버전 | 배포일 | 산출물 유형 | 보관 위치 | 보관 기한 | 담당자 | +|-------------|------|--------|------------|-----------|-----------|--------| +| MyProduct | v1.0.0 | 2024-03-01 | NOTICES 파일, GPL 소스코드 패키지 | /archive/myproduct/v1.0.0/ | 2027-03-01 | 홍길동 | +| MyProduct | v1.1.0 | 2024-09-15 | NOTICES 파일 | /archive/myproduct/v1.1.0/ | 2027-09-15 | 홍길동 | +| FirmwareX | v2.3.0 | 2025-01-10 | NOTICES 파일, LGPL 소스코드 패키지, SBOM | /archive/firmwarex/v2.3.0/ | 2028-01-10 | 이인프라 | +``` + +## 5. 참고 + +- 관련 가이드: [기업 오픈소스 관리 가이드 — 3. 프로세스](../../../opensource_for_enterprise/3-process/) +- 관련 템플릿: [오픈소스 프로세스 템플릿](../../../templates/2-process-template/) diff --git a/content/ko/guide/iso5230_guide/4-artifacts/_index.md b/content/ko/guide/iso5230_guide/4-artifacts/_index.md new file mode 100644 index 000000000..dcc23d0f2 --- /dev/null +++ b/content/ko/guide/iso5230_guide/4-artifacts/_index.md @@ -0,0 +1,8 @@ +--- +title: "§3.4 컴플라이언스 산출물" +weight: 40 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "컴플라이언스 산출물"] +description: > +--- diff --git a/content/ko/guide/iso5230_guide/5-community/1-contributions/_index.md b/content/ko/guide/iso5230_guide/5-community/1-contributions/_index.md new file mode 100644 index 000000000..3afbd607f --- /dev/null +++ b/content/ko/guide/iso5230_guide/5-community/1-contributions/_index.md @@ -0,0 +1,216 @@ +--- +title: "§3.5.1 기여" +weight: 10 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "기여"] +description: > +--- + +## 1. 조항 개요 + +많은 기업이 외부 오픈소스 프로젝트에 코드·문서·버그 리포트 등을 기여한다. +기여 활동은 커뮤니티 신뢰를 높이고 기술 영향력을 확대하지만, 회사 코드나 +특허가 의도치 않게 공개될 수 있는 리스크도 수반한다. §3.5.1은 조직이 +외부 오픈소스 기여를 허용하는 경우, 기여를 규율하는 문서화된 정책과 절차를 +수립하고 프로그램 참여자가 그 존재를 인식하도록 할 것을 요구한다. 이 조항은 +기여를 허용하지 않는 조직에는 적용되지 않으나, 허용하는 경우 세 가지 입증자료를 +모두 갖추어야 한다. + +## 2. 해야 할 활동 + +- 조직의 외부 오픈소스 기여 허용 여부를 결정하고 정책에 명시한다. +- 기여를 허용하는 경우 기여 유형(코드, 문서, 버그 리포트 등), 승인 절차, + 저작권·특허 처리 방침 등을 포함한 기여 정책을 문서화한다. +- 기여 제안부터 승인·제출·기록까지 실제 기여를 관리하는 절차를 수립하고 + 문서화한다. +- 기여 정책의 존재를 프로그램 참여자에게 전파하는 절차를 마련한다. +- 기여 이력을 기록하고 보관한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §3.5.1 | 조직이 오픈소스 프로젝트로의 기여를 고려하는 경우: 오픈소스 프로젝트 기여를 규율하는 문서화된 정책이 존재해야 한다 / 정책은 내부에 전파되어야 한다 / 오픈소스 기여를 관리하는 문서화된 절차가 존재해야 한다 | **3.5.1.1** 문서화된 오픈소스 기여 정책
**3.5.1.2** 오픈소스 기여를 관리하는 문서화된 절차
**3.5.1.3** 모든 프로그램 참여자가 오픈소스 기여 정책의 존재를 인식하도록 하는 문서화된 절차 | + +
영문 원문 보기 + +> **§3.5.1 Contributions** +> If an organization considers contributions to open source projects, then: +> - A written policy shall exist that governs contributions to open source +> projects; +> - The policy shall be internally communicated; and +> - A documented procedure shall exist that governs open source contributions. +> +> **Verification Material(s):** +> 3.5.1.1 A documented open source contribution policy; +> 3.5.1.2 A documented procedure that governs open source contributions; and +> 3.5.1.3 A documented procedure that makes all program participants aware of +> the existence of the open source contribution policy (e.g., via training, +> internal wiki, or other practical communication method). + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 3.5.1.1 오픈소스 기여 정책 + +**준수 방법** + +외부 오픈소스 프로젝트에 기여하는 행위를 규율하는 정책을 문서화해야 한다. +이 정책 문서가 입증자료 3.5.1.1이다. 기여 정책에는 ①기여 허용 범위(코드, +문서, 버그 리포트 등), ②기여 승인 절차, ③저작권 처리(회사 소유 vs. 개인 +소유), ④특허 처리 방침, ⑤CLA(Contributor License Agreement) 서명 기준, +⑥기여 금지 항목(영업 비밀, 미공개 특허 등)이 포함되어야 한다. + +정책은 오픈소스 정책 문서의 별도 섹션으로 포함하거나 독립된 기여 정책 문서로 +관리할 수 있다. 기여를 완전히 금지하는 조직도 "기여를 허용하지 않는다"는 +정책을 명시적으로 문서화하는 것이 바람직하다. + +**고려사항** + +- **기여 범위 정의**: 허용되는 기여 유형(버그 수정, 기능 추가, 문서 작성 등)을 + 구체적으로 열거한다. +- **저작권 귀속**: 기여물의 저작권이 회사에 귀속되는지, 개인에게 귀속되는지 + 정책에 명시한다. +- **특허 리스크 관리**: 기여물에 회사 특허가 포함될 수 있는 경우 법무 검토를 + 의무화한다. +- **CLA 처리**: 외부 프로젝트가 CLA를 요구하는 경우 서명 권한자와 절차를 + 정책에 명시한다. +- **기여 금지 항목**: 영업 비밀, 미등록 특허, 제3자 지식재산이 포함된 코드는 + 기여를 금지한다. + +**샘플** + +아래는 오픈소스 기여 정책 핵심 항목 샘플이다. + +``` +## 오픈소스 기여 정책 + +### 기여 허용 범위 +회사는 임직원이 업무 목적으로 외부 오픈소스 프로젝트에 기여하는 것을 허용한다. +허용되는 기여 유형은 다음과 같다: +- 버그 수정 및 패치 제출 +- 문서 개선 +- 기능 추가 (사전 승인 필요) +- 버그 리포트 및 이슈 제기 + +### 저작권 및 특허 +- 업무 시간에 회사 자원을 사용하여 작성한 기여물의 저작권은 회사에 귀속된다. +- 기여물에 회사 특허가 포함될 가능성이 있는 경우 법무 담당의 사전 검토를 받아야 한다. + +### 기여 금지 항목 +다음 항목이 포함된 코드는 기여할 수 없다: +- 영업 비밀 또는 기밀 정보 +- 제3자의 지식재산 +- 회사의 미공개 특허 기술 + +### CLA (Contributor License Agreement) +외부 프로젝트가 CLA 서명을 요구하는 경우 오픈소스 프로그램 매니저에게 +사전 보고하고 승인을 받아야 한다. +``` + +--- + +### 3.5.1.2 오픈소스 기여 관리 절차 + +**준수 방법** + +실제 기여 활동을 어떻게 처리하는지 단계별로 정의한 절차를 문서화해야 한다. +이 절차 문서가 입증자료 3.5.1.2다. 절차에는 ①기여 제안 및 승인 요청, +②법무·특허 검토(필요 시), ③승인, ④기여 제출, ⑤기여 이력 기록의 단계가 +포함되어야 한다. 기여 규모나 유형에 따라 간소화된 절차(소규모 버그 수정)와 +정식 절차(대규모 기능 추가)를 구분하여 운영할 수 있다. + +**고려사항** + +- **기여 규모별 절차 구분**: 소규모 버그 수정은 간소 승인, 대규모 기능 추가는 + 정식 법무 검토를 거치도록 규모별 기준을 설정한다. +- **기여 기록 보관**: 기여 제안서, 승인 기록, 제출 링크(PR/커밋 URL)를 기록하고 + 보관한다. +- **에스컬레이션**: 특허 또는 저작권 이슈가 발생하는 경우 법무 담당에게 + 에스컬레이션하는 경로를 절차에 포함한다. + +**샘플** + +아래는 오픈소스 기여 관리 절차 개요 샘플이다. + +``` +[오픈소스 기여 관리 절차] + +1. 기여 제안 + - 임직원이 기여하고자 하는 내용(프로젝트명, 기여 유형, 내용 요약)을 + 오픈소스 프로그램 매니저에게 보고한다. + +2. 검토 및 승인 + - 소규모 기여 (버그 수정, 문서 개선): + 오픈소스 프로그램 매니저가 정책 적합성을 확인 후 승인한다. + - 대규모 기여 (기능 추가, 핵심 모듈 기여): + 법무 담당의 특허·저작권 검토 후 오픈소스 프로그램 매니저가 최종 승인한다. + +3. CLA 처리 (해당 시) + - 외부 프로젝트가 CLA를 요구하는 경우 승인된 CLA 서명 양식에 따라 처리한다. + +4. 기여 제출 + - 승인된 내용에 한정하여 기여를 제출한다. + - 회사 이메일 또는 회사가 승인한 계정으로 기여한다. + +5. 기여 기록 + - 기여 내용, 승인자, 제출일, 기여 URL(PR/커밋 링크)을 기록하고 보관한다. +``` + +--- + +### 3.5.1.3 기여 정책 인식 절차 + +**준수 방법** + +모든 프로그램 참여자가 오픈소스 기여 정책의 존재를 인식할 수 있도록 전파하는 +절차를 문서화해야 한다. 이 절차 문서가 입증자료 3.5.1.3이다. §3.1.1.2의 +오픈소스 정책 전파 절차에 기여 정책을 포함하는 방식으로 통합 관리할 수 있다. + +전파 방법은 신규 입사자 온보딩 시 기여 정책 안내, 사내 위키 게시, 이메일 공지 +등을 조합하는 것이 효과적이다. 전파 사실을 증명하기 위해 공지 이력, 교육 이수 +기록 등을 보관한다. + +**고려사항** + +- **온보딩 포함**: 신규 입사자 온보딩 과정에 기여 정책 안내를 필수 항목으로 + 포함한다. +- **정책 갱신 시 재전파**: 기여 정책이 변경된 경우 프로그램 참여자에게 즉시 + 공지한다. +- **증거 보관**: 공지 발송 이력, 교육 이수 확인서 등을 최소 3년간 보관한다. +- **정책 접근성**: 기여 정책을 사내 포털 또는 위키에 항시 게시하여 언제든 + 확인할 수 있도록 한다. + +**샘플** + +아래는 기여 정책 전파 공지 이메일 샘플이다. + +``` +제목: [오픈소스] 오픈소스 기여 정책 안내 + +수신: 전체 개발 관련 임직원 +발신: 오픈소스 프로그램 매니저 + +안녕하세요. + +당사 오픈소스 기여 정책을 안내드립니다. +외부 오픈소스 프로젝트에 기여하는 업무에 관여하는 모든 임직원은 +아래 링크의 정책 문서를 확인하고 숙지해 주시기 바랍니다. + +- 정책 문서: [사내 포털 링크] +- 주요 내용: 기여 허용 범위, 승인 절차, 저작권·특허 처리 방침 +- 정책 버전: v1.0 (시행일: YYYY-MM-DD) + +기여를 희망하는 경우 반드시 사전 승인 절차를 거쳐 주십시오. +문의: 오픈소스 프로그램 매니저 (oss@company.com) + +감사합니다. +오픈소스 프로그램 매니저 +``` + +## 5. 참고 + +- 관련 가이드: [기업 오픈소스 관리 가이드 — 6. 기여](../../../opensource_for_enterprise/6-contribution/) +- 관련 템플릿: [오픈소스 정책 템플릿 — §3 오픈소스 기여](../../../templates/1-policy/) diff --git a/content/ko/guide/iso5230_guide/5-community/_index.md b/content/ko/guide/iso5230_guide/5-community/_index.md new file mode 100644 index 000000000..5afbea23e --- /dev/null +++ b/content/ko/guide/iso5230_guide/5-community/_index.md @@ -0,0 +1,8 @@ +--- +title: "§3.5 커뮤니티 참여" +weight: 50 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "커뮤니티", "기여"] +description: > +--- diff --git a/content/ko/guide/iso5230_guide/6-conformance/1-conformance/_index.md b/content/ko/guide/iso5230_guide/6-conformance/1-conformance/_index.md new file mode 100644 index 000000000..4da8bbcc1 --- /dev/null +++ b/content/ko/guide/iso5230_guide/6-conformance/1-conformance/_index.md @@ -0,0 +1,104 @@ +--- +title: "§3.6.1 적합성" +weight: 10 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "적합성"] +description: > +--- + +## 1. 조항 개요 + +ISO/IEC 5230 인증을 받으려면 §3.1.4에서 정의한 프로그램이 이 규격의 모든 +요구사항을 충족한다는 사실을 문서로 확인해야 한다. §3.6.1은 앞서 §3.1부터 +§3.5까지의 모든 조항을 충족하였음을 공식적으로 선언하는 단계다. 이 조항은 +규격 준수를 완결 짓는 최종 확인 절차로, 프로그램이 ISO/IEC 5230:2020 버전 +2.1의 모든 요구사항을 만족한다는 조직의 공식 확인이 필요하다. + +## 2. 해야 할 활동 + +- §3.1부터 §3.5까지 모든 조항의 입증자료(24개 항목)가 갖추어졌는지 자체 + 점검한다. +- 프로그램이 §3.1.4에서 정의한 적용 범위 내에서 ISO/IEC 5230의 모든 요구사항을 + 충족함을 확인하는 문서를 작성한다. +- 확인 문서에 검토자, 승인자, 확인 날짜를 기록한다. +- 자가 인증, 독립 평가, 또는 제3자 인증 중 적합한 인증 방법을 선택하여 진행한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §3.6.1 | 프로그램이 이 규격을 준수하는 것으로 간주되려면, 조직은 프로그램이 이 문서(버전 2.1)에 제시된 요구사항을 충족한다고 확인해야 한다. | **3.6.1.1** §3.1.4에서 명시한 프로그램이 이 규격의 모든 요구사항을 충족함을 확인하는 문서 | + +
영문 원문 보기 + +> **§3.6.1 Conformance** +> In order for a program to be deemed conformant with this specification, the +> organization shall affirm that the program satisfies the requirements +> presented in this document (version 2.1). +> +> **Verification Material(s):** +> 3.6.1.1 A document affirming the program specified in §3.1.4 satisfies all +> the requirements of this specification. + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 3.6.1.1 규격 준수 확인 문서 + +**준수 방법** + +§3.1.4에서 정의한 프로그램의 적용 범위 내에서 ISO/IEC 5230:2020의 모든 +요구사항을 충족한다는 사실을 확인하는 문서를 작성해야 한다. 이 문서가 +입증자료 3.6.1.1이다. 이 문서는 24개 입증자료 항목 각각에 대해 준수 여부를 +확인하는 체크리스트 형태, 또는 전반적인 준수 선언문 형태로 작성할 수 있다. + +작성 전 이 가이드의 [전체 조항 체크리스트](../../)를 활용하여 모든 입증자료가 +갖추어졌는지 점검한다. 문서에는 확인 대상 프로그램의 적용 범위, 확인 기준 +규격 버전(ISO/IEC 5230:2020 버전 2.1), 확인 날짜, 검토자 및 승인자가 반드시 +포함되어야 한다. + +**고려사항** + +- **자체 점검 선행**: 문서 작성 전 24개 입증자료 항목 전체를 자체 점검하여 + 누락 항목이 없는지 확인한다. +- **규격 버전 명시**: 준수를 확인한 규격 버전(ISO/IEC 5230:2020 버전 2.1)을 + 문서에 명시한다. +- **승인 절차**: 오픈소스 프로그램 매니저의 검토와 경영진 또는 OSRB의 승인을 + 거쳐 문서를 공식화한다. +- **갱신 주기**: 규격 새 버전 발행 후 18개월 이내에 최신 버전 기준으로 + 재확인해야 한다 (§3.6.2 참조). + +**샘플** + +아래는 ISO/IEC 5230 규격 준수 확인 문서 샘플이다. + +``` +[ISO/IEC 5230 규격 준수 확인서] + +프로그램 명칭: [회사명] 오픈소스 컴플라이언스 프로그램 +적용 범위: [§3.1.4에서 정의한 범위 기재] +준수 확인 규격: ISO/IEC 5230:2020 (버전 2.1) +확인 날짜: YYYY-MM-DD + +본 문서는 위 프로그램이 ISO/IEC 5230:2020의 §3.1부터 §3.6까지 +모든 요구사항을 충족함을 확인한다. + +준수 확인 항목 요약: +- §3.1 프로그램 기반 (5개 조항, 8개 입증자료): 충족 ✓ +- §3.2 관련 업무 (2개 조항, 7개 입증자료): 충족 ✓ +- §3.3 콘텐츠 검토 및 승인 (2개 조항, 3개 입증자료): 충족 ✓ +- §3.4 컴플라이언스 산출물 (1개 조항, 2개 입증자료): 충족 ✓ +- §3.5 커뮤니티 참여 (1개 조항, 3개 입증자료): 충족 ✓ +- §3.6 규격 준수 (2개 조항, 2개 입증자료): 충족 ✓ + +검토자: [오픈소스 프로그램 매니저 이름] +승인자: [경영진 또는 OSRB 책임자 이름] +승인일: YYYY-MM-DD +``` + +## 5. 참고 + +- ISO/IEC 5230 자가 인증: [https://certification.openchainproject.org/](https://certification.openchainproject.org/) +- 전체 조항 체크리스트: [ISO/IEC 5230 준수 가이드](../../) diff --git a/content/ko/guide/iso5230_guide/6-conformance/2-duration/_index.md b/content/ko/guide/iso5230_guide/6-conformance/2-duration/_index.md new file mode 100644 index 000000000..0e64a1dff --- /dev/null +++ b/content/ko/guide/iso5230_guide/6-conformance/2-duration/_index.md @@ -0,0 +1,117 @@ +--- +title: "§3.6.2 지속 기간" +weight: 20 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "지속 기간"] +description: > +--- + +## 1. 조항 개요 + +ISO/IEC 5230 인증은 한 번 취득으로 영구히 유효하지 않다. 규격의 새 버전이 +발행되면 이전 버전 기준으로 인증을 받은 프로그램은 새 버전 발행 후 18개월까지만 +적합성이 유지된다. §3.6.2는 프로그램이 적합성 인증을 취득한 날로부터 최근 +18개월 이내에 규격의 모든 요구사항을 충족하고 있음을 확인하는 문서를 유지하도록 +요구한다. 이 조항은 오픈소스 컴플라이언스 프로그램이 형식적 인증에 그치지 않고 +지속적으로 운영되는지 확인하는 장치다. + +## 2. 해야 할 활동 + +- 적합성 인증 취득 날짜를 기록하고 관리한다. +- 인증 취득 후 최근 18개월 이내에 규격의 모든 요구사항을 충족하고 있음을 + 재확인하고 문서화한다. +- 새로운 버전의 규격이 발행된 경우 18개월 이내에 최신 버전 기준으로 + 프로그램을 갱신하고 재확인한다. +- 정기적인 내부 감사를 통해 프로그램의 지속적 준수 여부를 점검한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §3.6.2 | 이 규격을 준수하는 프로그램은, 규격의 새 버전이 발행된 후 18개월이 경과할 때까지 이전에 준수하던 규격 버전에 대해서도 계속 준수하는 것으로 간주된다. 준수 프로그램이 최신 버전의 규격을 준수하도록 업데이트하는 것을 권장한다. | **3.6.2.1** 프로그램이 적합성 인증을 획득한 후 지난 18개월 동안 이 규격 버전의 모든 요구사항을 충족하고 있음을 확인하는 문서 | + +
영문 원문 보기 + +> **§3.6.2 Duration** +> A program that is conformant with this specification shall remain conformant +> even if the version of the specification it was conformant against is +> subsequently updated, for a period of 18 months after the new version of +> the specification is published. It is recommended that conformant programs +> be updated to be conformant with the latest version of the specification. +> +> **Verification Material(s):** +> 3.6.2.1 A document affirming the program meets all the requirements of this +> version of the specification, within the past 18 months of obtaining +> conformance. + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 3.6.2.1 18개월 이내 요구사항 충족 확인 문서 + +**준수 방법** + +적합성 인증 취득 후 18개월 이내에 프로그램이 규격의 모든 요구사항을 여전히 +충족하고 있음을 확인하는 문서를 유지해야 한다. 이 문서가 입증자료 3.6.2.1이다. +가장 간단한 방법은 §3.6.1.1의 규격 준수 확인 문서를 정기적으로(최소 연 1회) +재검토하고 갱신하는 것이다. 갱신 시마다 검토 날짜와 검토자를 기록하여 최근 +18개월 이내에 검토가 이루어졌음을 증명할 수 있도록 한다. + +새로운 버전의 ISO/IEC 5230이 발행된 경우 18개월의 유예 기간 내에 최신 버전 +기준으로 프로그램을 갱신하고 재확인 문서를 작성한다. 유예 기간을 초과하면 +인증 효력이 만료되므로, 규격 개정 동향을 모니터링하고 적시에 대응하는 것이 +중요하다. + +**고려사항** + +- **정기 재확인 일정 수립**: 최소 연 1회 정기 내부 감사를 통해 모든 입증자료 + 항목의 유효성을 재확인하고 문서화한다. +- **규격 개정 모니터링**: OpenChain 프로젝트의 규격 개정 공지를 정기적으로 + 확인하고, 새 버전 발행 시 18개월 이내에 대응 계획을 수립한다. +- **인증 만료 관리**: 인증 취득일과 유효 기간(18개월)을 캘린더 또는 관리 + 시스템에 등록하여 만료 전 갱신 알림을 받도록 설정한다. +- **변경 사항 반영**: 조직 구조, 제품 포트폴리오, 프로세스 변경 발생 시 즉시 + 프로그램에 반영하고 재확인 문서를 갱신한다. + +**샘플** + +아래는 ISO/IEC 5230 규격 준수 정기 재확인 기록 샘플이다. + +``` +[ISO/IEC 5230 규격 준수 정기 재확인 기록] + +프로그램 명칭: [회사명] 오픈소스 컴플라이언스 프로그램 +최초 인증 취득일: YYYY-MM-DD +준수 확인 규격: ISO/IEC 5230:2020 (버전 2.1) + +| 재확인 날짜 | 확인 결과 | 변경 사항 | 검토자 | 비고 | +|------------|-----------|-----------|--------|------| +| 2025-01-10 | 전체 충족 | 담당자 변경 반영 (§3.2.2.1 갱신) | 홍길동 | - | +| 2026-01-08 | 전체 충족 | 없음 | 홍길동 | 다음 재확인 예정: 2027-01-08 | + +다음 재확인 예정일: YYYY-MM-DD (최근 재확인일로부터 12개월 이내) +18개월 유효 기한: YYYY-MM-DD (최근 재확인일로부터 18개월) +``` + +아래는 규격 새 버전 발행 시 대응 체크리스트 샘플이다. + +``` +[ISO/IEC 5230 새 버전 발행 대응 체크리스트] + +새 버전 발행일: YYYY-MM-DD +대응 기한 (18개월): YYYY-MM-DD + +□ 새 버전과 현행 버전의 요구사항 변경 사항 파악 +□ 변경된 요구사항에 따른 프로그램 갱신 계획 수립 +□ 갱신 작업 완료 및 새 버전 기준 입증자료 정비 +□ 새 버전 기준 규격 준수 확인 문서 작성 및 승인 +□ 자가 인증 또는 인증 갱신 절차 진행 +``` + +## 5. 참고 + +- OpenChain 규격 최신 버전 확인: [https://www.openchainproject.org/license-compliance](https://www.openchainproject.org/license-compliance) +- 자가 인증 갱신: [https://certification.openchainproject.org/](https://certification.openchainproject.org/) +- §3.6.1 적합성: [이전 조항 바로가기](../1-conformance/) diff --git a/content/ko/guide/iso5230_guide/6-conformance/_index.md b/content/ko/guide/iso5230_guide/6-conformance/_index.md new file mode 100644 index 000000000..57279468d --- /dev/null +++ b/content/ko/guide/iso5230_guide/6-conformance/_index.md @@ -0,0 +1,8 @@ +--- +title: "§3.6 규격 준수" +weight: 60 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "규격 준수", "적합성"] +description: > +--- diff --git a/content/ko/guide/iso5230_guide/_index.md b/content/ko/guide/iso5230_guide/_index.md new file mode 100644 index 000000000..817906860 --- /dev/null +++ b/content/ko/guide/iso5230_guide/_index.md @@ -0,0 +1,131 @@ +--- +title: "ISO/IEC 5230 준수 가이드" +linkTitle: "ISO/IEC 5230 준수 가이드" +weight: 20 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "라이선스 컴플라이언스", "OpenChain"] +description: > + ISO/IEC 5230의 24개 입증자료 항목을 조항별로 풀어서 설명하는 준수 가이드다. +--- + +이 가이드는 ISO/IEC 5230(OpenChain License Compliance)의 각 요구사항 조항을 하나씩 +풀어서 설명한다. 각 조항이 요구하는 입증자료가 무엇인지, 어떻게 준수할 수 있는지, +바로 활용할 수 있는 샘플 문서는 무엇인지 안내한다. + +**Author : OpenChain Korea Work Group / [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)** + +## 대상 독자 + +- 오픈소스 컴플라이언스 담당자 및 오픈소스 프로그램 매니저 +- ISO/IEC 5230 인증 취득을 준비 중인 기업의 담당자 +- 기존 오픈소스 관리 체계를 ISO 표준 기준으로 점검하고 싶은 실무자 + +## 이 가이드의 활용 방법 + +{{% alert title="기업 오픈소스 관리 가이드와의 관계" color="success" %}} + +**[기업 오픈소스 관리 가이드](../opensource_for_enterprise/)** 는 오픈소스를 +어떻게 관리할지 실무 구현 방법(정책·프로세스·도구·조직)을 설명한다. + +**이 가이드(ISO/IEC 5230 준수 가이드)** 는 인증을 위해 무엇을 입증해야 하는지 +조항 단위로 정리한다. + +| 가이드 | 중점 | 활용 상황 | +|--------|------|-----------| +| 기업 오픈소스 관리 가이드 | 실무 구현 방법 (How to implement) | 오픈소스 관리 체계를 처음 구축할 때 | +| ISO/IEC 5230 준수 가이드 | 조항별 입증자료 기준 (What to prove) | 인증 준비 또는 자체 점검 시 | + +두 가이드는 상호 보완적이다. 각 조항 페이지는 기업 오픈소스 관리 가이드의 +대응 섹션으로 교차 링크를 제공한다. + +{{% /alert %}} + +## 전체 조항 체크리스트 + +ISO/IEC 5230은 총 **13개 조항, 24개 입증자료 항목**으로 구성된다. + +### §3.1 프로그램 기반 + +| 조항 | 제목 | 입증자료 | 상세 | +|------|------|:---:|------| +| §3.1.1 | 정책 (Policy) | 2건 | [바로가기](./1-program-foundation/1-policy/) | +| §3.1.2 | 역량 (Competence) | 3건 | [바로가기](./1-program-foundation/2-competence/) | +| §3.1.3 | 인식 (Awareness) | 1건 | [바로가기](./1-program-foundation/3-awareness/) | +| §3.1.4 | 프로그램 범위 (Program Scope) | 1건 | [바로가기](./1-program-foundation/4-scope/) | +| §3.1.5 | 라이선스 의무 (License Obligations) | 1건 | [바로가기](./1-program-foundation/5-license-obligations/) | + +### §3.2 관련 업무 + +| 조항 | 제목 | 입증자료 | 상세 | +|------|------|:---:|------| +| §3.2.1 | 외부 문의 대응 (Access) | 2건 | [바로가기](./2-relevant-tasks/1-access/) | +| §3.2.2 | 효과적 리소스 (Effectively Resourced) | 5건 | [바로가기](./2-relevant-tasks/2-resourced/) | + +### §3.3 콘텐츠 검토 및 승인 + +| 조항 | 제목 | 입증자료 | 상세 | +|------|------|:---:|------| +| §3.3.1 | SBOM | 2건 | [바로가기](./3-content-review/1-sbom/) | +| §3.3.2 | 라이선스 컴플라이언스 (License Compliance) | 1건 | [바로가기](./3-content-review/2-license-compliance/) | + +### §3.4 컴플라이언스 산출물 + +| 조항 | 제목 | 입증자료 | 상세 | +|------|------|:---:|------| +| §3.4.1 | 컴플라이언스 산출물 (Compliance Artifacts) | 2건 | [바로가기](./4-artifacts/1-compliance-artifacts/) | + +### §3.5 커뮤니티 참여 + +| 조항 | 제목 | 입증자료 | 상세 | +|------|------|:---:|------| +| §3.5.1 | 기여 (Contributions) | 3건 | [바로가기](./5-community/1-contributions/) | + +### §3.6 규격 준수 + +| 조항 | 제목 | 입증자료 | 상세 | +|------|------|:---:|------| +| §3.6.1 | 적합성 (Conformance) | 1건 | [바로가기](./6-conformance/1-conformance/) | +| §3.6.2 | 지속 기간 (Duration) | 1건 | [바로가기](./6-conformance/2-duration/) | + +**합계: 13개 조항 / 24개 입증자료 항목** + +## ISO/IEC 5230 인증 절차 + +ISO/IEC 5230 준수 여부를 공식적으로 인정받는 방법은 세 가지다. + +{{% pageinfo %}} + +**1단계. 자가 인증 (Self-Certification)** + +OpenChain 프로젝트가 제공하는 온라인 체크리스트를 작성하여 자체적으로 준수 여부를 +선언한다. 비용이 없으며 즉시 시작할 수 있다. + +- 체크리스트: [https://certification.openchainproject.org/](https://certification.openchainproject.org/) +- 적합 대상: 인증을 처음 준비하거나 내부 점검 용도 + +--- + +**2단계. 독립 평가 (Independent Assessment)** + +외부 전문가 또는 컨설팅 기관이 오픈소스 프로그램을 평가한다. 자가 인증보다 신뢰도가 +높으며, 공급망 파트너에게 준수 수준을 입증하는 데 활용된다. + +- 파트너 목록: [Open Compliance Directory](https://www.openchainproject.org/find-a-partner) + +--- + +**3단계. 제3자 인증 (Third-party Certification)** + +OpenChain이 공인한 인증 기관이 심사하여 공식 인증서를 발급한다. 가장 높은 신뢰도를 +가지며, 글로벌 공급망 요구사항 충족에 적합하다. + +- 공인 인증 기관 (2024년 기준): ORCRO, PwC, TÜV SÜD, Synopsys, Bureau Veritas + +{{% /pageinfo %}} + +{{% alert title="단계적 접근 권장" color="success" %}} +처음 인증을 준비하는 기업은 **자가 인증 → 독립 평가 → 제3자 인증** 순서로 +단계적으로 진행하는 것을 권장한다. 자가 인증만으로도 많은 공급망 파트너가 요구하는 +준수 수준을 충족할 수 있다. +{{% /alert %}} From 68cca98a6c8bc3be4381bebac050ac3e5af56622 Mon Sep 17 00:00:00 2001 From: Haksung Jang Date: Thu, 26 Mar 2026 16:32:13 +0900 Subject: [PATCH 2/2] fix: title in english --- content/ko/guide/archive/_index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ko/guide/archive/_index.md b/content/ko/guide/archive/_index.md index f6877ab32..dd045147d 100644 --- a/content/ko/guide/archive/_index.md +++ b/content/ko/guide/archive/_index.md @@ -1,6 +1,6 @@ --- -title: "아카이브" -linkTitle: "아카이브" +title: "Archive" +linkTitle: "Archive" weight: 900 type: docs description: >