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

이 페이지의 일반 화면으로 돌아가기.

§3.3 콘텐츠 검토 및 승인

1 - §3.3.1 SBOM

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]년간 보관한다.

샘플

아래는 오픈소스 컴포넌트 관리 절차 개요 샘플이다. 오픈소스 프로세스 템플릿에서 전체 프로세스 양식을 확인할 수 있다.

[오픈소스 컴포넌트 관리 절차 개요]

(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. 참고

2 - §3.3.2 라이선스 컴플라이언스

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. 참고