이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.

§4.2 관련 업무

1: §4.2.1 접근성

2: §4.2.2 효과적 리소스

1 - §4.2.1 접근성

1. 조항 개요

§4.2.1은 ISO/IEC 5230 §3.2.1(외부 문의 대응)과 구조가 동일하지만, 초점이 라이선스 컴플라이언스 문의에서 취약점 문의로 전환된다. 제3자가 공급 소프트웨어에서 알려진 취약점 또는 새로 발견한 취약점에 대해 문의할 수 있는 공개 채널을 마련하고, 내부적으로는 이 문의에 체계적으로 대응하는 절차를 문서화해야 한다. 보안 취약점 보고 채널은 CVD(Coordinated Vulnerability Disclosure) 절차와 연결되어 있으므로, 보안 연구자나 고객이 발견한 취약점을 안전하게 접수하고 처리하는 체계가 필요하다.

2. 해야 할 활동

제3자가 취약점 관련 문의를 보낼 수 있는 공개 연락처(이메일 주소, 웹폼 등)를 제품 또는 웹사이트에 명시한다.
공개 채널을 통해 접수된 취약점 보고를 내부적으로 처리하는 절차를 문서화한다.
문의 접수·분류·담당자 배정·대응·종결까지의 처리 단계를 절차에 포함한다.
CVD 원칙(비공개 협력 후 공개)에 따른 처리 방침을 절차에 명시한다.
문의 접수 및 대응 이력을 기록하고 일정 기간 보관한다.

3. 요구사항 및 입증자료

조항 번호	요구사항 (KO)	입증자료
§4.2.1	외부의 취약점 문의에 효과적으로 대응하기 위한 프로세스를 유지해야 한다. 제3자가 알려진 취약점 또는 새로 발견된 취약점에 대한 문의를 할 수 있는 수단을 공개적으로 밝혀야 한다.	4.2.1.1 제3자가 알려진 취약점 또는 새로 발견된 취약점에 대한 문의를 할 수 있도록 공개적으로 볼 수 있는 방법 (예: 프로그램 참여자가 모니터링하는 이메일 주소 또는 웹 포털) 4.2.1.2 제3자의 알려진 취약점 또는 새로 발견된 취약점 문의에 응답하기 위한 내부 문서화된 절차

영문 원문 보기

§4.2.1 Access Maintain a process to effectively respond to external vulnerability inquiries. Publicly identify a means by which a third party can make an inquiry about known vulnerabilities or newly discovered vulnerabilities.
Verification Material(s): 4.2.1.1 Publicly visible method that allows any third party to make a known vulnerability or newly discovered vulnerability inquiry (e.g., via a published contact email address, or web portal that is monitored by program participants). 4.2.1.2 An internal documented procedure for responding to third party known vulnerability or newly discovered vulnerability inquiries.

4. 입증자료별 준수 방법 및 샘플

4.2.1.1 공개된 취약점 문의 채널

준수 방법

제3자가 취약점을 보고하거나 문의할 수 있는 공개 연락처를 마련하고 외부에 명시해야 한다. 보안 전용 이메일 주소(예: security@company.com)를 제품 문서, 웹사이트 보안 정책 페이지, 또는 SECURITY.md 파일(GitHub 등 오픈소스 저장소)에 게시하는 것이 일반적이다. 이 공개 채널 자체가 입증자료 4.2.1.1이다.

ISO/IEC 5230 §3.2.1.1(라이선스 문의 채널)과 별도로 운영하거나, 보안 취약점 보고 전용 채널을 추가하는 방식으로 구성할 수 있다.

고려사항

보안 전용 채널 분리: 라이선스 문의 채널(oss@company.com)과 보안 취약점 보고 채널(security@company.com)을 분리하여 운영하면 처리 우선순위 관리가 용이하다.
응답 보장: 보고 채널이 실제로 모니터링되고 있음을 명시한다(예: “영업일 기준 3일 이내 수신 확인 응답”).
security.txt 표준 활용: RFC 9116의 security.txt 표준을 적용하면 보안 연구자가 쉽게 연락처를 찾을 수 있다.

샘플

[웹사이트 보안 정책 페이지 / SECURITY.md 샘플]

## 보안 취약점 보고

당사 소프트웨어에서 보안 취약점을 발견하신 경우 아래 채널로 보고해 주십시오.
저희는 책임있는 공개(Coordinated Vulnerability Disclosure) 원칙을 따릅니다.

