Skip to content

Commit 15296b3

Browse files
haksungjanghaksungjang
authored
Merge pull request #256 from OpenChain-Project/guide/iso18974-compliance-guide
docs(guide): ISO/IEC 18974 준수 가이드 전체 조항 페이지 추가
2 parents ea18be8 + 9b5c780 commit 15296b3

17 files changed

Lines changed: 1880 additions & 0 deletions

File tree

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

Lines changed: 153 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,153 @@
1+
---
2+
title: "§4.1.1 정책"
3+
weight: 10
4+
type: docs
5+
categories: ["guide"]
6+
tags: ["ISO/IEC 18974", "정책"]
7+
description: >
8+
---
9+
10+
## 1. 조항 개요
11+
12+
§4.1.1은 ISO/IEC 5230 §3.1.1(라이선스 컴플라이언스 정책)과 대응하는 조항이지만,
13+
초점이 **보안 보증**으로 전환된다. 오픈소스 컴포넌트의 알려진 취약점과 새로
14+
발견되는 취약점을 체계적으로 관리하는 정책이 문서화되어 있어야 하며, 그 정책이
15+
조직 내부에 전파되어야 한다. ISO/IEC 5230 §3.1.1과의 핵심 차이점은 **정책과
16+
전파 절차 자체에 대한 정기 검토 프로세스**를 요구한다는 점이다. 정책을 수립하는
17+
것에 그치지 않고, 정책이 항상 유효하고 최신 상태를 유지하도록 검토 체계를
18+
갖추어야 한다.
19+
20+
## 2. 해야 할 활동
21+
22+
- 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안 취약점을 관리하는 정책을
23+
문서화하고 공식화한다.
24+
- 정책에 취약점 탐지·평가·대응·통보 원칙과 CVD(Coordinated Vulnerability
25+
Disclosure) 방침을 포함한다.
26+
- 프로그램 참여자(개발자·보안 담당·법무·IT 등)에게 정책을 전파하는 절차를
27+
수립하고 문서화한다.
28+
- **정책과 전파 절차 자체를 정기적으로 검토하여 최신 상태를 유지하는 검토
29+
프로세스**를 정책 내에 명시한다.
30+
- 검토 완료 일자, 검토자, 변경 이력을 문서에 기록한다.
31+
32+
## 3. 요구사항 및 입증자료
33+
34+
| 조항 번호 | 요구사항 (KO) | 입증자료 |
35+
|-----------|--------------|---------|
36+
| §4.1.1 | 배포용 소프트웨어의 오픈소스 소프트웨어 보안 보증을 관리하는 문서화된 오픈소스 정책이 있어야 한다. 이 정책은 조직 내부에 전파되어야 한다. **정책과 전달 방법은 항상 유효하고 최신 상태를 유지하기 위한 검토 프로세스를 가져야 한다.** | **4.1.1.1** 문서화된 오픈소스 소프트웨어 보안 보증 정책<br>**4.1.1.2** 프로그램 참여자가 보안 보증 정책을 인식하도록 하기 위한 문서화된 절차 |
37+
38+
<details><summary>영문 원문 보기</summary>
39+
40+
> **§4.1.1 Policy**
41+
> A written open source software security assurance policy shall exist that
42+
> governs open source software security assurance of the supplied software.
43+
> The policy shall be internally communicated. The policy and its method of
44+
> communication shall have a review process to ensure they remain current and
45+
> valid.
46+
>
47+
> **Verification Material(s):**
48+
> 4.1.1.1 A documented open source software security assurance policy.
49+
> 4.1.1.2 A documented procedure that makes program participants aware of the
50+
> security assurance policy.
51+
52+
</details>
53+
54+
## 4. 입증자료별 준수 방법 및 샘플
55+
56+
### 4.1.1.1 문서화된 보안 보증 정책
57+
58+
**준수 방법**
59+
60+
ISO/IEC 5230의 오픈소스 정책을 이미 보유한 경우, 해당 정책에 보안 보증 관련
61+
섹션을 추가하거나 별도 보안 보증 정책 문서를 작성하는 두 가지 방법을 선택할
62+
수 있다. 두 방법 모두 입증자료 4.1.1.1을 충족한다.
63+
64+
정책에는 ①보안 취약점 식별·추적·대응 원칙, ②CVSS 기반 위험 평가 및 조치
65+
기한 기준, ③CVD(Coordinated Vulnerability Disclosure) 방침, ④배포 후
66+
모니터링 원칙, ⑤정기 검토 주기와 검토자가 포함되어야 한다. ISO/IEC 5230
67+
§3.1.1.1과의 핵심 차이는 **정기 검토 프로세스**를 정책 문서 안에 명시해야
68+
한다는 점이다.
69+
70+
**고려사항**
71+
72+
- **5230 정책과 통합**: 기존 ISO/IEC 5230 정책의 §5 보안 취약점 대응 섹션을
73+
확장하는 방식으로 통합 관리할 수 있다.
74+
- **검토 주기 명시**: 최소 연 1회 정기 검토를 수행하며, 새로운 위협 환경이나
75+
법적 요건 변화 시 즉시 검토한다는 조항을 포함한다.
76+
- **CVSS 기준 채택**: 취약점 심각도 평가에 CVSS(Common Vulnerability Scoring
77+
System)를 활용하고 조치 기한(예: Critical 7일, High 30일)을 정책에 명시한다.
78+
- **CVD 방침 포함**: 외부에서 취약점이 보고되었을 때 비공개로 협력하여 해결한
79+
후 공개하는 CVD 절차를 정책에 포함한다.
80+
- **버전 관리**: 정책 버전 번호, 변경 이력, 검토 완료 날짜를 기록한다.
81+
82+
**샘플**
83+
84+
아래는 오픈소스 정책의 보안 보증 섹션 샘플이다.
85+
86+
```
87+
## §5 오픈소스 보안 보증
88+
89+
### 5.1 목적
90+
회사는 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안 취약점을
91+
체계적으로 식별하고 대응하여 보안 위험을 최소화한다.
92+
93+
### 5.2 취약점 대응 원칙
94+
알려진 취약점(CVE)에 대한 조치 기한 기준은 다음과 같다:
95+
- Critical (CVSS 9.0~10.0): 7일 이내 패치 또는 완화 조치
96+
- High (CVSS 7.0~8.9): 30일 이내 패치 또는 완화 조치
97+
- Medium (CVSS 4.0~6.9): 90일 이내 패치 계획 수립
98+
- Low (CVSS 0.1~3.9): 다음 정기 업데이트 시 처리
99+
100+
### 5.3 CVD(Coordinated Vulnerability Disclosure) 방침
101+
외부에서 취약점이 보고된 경우 보고자와 협력하여 해결 후 공개한다.
102+
취약점 보고 채널: security@company.com
103+
104+
### 5.4 정책 검토
105+
이 정책과 전파 절차는 최소 연 1회 검토하며 최신 상태를 유지한다.
106+
검토 완료 날짜와 검토자를 문서에 기록한다.
107+
```
108+
109+
---
110+
111+
### 4.1.1.2 보안 보증 정책 인식 방법 문서화
112+
113+
**준수 방법**
114+
115+
ISO/IEC 5230의 정책 전파 절차(§3.1.1.2)와 동일한 방식으로 보안 보증 정책을
116+
프로그램 참여자에게 전파하는 절차를 문서화해야 한다. §4.1.1의 추가 요건은
117+
전파 절차 자체도 정기적으로 검토하여 유효성을 유지해야 한다는 점이다. 기존
118+
5230 정책 전파 절차에 보안 보증 정책 내용을 추가하거나, 별도 보안 정책 전파
119+
절차를 수립하는 방식으로 대응할 수 있다.
120+
121+
**고려사항**
122+
123+
- **5230 절차 재활용**: 기존 오픈소스 정책 전파 채널(온보딩, 사내 위키,
124+
이메일)에 보안 보증 정책을 추가하는 방식으로 효율적으로 대응한다.
125+
- **전파 절차 검토**: 전파 절차 문서에 검토 주기(연 1회)와 검토자를 명시하여
126+
절차 자체의 유효성을 관리한다.
127+
- **증거 보관**: 공지 이력, 교육 이수 기록을 최소 3년간 보관한다.
128+
129+
**샘플**
130+
131+
```
132+
제목: [보안] 오픈소스 보안 보증 정책 안내 및 숙지 요청
133+
134+
수신: 전체 개발/배포/보안 관련 임직원
135+
발신: 오픈소스 프로그램 매니저
136+
137+
안녕하세요.
138+
139+
당사 오픈소스 보안 보증 정책이 제정(또는 개정)되었습니다.
140+
아래 링크의 정책 문서를 확인하고 숙지해 주시기 바랍니다.
141+
142+
- 정책 문서: [사내 포털 링크]
143+
- 주요 내용: 취약점 대응 원칙, CVSS 기반 조치 기한, CVD 방침
144+
- 정책 버전: v1.0 (시행일: YYYY-MM-DD) / 차기 검토 예정: YYYY-MM-DD
145+
146+
문의: 오픈소스 프로그램 매니저 (oss@company.com)
147+
```
148+
149+
## 5. 참고
150+
151+
- 대응 ISO/IEC 5230 조항: [§3.1.1 정책](../../iso5230_guide/1-program-foundation/1-policy/)
152+
- 관련 가이드: [기업 오픈소스 관리 가이드 — 2. 정책](../../../opensource_for_enterprise/2-policy/)
153+
- 관련 템플릿: [오픈소스 정책 템플릿](../../../templates/1-policy/)

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

