docs(guide): ISO/IEC 18974 준수 가이드 전체 조항 페이지 추가

content/ko/guide/iso18974_guide/1-program-foundation/1-policy/_index.md

@@ -0,0 +1,153 @@
+---
+title: "§4.1.1 정책"
+weight: 10
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974", "정책"]
+description: >
+---
+
+## 1. 조항 개요
+
+§4.1.1은 ISO/IEC 5230 §3.1.1(라이선스 컴플라이언스 정책)과 대응하는 조항이지만,
+초점이 **보안 보증**으로 전환된다. 오픈소스 컴포넌트의 알려진 취약점과 새로
+발견되는 취약점을 체계적으로 관리하는 정책이 문서화되어 있어야 하며, 그 정책이
+조직 내부에 전파되어야 한다. ISO/IEC 5230 §3.1.1과의 핵심 차이점은 **정책과
+전파 절차 자체에 대한 정기 검토 프로세스**를 요구한다는 점이다. 정책을 수립하는
+것에 그치지 않고, 정책이 항상 유효하고 최신 상태를 유지하도록 검토 체계를
+갖추어야 한다.
+
+## 2. 해야 할 활동
+
+- 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안 취약점을 관리하는 정책을
+  문서화하고 공식화한다.
+- 정책에 취약점 탐지·평가·대응·통보 원칙과 CVD(Coordinated Vulnerability
+  Disclosure) 방침을 포함한다.
+- 프로그램 참여자(개발자·보안 담당·법무·IT 등)에게 정책을 전파하는 절차를
+  수립하고 문서화한다.
+- **정책과 전파 절차 자체를 정기적으로 검토하여 최신 상태를 유지하는 검토
+  프로세스**를 정책 내에 명시한다.
+- 검토 완료 일자, 검토자, 변경 이력을 문서에 기록한다.
+
+## 3. 요구사항 및 입증자료
+
+| 조항 번호 | 요구사항 (KO) | 입증자료 |
+|-----------|--------------|---------|
+| §4.1.1 | 배포용 소프트웨어의 오픈소스 소프트웨어 보안 보증을 관리하는 문서화된 오픈소스 정책이 있어야 한다. 이 정책은 조직 내부에 전파되어야 한다. **정책과 전달 방법은 항상 유효하고 최신 상태를 유지하기 위한 검토 프로세스를 가져야 한다.** | **4.1.1.1** 문서화된 오픈소스 소프트웨어 보안 보증 정책<br>**4.1.1.2** 프로그램 참여자가 보안 보증 정책을 인식하도록 하기 위한 문서화된 절차 |
+
+<details><summary>영문 원문 보기</summary>
+
+> **§4.1.1 Policy**
+> A written open source software security assurance policy shall exist that
+> governs open source software security assurance of the supplied software.
+> The policy shall be internally communicated. The policy and its method of
+> communication shall have a review process to ensure they remain current and
+> valid.
+>
+> **Verification Material(s):**
+> 4.1.1.1 A documented open source software security assurance policy.
+> 4.1.1.2 A documented procedure that makes program participants aware of the
+> security assurance policy.
+
+</details>
+
+## 4. 입증자료별 준수 방법 및 샘플
+
+### 4.1.1.1 문서화된 보안 보증 정책
+
+**준수 방법**
+
+ISO/IEC 5230의 오픈소스 정책을 이미 보유한 경우, 해당 정책에 보안 보증 관련
+섹션을 추가하거나 별도 보안 보증 정책 문서를 작성하는 두 가지 방법을 선택할
+수 있다. 두 방법 모두 입증자료 4.1.1.1을 충족한다.
+
+정책에는 ①보안 취약점 식별·추적·대응 원칙, ②CVSS 기반 위험 평가 및 조치
+기한 기준, ③CVD(Coordinated Vulnerability Disclosure) 방침, ④배포 후
+모니터링 원칙, ⑤정기 검토 주기와 검토자가 포함되어야 한다. ISO/IEC 5230
+§3.1.1.1과의 핵심 차이는 **정기 검토 프로세스**를 정책 문서 안에 명시해야
+한다는 점이다.
+
+**고려사항**
+
+- **5230 정책과 통합**: 기존 ISO/IEC 5230 정책의 §5 보안 취약점 대응 섹션을
+  확장하는 방식으로 통합 관리할 수 있다.
+- **검토 주기 명시**: 최소 연 1회 정기 검토를 수행하며, 새로운 위협 환경이나
+  법적 요건 변화 시 즉시 검토한다는 조항을 포함한다.
+- **CVSS 기준 채택**: 취약점 심각도 평가에 CVSS(Common Vulnerability Scoring
+  System)를 활용하고 조치 기한(예: Critical 7일, High 30일)을 정책에 명시한다.
+- **CVD 방침 포함**: 외부에서 취약점이 보고되었을 때 비공개로 협력하여 해결한
+  후 공개하는 CVD 절차를 정책에 포함한다.
+- **버전 관리**: 정책 버전 번호, 변경 이력, 검토 완료 날짜를 기록한다.
+
+**샘플**
+
+아래는 오픈소스 정책의 보안 보증 섹션 샘플이다.
+
+```
+## §5 오픈소스 보안 보증
+
+### 5.1 목적
+회사는 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안 취약점을
+체계적으로 식별하고 대응하여 보안 위험을 최소화한다.
+
+### 5.2 취약점 대응 원칙
+알려진 취약점(CVE)에 대한 조치 기한 기준은 다음과 같다:
+- Critical (CVSS 9.0~10.0): 7일 이내 패치 또는 완화 조치
+- High (CVSS 7.0~8.9): 30일 이내 패치 또는 완화 조치
+- Medium (CVSS 4.0~6.9): 90일 이내 패치 계획 수립
+- Low (CVSS 0.1~3.9): 다음 정기 업데이트 시 처리
+
+### 5.3 CVD(Coordinated Vulnerability Disclosure) 방침
+외부에서 취약점이 보고된 경우 보고자와 협력하여 해결 후 공개한다.
+취약점 보고 채널: security@company.com
+
+### 5.4 정책 검토
+이 정책과 전파 절차는 최소 연 1회 검토하며 최신 상태를 유지한다.
+검토 완료 날짜와 검토자를 문서에 기록한다.
+```
+
+---
+
+### 4.1.1.2 보안 보증 정책 인식 방법 문서화
+
+**준수 방법**
+
+ISO/IEC 5230의 정책 전파 절차(§3.1.1.2)와 동일한 방식으로 보안 보증 정책을
+프로그램 참여자에게 전파하는 절차를 문서화해야 한다. §4.1.1의 추가 요건은
+전파 절차 자체도 정기적으로 검토하여 유효성을 유지해야 한다는 점이다. 기존
+5230 정책 전파 절차에 보안 보증 정책 내용을 추가하거나, 별도 보안 정책 전파
+절차를 수립하는 방식으로 대응할 수 있다.
+
+**고려사항**
+
+- **5230 절차 재활용**: 기존 오픈소스 정책 전파 채널(온보딩, 사내 위키,
+  이메일)에 보안 보증 정책을 추가하는 방식으로 효율적으로 대응한다.
+- **전파 절차 검토**: 전파 절차 문서에 검토 주기(연 1회)와 검토자를 명시하여
+  절차 자체의 유효성을 관리한다.
+- **증거 보관**: 공지 이력, 교육 이수 기록을 최소 3년간 보관한다.
+
+**샘플**
+
+```
+제목: [보안] 오픈소스 보안 보증 정책 안내 및 숙지 요청
+
+수신: 전체 개발/배포/보안 관련 임직원
+발신: 오픈소스 프로그램 매니저
+
+안녕하세요.
+
+당사 오픈소스 보안 보증 정책이 제정(또는 개정)되었습니다.
+아래 링크의 정책 문서를 확인하고 숙지해 주시기 바랍니다.
+
+- 정책 문서: [사내 포털 링크]
+- 주요 내용: 취약점 대응 원칙, CVSS 기반 조치 기한, CVD 방침
+- 정책 버전: v1.0 (시행일: YYYY-MM-DD) / 차기 검토 예정: YYYY-MM-DD
+
+문의: 오픈소스 프로그램 매니저 (oss@company.com)
+```
+
+## 5. 참고
+
+- 대응 ISO/IEC 5230 조항: [§3.1.1 정책](../../iso5230_guide/1-program-foundation/1-policy/)
+- 관련 가이드: [기업 오픈소스 관리 가이드 — 2. 정책](../../../opensource_for_enterprise/2-policy/)
+- 관련 템플릿: [오픈소스 정책 템플릿](../../../templates/1-policy/)