- 보고 이메일: security@company.com
- 수신 확인: 영업일 기준 3일 이내
- 처리 원칙: 비공개로 취약점을 검토하고 패치 후 공개

Security Vulnerability Reporting

To report a security vulnerability, please contact: security@company.com
We follow Coordinated Vulnerability Disclosure (CVD) practices.

4.2.1.2 내부 취약점 문의 대응 절차

준수 방법

외부에서 취약점 보고가 접수되었을 때 내부적으로 처리하는 절차를 문서화해야 한다. CVD 원칙에 따라 보고자와 비공개로 협력하여 취약점을 해결하고, 패치 준비 후 공개하는 흐름이 기본 골격이 된다. 이 절차 문서가 입증자료 4.2.1.2다.

고려사항

CVD 원칙 준수: 보고자와 협력하여 취약점 해결 전까지 비공개를 유지하고 공개 일정을 합의한다.
처리 기한: 수신 확인, 취약점 검증, 패치 제공, 공개 각 단계별 기한을 절차에 명시한다.
기록 보관: 보고 내용, 검토 과정, 대응 조치, 공개 이력을 최소 3년간 보관한다.

샘플

[외부 취약점 보고 대응 절차]

1. 접수 및 수신 확인 (3영업일 이내)
   - security@company.com 수신함을 매일 확인한다.
   - 보고자에게 수신 확인 및 비공개 처리 약속을 회신한다.

2. 취약점 검증 (7영업일 이내)
   - 보안 담당자가 보고된 취약점의 재현 가능성과 영향 범위를 검증한다.
   - CVSS 점수를 산정하고 심각도를 분류한다.

3. 패치 개발 및 조치 (심각도에 따라 7~90일)
   - §4.1.5 방법 3(후속 조치) 절차에 따라 패치 또는 완화 조치를 수행한다.
   - 필요 시 보고자와 패치 일정을 공유하고 협의한다.

4. 공개 (패치 완료 후)
   - 보안 권고문(Security Advisory)을 작성하고 보고자 확인 후 공개한다.
   - CVE ID 발급을 요청한다 (필요 시).
   - 영향받는 고객에게 §4.1.5 방법 4(고객 통보) 절차에 따라 통보한다.

5. 기록 보관
   - 보고 내용, 검토 과정, 조치 결과, 공개 이력을 최소 3년간 보관한다.

5. 참고

대응 ISO/IEC 5230 조항: §3.2.1 외부 문의 대응
관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스

2 - §4.2.2 효과적 리소스

1. 조항 개요

§4.2.2는 ISO/IEC 5230 §3.2.2(효과적 리소스)에 대응하지만 두 가지 차이가 있다. 첫째, 5230이 5개 입증자료를 요구하는 반면 18974는 4개를 요구한다. 5230의 §3.2.2.5(미준수 사례 검토·시정 절차)가 18974에서는 §4.1.5 표준 관행 구현에 흡수된다. 둘째, §3.2.2.3(법률 자문 접근 방법)이 §4.2.2.3에서는 취약점 해결 전문성으로 대체된다. 라이선스 법률 자문이 아니라, 알려진 취약점을 실제로 해결할 수 있는 기술적·보안 전문성을 확보하고 그 접근 방법을 문서화해야 한다.

2. 해야 할 활동

프로그램 내 각 역할을 담당하는 인원의 이름 또는 직무를 문서에 기재한다.
각 역할 담당자에게 충분한 시간과 예산이 배정되었음을 확인하고 기록한다.
알려진 취약점을 해결하기 위해 이용 가능한 내부 또는 외부 보안 전문성을 식별하고 문서화한다 (5230과 초점이 다름).
보안 보증 컴플라이언스에 대한 내부 책임을 각 역할에 할당하는 절차를 문서화한다.

3. 요구사항 및 입증자료

조항 번호	요구사항 (KO)	입증자료
§4.2.2	프로그램 업무를 식별하고 리소스를 제공한다: 역할별 책임을 할당하고 충분한 리소스를 제공하며, 취약점 해결 전문성에 접근할 수 있는 방법을 확보하고, 내부 책임 할당 절차를 마련한다.	4.2.2.1 프로그램 역할에 지정된 개인, 그룹 또는 기능의 이름이 포함된 문서 4.2.2.2 식별된 프로그램 역할이 적절히 인력 배치되었으며 충분한 예산이 제공되었음을 나타내는 문서 4.2.2.3 식별된 알려진 취약점을 해결하기 위해 이용 가능한 전문성을 명시한 문서 ★ 4.2.2.4 보안 보증을 위해 내부 책임을 할당하는 절차를 문서화한 자료