Lines changed: 183 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,183 @@
1+
---
2+
title: "§4.1.2 역량"
3+
weight: 20
4+
type: docs
5+
categories: ["guide"]
6+
tags: ["ISO/IEC 18974", "역량"]
7+
description: >
8+
---
9+
10+
## 1. 조항 개요
11+
12+
§4.1.2는 ISO/IEC 5230 §3.1.2(역량)와 기본 구조는 동일하지만, 입증자료 항목이
13+
3건 더 많다. 5230이 역할 목록·역량 정의·역량 평가 증거 3가지를 요구하는 반면,
14+
18974는 여기에 **참여자 목록 및 역할 매핑(4.1.2.3)**, **주기적 검토 및 프로세스
15+
변경 증거(4.1.2.5)**, **내부 모범 사례와의 일치 검증(4.1.2.6)** 을 추가로
16+
요구한다. 이 세 가지 추가 항목은 역량 체계가 형식에 그치지 않고 실제로 최신
17+
상태를 유지하며 업계 표준과 정합성을 갖추고 있음을 입증하도록 요구한다.
18+
19+
## 2. 해야 할 활동
20+
21+
- 프로그램 역할별 책임 목록을 작성한다 (5230과 동일).
22+
- 각 역할에 필요한 역량을 정의하고 문서화한다 (5230과 동일).
23+
- **참여자 이름과 각자의 역할을 매핑한 목록**을 별도로 작성한다 (18974 추가).
24+
- 각 참여자의 역량을 평가하고 기록한다 (5230과 동일).
25+
- **주기적으로 역량 체계를 검토하고 프로세스 변경 사항을 기록한다** (18974 추가).
26+
- **역량 체계가 회사 내부 모범 사례와 일치하는지 확인하고 담당자를 지정한다**
27+
(18974 추가).
28+
29+
## 3. 요구사항 및 입증자료
30+
31+
| 조항 번호 | 요구사항 (KO) | 입증자료 |
32+
|-----------|--------------|---------|
33+
| §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** 이러한 프로세스가 회사 내부 모범 사례와 일치하며 최신 상태를 유지하고 있는지, 그리고 이를 확인하는 담당자가 지정되었는지에 대한 문서화된 증거 ★ |
34+
35+
★ = ISO/IEC 5230 §3.1.2 대비 추가 항목
36+
37+
<details><summary>영문 원문 보기</summary>
38+
39+
> **§4.1.2 Competence**
40+
> The organization shall:
41+
> - Identify the roles and responsibilities that impact the performance and
42+
> effectiveness of the program;
43+
> - Determine the necessary competence of program participants fulfilling
44+
> each role;
45+
> - Ensure that program participants are competent on the basis of appropriate
46+
> education, training, and/or experience;
47+
> - Where applicable, take actions to acquire the necessary competence;
48+
> - Retain appropriate documented information as evidence of competence.
49+
>
50+
> **Verification Material(s):**
51+
> 4.1.2.1 A documented list of roles with corresponding responsibilities for
52+
> the different participants in the program.
53+
> 4.1.2.2 A document that identifies the competencies for each role.
54+
> 4.1.2.3 List of participants and their roles.
55+
> 4.1.2.4 Documented evidence of assessed competence for each program
56+
> participant.
57+
> 4.1.2.5 Documented evidence of periodic reviews and changes to the process.
58+
> 4.1.2.6 Documented evidence that these processes align with and are
59+
> up-to-date with company internal best practices, and that a person has been
60+
> assigned to make sure they remain so.
61+
62+
</details>
63+
64+
## 4. 입증자료별 준수 방법 및 샘플
65+
66+
### 4.1.2.1 역할과 책임 목록 문서
67+
68+
ISO/IEC 5230 §3.1.2.1과 동일하다. 보안 보증 관점에서 보안 담당(DevSecOps,
69+
취약점 분석)의 역할을 명확히 포함해야 한다. 작성 방법은
70+
[§3.1.2.1 역할과 책임 목록 문서](../../iso5230_guide/1-program-foundation/2-competence/)를 참고한다.
71+
72+
---
73+
74+
### 4.1.2.2 역할별 필요 역량 문서
75+
76+
ISO/IEC 5230 §3.1.2.2와 동일하다. 보안 담당 역할에 **CVSS 점수 해석, 취약점
77+
분석 도구(OSV-SCALIBR, Dependency-Track 등) 운용, DevSecOps 이해** 역량을
78+
포함해야 한다. 작성 방법은
79+
[§3.1.2.2 역할별 필요 역량 문서](../../iso5230_guide/1-program-foundation/2-competence/)를 참고한다.
80+
81+
---
82+
83+
### 4.1.2.3 참여자 목록 및 역할 ★
84+
85+
**준수 방법**
86+
87+
4.1.2.1의 역할 목록과 달리, 이 항목은 **실제 인원의 이름**과 그들이 담당하는
88+
역할을 매핑한 목록을 요구한다. 조직도 상의 역할이 아니라 현재 프로그램에
89+
참여하는 실제 담당자가 누구인지를 명확히 하는 것이 목적이다. 인사 변동 시
90+
즉시 갱신해야 한다.
91+
92+
**고려사항**
93+
94+
- **이름 또는 직무명**: 개인 이름 대신 직무명을 사용해도 무방하나, 특정인을
95+
식별할 수 있는 수준이어야 한다.
96+
- **겸임 명시**: 여러 역할을 겸임하는 경우 모든 역할을 기재한다.
97+
- **갱신 즉시성**: 담당자 변경 즉시 문서를 갱신하고 버전을 업데이트한다.
98+
99+
**샘플**
100+
101+
```
102+
| 이름 | 역할 | 연락처 | 지정일 |
103+
|------|------|--------|--------|
104+
| 홍길동 | 오픈소스 프로그램 매니저 | oss@company.com | 2025-01-01 |
105+
| 김철수 | 보안 담당 (DevSecOps) | security@company.com | 2025-01-01 |
106+
| 이영희 | 법무 담당 | legal@company.com | 2025-01-01 |
107+
| 박인프라 | IT 담당 | it@company.com | 2025-03-15 |
108+
```
109+
110+
---
111+
112+
### 4.1.2.4 역량 평가 증거
113+
114+
ISO/IEC 5230 §3.1.2.3과 동일하다. 작성 방법은
115+
[§3.1.2.3 역량 평가 증거](../../iso5230_guide/1-program-foundation/2-competence/)를 참고한다.
116+
117+
---
118+
119+
### 4.1.2.5 주기적 검토 및 프로세스 변경 증거 ★
120+
121+
**준수 방법**
122+
123+
역량 체계(역할 정의, 역량 기준, 평가 방법)를 주기적으로 검토하고, 검토 과정에서
124+
발생한 변경 사항을 기록해야 한다. 새로운 보안 도구 도입, 조직 구조 변경, 취약점
125+
대응 프로세스 개선 등이 역량 체계에 반영되었는지 확인하는 것이 핵심이다. 검토
126+
기록 자체가 입증자료 4.1.2.5다.
127+
128+
**고려사항**
129+
130+
- **검토 주기**: 최소 연 1회 정기 검토를 실시하고, 조직·프로세스 변경 시 즉시
131+
검토한다.
132+
- **변경 이력 기록**: 변경 내용, 변경 이유, 변경 날짜, 변경자를 기록한다.
133+
- **검토 증거 형식**: 검토 회의록, 검토 완료 확인서, 변경 이력 로그 등이
134+
증거로 활용 가능하다.
135+
136+
**샘플**
137+
138+
```
139+
[역량 체계 정기 검토 기록]
140+
141+
| 검토 날짜 | 검토 내용 | 변경 사항 | 검토자 |
142+
|----------|-----------|-----------|--------|
143+
| 2025-01-10 | 전체 역할·역량 검토 | 보안 담당 역량에 CVSS v4.0 해석 항목 추가 | 홍길동 |
144+
| 2026-01-08 | 전체 역할·역량 검토 | Dependency-Track 운용 역량 IT 담당에 추가 | 홍길동 |
145+
```
146+
147+
---
148+
149+
### 4.1.2.6 내부 모범 사례 일치 검증 ★
150+
151+
**준수 방법**
152+
153+
역량 정의 및 평가 프로세스가 회사 내부 모범 사례(HR 정책, 기술 교육 기준 등)와
154+
정합성을 유지하고 있는지 확인하며, 이를 지속적으로 관리하는 담당자를 지정해야
155+
한다. 역량 체계가 산업 표준이나 내부 지침과 괴리되지 않도록 하는 것이 목적이다.
156+
157+
**고려사항**
158+
159+
- **담당자 지정**: 역량 체계의 최신성과 내부 모범 사례 정합성을 관리하는
160+
책임자를 명시적으로 지정하고 기록한다.
161+
- **모범 사례 기준**: 업계 표준(NIST SSDF, ISO 27001 등), 사내 보안 정책,
162+
DevSecOps 가이드라인 등을 모범 사례 기준으로 활용할 수 있다.
163+
164+
**샘플**
165+
166+
```
167+
[내부 모범 사례 정합성 확인서]
168+
169+
역량 체계 관리 담당자: 홍길동 (오픈소스 프로그램 매니저)
170+
마지막 정합성 검토일: 2026-01-08
171+
참조 모범 사례 기준: 사내 보안 교육 기준 v3.0, NIST SSDF 1.1
172+
173+
검토 결과:
174+
- 보안 담당 역량 기준이 사내 보안 교육 커리큘럼과 일치함 ✓
175+
- 취약점 분석 도구 역량이 최신 도구(Dependency-Track v4.x)를 반영함 ✓
176+
- 다음 정합성 검토 예정일: 2027-01-08
177+
```
178+
179+
## 5. 참고
180+
181+
- 대응 ISO/IEC 5230 조항: [§3.1.2 역량](../../iso5230_guide/1-program-foundation/2-competence/)
182+
- 관련 가이드: [기업 오픈소스 관리 가이드 — 1. 조직](../../../opensource_for_enterprise/1-teams/)
183+
- 관련 템플릿: [오픈소스 정책 템플릿 — Appendix 1. 담당자 현황](../../../templates/1-policy/appendix/)

0 commit comments

Comments
 (0)