From 9b5c78055fea831d140ccef1ed5708db126932e4 Mon Sep 17 00:00:00 2001 From: Haksung Jang Date: Thu, 26 Mar 2026 18:23:36 +0900 Subject: [PATCH] =?UTF-8?q?docs(guide):=20add=20ISO/IEC=2018974=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 18974:2023(버전 1.0)의 11개 조항·25개 입증자료 항목을 모두 작성. ISO/IEC 5230 준수 가이드와 동일한 5섹션 표준 템플릿 사용. 5230 대응 조항은 차이점과 추가 항목에 집중하여 서술하고 교차 링크 포함. - §4.1 프로그램 기반: 정책(검토 프로세스 추가)·역량(3개 항목 추가)· 인식·범위(성과 메트릭·지속 개선 증거)·표준 관행 구현(8가지 취약점 처리) - §4.2 관련 업무: 접근성(취약점 CVD 중심)·효과적 리소스(보안 전문성 전환) - §4.3 콘텐츠 검토: SBOM(수명주기 지속 기록)· 보안 보증(Mermaid 플로우차트 포함, CVE 탐지→조치→모니터링 전 과정) - §4.4 규격 준수: 완전성(25개 체크리스트)·기간 - compare/: ISO/IEC 5230 vs 18974 조항 1:1 대조표 및 동시 준수 전략 Co-Authored-By: Claude Sonnet 4.6 --- .../1-program-foundation/1-policy/_index.md | 153 +++++++++++++ .../2-competence/_index.md | 183 +++++++++++++++ .../3-awareness/_index.md | 98 ++++++++ .../1-program-foundation/4-scope/_index.md | 140 ++++++++++++ .../5-standard-practice/_index.md | 211 ++++++++++++++++++ .../1-program-foundation/_index.md | 8 + .../2-relevant-tasks/1-access/_index.md | 143 ++++++++++++ .../2-relevant-tasks/2-resourced/_index.md | 137 ++++++++++++ .../iso18974_guide/2-relevant-tasks/_index.md | 8 + .../3-content-review/1-sbom/_index.md | 129 +++++++++++ .../2-security-assurance/_index.md | 183 +++++++++++++++ .../iso18974_guide/3-content-review/_index.md | 8 + .../4-conformance/1-completeness/_index.md | 135 +++++++++++ .../4-conformance/2-duration/_index.md | 82 +++++++ .../iso18974_guide/4-conformance/_index.md | 8 + content/ko/guide/iso18974_guide/_index.md | 160 +++++++++++++ .../ko/guide/iso18974_guide/compare/_index.md | 94 ++++++++ 17 files changed, 1880 insertions(+) create mode 100644 content/ko/guide/iso18974_guide/1-program-foundation/1-policy/_index.md create mode 100644 content/ko/guide/iso18974_guide/1-program-foundation/2-competence/_index.md create mode 100644 content/ko/guide/iso18974_guide/1-program-foundation/3-awareness/_index.md create mode 100644 content/ko/guide/iso18974_guide/1-program-foundation/4-scope/_index.md create mode 100644 content/ko/guide/iso18974_guide/1-program-foundation/5-standard-practice/_index.md create mode 100644 content/ko/guide/iso18974_guide/1-program-foundation/_index.md create mode 100644 content/ko/guide/iso18974_guide/2-relevant-tasks/1-access/_index.md create mode 100644 content/ko/guide/iso18974_guide/2-relevant-tasks/2-resourced/_index.md create mode 100644 content/ko/guide/iso18974_guide/2-relevant-tasks/_index.md create mode 100644 content/ko/guide/iso18974_guide/3-content-review/1-sbom/_index.md create mode 100644 content/ko/guide/iso18974_guide/3-content-review/2-security-assurance/_index.md create mode 100644 content/ko/guide/iso18974_guide/3-content-review/_index.md create mode 100644 content/ko/guide/iso18974_guide/4-conformance/1-completeness/_index.md create mode 100644 content/ko/guide/iso18974_guide/4-conformance/2-duration/_index.md create mode 100644 content/ko/guide/iso18974_guide/4-conformance/_index.md create mode 100644 content/ko/guide/iso18974_guide/_index.md create mode 100644 content/ko/guide/iso18974_guide/compare/_index.md diff --git a/content/ko/guide/iso18974_guide/1-program-foundation/1-policy/_index.md b/content/ko/guide/iso18974_guide/1-program-foundation/1-policy/_index.md new file mode 100644 index 000000000..481cbb4c9 --- /dev/null +++ b/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** 문서화된 오픈소스 소프트웨어 보안 보증 정책
**4.1.1.2** 프로그램 참여자가 보안 보증 정책을 인식하도록 하기 위한 문서화된 절차 | + +
영문 원문 보기 + +> **§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. + +
+ +## 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/) diff --git a/content/ko/guide/iso18974_guide/1-program-foundation/2-competence/_index.md b/content/ko/guide/iso18974_guide/1-program-foundation/2-competence/_index.md new file mode 100644 index 000000000..040bb57e2 --- /dev/null +++ b/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** 여러 프로그램 참여자에 대한 해당 책임이 있는 문서화된 역할 목록
**4.1.2.2** 각 역할에 대한 역량을 식별하는 문서
**4.1.2.3** 참여자 목록 및 해당 역할 ★
**4.1.2.4** 각 프로그램 참여자에 대해 평가된 역량에 대한 문서화된 증거
**4.1.2.5** 주기적인 검토 및 프로세스 변경에 대한 문서화된 증거 ★
**4.1.2.6** 이러한 프로세스가 회사 내부 모범 사례와 일치하며 최신 상태를 유지하고 있는지, 그리고 이를 확인하는 담당자가 지정되었는지에 대한 문서화된 증거 ★ | + +★ = ISO/IEC 5230 §3.1.2 대비 추가 항목 + +
영문 원문 보기 + +> **§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. + +
+ +## 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/) diff --git a/content/ko/guide/iso18974_guide/1-program-foundation/3-awareness/_index.md b/content/ko/guide/iso18974_guide/1-program-foundation/3-awareness/_index.md new file mode 100644 index 000000000..966baa762 --- /dev/null +++ b/content/ko/guide/iso18974_guide/1-program-foundation/3-awareness/_index.md @@ -0,0 +1,98 @@ +--- +title: "§4.1.3 인식" +weight: 30 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 18974", "인식"] +description: > +--- + +## 1. 조항 개요 + +§4.1.3은 ISO/IEC 5230 §3.1.3(인식)과 입증자료 구조가 동일하다. 프로그램 +참여자가 프로그램의 목표, 자신의 기여 방법, 미준수 시 발생하는 영향을 인식하고 +있음을 평가하고 기록하도록 요구한다. 5230과의 차이는 인식 평가의 **초점이 +보안 보증**으로 전환된다는 점이다. 참여자는 라이선스 컴플라이언스뿐 아니라 +취약점 관리 프로세스, CVD 절차, CVSS 기반 대응 기준을 인식하고 있어야 한다. + +## 2. 해야 할 활동 + +- 프로그램 참여자가 오픈소스 보안 보증 프로그램의 목표(취약점 탐지·평가· + 대응·통보)를 이해하고 있는지 확인한다. +- 각 참여자가 자신의 역할이 보안 보증 체계에 어떻게 기여하는지 인식하고 있는지 + 평가한다. +- 취약점 대응 프로세스를 미준수할 경우 발생하는 법적·사업적·보안적 영향에 + 대한 인식을 평가한다. +- 인식 평가 결과를 문서로 기록하고 보관한다. +- 미흡한 참여자에 대해 추가 교육을 실시하고 재평가 결과를 보관한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §4.1.3 | 조직은 프로그램 참여자가 다음 사항을 인식하도록 해야 한다: 보안 보증 정책의 존재와 위치 / 보안 보증 관련 목표 / 프로그램 효과에 대한 자신의 기여 방법 / 프로그램 요구사항을 따르지 않을 경우 발생하는 영향 | **4.1.3.1** 프로그램 목표, 프로그램 내에서의 개인 기여, 프로그램 미준수의 영향 등이 포함되어야 하는 프로그램 참여자에 대한 평가된 인식에 대한 문서화된 증거 | + +
영문 원문 보기 + +> **§4.1.3 Awareness** +> The organization shall ensure that the program participants are aware of: +> - The open source software security assurance policy and where to find it; +> - Relevant open source software security assurance objectives; +> - Their contribution to the effectiveness of the program; and +> - The implications of not following the program's requirements. +> +> **Verification Material(s):** +> 4.1.3.1 Documented evidence of assessed awareness for the program +> participants - which shall include the program's objectives, contributions +> within the program, and implications of failing to follow the program's +> requirements. + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 4.1.3.1 참여자 인식 평가 증거 + +**준수 방법** + +ISO/IEC 5230 §3.1.3.1과 기본 방법은 동일하나, 인식 평가 문항이 **보안 보증**에 +초점을 두어야 한다. 세 가지 핵심 인식 항목은 ①보안 보증 프로그램의 목표(취약점 +식별·평가·대응·CVD), ②자신의 역할이 보안 체계에 기여하는 방법, ③프로세스 +미준수 시 발생하는 보안·법적·사업적 위험이다. + +평가 결과를 문서로 기록하고 보관하는 방법은 5230과 동일하다. 최소 연 1회 +정기 평가를 실시하고, 신규 참여자는 합류 즉시 초기 평가를 수행한다. + +**고려사항** + +- **보안 특화 문항 설계**: 취약점 대응 절차, CVSS 기준, CVD 방침 등 보안 + 보증 고유의 내용을 평가 문항에 포함한다. +- **역할별 심화 평가**: 보안 담당자는 기술적 취약점 분석 인식까지 평가하고, + 개발자는 안전한 코딩 관행 인식을 함께 평가한다. +- **평가 주기 및 증거 보관**: 최소 연 1회, 신규 참여자 합류 즉시 평가를 + 실시하고 결과를 최소 3년간 보관한다. + +**샘플** + +아래는 보안 보증 관점의 정책 인식 확인서 샘플이다. + +``` +[오픈소스 보안 보증 정책 인식 확인서] + +본인은 다음 사항을 숙지하였음을 확인합니다: + +1. 당사 오픈소스 보안 보증 정책의 존재와 해당 문서의 위치 +2. 오픈소스 컴포넌트 취약점 탐지·평가·대응·CVD 프로그램의 목표 +3. 본인의 역할이 보안 보증 프로그램 운영에 기여하는 방법 +4. 취약점 대응 프로세스를 준수하지 않을 경우 발생할 수 있는 + 보안 침해, 법적 책임, 사업적 위험 + +이름: ________________ 역할: ________________ +서명: ________________ 날짜: ________________ +``` + +## 5. 참고 + +- 대응 ISO/IEC 5230 조항: [§3.1.3 인식](../../iso5230_guide/1-program-foundation/3-awareness/) +- 관련 가이드: [기업 오픈소스 관리 가이드 — 5. 교육](../../../opensource_for_enterprise/5-training/) +- 관련 템플릿: [오픈소스 정책 템플릿 — §6 교육 및 인식 제고](../../../templates/1-policy/) diff --git a/content/ko/guide/iso18974_guide/1-program-foundation/4-scope/_index.md b/content/ko/guide/iso18974_guide/1-program-foundation/4-scope/_index.md new file mode 100644 index 000000000..01c5bad17 --- /dev/null +++ b/content/ko/guide/iso18974_guide/1-program-foundation/4-scope/_index.md @@ -0,0 +1,140 @@ +--- +title: "§4.1.4 프로그램 범위" +weight: 40 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 18974", "프로그램 범위"] +description: > +--- + +## 1. 조항 개요 + +§4.1.4는 ISO/IEC 5230 §3.1.4(프로그램 범위)에 입증자료 2건이 추가된 조항이다. +5230이 프로그램 적용 범위를 명확히 정의한 진술만 요구하는 반면, 18974는 +여기에 **프로그램이 달성해야 하는 성과 메트릭(4.1.4.2)** 과 **지속적 개선을 +입증하는 검토·감사 증거(4.1.4.3)** 를 추가로 요구한다. 이 두 항목은 보안 +보증 프로그램이 정적인 규정 준수에 그치지 않고 측정 가능한 목표를 가지고 +지속적으로 개선되는 체계임을 입증하기 위한 것이다. + +## 2. 해야 할 활동 + +- 프로그램 적용 범위(대상 소프트웨어, 조직 단위, 제외 항목)를 명확히 정의한 + 문서화된 진술을 작성한다 (5230과 동일). +- **프로그램이 개선하기 위해 달성해야 하는 성과 메트릭을 정의한다** (18974 추가). +- **정기 검토·업데이트·감사를 통해 지속적 개선이 이루어지고 있음을 증명하는 + 기록을 유지한다** (18974 추가). +- 메트릭 목표 대비 실적을 주기적으로 측정하고 기록한다. +- 개선 필요 사항을 도출하고 후속 조치 이력을 문서화한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §4.1.4 | 프로그램의 적용 범위가 명확하게 정의되어야 하며, 프로그램 개선을 위한 메트릭과 지속적 개선 증거를 유지해야 한다. | **4.1.4.1** 프로그램의 범위와 제한 사항을 명확하게 정의하는 서면 진술
**4.1.4.2** 프로그램이 개선하기 위해 달성해야 하는 메트릭 세트 ★
**4.1.4.3** 지속적인 개선을 입증하기 위한 각 검토, 업데이트 또는 감사에서 얻은 문서화된 증거 ★ | + +★ = ISO/IEC 5230 §3.1.4 대비 추가 항목 + +
영문 원문 보기 + +> **§4.1.4 Program Scope** +> Different programs may be designed to address different scopes depending on +> the supplier's needs and business model. The scope needs to be clear. +> +> **Verification Material(s):** +> 4.1.4.1 A written statement that clearly defines the scope and limits of +> the program. +> 4.1.4.2 A set of metrics the program seeks to improve upon. +> 4.1.4.3 Documented evidence from each review, update, or audit to +> demonstrate continuous improvement. + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 4.1.4.1 프로그램 적용 범위 진술 + +ISO/IEC 5230 §3.1.4.1과 동일하다. 작성 방법은 +[§3.1.4.1 프로그램 적용 범위 진술](../../iso5230_guide/1-program-foundation/4-scope/)을 참고한다. +보안 보증 관점에서 "알려진 취약점 및 새로 발견된 취약점 대응"이 적용 범위 +내에 포함됨을 명시한다. + +--- + +### 4.1.4.2 성과 메트릭 세트 ★ + +**준수 방법** + +보안 보증 프로그램이 개선하고자 하는 성과 메트릭을 정의하고 문서화해야 한다. +메트릭은 측정 가능하고 현실적이어야 하며, 프로그램의 주요 목표(취약점 탐지율, +대응 시간, SBOM 완전성 등)와 연결되어야 한다. 메트릭 세트 자체가 입증자료 +4.1.4.2다. + +**고려사항** + +- **측정 가능성**: 정성적 서술보다 수치 기반 지표를 설정한다. +- **현실적 목표**: 초기에는 달성 가능한 수준으로 목표를 설정하고 점진적으로 + 높인다. +- **주기적 측정**: 메트릭을 최소 분기별로 측정하고 결과를 기록한다. + +**샘플** + +``` +[보안 보증 프로그램 성과 메트릭] + +| 메트릭 | 측정 방법 | 목표 | 측정 주기 | +|--------|-----------|------|-----------| +| SBOM 완전성 | 배포 소프트웨어 중 SBOM 보유 비율 | 100% | 분기 | +| Critical 취약점 평균 대응 시간 | 탐지일~패치 적용일 | 7일 이하 | 분기 | +| High 취약점 평균 대응 시간 | 탐지일~패치 적용일 | 30일 이하 | 분기 | +| 취약점 재발생률 | 동일 컴포넌트 재취약점 비율 | 10% 이하 | 반기 | +| 신규 참여자 인식 평가 완료율 | 입사 30일 이내 평가 완료 비율 | 100% | 분기 | +| 외부 취약점 문의 응답 준수율 | 14일 이내 응답 완료 비율 | 95% 이상 | 분기 | +``` + +--- + +### 4.1.4.3 지속적 개선 증거 ★ + +**준수 방법** + +정기 검토, 프로세스 업데이트, 내부 감사 등을 통해 보안 보증 프로그램이 실제로 +개선되고 있음을 보여주는 기록을 유지해야 한다. 각 검토·감사 시마다 발견된 +문제점, 수행된 개선 조치, 개선 결과를 문서화한다. 이 기록 자체가 입증자료 +4.1.4.3이다. + +**고려사항** + +- **정기 감사 일정**: 최소 연 1회 전체 프로그램 감사를 실시하고 결과를 + 기록한다. +- **개선 이력 추적**: 이전 감사에서 제기된 문제가 다음 감사에서 해결되었는지 + 추적하여 기록한다. +- **메트릭 연계**: 4.1.4.2에서 정의한 메트릭의 실적 추이를 개선 증거로 + 활용한다. + +**샘플** + +``` +[보안 보증 프로그램 정기 검토 기록] + +검토 날짜: 2026-01-10 +검토자: 홍길동 (오픈소스 프로그램 매니저), 김철수 (보안 담당) + +메트릭 실적: +- SBOM 완전성: 97% → 100% (목표 달성) +- Critical 취약점 평균 대응 시간: 9일 → 6일 (목표 달성) +- High 취약점 평균 대응 시간: 35일 → 28일 (목표 달성) + +발견된 개선 사항: +1. 외부 취약점 문의 응답 준수율 88% → 95% 목표 미달 + 조치: 문의 모니터링 담당자 추가 지정 (2026-02-01 완료) +2. 신규 참여자 인식 평가 지연 사례 발생 + 조치: 온보딩 체크리스트에 인식 평가 필수 항목 추가 (2026-01-20 완료) + +다음 검토 예정일: 2027-01-09 +``` + +## 5. 참고 + +- 대응 ISO/IEC 5230 조항: [§3.1.4 프로그램 범위](../../iso5230_guide/1-program-foundation/4-scope/) +- 관련 가이드: [기업 오픈소스 관리 가이드 — 2. 정책](../../../opensource_for_enterprise/2-policy/) +- 관련 템플릿: [오픈소스 정책 템플릿 — §1.4 적용 범위](../../../templates/1-policy/) diff --git a/content/ko/guide/iso18974_guide/1-program-foundation/5-standard-practice/_index.md b/content/ko/guide/iso18974_guide/1-program-foundation/5-standard-practice/_index.md new file mode 100644 index 000000000..f85f14e2d --- /dev/null +++ b/content/ko/guide/iso18974_guide/1-program-foundation/5-standard-practice/_index.md @@ -0,0 +1,211 @@ +--- +title: "§4.1.5 표준 관행 구현" +weight: 50 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 18974", "표준 관행", "취약점 대응"] +description: > +--- + +## 1. 조항 개요 + +§4.1.5는 ISO/IEC 5230에 없는 18974 전용 신규 조항이다. 오픈소스 취약점을 +다루는 **8가지 표준 처리 방법** 각각에 대해 문서화된 절차를 수립하도록 요구한다. +이 조항은 단순히 취약점에 "대응한다"는 선언을 넘어, 위협 식별·탐지·후속 조치· +고객 통보·배포 후 모니터링·지속적 보안 테스트·위험 검증·정보 수출까지 전체 +취약점 생명주기를 절차로 명문화할 것을 요구한다. 이 조항은 §4.3.2 보안 보증과 +함께 ISO/IEC 18974의 핵심을 이룬다. + +## 2. 해야 할 활동 + +8가지 방법 각각에 대한 문서화된 절차를 수립한다: + +1. **구조적·기술적 위협 식별**: 공급 소프트웨어에 영향을 미치는 위협을 식별하는 + 방법을 정의한다. +2. **알려진 취약점 탐지**: 오픈소스 컴포넌트의 알려진 취약점(CVE) 존재를 + 탐지하는 방법을 정의한다. +3. **취약점 후속 조치**: 식별된 취약점에 대해 패치·완화·수용 등 후속 조치를 + 취하는 방법을 정의한다. +4. **고객 통보**: 해당되는 경우 식별된 취약점을 고객에게 전달하는 방법을 정의한다. +5. **배포 후 신규 취약점 분석**: 출시 후 새로 공개된 CVE에 대해 기배포 소프트웨어를 + 분석하는 방법을 정의한다. +6. **지속적 보안 테스트**: 출시 전 모든 소프트웨어에 지속적·반복적 보안 테스트를 + 적용하는 방법을 정의한다. +7. **위험 해결 검증**: 식별된 위험이 출시 전에 해결되었는지 검증하는 방법을 + 정의한다. +8. **위험 정보 수출**: 적절한 경우 제3자에게 위험 정보를 내보내는 방법을 정의한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §4.1.5 | 프로그램은 알려진 취약점의 건전하고 견고한 처리 절차와 보안 소프트웨어 개발을 다음 8가지를 정의하고 구현하여 시연해야 한다: 위협 식별 / 취약점 탐지 / 후속 조치 / 고객 통보 / 배포 후 신규 취약점 분석 / 지속적 보안 테스트 / 위험 해결 검증 / 위험 정보 수출 | **4.1.5.1** 위에 식별된 각 방법에 대한 문서화된 절차가 존재 | + +
영문 원문 보기 + +> **§4.1.5 Standard Practice Implementation** +> A program shall demonstrate defined and implemented processes for sound and +> robust handling of known vulnerabilities and security software development, +> specifically by defining and implementing the following: +> - A method to identify structural and technical threats to the supplied +> software; +> - A method to detect the existence of known vulnerabilities in the supplied +> software; +> - A method to follow up on identified known vulnerabilities; +> - A method to communicate identified known vulnerabilities to customers, +> where applicable; +> - A method to analyze the supplied software for newly disclosed known +> vulnerabilities when they are published; +> - A method to apply continuous and iterative security testing to all +> supplied software before release; +> - A method to verify that identified risks have been addressed before +> release; and +> - A method to export information about identified risks to third parties, +> where appropriate. +> +> **Verification Material(s):** +> 4.1.5.1 A documented procedure exists for each of the methods identified +> above. + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 4.1.5.1 8가지 취약점 처리 방법에 대한 문서화된 절차 + +**준수 방법** + +8가지 방법 각각에 대해 "어떻게 수행하는가"를 설명하는 절차를 문서화해야 한다. +이 절차들이 모여 입증자료 4.1.5.1을 구성한다. 별도의 8개 문서를 작성할 수도 +있고, 하나의 통합 취약점 관리 절차 문서 안에 8개 섹션으로 구성할 수도 있다. +후자가 관리 부담이 적고 일관성을 유지하기 쉬운 방식이다. + +**방법 1 — 구조적·기술적 위협 식별** + +공급 소프트웨어에 영향을 미칠 수 있는 구조적(아키텍처 설계, 의존성 구조) 및 +기술적(알려진 취약 패턴, 위험 컴포넌트) 위협을 식별하는 방법을 정의한다. +위협 모델링(STRIDE, PASTA 등)을 활용하거나, 정기적으로 의존성 트리를 분석하여 +위험 컴포넌트를 식별하는 방식이 일반적이다. + +``` +[위협 식별 절차 개요] +- 신규 소프트웨어 아키텍처 설계 시 위협 모델링을 수행한다. +- 분기별로 의존성 트리를 분석하여 EOL(End-of-Life) 컴포넌트, + 유지보수 중단 프로젝트, 높은 의존성 집중도를 가진 컴포넌트를 식별한다. +- 식별된 위협은 위험 레지스트리(Risk Registry)에 등록하고 담당자를 배정한다. +``` + +**방법 2 — 알려진 취약점 탐지** + +SBOM을 기반으로 오픈소스 컴포넌트의 CVE(Common Vulnerabilities and Exposures) +존재 여부를 탐지하는 방법을 정의한다. 자동화 도구(OSV-SCALIBR, Dependency-Track, +Grype 등)를 CI/CD 파이프라인에 통합하여 빌드 시마다 취약점을 스캔하는 것이 +효과적이다. + +``` +[취약점 탐지 절차 개요] +- CI/CD 파이프라인에 SCA(Software Composition Analysis) 도구를 통합한다. +- 빌드마다 SBOM 기반 취약점 스캔을 자동 실행한다. +- OSV(Open Source Vulnerabilities), NVD(National Vulnerability Database), + GitHub Advisory Database 등 복수의 취약점 데이터베이스를 참조한다. +- 탐지된 취약점은 심각도와 함께 보안 담당자에게 자동 알림 발송한다. +``` + +**방법 3 — 취약점 후속 조치** + +식별된 취약점에 대해 패치 적용, 완화 조치, 컴포넌트 교체, 위험 수용 등 후속 +조치를 취하는 방법을 정의한다. CVSS 점수 기반 우선순위와 조치 기한을 절차에 +명시한다. + +``` +[후속 조치 절차 개요] +- CVSS 점수에 따라 조치 우선순위와 기한을 결정한다: + Critical(9.0+): 7일 이내 / High(7.0-8.9): 30일 이내 + Medium(4.0-6.9): 90일 이내 / Low(0.1-3.9): 다음 릴리스 시 +- 패치가 없는 경우 완화 조치(네트워크 격리, WAF 규칙 추가 등)를 수행하고 + 위험 수용 결정은 보안 담당자 + 오픈소스 PM이 공동 승인한다. +- 조치 결과를 취약점 추적 시스템에 기록하고 완료 여부를 검증한다. +``` + +**방법 4 — 고객 통보** + +공급한 소프트웨어에서 취약점이 발견되어 고객에게 영향을 미칠 수 있는 경우 +이를 고객에게 전달하는 방법을 정의한다. 고객 통보 기준(심각도, 고객 영향 범위), +통보 채널, 통보 기한을 절차에 명시한다. + +``` +[고객 통보 절차 개요] +- Critical/High 취약점 중 고객 배포 제품에 영향을 미치는 경우 통보한다. +- 통보 채널: 제품 보안 공지(웹사이트), 고객사 담당자 이메일, 보안 권고문 발행 +- 통보 기한: 패치 또는 완화 조치 확정 후 7일 이내 +- 통보 내용: 영향받는 컴포넌트, CVE ID, 심각도, 권장 조치, 패치 제공 일정 +``` + +**방법 5 — 배포 후 신규 취약점 분석** + +이미 배포된 소프트웨어에 대해 새로 공개된 CVE가 영향을 미치는지 분석하는 방법을 +정의한다. 배포된 소프트웨어의 SBOM을 보관하고, 신규 CVE 발행 시 해당 컴포넌트 +포함 여부를 자동 대조하는 모니터링 체계가 필요하다. + +``` +[배포 후 신규 취약점 분석 절차 개요] +- 배포된 소프트웨어의 SBOM을 버전별로 보관한다. +- Dependency-Track 등 도구를 활용하여 신규 CVE 발행 시 기배포 SBOM과 + 자동 대조하고 영향을 받는 소프트웨어 버전 목록을 생성한다. +- 영향받는 버전이 확인된 경우 방법 3(후속 조치)과 방법 4(고객 통보) 절차에 + 따라 처리한다. +- 모니터링은 상시 자동 수행하며, 주간 요약 보고를 보안 담당자에게 발송한다. +``` + +**방법 6 — 지속적 보안 테스트** + +출시 전 모든 공급 소프트웨어에 지속적이고 반복적인 보안 테스트를 적용하는 +방법을 정의한다. SAST(Static Application Security Testing), DAST(Dynamic +Application Security Testing), SCA를 CI/CD 파이프라인에 통합하는 것이 +일반적인 방식이다. + +``` +[지속적 보안 테스트 절차 개요] +- CI/CD 파이프라인 단계별 보안 테스트: + · 코드 커밋 시: SAST(정적 분석), SCA(오픈소스 취약점 스캔) + · PR 머지 시: 보안 게이트 통과 여부 확인 (Critical/High 미해결 시 블로킹) + · 릴리스 후보 빌드: DAST(동적 분석), 컨테이너 이미지 스캔 +- 보안 테스트 실패 시 릴리스를 자동 차단하고 보안 담당자에게 알림 발송한다. +- 테스트 커버리지와 결과를 대시보드에서 지속 모니터링한다. +``` + +**방법 7 — 위험 해결 검증** + +식별된 위험이 출시 전에 실제로 해결되었는지 검증하는 방법을 정의한다. 패치 +적용 후 재스캔을 통해 취약점이 제거되었음을 확인하고 그 결과를 기록해야 한다. + +``` +[위험 해결 검증 절차 개요] +- 패치 또는 완화 조치 완료 후 동일 도구로 재스캔을 실행한다. +- 재스캔 결과 취약점이 제거되었음을 확인하고 취약점 추적 시스템에 기록한다. +- Critical/High 취약점의 경우 보안 담당자가 검증 결과를 승인한다. +- 위험이 해결되지 않은 채 출시하는 경우 경영진 승인과 완화 계획을 문서화한다. +``` + +**방법 8 — 위험 정보 수출** + +적절한 경우 식별된 위험 정보를 제3자(공급망 파트너, 고객, 취약점 데이터베이스 +등)에게 내보내는 방법을 정의한다. VEX(Vulnerability Exploitability eXchange) +형식을 활용하거나, CVD 채널을 통해 상류 프로젝트에 취약점 정보를 제보하는 +절차가 여기에 해당한다. + +``` +[위험 정보 수출 절차 개요] +- 자체적으로 새로운 취약점을 발견한 경우 CVD 절차에 따라 상류 프로젝트 + 또는 CERT에 보고한다. +- 공급망 파트너에게 취약점 영향 정보를 공유할 때는 VEX 형식을 사용한다. +- 제3자 공유 전 법무 담당의 검토를 거쳐 영업 비밀 또는 미공개 정보가 + 포함되지 않도록 확인한다. +- 정보 수출 이력(대상, 날짜, 내용 요약)을 기록하고 보관한다. +``` + +## 5. 참고 + +- ISO/IEC 5230 대응 조항 없음 (18974 전용 신규 조항) +- 관련 가이드: [기업 오픈소스 관리 가이드 — 3. 프로세스](../../../opensource_for_enterprise/3-process/) +- 관련 도구: [OSV-SCALIBR](../../../tools/4-osvscalibr/), [Dependency-Track](../../../tools/7-dependency-track/) diff --git a/content/ko/guide/iso18974_guide/1-program-foundation/_index.md b/content/ko/guide/iso18974_guide/1-program-foundation/_index.md new file mode 100644 index 000000000..96dfdefba --- /dev/null +++ b/content/ko/guide/iso18974_guide/1-program-foundation/_index.md @@ -0,0 +1,8 @@ +--- +title: "§4.1 프로그램 기반" +weight: 10 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 18974"] +description: > +--- diff --git a/content/ko/guide/iso18974_guide/2-relevant-tasks/1-access/_index.md b/content/ko/guide/iso18974_guide/2-relevant-tasks/1-access/_index.md new file mode 100644 index 000000000..3f48724fd --- /dev/null +++ b/content/ko/guide/iso18974_guide/2-relevant-tasks/1-access/_index.md @@ -0,0 +1,143 @@ +--- +title: "§4.2.1 접근성" +weight: 10 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 18974", "외부 문의"] +description: > +--- + +## 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 외부 문의 대응](../../iso5230_guide/2-relevant-tasks/1-access/) +- 관련 가이드: [기업 오픈소스 관리 가이드 — 3. 프로세스](../../../opensource_for_enterprise/3-process/) diff --git a/content/ko/guide/iso18974_guide/2-relevant-tasks/2-resourced/_index.md b/content/ko/guide/iso18974_guide/2-relevant-tasks/2-resourced/_index.md new file mode 100644 index 000000000..0b109c4d8 --- /dev/null +++ b/content/ko/guide/iso18974_guide/2-relevant-tasks/2-resourced/_index.md @@ -0,0 +1,137 @@ +--- +title: "§4.2.2 효과적 리소스" +weight: 20 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 18974", "리소스"] +description: > +--- + +## 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 역할 담당자 명시 문서](../../iso5230_guide/2-relevant-tasks/2-resourced/)를 참고한다. + +--- + +### 4.2.2.2 인원 배치 및 예산 지원 확인 + +ISO/IEC 5230 §3.2.2.2와 동일하다. 취약점 스캔 도구, 보안 교육, 외부 보안 +컨설팅 등 보안 관련 예산 항목이 포함되어야 한다. 작성 방법은 +[§3.2.2.2 인원 배치 및 예산 지원 확인](../../iso5230_guide/2-relevant-tasks/2-resourced/)을 참고한다. + +--- + +### 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 내부 책임 할당 절차](../../iso5230_guide/2-relevant-tasks/2-resourced/)를 참고하되, 아래 샘플처럼 보안 업무를 반영한다. + +**샘플** + +``` +| 업무 | 오픈소스 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 효과적 리소스](../../iso5230_guide/2-relevant-tasks/2-resourced/) +- 관련 가이드: [기업 오픈소스 관리 가이드 — 1. 조직](../../../opensource_for_enterprise/1-teams/) diff --git a/content/ko/guide/iso18974_guide/2-relevant-tasks/_index.md b/content/ko/guide/iso18974_guide/2-relevant-tasks/_index.md new file mode 100644 index 000000000..0b299767c --- /dev/null +++ b/content/ko/guide/iso18974_guide/2-relevant-tasks/_index.md @@ -0,0 +1,8 @@ +--- +title: "§4.2 관련 업무" +weight: 20 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 18974"] +description: > +--- diff --git a/content/ko/guide/iso18974_guide/3-content-review/1-sbom/_index.md b/content/ko/guide/iso18974_guide/3-content-review/1-sbom/_index.md new file mode 100644 index 000000000..582b50bb7 --- /dev/null +++ b/content/ko/guide/iso18974_guide/3-content-review/1-sbom/_index.md @@ -0,0 +1,129 @@ +--- +title: "§4.3.1 SBOM" +weight: 10 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 18974", "SBOM"] +description: > +--- + +## 1. 조항 개요 + +§4.3.1은 ISO/IEC 5230 §3.3.1(SBOM)과 기본 구조는 동일하지만, 강조점이 +다르다. 5230은 오픈소스 컴포넌트의 라이선스 관리를 위한 SBOM을 다루는 반면, +18974의 §4.3.1은 **소프트웨어 수명주기 전반에 걸쳐 지속적으로 SBOM을 +기록하고 보관**하는 것을 강조한다. 특히 배포 후에도 SBOM을 유지하여 §4.3.2 +보안 보증의 취약점 모니터링과 연계되어야 한다. SBOM이 없으면 배포 후 새로 +공개된 CVE에 대한 영향 분석(§4.1.5 방법 5)을 수행할 수 없다. + +## 2. 해야 할 활동 + +- 공급 소프트웨어의 오픈소스 컴포넌트를 식별·추적·검토·승인하는 절차를 + 수립한다 (5230과 동일). +- **소프트웨어 수명주기 동안 지속적으로 SBOM을 기록하고 보관하는 절차**를 + 수립한다 (18974 강조 사항). +- 배포된 소프트웨어 버전별로 SBOM을 보관하여 배포 후 취약점 영향 분석에 + 활용한다. +- SBOM 정보를 취약점 관리 도구(Dependency-Track 등)와 연동하여 신규 CVE + 발행 시 자동으로 영향 분석이 이루어지도록 구성한다. +- 컴포넌트 추가·변경·제거 시 SBOM을 즉시 갱신하는 트리거를 정의한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §4.3.1 | 공급 소프트웨어에 사용되는 모든 오픈소스 소프트웨어가 공급 소프트웨어의 수명주기 동안 지속적으로 기록되도록 보장하는 프로세스가 있어야 한다. | **4.3.1.1** 공급 소프트웨어에 사용되는 모든 오픈소스 소프트웨어가 공급 소프트웨어의 수명주기 동안 지속적으로 기록되도록 보장하는 문서화된 절차 (아카이브 포함)
**4.3.1.2** 문서화된 절차가 올바르게 수행되었음을 입증하는 공급 소프트웨어에 대한 오픈소스 소프트웨어 컴포넌트 기록 | + +
영문 원문 보기 + +> **§4.3.1 Software Bill of Materials** +> A process shall exist for creating and managing a software bill of materials +> that includes each open source software component (and its identified +> licenses) from which the supplied software is comprised, in a manner that +> ensures the supplied software's open source software components are +> continuously recorded throughout the supplied software's life cycle, +> including archiving. +> +> **Verification Material(s):** +> 4.3.1.1 A documented procedure to ensure that all open source software used +> in the supplied software is continuously recorded during the life cycle of +> the supplied software. This includes an archive of all open source software +> used in the supplied software. +> 4.3.1.2 Open source software component records for the supplied software +> that demonstrates the documented procedure was followed. + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 4.3.1.1 SBOM 수명주기 지속 기록 절차 + +**준수 방법** + +ISO/IEC 5230 §3.3.1.1의 SBOM 관리 절차를 기반으로 하되, **수명주기 지속 +기록**과 **아카이브**에 초점을 맞춰 절차를 보강해야 한다. 이 절차 문서가 +입증자료 4.3.1.1이다. + +보안 보증 관점에서 SBOM 관리의 핵심은 배포 후에도 SBOM이 유효하게 유지되어 +신규 CVE 발행 시 즉시 영향 분석에 활용될 수 있어야 한다는 점이다. 이를 위해 +배포된 모든 소프트웨어 버전의 SBOM을 아카이브하고, 취약점 관리 도구와 연동하는 +절차를 포함해야 한다. + +**고려사항** + +- **수명주기 단계별 SBOM 유지**: 개발·빌드·배포·배포 후 모니터링 각 단계에서 + SBOM이 최신 상태를 유지하도록 절차를 정의한다. +- **아카이브 정책**: 배포된 모든 버전의 SBOM을 버전별로 아카이브하고 보관 + 기간을 명시한다(최소 해당 소프트웨어 지원 기간 + 3년). +- **취약점 도구 연동**: Dependency-Track 등에 SBOM을 임포트하여 신규 CVE가 + 발행될 때마다 자동 대조가 이루어지도록 설정한다. +- **갱신 트리거**: 컴포넌트 추가·업그레이드·제거, 라이선스 변경, 새로운 취약점 + 발견 시 SBOM 갱신을 의무화한다. + +**샘플** + +아래는 보안 보증 관점으로 강화된 SBOM 관리 절차 개요 샘플이다. + +``` +[SBOM 수명주기 관리 절차 개요] + +(1) 개발 단계 + - 오픈소스 컴포넌트 도입 시 즉시 SBOM에 등록한다. + - CI/CD 파이프라인 SCA 도구(Syft, cdxgen 등)가 자동 탐지한다. + +(2) 빌드 단계 + - 빌드마다 최신 SBOM을 자동 생성한다 (SPDX 또는 CycloneDX 형식). + - 취약점 스캔 도구와 연동하여 빌드 시점 취약점 현황을 기록한다. + +(3) 배포 단계 + - 릴리스 버전의 SBOM을 확정하고 아카이브 저장소에 보관한다. + - Dependency-Track에 SBOM을 임포트하여 지속 모니터링을 활성화한다. + +(4) 배포 후 모니터링 + - 신규 CVE 발행 시 아카이브된 모든 버전 SBOM과 자동 대조한다. + - 영향받는 버전이 확인되면 §4.1.5 방법 5 절차에 따라 처리한다. + +(5) 갱신 트리거 + - 다음 이벤트 발생 시 SBOM을 즉시 갱신한다: + · 컴포넌트 추가, 버전 업그레이드, 컴포넌트 제거 + · 라이선스 변경, 새로운 취약점 발견으로 인한 대체 + +(6) 아카이브 보관 + - 배포된 모든 버전의 SBOM을 버전별로 보관한다. + - 보관 기간: 해당 소프트웨어 공식 지원 종료 후 최소 3년 +``` + +--- + +### 4.3.1.2 오픈소스 컴포넌트 기록 (SBOM) + +ISO/IEC 5230 §3.3.1.2와 동일하다. 보안 보증 관점에서 SBOM에는 라이선스 정보 +외에 각 컴포넌트의 **알려진 취약점 현황** 또는 취약점 관리 도구 링크를 함께 +기록하면 §4.3.2와 연계가 용이하다. 작성 방법은 +[§3.3.1.2 오픈소스 컴포넌트 기록](../../iso5230_guide/3-content-review/1-sbom/)을 참고한다. + +## 5. 참고 + +- 대응 ISO/IEC 5230 조항: [§3.3.1 SBOM](../../iso5230_guide/3-content-review/1-sbom/) +- 관련 가이드: [기업 오픈소스 관리 가이드 — 3. 프로세스](../../../opensource_for_enterprise/3-process/) +- 관련 도구: [Syft](../../../tools/6-syft/), [cdxgen](../../../tools/5-cdxgen/), [Dependency-Track](../../../tools/7-dependency-track/) diff --git a/content/ko/guide/iso18974_guide/3-content-review/2-security-assurance/_index.md b/content/ko/guide/iso18974_guide/3-content-review/2-security-assurance/_index.md new file mode 100644 index 000000000..2c10bca03 --- /dev/null +++ b/content/ko/guide/iso18974_guide/3-content-review/2-security-assurance/_index.md @@ -0,0 +1,183 @@ +--- +title: "§4.3.2 보안 보증" +weight: 20 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 18974", "보안 보증", "취약점", "CVE"] +description: > +--- + +## 1. 조항 개요 + +§4.3.2는 ISO/IEC 18974의 핵심 조항으로, ISO/IEC 5230에 없는 18974 전용 신규 +조항이다. SBOM에 포함된 각 오픈소스 컴포넌트에 대해 **취약점 탐지 → 위험 +평가 → 조치 결정 → 고객 동의(필요 시) → 조치 수행 → 배포 후 신규 취약점 +대응 → 지속 모니터링** 의 전 과정을 절차로 수립하고 이행 기록을 유지하도록 +요구한다. §4.1.5가 취약점 처리 방법의 존재를 요구한다면, §4.3.2는 그 방법이 +각 컴포넌트에 실제로 적용되어 기록이 남아 있을 것을 요구한다. + +## 2. 해야 할 활동 + +- SBOM의 각 오픈소스 컴포넌트에 대해 알려진 취약점 존재 여부를 탐지한다. +- 탐지된 각 취약점에 위험·영향 점수(CVSS)를 할당한다. +- 각 취약점에 대해 필요한 수정 또는 완화 단계를 결정하고 문서화한다. +- 필요한 경우 사전에 결정된 수준 이상에서 고객 동의를 획득한다. +- 위험·영향 점수에 따라 적절한 조치를 수행하고 기록한다. +- 배포된 소프트웨어에 새로 공개된 취약점이 있는 경우 적절한 조치를 수행한다. +- 출시 후에도 공급 소프트웨어의 취약점 공개를 모니터링하고 대응한다. +- 취약점별 탐지 및 조치 결과를 컴포넌트 기록으로 유지한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §4.3.2 | SBOM에 포함될 각 오픈소스 소프트웨어 컴포넌트에 보안 보증 활동을 적용하는 프로세스가 있어야 한다: 알려진 취약점 탐지 / 위험·영향 점수 할당 / 수정 또는 완화 단계 결정·문서화 / 필요 시 고객 동의 획득 / 위험 점수에 따른 조치 수행 / 새로 발견된 취약점 조치 / 출시 후 모니터링 및 취약점 공개 대응 | **4.3.2.1** 공급 소프트웨어의 오픈소스 소프트웨어 컴포넌트에 대해 알려진 취약점의 탐지 및 해결을 처리하기 위한 문서화된 절차
**4.3.2.2** 각 오픈소스 소프트웨어 컴포넌트에 대해 식별된 알려진 취약점 및 취해진 조치(조치가 필요하지 않은 경우도 포함)에 대한 기록이 유지 관리되어야 함 | + +
영문 원문 보기 + +> **§4.3.2 Security Assurance** +> There shall exist a process to apply security assurance activities to each +> open source software component that is to be included in the bill of +> materials (SBOM): +> - Applying a method to detect the existence of known vulnerabilities; +> - Assign a risk/impact score to each identified known vulnerability; +> - Determine and document the necessary remediation or mitigation steps for +> each detected and scored known vulnerability; +> - Obtain customer approval above a pre-determined threshold, where +> applicable; +> - Perform appropriate action based on risk/impact score; +> - Perform appropriate action for newly disclosed known vulnerabilities in +> previously released supplied software; +> - Ability to monitor and respond to vulnerability disclosures for the +> supplied software after its release. +> +> **Verification Material(s):** +> 4.3.2.1 A documented procedure for handling detection and resolution of +> known vulnerabilities for the open source software components of the +> supplied software. +> 4.3.2.2 For each open source software component, a record is maintained of +> the identified known vulnerabilities and action taken (including a +> determination that no action was required). + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 4.3.2.1 취약점 탐지 및 해결 절차 + +**준수 방법** + +SBOM의 각 오픈소스 컴포넌트에 대한 취약점 탐지부터 해결까지의 전체 과정을 +문서화한 절차가 입증자료 4.3.2.1이다. 이 절차는 §4.1.5에서 정의한 개별 방법들을 +통합하여 운영 흐름으로 구체화한 것이다. + +아래 플로우차트는 CVE 탐지부터 조치 완료까지의 전체 흐름을 나타낸다. + +```mermaid +flowchart TD + A([SBOM 컴포넌트]) --> B[취약점 스캔\nSCA 도구] + B --> C{CVE 탐지?} + C -- 없음 --> D[탐지 없음 기록\n정기 재스캔 대기] + C -- 있음 --> E[CVSS 점수 산정\n위험·영향 평가] + E --> F{심각도 분류} + F -- Critical/High --> G[즉시 대응\n7~30일 기한] + F -- Medium --> H[계획 대응\n90일 기한] + F -- Low --> I[다음 릴리스 처리] + G --> J{고객 영향?} + H --> J + J -- 있음 --> K[고객 통보\n§4.1.5 방법 4] + J -- 없음 --> L[조치 결정] + K --> L + L --> M{패치 가능?} + M -- 예 --> N[패치 적용\n재스캔 검증] + M -- 아니오 --> O[완화 조치\n또는 위험 수용] + N --> P[조치 결과 기록\n§4.3.2.2] + O --> P + P --> Q([지속 모니터링\n§4.1.5 방법 5]) +``` + +**절차 단계별 상세** + +아래는 플로우차트의 각 단계를 절차 문서 형태로 기술한 샘플이다. + +``` +[취약점 탐지 및 해결 절차] + +1단계 — 취약점 탐지 +- CI/CD 파이프라인 빌드 시 SCA 도구(Dependency-Track, OSV-SCALIBR 등)가 + SBOM을 기반으로 취약점을 자동 스캔한다. +- NVD, OSV, GitHub Advisory Database 등 복수의 취약점 DB를 참조한다. +- 배포 후에도 신규 CVE 발행 시 아카이브된 SBOM과 자동 대조한다. + +2단계 — 위험·영향 점수 산정 +- 탐지된 CVE에 대해 CVSS v3.1 기준 기본 점수를 산정한다. +- 당사 제품의 실제 사용 맥락(네트워크 노출도, 권한 필요 여부 등)을 고려하여 + 환경 점수(Environmental Score)를 조정한다. +- 심각도 분류: Critical(9.0+) / High(7.0-8.9) / Medium(4.0-6.9) / Low(0.1-3.9) + +3단계 — 조치 결정 및 문서화 +- 심각도와 고객 영향 범위에 따라 조치 방법을 결정한다: + · 패치 적용: 상위 버전으로 업그레이드 또는 패치 적용 + · 완화 조치: 패치가 없는 경우 네트워크 격리, 기능 비활성화 등 + · 위험 수용: 실제 악용 가능성이 낮고 완화 조치도 불필요한 경우 + (보안 담당자 + 오픈소스 PM 공동 승인 필수) +- 조치 결정 근거를 취약점 추적 시스템에 기록한다. + +4단계 — 고객 동의 획득 (해당 시) +- Critical/High 취약점이 고객 배포 제품에 영향을 미치는 경우: + · 고객사 보안 담당자에게 취약점 정보와 대응 계획을 사전 통보한다. + · 패치 배포 일정과 완화 조치 방법을 공유한다. + +5단계 — 조치 수행 +- 결정된 조치를 조치 기한 내에 수행한다. +- 패치 적용 후 재스캔을 실행하여 취약점 제거를 확인한다. +- 조치 완료 결과를 §4.3.2.2 기록에 업데이트한다. + +6단계 — 지속 모니터링 +- Dependency-Track 등 도구를 통해 배포된 소프트웨어의 취약점 현황을 + 상시 모니터링한다. +- 신규 CVE 발행 시 1~3단계를 자동 또는 즉시 재수행한다. +``` + +--- + +### 4.3.2.2 취약점 및 조치 기록 + +**준수 방법** + +SBOM의 각 오픈소스 컴포넌트에 대해 식별된 취약점과 취해진 조치(조치가 불필요 +하다고 판단한 경우 포함)를 기록하고 유지해야 한다. 이 기록이 입증자료 4.3.2.2다. +"조치가 필요하지 않은 경우도 포함"이라는 표현이 중요하다 — 취약점이 탐지되지 +않은 컴포넌트도 스캔했다는 사실과 탐지 결과를 기록해야 한다. + +기록은 Dependency-Track, Jira 보안 이슈 트래커, 스프레드시트 등 다양한 +도구로 관리할 수 있으며, 감사 시 즉시 제출 가능한 형태로 유지한다. + +**고려사항** + +- **컴포넌트별 기록**: SBOM의 각 컴포넌트에 대해 개별 기록을 유지한다. +- **탐지 없음도 기록**: 취약점이 탐지되지 않은 컴포넌트도 스캔 날짜와 결과를 + 기록한다. +- **조치 이력 추적**: 동일 컴포넌트의 취약점 발생·조치·재스캔 이력을 시계열로 + 관리한다. +- **보관 기간**: 해당 소프트웨어의 지원 기간 + 최소 3년간 보관한다. + +**샘플** + +아래는 컴포넌트별 취약점 및 조치 기록부 샘플이다. + +``` +| 소프트웨어 | 버전 | 컴포넌트 | 컴포넌트 버전 | CVE ID | CVSS | 심각도 | 조치 내용 | 조치일 | 담당자 | 비고 | +|-----------|------|---------|--------------|--------|------|--------|-----------|--------|--------|------| +| MyProduct | v1.2.0 | openssl | 3.0.7 | CVE-2023-0286 | 7.4 | High | 3.0.8로 업그레이드 | 2023-02-10 | 김철수 | 재스캔 확인 완료 | +| MyProduct | v1.2.0 | zlib | 1.2.11 | CVE-2022-37434 | 9.8 | Critical | 1.2.13으로 업그레이드 | 2022-10-15 | 김철수 | 고객 통보 완료 | +| MyProduct | v1.2.0 | libpng | 1.6.37 | 없음 | - | - | 조치 불필요 | 2023-03-01 | 김철수 | 정기 스캔 결과 | +| FirmwareX | v2.3.0 | busybox | 1.35.0 | CVE-2022-28391 | 9.8 | Critical | 위험 수용 (네트워크 격리 완화) | 2022-11-20 | 김철수 | 패치 미존재, PM 승인 완료 | +``` + +## 5. 참고 + +- ISO/IEC 5230 대응 조항 없음 (18974 전용 신규 조항) +- 관련 가이드: [기업 오픈소스 관리 가이드 — 3. 프로세스](../../../opensource_for_enterprise/3-process/) +- 관련 도구: [Dependency-Track](../../../tools/7-dependency-track/), [OSV-SCALIBR](../../../tools/4-osvscalibr/) +- 연계 조항: [§4.1.5 표준 관행 구현](../../../iso18974_guide/1-program-foundation/5-standard-practice/), [§4.3.1 SBOM](../1-sbom/) diff --git a/content/ko/guide/iso18974_guide/3-content-review/_index.md b/content/ko/guide/iso18974_guide/3-content-review/_index.md new file mode 100644 index 000000000..891b38581 --- /dev/null +++ b/content/ko/guide/iso18974_guide/3-content-review/_index.md @@ -0,0 +1,8 @@ +--- +title: "§4.3 콘텐츠 검토 및 승인" +weight: 30 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 18974"] +description: > +--- diff --git a/content/ko/guide/iso18974_guide/4-conformance/1-completeness/_index.md b/content/ko/guide/iso18974_guide/4-conformance/1-completeness/_index.md new file mode 100644 index 000000000..146c9602e --- /dev/null +++ b/content/ko/guide/iso18974_guide/4-conformance/1-completeness/_index.md @@ -0,0 +1,135 @@ +--- +title: "§4.4.1 완전성" +weight: 10 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 18974", "완전성"] +description: > +--- + +## 1. 조항 개요 + +§4.4.1은 ISO/IEC 5230 §3.6.1(적합성)에 대응하는 조항이다. §4.1.4에서 정의한 +프로그램이 ISO/IEC 18974의 모든 요구사항을 충족함을 확인하는 문서를 작성해야 +한다. 5230 §3.6.1과 구조는 동일하지만, 확인 대상이 18974의 25개 입증자료 +항목 전체라는 점이 다르다. ISO/IEC 5230 인증과 18974 인증을 동시에 준비하는 +경우 두 규격의 공통 항목을 통합 점검하고, 18974 전용 9개 항목(★ 표시)을 +추가로 확인하는 방식이 효율적이다. + +## 2. 해야 할 활동 + +- §4.1부터 §4.3까지 모든 조항의 입증자료(25개 항목)가 갖추어졌는지 자체 + 점검한다. +- 프로그램이 §4.1.4에서 정의한 적용 범위 내에서 ISO/IEC 18974의 모든 요구사항을 + 충족함을 확인하는 문서를 작성한다. +- 확인 문서에 검토자, 승인자, 확인 날짜를 기록한다. +- ISO/IEC 5230과 18974를 동시에 준수하는 경우 통합 점검표를 활용하여 중복 + 검토 부담을 줄인다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §4.4.1 | 프로그램이 이 규격을 준수하는 것으로 간주되려면, 조직은 프로그램이 이 문서의 모든 요구사항을 충족한다고 확인해야 한다. | **4.4.1.1** §4.1.4에 명시된 프로그램이 이 문서의 모든 요구 사항을 충족함을 확인하는 문서화된 증거 | + +
영문 원문 보기 + +> **§4.4.1 Completeness** +> 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 specification. +> +> **Verification Material(s):** +> 4.4.1.1 Documented evidence affirming the program specified in §4.1.4 +> satisfies all the requirements of this specification. + +
+ +## 4. 입증자료별 준수 방법 및 샘플 + +### 4.4.1.1 규격 준수 확인 문서 + +**준수 방법** + +§4.1.4에서 정의한 프로그램의 적용 범위 내에서 ISO/IEC 18974의 모든 요구사항을 +충족한다는 사실을 확인하는 문서를 작성해야 한다. 이 문서가 입증자료 4.4.1.1이다. +아래 체크리스트를 활용하여 25개 입증자료 항목 전체를 점검하고, 확인 결과를 +기록한다. + +**ISO/IEC 18974 준수 자체 점검 체크리스트** + +``` +§4.1 프로그램 기반 +□ 4.1.1.1 문서화된 보안 보증 정책 +□ 4.1.1.2 정책 인식 전파 절차 +□ 4.1.2.1 역할과 책임 목록 +□ 4.1.2.2 역할별 역량 정의 문서 +□ 4.1.2.3 참여자 목록 및 역할 매핑 ★ +□ 4.1.2.4 역량 평가 증거 +□ 4.1.2.5 주기적 검토 및 변경 증거 ★ +□ 4.1.2.6 내부 모범 사례 일치 검증 ★ +□ 4.1.3.1 참여자 인식 평가 증거 +□ 4.1.4.1 프로그램 적용 범위 진술 +□ 4.1.4.2 성과 메트릭 세트 ★ +□ 4.1.4.3 지속적 개선 증거 ★ +□ 4.1.5.1 8가지 취약점 처리 방법 문서화 절차 ★ + +§4.2 관련 업무 +□ 4.2.1.1 공개된 취약점 문의 채널 +□ 4.2.1.2 내부 취약점 문의 대응 절차 +□ 4.2.2.1 역할 담당자 명시 문서 +□ 4.2.2.2 인원 배치 및 예산 확인 +□ 4.2.2.3 취약점 해결 전문성 명시 ★ +□ 4.2.2.4 내부 책임 할당 절차 + +§4.3 콘텐츠 검토 및 승인 +□ 4.3.1.1 SBOM 수명주기 지속 기록 절차 +□ 4.3.1.2 오픈소스 컴포넌트 기록 (SBOM) +□ 4.3.2.1 취약점 탐지 및 해결 절차 ★ +□ 4.3.2.2 취약점 및 조치 기록 ★ + +§4.4 규격 준수 +□ 4.4.1.1 모든 요구사항 충족 확인 문서 +□ 4.4.2.1 18개월 이내 요구사항 충족 확인 문서 + +★ = ISO/IEC 5230 대비 추가 항목 (9건) +``` + +**고려사항** + +- **5230과 통합 점검**: ISO/IEC 5230 인증을 보유한 경우 공통 항목(16건)은 + 기존 자료를 재활용하고 18974 전용 항목(9건)에 집중한다. +- **승인 절차**: 오픈소스 프로그램 매니저의 검토와 경영진 승인을 거쳐 문서를 + 공식화한다. +- **규격 버전 명시**: ISO/IEC 18974:2023(버전 1.0)을 준수 확인 규격으로 + 문서에 명시한다. + +**샘플** + +``` +[ISO/IEC 18974 규격 준수 확인서] + +프로그램 명칭: [회사명] 오픈소스 보안 보증 프로그램 +적용 범위: [§4.1.4에서 정의한 범위] +준수 확인 규격: ISO/IEC 18974:2023 (버전 1.0) +확인 날짜: YYYY-MM-DD + +본 문서는 위 프로그램이 ISO/IEC 18974:2023의 §4.1부터 §4.4까지 +모든 요구사항(25개 입증자료 항목)을 충족함을 확인한다. + +준수 확인 항목 요약: +- §4.1 프로그램 기반 (5개 조항, 13개 입증자료): 충족 ✓ +- §4.2 관련 업무 (2개 조항, 6개 입증자료): 충족 ✓ +- §4.3 콘텐츠 검토 및 승인 (2개 조항, 4개 입증자료): 충족 ✓ +- §4.4 규격 준수 (2개 조항, 2개 입증자료): 충족 ✓ + +검토자: [오픈소스 프로그램 매니저 이름] +승인자: [경영진 또는 OSRB 책임자 이름] +승인일: YYYY-MM-DD +``` + +## 5. 참고 + +- 대응 ISO/IEC 5230 조항: [§3.6.1 적합성](../../iso5230_guide/6-conformance/1-conformance/) +- ISO/IEC 18974 자가 인증: [https://certification.openchainproject.org/](https://certification.openchainproject.org/) +- 전체 조항 체크리스트: [ISO/IEC 18974 준수 가이드](../../) diff --git a/content/ko/guide/iso18974_guide/4-conformance/2-duration/_index.md b/content/ko/guide/iso18974_guide/4-conformance/2-duration/_index.md new file mode 100644 index 000000000..c0e027a58 --- /dev/null +++ b/content/ko/guide/iso18974_guide/4-conformance/2-duration/_index.md @@ -0,0 +1,82 @@ +--- +title: "§4.4.2 기간" +weight: 20 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 18974", "기간"] +description: > +--- + +## 1. 조항 개요 + +§4.4.2는 ISO/IEC 5230 §3.6.2(지속 기간)와 동일한 구조다. 적합성 인증을 취득한 +후 18개월 이내에 이 규격의 모든 요구사항을 충족하고 있음을 확인하는 문서를 +유지하도록 요구한다. 규격의 새 버전이 발행되면 18개월의 유예 기간 동안 이전 +버전 기준 인증이 유지되며, 유예 기간 내에 최신 버전 기준으로 갱신하는 것을 +권장한다. + +## 2. 해야 할 활동 + +- 적합성 인증 취득 날짜를 기록하고 관리한다. +- 인증 취득 후 최근 18개월 이내에 규격의 모든 요구사항을 충족하고 있음을 + 재확인하고 문서화한다. +- 새로운 버전의 ISO/IEC 18974가 발행된 경우 18개월 이내에 최신 버전 기준으로 + 프로그램을 갱신하고 재확인한다. +- 정기적인 내부 감사를 통해 25개 입증자료 항목의 지속적 준수 여부를 점검한다. + +## 3. 요구사항 및 입증자료 + +| 조항 번호 | 요구사항 (KO) | 입증자료 | +|-----------|--------------|---------| +| §4.4.2 | 이 규격을 준수하는 프로그램은 규격의 새 버전이 발행된 후 18개월이 경과할 때까지 이전 버전에 대해서도 계속 준수하는 것으로 간주된다. 준수 프로그램을 최신 버전으로 업데이트하는 것을 권장한다. | **4.4.2.1** 프로그램이 적합성 검증을 획득한 후 지난 18개월 이내에 이 규격의 모든 요구 사항을 충족함을 확인하는 문서 | + +
영문 원문 보기 + +> **§4.4.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):** +> 4.4.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. 입증자료별 준수 방법 및 샘플 + +### 4.4.2.1 18개월 이내 요구사항 충족 확인 문서 + +**준수 방법** + +ISO/IEC 5230 §3.6.2.1과 동일한 방식으로, §4.4.1.1의 규격 준수 확인 문서를 +최소 연 1회 재검토하고 갱신한다. 갱신 시마다 검토 날짜와 검토자를 기록하여 +최근 18개월 이내에 검토가 이루어졌음을 증명한다. + +ISO/IEC 5230과 18974를 동시에 운영하는 경우, 두 규격의 정기 재확인 일정을 +통합하여 연 1회 통합 감사로 처리하면 관리 효율이 높다. + +**샘플** + +``` +[ISO/IEC 18974 규격 준수 정기 재확인 기록] + +최초 인증 취득일: YYYY-MM-DD +준수 확인 규격: ISO/IEC 18974:2023 (버전 1.0) + +| 재확인 날짜 | 확인 결과 | 변경 사항 | 검토자 | 비고 | +|------------|-----------|-----------|--------|------| +| 2025-01-10 | 전체 충족 | 취약점 해결 전문성 문서 갱신 (§4.2.2.3) | 홍길동 | - | +| 2026-01-08 | 전체 충족 | 성과 메트릭 목표치 상향 (§4.1.4.2) | 홍길동 | - | + +다음 재확인 예정일: YYYY-MM-DD +18개월 유효 기한: YYYY-MM-DD +``` + +## 5. 참고 + +- 대응 ISO/IEC 5230 조항: [§3.6.2 지속 기간](../../iso5230_guide/6-conformance/2-duration/) +- OpenChain 규격 최신 버전 확인: [https://www.openchainproject.org/security-assurance](https://www.openchainproject.org/security-assurance) diff --git a/content/ko/guide/iso18974_guide/4-conformance/_index.md b/content/ko/guide/iso18974_guide/4-conformance/_index.md new file mode 100644 index 000000000..6d35cd5db --- /dev/null +++ b/content/ko/guide/iso18974_guide/4-conformance/_index.md @@ -0,0 +1,8 @@ +--- +title: "§4.4 규격 준수" +weight: 40 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 18974"] +description: > +--- diff --git a/content/ko/guide/iso18974_guide/_index.md b/content/ko/guide/iso18974_guide/_index.md new file mode 100644 index 000000000..3d228ff5b --- /dev/null +++ b/content/ko/guide/iso18974_guide/_index.md @@ -0,0 +1,160 @@ +--- +title: "ISO/IEC 18974 준수 가이드" +linkTitle: "ISO/IEC 18974 준수 가이드" +weight: 30 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 18974", "보안 보증", "OpenChain"] +description: > + ISO/IEC 18974의 25개 입증자료 항목을 조항별로 풀어서 설명하는 준수 가이드다. +--- + +이 가이드는 ISO/IEC 18974(OpenChain Security Assurance)의 각 요구사항 조항을 +하나씩 풀어서 설명한다. 각 조항이 요구하는 입증자료가 무엇인지, 어떻게 준수할 +수 있는지, 바로 활용할 수 있는 샘플 문서는 무엇인지 안내한다. + +**Author : OpenChain Korea Work Group / [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)** + +## 대상 독자 + +- 오픈소스 보안 보증 체계를 처음 수립하는 기업의 보안 담당자 및 오픈소스 프로그램 매니저 +- DevSecOps 환경에서 오픈소스 취약점 관리 프로세스를 구축하는 엔지니어 +- ISO/IEC 5230 인증 취득 후 ISO/IEC 18974 추가 인증을 준비하는 기업 담당자 + +## ISO/IEC 5230과의 관계 + +{{% alert title="ISO/IEC 18974는 ISO/IEC 5230 위에 보안 레이어를 추가한다" color="warning" %}} + +**ISO/IEC 5230(라이선스 컴플라이언스)** 은 오픈소스 라이선스 의무 이행을 +체계적으로 관리하는 기반 프로그램을 다룬다. + +**ISO/IEC 18974(보안 보증)** 은 그 위에 취약점 탐지·평가·대응이라는 보안 +레이어를 추가한다. 두 규격은 정책·역량·SBOM 등 핵심 인프라를 공유하며, +18974는 이를 보안 관점에서 확장하고 심화한다. + +| 구분 | ISO/IEC 5230 | ISO/IEC 18974 | +|------|-------------|--------------| +| 목적 | 라이선스 컴플라이언스 | 보안 보증 | +| 입증자료 | 24개 | 25개 | +| 공통 기반 조항 | — | 16개 (5230과 대응) | +| 18974 전용 조항 | — | 9개 (보안 특화) | +| 핵심 추가 요소 | — | 취약점 탐지·대응·CVD 절차 | + +{{% /alert %}} + +{{% alert title="권장 취득 경로" color="success" %}} +오픈소스 보안 보증 인증을 처음 준비하는 기업은 **ISO/IEC 5230 취득 → +ISO/IEC 18974 추가 취득** 순서로 단계적으로 진행하는 것을 권장한다. +5230에서 구축한 정책·프로세스·SBOM 인프라를 18974에서 그대로 활용할 수 +있어 추가 비용과 노력을 최소화할 수 있다. + +두 규격의 조항별 상세 비교는 **[ISO/IEC 5230 vs 18974 비교](./compare/)** 페이지를 참고한다. +{{% /alert %}} + +## 이 가이드의 활용 방법 + +{{% alert title="기업 오픈소스 관리 가이드와의 관계" color="success" %}} + +**[기업 오픈소스 관리 가이드](../opensource_for_enterprise/)** 는 오픈소스를 +어떻게 관리할지 실무 구현 방법(정책·프로세스·도구·조직)을 설명한다. + +**이 가이드(ISO/IEC 18974 준수 가이드)** 는 보안 보증 인증을 위해 무엇을 +입증해야 하는지 조항 단위로 정리한다. + +| 가이드 | 중점 | 활용 상황 | +|--------|------|-----------| +| 기업 오픈소스 관리 가이드 | 실무 구현 방법 (How to implement) | 오픈소스 관리 체계를 처음 구축할 때 | +| ISO/IEC 18974 준수 가이드 | 조항별 입증자료 기준 (What to prove) | 보안 보증 인증 준비 또는 자체 점검 시 | + +{{% /alert %}} + +## 전체 조항 체크리스트 + +ISO/IEC 18974는 총 **11개 조항, 25개 입증자료 항목**으로 구성된다. +★ 표시는 ISO/IEC 5230 대비 추가되거나 보안 관점으로 변경된 항목이다. + +### §4.1 프로그램 기반 + +| 조항 | 제목 | 입증자료 | 상세 | +|------|------|:---:|------| +| §4.1.1 | 정책 (Policy) | 2건 | [바로가기](./1-program-foundation/1-policy/) | +| §4.1.2 | 역량 (Competence) ★ | 6건 | [바로가기](./1-program-foundation/2-competence/) | +| §4.1.3 | 인식 (Awareness) | 1건 | [바로가기](./1-program-foundation/3-awareness/) | +| §4.1.4 | 프로그램 범위 (Program Scope) ★ | 3건 | [바로가기](./1-program-foundation/4-scope/) | +| §4.1.5 | 표준 관행 구현 (Standard Practice Implementation) ★ | 1건 | [바로가기](./1-program-foundation/5-standard-practice/) | + +### §4.2 관련 업무 + +| 조항 | 제목 | 입증자료 | 상세 | +|------|------|:---:|------| +| §4.2.1 | 접근성 (Access) | 2건 | [바로가기](./2-relevant-tasks/1-access/) | +| §4.2.2 | 효과적 리소스 (Effectively Resourced) | 4건 | [바로가기](./2-relevant-tasks/2-resourced/) | + +### §4.3 콘텐츠 검토 및 승인 + +| 조항 | 제목 | 입증자료 | 상세 | +|------|------|:---:|------| +| §4.3.1 | SBOM | 2건 | [바로가기](./3-content-review/1-sbom/) | +| §4.3.2 | 보안 보증 (Security Assurance) ★ | 2건 | [바로가기](./3-content-review/2-security-assurance/) | + +### §4.4 규격 준수 + +| 조항 | 제목 | 입증자료 | 상세 | +|------|------|:---:|------| +| §4.4.1 | 완전성 (Completeness) | 1건 | [바로가기](./4-conformance/1-completeness/) | +| §4.4.2 | 기간 (Duration) | 1건 | [바로가기](./4-conformance/2-duration/) | + +**합계: 11개 조항 / 25개 입증자료 항목** + +{{% pageinfo %}} + +★ **ISO/IEC 5230 대비 18974 추가 항목 요약** + +| 조항 | 추가 내용 | 추가 항목 수 | +|------|-----------|:-----------:| +| §4.1.2 역량 | 참여자 목록(4.1.2.3), 주기적 검토 증거(4.1.2.5), 내부 모범 사례 일치 검증(4.1.2.6) | +3건 | +| §4.1.4 프로그램 범위 | 성과 메트릭(4.1.4.2), 지속적 개선 증거(4.1.4.3) | +2건 | +| §4.1.5 표준 관행 구현 | 8가지 취약점 처리 방법 전체에 대한 문서화 절차(4.1.5.1) | 신규 조항 | +| §4.3.2 보안 보증 | 취약점 탐지·해결 절차(4.3.2.1), 취약점 및 조치 기록(4.3.2.2) | 신규 조항 | + +{{% /pageinfo %}} + +## ISO/IEC 18974 인증 절차 + +ISO/IEC 18974 준수 여부를 공식적으로 인정받는 방법은 세 가지다. + +{{% 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" %}} +ISO/IEC 5230을 이미 취득한 기업은 기존 인프라(정책·역량·SBOM)를 활용하여 +보안 보증 특화 항목(§4.1.5, §4.3.2)을 추가하는 방식으로 효율적으로 18974 +인증을 준비할 수 있다. +{{% /alert %}} diff --git a/content/ko/guide/iso18974_guide/compare/_index.md b/content/ko/guide/iso18974_guide/compare/_index.md new file mode 100644 index 000000000..ab4f5dcb5 --- /dev/null +++ b/content/ko/guide/iso18974_guide/compare/_index.md @@ -0,0 +1,94 @@ +--- +title: "ISO/IEC 5230 vs 18974 비교" +weight: 50 +type: docs +categories: ["guide"] +tags: ["ISO/IEC 5230", "ISO/IEC 18974", "비교"] +description: > +--- + +## 1. 두 표준의 관계 + +ISO/IEC 5230과 ISO/IEC 18974는 모두 OpenChain 프로젝트가 주도하는 오픈소스 +관련 국제 표준이지만, 서로 다른 문제를 다룬다. 5230은 오픈소스 라이선스 +컴플라이언스(저작권 의무 이행·SBOM 관리·컴플라이언스 산출물 배포)를 다루고, +18974는 오픈소스 보안 보증(취약점 탐지·평가·대응·CVD)을 다룬다. 두 표준은 +완전한 상위·하위 집합 관계가 아니다. 정책·역량·SBOM 등 9개 공통 조항을 +공유하되, 5230에만 있는 조항(라이선스 컴플라이언스·산출물·기여)과 18974에만 +있는 조항(표준 관행 구현·보안 보증)이 각각 존재한다. + +두 표준을 동시에 준수하면 라이선스 의무 이행과 보안 취약점 관리를 하나의 +통합 오픈소스 프로그램으로 운영할 수 있다. 공통 기반 문서(정책·역량 기록·SBOM +절차)는 한 번 작성으로 두 표준에 동시 활용되므로, 5230 인증 후 18974를 +추가로 준비하는 데 드는 실질적 추가 작업량은 전체의 30~40% 수준이다. + +--- + +## 2. 조항 1:1 대조표 + +| ISO/IEC 5230 조항 | 제목 | ISO/IEC 18974 조항 | 차이점 | +|---|---|---|---| +| §3.1.1 | 정책 | §4.1.1 | 정책·전파 절차의 정기 검토 프로세스 요건 추가 | +| §3.1.2 | 역량 | §4.1.2 | 입증자료 3건 추가 (참여자 목록·주기적 검토·내부 모범 사례 일치 검증) | +| §3.1.3 | 인식 | §4.1.3 | 보안 보증 관점의 인식 항목 추가, 입증자료 수 동일 | +| §3.1.4 | 프로그램 범위 | §4.1.4 | 입증자료 2건 추가 (성과 메트릭·지속 개선 증거) | +| — | — | §4.1.5 | 표준 관행 구현 (18974 전용 신규 — 8가지 취약점 처리 방법 문서화) | +| §3.2.1 | 외부 문의 대응 | §4.2.1 | 라이선스 문의 → 취약점 문의로 초점 전환 | +| §3.2.2 | 효과적 리소스 | §4.2.2 | 법률 자문 → 취약점 해결 전문성으로 전환, 입증자료 5건→4건 | +| §3.3.1 | SBOM | §4.3.1 | 수명주기 지속 기록·취약점 모니터링 연동 강조 | +| §3.3.2 | 라이선스 컴플라이언스 | — | 5230 전용 (18974에 없음) | +| §3.4.1 | 컴플라이언스 산출물 | — | 5230 전용 (18974에 없음) | +| §3.5.1 | 기여 | — | 5230 전용 (18974에 없음) | +| — | — | §4.3.2 | 보안 보증 (18974 전용 신규 — CVE 탐지·평가·조치·통보·모니터링 전 과정) | +| §3.6.1 | 적합성 | §4.4.1 | 명칭만 완전성으로 변경, 내용 동일 | +| §3.6.2 | 지속 기간 | §4.4.2 | 동일 | + +**요약** + +- **공통 조항**: 9개 (입증자료 16개) +- **5230 전용 조항**: §3.3.2, §3.4.1, §3.5.1 (입증자료 6개) +- **18974 전용 조항**: §4.1.5, §4.3.2 (입증자료 3개) +- **18974에서 확장된 공통 조항**: 4개 — §4.1.1, §4.1.2, §4.1.4, §4.2.2 (입증자료 6개 추가) + +--- + +## 3. 입증자료 수 비교 + +| 구분 | ISO/IEC 5230 | ISO/IEC 18974 | +|------|-------------|--------------| +| 전체 입증자료 수 | 24개 | 25개 | +| 전용 조항 (입증자료) | §3.3.2·§3.4.1·§3.5.1 (6개) | §4.1.5·§4.3.2 (3개) | +| 공통 조항 내 추가 입증자료 | — | +6개 (공통 조항 확장) | +| 공통 입증자료 | 18개 | 16개 (성격 변경 포함) | + +--- + +## 4. 두 표준 동시 준수 전략 + +5230을 먼저 취득한 후 18974를 추가로 준비하는 경로가 가장 효율적이다. +5230 인증 과정에서 구축한 정책 문서, 역량 기록, SBOM 절차는 18974의 공통 +조항(§4.1.1~§4.1.4, §4.2.1, §4.2.2, §4.3.1, §4.4.1, §4.4.2)에 그대로 +활용된다. 별도로 작성이 필요한 것은 기존 문서에 추가하는 항목들과 18974 +전용 신규 조항 2개다. + +18974 전용으로 새로 준비해야 하는 항목은 다음과 같다: + +- **§4.1.5 표준 관행 구현**: 8가지 취약점 처리 방법(위협 식별·탐지·후속 조치· + 고객 통보·배포 후 분석·보안 테스트·위험 검증·정보 수출) 각각의 절차 문서화 +- **§4.3.2 보안 보증**: CVE 탐지→위험 평가→조치 결정→수행→모니터링 전 과정 + 절차 및 컴포넌트별 취약점 조치 기록 +- **공통 조항 보완**: §4.1.2 참여자 목록(4.1.2.3)·주기적 검토 증거(4.1.2.5)· + 모범 사례 일치 검증(4.1.2.6), §4.1.4 성과 메트릭(4.1.4.2)·지속 개선 증거 + (4.1.4.3) 추가 작성 + +5230 체계를 갖춘 조직이 18974를 추가로 준비하는 데 드는 실질적 작업량은 전체 +5230 준비 작업의 약 30~40% 수준으로 예상된다. + +--- + +## 5. 참고 링크 + +- [ISO/IEC 5230 준수 가이드](../../iso5230_guide/) +- [ISO/IEC 18974 준수 가이드](../) +- [기업 오픈소스 관리 가이드](../../../opensource_for_enterprise/) +- [OpenChain 자가 인증](https://certification.openchainproject.org/)