★ = ISO/IEC 5230 §3.2.2.3(법률 자문)과 다름 — 보안 전문성으로 초점 전환

영문 원문 보기

§4.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.
Verification Material(s): 4.2.2.1 A document with the names of the persons, group or function in program role(s) identified. 4.2.2.2 The identified program roles have been properly staffed and adequate funding provided. 4.2.2.3 A document identifying the expertise available to address identified known vulnerabilities. 4.2.2.4 A documented procedure that assigns internal responsibilities for security assurance.

4. 입증자료별 준수 방법 및 샘플

4.2.2.1 역할 담당자 명시 문서

ISO/IEC 5230 §3.2.2.1과 동일하다. 보안 보증 역할(DevSecOps 엔지니어, 취약점 분석 담당 등)이 명시되어야 한다. 작성 방법은 §3.2.2.1 역할 담당자 명시 문서를 참고한다.

4.2.2.2 인원 배치 및 예산 지원 확인

ISO/IEC 5230 §3.2.2.2와 동일하다. 취약점 스캔 도구, 보안 교육, 외부 보안 컨설팅 등 보안 관련 예산 항목이 포함되어야 한다. 작성 방법은 §3.2.2.2 인원 배치 및 예산 지원 확인을 참고한다.

4.2.2.3 취약점 해결 전문성 명시 문서 ★

준수 방법

알려진 취약점이 식별되었을 때 이를 실제로 분석하고 해결할 수 있는 전문성이 어디에 있는지를 식별하고 문서화해야 한다. 이는 ISO/IEC 5230 §3.2.2.3의 법률 자문 접근 방법과 성격이 다르다. 내부 보안 팀이 있으면 해당 팀의 역량과 연락처를 기록하고, 내부에 전문성이 부족한 경우 외부 보안 전문가 또는 PSIRT(Product Security Incident Response Team) 서비스를 활용하는 방법을 문서화한다.

고려사항

내부 전문성 목록: 취약점 유형별(웹 보안, 펌웨어 보안, 암호화 등) 내부 전문가 또는 담당 팀을 식별한다.
외부 전문성 확보: 내부에 처리하기 어려운 취약점 유형에 대해 외부 보안 전문 기관(CERT, 보안 컨설팅사)과의 계약 또는 연락 방법을 기록한다.
에스컬레이션 기준: 어떤 상황에서 외부 전문성을 활용하는지 기준을 명시한다.

샘플

[취약점 해결 전문성 현황]

내부 전문성:
- 보안 담당 (김철수): 웹 취약점, 오픈소스 컴포넌트 CVE 분석, CVSS 평가
- DevSecOps 팀: CI/CD 보안 파이프라인 운영, 컨테이너 취약점 분석

외부 전문성 활용 기준:
- Zero-day 취약점, 펌웨어 취약점, 암호화 관련 취약점 발생 시
- 내부 팀이 30일 이내 해결 불가능하다고 판단하는 경우

외부 전문 기관:
- [외부 보안 컨설팅사명] (연간 계약, 취약점 분석 서비스)
- KrCERT/CC (취약점 조정 및 신고 채널)

4.2.2.4 내부 책임 할당 절차

ISO/IEC 5230 §3.2.2.4와 동일한 구조이나, 보안 보증에 특화된 책임(취약점 탐지, CVSS 평가, 고객 통보, CVD 관리 등)을 각 역할에 할당하는 절차를 포함해야 한다. 작성 방법은 §3.2.2.4 내부 책임 할당 절차를 참고하되, 아래 샘플처럼 보안 업무를 반영한다.

샘플

| 업무 | 오픈소스 PM | 보안 담당 | IT 담당 | 개발자 |
|------|------------|-----------|---------|--------|
| 취약점 스캔 도구 운영 | I | C | A/R | I |
| CVE 탐지 및 분류 | I | A/R | C | I |
| CVSS 점수 평가 | I | A/R | - | C |
| 패치 적용 및 검증 | C | A | C | R |
| 고객 통보 결정 | A | R | - | I |
| CVD 외부 보고 대응 | C | A/R | - | I |
| 취약점 기록 관리 | I | A/R | C | I |

R: 실행 책임 / A: 최종 책임 / C: 협의 / I: 정보 공유

5. 참고

대응 ISO/IEC 5230 조항: §3.2.2 효과적 리소스
관련 가이드: 기업 오픈소스 관리 가이드 — 1. 조직