content/ko/guide/iso18974_guide/1-program-foundation/2-competence/_index.md

@@ -0,0 +1,183 @@
+---
+title: "§4.1.2 역량"
+weight: 20
+type: docs
+categories: ["guide"]
+tags: ["ISO/IEC 18974", "역량"]
+description: >
+---
+
+## 1. 조항 개요
+
+§4.1.2는 ISO/IEC 5230 §3.1.2(역량)와 기본 구조는 동일하지만, 입증자료 항목이
+3건 더 많다. 5230이 역할 목록·역량 정의·역량 평가 증거 3가지를 요구하는 반면,
+18974는 여기에 **참여자 목록 및 역할 매핑(4.1.2.3)**, **주기적 검토 및 프로세스
+변경 증거(4.1.2.5)**, **내부 모범 사례와의 일치 검증(4.1.2.6)** 을 추가로
+요구한다. 이 세 가지 추가 항목은 역량 체계가 형식에 그치지 않고 실제로 최신
+상태를 유지하며 업계 표준과 정합성을 갖추고 있음을 입증하도록 요구한다.
+
+## 2. 해야 할 활동
+
+- 프로그램 역할별 책임 목록을 작성한다 (5230과 동일).
+- 각 역할에 필요한 역량을 정의하고 문서화한다 (5230과 동일).
+- **참여자 이름과 각자의 역할을 매핑한 목록**을 별도로 작성한다 (18974 추가).
+- 각 참여자의 역량을 평가하고 기록한다 (5230과 동일).
+- **주기적으로 역량 체계를 검토하고 프로세스 변경 사항을 기록한다** (18974 추가).
+- **역량 체계가 회사 내부 모범 사례와 일치하는지 확인하고 담당자를 지정한다**
+  (18974 추가).
+
+## 3. 요구사항 및 입증자료
+
+| 조항 번호 | 요구사항 (KO) | 입증자료 |
+|-----------|--------------|---------|
+| §4.1.2 | 조직은 프로그램의 성과와 효율에 영향을 미치는 역할과 책임을 확인하고, 각 역할의 필요 역량을 결정하며, 참여자의 역량을 확인하고 필요 시 조치를 취하고, 역량 보유 증거를 문서화하여 유지해야 한다. | **4.1.2.1** 여러 프로그램 참여자에 대한 해당 책임이 있는 문서화된 역할 목록<br>**4.1.2.2** 각 역할에 대한 역량을 식별하는 문서<br>**4.1.2.3** 참여자 목록 및 해당 역할 ★<br>**4.1.2.4** 각 프로그램 참여자에 대해 평가된 역량에 대한 문서화된 증거<br>**4.1.2.5** 주기적인 검토 및 프로세스 변경에 대한 문서화된 증거 ★<br>**4.1.2.6** 이러한 프로세스가 회사 내부 모범 사례와 일치하며 최신 상태를 유지하고 있는지, 그리고 이를 확인하는 담당자가 지정되었는지에 대한 문서화된 증거 ★ |
+
+★ = ISO/IEC 5230 §3.1.2 대비 추가 항목
+
+<details><summary>영문 원문 보기</summary>
+
+> **§4.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):**
+> 4.1.2.1 A documented list of roles with corresponding responsibilities for
+> the different participants in the program.
+> 4.1.2.2 A document that identifies the competencies for each role.
+> 4.1.2.3 List of participants and their roles.
+> 4.1.2.4 Documented evidence of assessed competence for each program
+> participant.
+> 4.1.2.5 Documented evidence of periodic reviews and changes to the process.
+> 4.1.2.6 Documented evidence that these processes align with and are
+> up-to-date with company internal best practices, and that a person has been
+> assigned to make sure they remain so.
+
+</details>
+
+## 4. 입증자료별 준수 방법 및 샘플
+
+### 4.1.2.1 역할과 책임 목록 문서
+
+ISO/IEC 5230 §3.1.2.1과 동일하다. 보안 보증 관점에서 보안 담당(DevSecOps,
+취약점 분석)의 역할을 명확히 포함해야 한다. 작성 방법은
+[§3.1.2.1 역할과 책임 목록 문서](../../iso5230_guide/1-program-foundation/2-competence/)를 참고한다.
+
+---
+
+### 4.1.2.2 역할별 필요 역량 문서
+
+ISO/IEC 5230 §3.1.2.2와 동일하다. 보안 담당 역할에 **CVSS 점수 해석, 취약점
+분석 도구(OSV-SCALIBR, Dependency-Track 등) 운용, DevSecOps 이해** 역량을
+포함해야 한다. 작성 방법은
+[§3.1.2.2 역할별 필요 역량 문서](../../iso5230_guide/1-program-foundation/2-competence/)를 참고한다.
+
+---
+
+### 4.1.2.3 참여자 목록 및 역할 ★
+
+**준수 방법**
+
+4.1.2.1의 역할 목록과 달리, 이 항목은 **실제 인원의 이름**과 그들이 담당하는
+역할을 매핑한 목록을 요구한다. 조직도 상의 역할이 아니라 현재 프로그램에
+참여하는 실제 담당자가 누구인지를 명확히 하는 것이 목적이다. 인사 변동 시
+즉시 갱신해야 한다.
+
+**고려사항**
+
+- **이름 또는 직무명**: 개인 이름 대신 직무명을 사용해도 무방하나, 특정인을
+  식별할 수 있는 수준이어야 한다.
+- **겸임 명시**: 여러 역할을 겸임하는 경우 모든 역할을 기재한다.
+- **갱신 즉시성**: 담당자 변경 즉시 문서를 갱신하고 버전을 업데이트한다.
+
+**샘플**
+
+```
+| 이름 | 역할 | 연락처 | 지정일 |
+|------|------|--------|--------|
+| 홍길동 | 오픈소스 프로그램 매니저 | oss@company.com | 2025-01-01 |
+| 김철수 | 보안 담당 (DevSecOps) | security@company.com | 2025-01-01 |
+| 이영희 | 법무 담당 | legal@company.com | 2025-01-01 |
+| 박인프라 | IT 담당 | it@company.com | 2025-03-15 |
+```
+
+---
+
+### 4.1.2.4 역량 평가 증거
+
+ISO/IEC 5230 §3.1.2.3과 동일하다. 작성 방법은
+[§3.1.2.3 역량 평가 증거](../../iso5230_guide/1-program-foundation/2-competence/)를 참고한다.
+
+---
+
+### 4.1.2.5 주기적 검토 및 프로세스 변경 증거 ★
+
+**준수 방법**
+
+역량 체계(역할 정의, 역량 기준, 평가 방법)를 주기적으로 검토하고, 검토 과정에서
+발생한 변경 사항을 기록해야 한다. 새로운 보안 도구 도입, 조직 구조 변경, 취약점
+대응 프로세스 개선 등이 역량 체계에 반영되었는지 확인하는 것이 핵심이다. 검토
+기록 자체가 입증자료 4.1.2.5다.
+
+**고려사항**
+
+- **검토 주기**: 최소 연 1회 정기 검토를 실시하고, 조직·프로세스 변경 시 즉시
+  검토한다.
+- **변경 이력 기록**: 변경 내용, 변경 이유, 변경 날짜, 변경자를 기록한다.
+- **검토 증거 형식**: 검토 회의록, 검토 완료 확인서, 변경 이력 로그 등이
+  증거로 활용 가능하다.
+
+**샘플**
+
+```
+[역량 체계 정기 검토 기록]
+
+| 검토 날짜 | 검토 내용 | 변경 사항 | 검토자 |
+|----------|-----------|-----------|--------|
+| 2025-01-10 | 전체 역할·역량 검토 | 보안 담당 역량에 CVSS v4.0 해석 항목 추가 | 홍길동 |
+| 2026-01-08 | 전체 역할·역량 검토 | Dependency-Track 운용 역량 IT 담당에 추가 | 홍길동 |
+```
+
+---
+
+### 4.1.2.6 내부 모범 사례 일치 검증 ★
+
+**준수 방법**
+
+역량 정의 및 평가 프로세스가 회사 내부 모범 사례(HR 정책, 기술 교육 기준 등)와
+정합성을 유지하고 있는지 확인하며, 이를 지속적으로 관리하는 담당자를 지정해야
+한다. 역량 체계가 산업 표준이나 내부 지침과 괴리되지 않도록 하는 것이 목적이다.
+
+**고려사항**
+
+- **담당자 지정**: 역량 체계의 최신성과 내부 모범 사례 정합성을 관리하는
+  책임자를 명시적으로 지정하고 기록한다.
+- **모범 사례 기준**: 업계 표준(NIST SSDF, ISO 27001 등), 사내 보안 정책,
+  DevSecOps 가이드라인 등을 모범 사례 기준으로 활용할 수 있다.
+
+**샘플**
+
+```
+[내부 모범 사례 정합성 확인서]
+
+역량 체계 관리 담당자: 홍길동 (오픈소스 프로그램 매니저)
+마지막 정합성 검토일: 2026-01-08
+참조 모범 사례 기준: 사내 보안 교육 기준 v3.0, NIST SSDF 1.1
+
+검토 결과:
+- 보안 담당 역량 기준이 사내 보안 교육 커리큘럼과 일치함 ✓
+- 취약점 분석 도구 역량이 최신 도구(Dependency-Track v4.x)를 반영함 ✓
+- 다음 정합성 검토 예정일: 2027-01-08
+```
+
+## 5. 참고
+
+- 대응 ISO/IEC 5230 조항: [§3.1.2 역량](../../iso5230_guide/1-program-foundation/2-competence/)
+- 관련 가이드: [기업 오픈소스 관리 가이드 — 1. 조직](../../../opensource_for_enterprise/1-teams/)
+- 관련 템플릿: [오픈소스 정책 템플릿 — Appendix 1. 담당자 현황](../../../templates/1-policy/appendix/)