Guide on OpenChain KWG

1. OpenChain 표준

Mon, 01 Jan 0001 00:00:00 +0000

ISO/IEC 5230

OpenChain 프로젝트는 2016년 OpenChain 규격 1.0을 제작하여 배포했다. OpenChain 규격은 오픈소스 컴플라이언스를 위한 핵심 요구사항을 정의한 12페이지 분량의 규격으로, 기업의 규모나 업종과 관계없이 모든 분야의 회사에 적합하도록 고안되었다. 2020년 12월 Openchain 규격 2.1은 ISO/IEC 5230 국제표준으로 등록되었다.

ISO/IEC 5230은 기업이 오픈소스 컴플라이언스 달성을 위해 꼭 수행해야 할 여섯 가지 주요 요구사항과 이를 입증하기 위해 필요한 자료 목록을 정의하고 있다.

프로그램 설립
관련 업무 정의 및 지원
오픈소스 컨텐츠 검토 및 승인
컴플라이언스 산출물 생성 및 제공
오픈소스 커뮤니티 참여에 대한 이해
규격 요구사항 적합성

오픈소스 컴플라이언스를 처음 시작하는 기업이라면 이러한 ISO/IEC 5230 표준의 요구사항을 하나씩 충족해가면서 수준을 향상시키는 것이 좋은 전략이다.

FOSSology

Mon, 01 Jan 0001 00:00:00 +0000

오픈소스 컴플라이언스를 위해 소프트웨어 내에 포함된 오픈소스와 라이선스 정보를 검출하기 위해 소스코드 스캔 도구를 사용할 수 있다.

< https://www.fossology.org/ >

Linux Foundation의 FOSSology 프로젝트는 이러한 스캔 도구를 개발하고 오픈소스로 공개해 누구나 자유롭게 사용할 수 있게 한 도구이다.

주요 특징

FOSSology는 웹기반의 프로그램으로 사용자는 웹사이트에 로그인하여 개별 파일 혹은 소프트웨어 패키지를 업로드할 수 있다. FOSSology는 업로드된 파일 내에 라이선스 텍스트와 Copyright 정보를 검출한다. 개발자는 사용하고자 하는 오픈소스의 라이선스가 무엇인지, Copyright은 어떻게 되는지에 대한 정보를 확인하고자 할때 FOSSology를 이용하는 것이 좋다. FOSSology는 개발자가 업로드한 오픈소스 패키지 내의 모든 파일을 스캔하여 각 파일 내 라이선스 관련 텍스트와 Copyright 정보를 자동으로 검출하고, 이를 리포트로 생성한다. FOSSology 주요 특징에 대한 자세한 내용은 다음 페이지를 참고할 수 있다. : https://www.fossology.org/features/

I. OpenChain 프로젝트란?

Mon, 01 Jan 0001 00:00:00 +0000

오늘날 소프트웨어는 갈수록 그 규모와 복잡도가 커지고 있다. 하나의 소프트웨어를 개발하기 위해서는 자체 개발한 소프트웨어뿐 아니라 오픈소스, 타사 소프트웨어_{3rd party software}, 벤더의 SDK 등 소프트웨어 공급망에 걸친 다양한 소프트웨어가 사용될 수 있다.

이러한 복잡한 소프트웨어 공급망의 여러 조직 중 한 곳이라도 오픈소스 라이선스 의무를 준수하지 않거나 올바른 오픈소스 사용 정보를 제공하지 않으면 최종 소프트웨어를 배포하는 기업은 오픈소스 라이선스 의무 준수에 실패할 수밖에 없다. 이로 인해 소송을 제기당해 제품 판매가 중단되는 상황이 발생할 수도 있다.

2. OpenChain 인증

Mon, 01 Jan 0001 00:00:00 +0000

OpenChain 규격에서의 요구 사항을 모두 준수한다면 OpenChain 적합한 오픈소스 프로그램을 보유했음을 인증받을 수 있다. 오픈소스 프로그램이란 정책, 프로세스, 인원 등 기업이 오픈소스 컴플라이언스 활동을 수행하기 위한 일련의 관리 체계를 의미한다. 이 장에서는 인증 방법과 적합성 선언에 관해 설명한다.

OpenChain 프로젝트에서 제안하는 인증 방법은 세 가지 이다.

자체 인증
독립 평가
타사 인증

각각의 방법을 알아보자.

자체 인증

자체 인증은 OpenChain 프로젝트에서 제일 권장하는 방법이며, 비용이 발생하지 않는다는 장점이 있다. OpenChain 프로젝트는 기업이 자체적으로 OpenChain 규격을 충족하는지 확인할 수 있도록 온라인 자체 인증 웹사이트를 제공한다.

SW360

Mon, 01 Jan 0001 00:00:00 +0000

(Updated on August 29, 2023.)

오픈소스를 포함하는 제품을 개발하고 배포하는 기업이라면 각 제품과 릴리스 버전마다 사용한 오픈소스의 버전, 라이선스 등의 정보를 수집하고 추적해야 한다. 이를 통해 기업은 올바른 오픈소스 컴플라이언스 활동을 수행할 수 있다.

특히, NVD (https://nvd.nist.gov/vuln)에서 특정 오픈소스 버전에 보안 취약점이 보고 되었을때, 해당 버전을 사용하고 있는 제품이 무엇인지 추적을 할 수 없다면, 그 기업은 어느 제품에 보안 패치를 적용해야 할 지 알 수 없는 상황에 처하게 되고, 그 기업의 제품들은 보안 취약점에 그대로 노출이 될 수 밖에 없다.

3. OpenChain 리소스

Mon, 01 Jan 0001 00:00:00 +0000

OpenChain 프로젝트에서는 기업이 컴플라이언스 프로그램을 구축하는 데 필요한 정책 문서 템플릿, 교육 자료 등 다양한 리소스를 제공한다. 이 자료들은 OpenChain 표준 준수와 일반적인 오픈소스 컴플라이언스 활동을 지원하기 위해 고안됐으며, 누구나 자유롭게 사용할 수 있도록 CC-0 라이선스로 제공된다.

< https://www.openchainproject.org/resources >

이 가이드의 많은 내용도 OpenChain에서 공개한 자료를 기반으로 작성하였다. 각 기업의 오픈소스 담당자는 정책, 프로세스, 교육자료가 필요하다면 OpenChain Resources를 먼저 찾아보기 바란다. 또한 이 자료는 한국어로도 번역되어 공개되고 있다. OpenChain Korea Work Group¹에서 이러한 번역 작업을 주도하고 있다. 한국어 번역은 관심 있는 누구나 참여할 수 있다².

FOSSLight

Mon, 01 Jan 0001 00:00:00 +0000

FOSSLight는 LG Electronics가 주도하는 오픈소스 컴플라이언스 도구 모음입니다. 소스 코드·의존성·바이너리를 분석하는 FOSSLight Scanner와, 분석 결과를 중앙에서 관리하는 웹 플랫폼 FOSSLight Hub로 구성됩니다.

GitHub (Hub): https://github.com/fosslight/fosslight
GitHub (Scanner): https://github.com/fosslight/fosslight_scanner
공식 문서: https://fosslight.org/fosslight-guide/
라이선스: AGPL-3.0-only

주요 특징

FOSSLight Hub

컴플라이언스 프로세스 통합 관리: 프로젝트별 BOM 관리, 라이선스 의무사항 이행, 공지문 생성까지 일괄 처리
취약점 모니터링: NVD·CVE 연동으로 사용 중인 오픈소스의 취약점 현황 추적
3rd Party 관리: 외부 소프트웨어 공급망의 오픈소스 현황 등록 및 관리
SBOM 관리: SPDX(ISO 표준) 형식 지원

FOSSLight Dependency Scanner

14개 이상의 패키지 매니저 지원: NPM, Yarn, Maven, Gradle, PyPI, Go, Cargo, NuGet, CocoaPods 등
자동 감지: manifest 파일을 자동으로 탐지하여 분석
직·간접 의존성 분석: 전이적 의존성까지 재귀적으로 수집
다양한 출력 형식: Excel, SPDX, CycloneDX, YAML, CSV

FOSSLight Hub 설치

Docker Compose를 사용합니다. 공식 저장소를 clone하여 실행합니다.

OSV-SCALIBR

Mon, 01 Jan 0001 00:00:00 +0000

OSV-SCALIBR (Open Source Vulnerabilities - Software Composition Analysis LIBRary)은 Google이 개발한 오픈소스 소프트웨어 구성 분석 도구입니다. 파일시스템, 컨테이너 이미지, 바이너리를 스캔하여 포함된 패키지를 식별하고, OSV(Open Source Vulnerabilities) 데이터베이스와 대조하여 알려진 취약점을 검출합니다. SPDX, CycloneDX 형식의 SBOM 생성도 지원합니다.

GitHub: https://github.com/google/osv-scalibr
라이선스: Apache-2.0

1. 주요 특징

다양한 스캔 대상 지원: 로컬 파일시스템, 컨테이너 이미지, 아카이브 파일
폭넓은 생태계 지원: Go, Python, Java(Maven), JavaScript(npm), Rust, Ruby 등
OSV DB 연동: 스캔 결과를 OSV 데이터베이스와 대조하여 CVE 등 취약점 정보 제공
다양한 SBOM 출력 형식: SPDX 2.3, CycloneDX JSON 형식으로 결과 내보내기 가능
CLI 및 라이브러리 이중 제공: 독립 실행 바이너리(CLI)와 Go 라이브러리 모두 제공

2. 설치 방법

Go 1.21 이상이 설치된 환경에서 아래 명령으로 설치합니다.

cdxgen

Mon, 01 Jan 0001 00:00:00 +0000

cdxgen은 OWASP(Open Web Application Security Project)가 관리하는 오픈소스 SBOM 생성 도구입니다. 소스 코드, 빌드 결과물, 컨테이너 이미지를 분석하여 CycloneDX 형식의 SBOM을 자동으로 생성합니다.

GitHub: https://github.com/CycloneDX/cdxgen
라이선스: Apache-2.0

주요 특징

광범위한 언어·생태계 지원: Java(Maven/Gradle), Node.js, Python, Go, Rust, PHP, Ruby, .NET 등 20개 이상
다양한 스캔 대상: 소스 코드 디렉토리, 컨테이너 이미지, GitHub 저장소
CycloneDX 표준 출력: CycloneDX 1.4/1.5/1.6 JSON 및 XML 형식 지원
REPL 모드: 대화형 인터페이스로 SBOM 탐색 및 조회 가능
CI/CD 통합: GitHub Actions, GitLab CI 등 주요 파이프라인과 쉽게 연동

설치 방법

Node.js 18 이상이 설치된 환경에서 아래 명령으로 설치합니다.

ISO 5230 · 18974 · 42001 비교

Mon, 01 Jan 0001 00:00:00 +0000

1. 세 표준의 관계

오픈소스를 사용하는 AI 시스템을 개발하는 기업은 세 가지 표준이 교차하는 지점에 있다.

flowchart LR
 subgraph oss["오픈소스 관리"]
 A["ISO/IEC 5230\n라이선스 컴플라이언스\n(라이선스·SBOM·산출물)"]
 B["ISO/IEC 18974\n보안 보증\n(취약점 탐지·대응·CVD)"]
 end

 subgraph ai["AI 시스템 관리"]
 C["ISO/IEC 42001\nAI 관리 시스템\n(거버넌스·리스크·생애주기)"]
 end

 oss -- "AI 시스템 내\n오픈소스 컴플라이언스" --> ai

ISO 5230과 18974는 오픈소스 자체를 관리하는 표준이고, ISO 42001은 AI 시스템을 관리하는 표준이다. 두 영역은 독립적이지만, AI 시스템이 오픈소스를 활용할 때 교차점이 발생한다.

ISO/IEC 42003 — AI 시스템 구현 가이드 (개발 중)

ISO/IEC 42001이 원칙적 요구사항을 제시하는 반면, ISO/IEC 42003은 42001의 구체적 구현 방법을 안내하는 가이드(새롭게 승인된 work item)다. OpenChain AI Work Group은 AI SBOM을 ISO 42003의 투명성·설명 가능성 조항 (Appendix C.2.11 — Transparency and Explainability)에 반영하는 것을 추진 중이다. AI SBOM 의무화 관련 최신 동향은 AI Work Group 활동을 참고한다.

Syft

Mon, 01 Jan 0001 00:00:00 +0000

Syft는 Anchore가 개발한 오픈소스 SBOM 생성 CLI 도구입니다. 컨테이너 이미지, 파일시스템, 아카이브를 스캔하여 포함된 패키지를 식별하고 SPDX 또는 CycloneDX 형식의 SBOM을 생성합니다.

GitHub: https://github.com/anchore/syft
라이선스: Apache-2.0

주요 특징

다양한 스캔 대상: 컨테이너 이미지(Docker, OCI), 로컬 파일시스템, tar 아카이브
폭넓은 생태계 지원: Alpine(apk), Debian/Ubuntu(dpkg), RPM, Python, Java, Go, Node.js, Ruby, Rust 등
표준 출력 형식: SPDX 2.2/2.3 (JSON·tag-value), CycloneDX 1.4/1.5 (JSON·XML), Syft JSON
Grype 연동: Anchore의 취약점 스캐너 Grype와 자연스럽게 연동하여 SBOM 기반 취약점 분석 가능
빠른 설치: 단일 바이너리 배포, 별도 런타임 불필요

설치 방법

스크립트 설치 (Linux/macOS)

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

Homebrew (macOS)

brew install syft

Docker

docker pull anchore/syft

기본 사용법

(1) 컨테이너 이미지 스캔

# Docker 이미지 스캔 (SPDX JSON 출력)
syft ubuntu:22.04 -o spdx-json=sbom.spdx.json

# CycloneDX JSON 출력
syft ubuntu:22.04 -o cyclonedx-json=sbom.cdx.json

(2) 로컬 디렉토리 스캔

syft dir:/path/to/project -o spdx-json=sbom.spdx.json

(3) 표준 출력으로 결과 확인

# 터미널에서 패키지 목록 확인
syft ubuntu:22.04

# JSON 형식으로 표준 출력
syft ubuntu:22.04 -o json

(4) Grype와 연동하여 취약점 스캔

# Syft로 SBOM 생성 후 Grype로 취약점 분석
syft ubuntu:22.04 -o json | grype

CI/CD 연동 예시

# GitHub Actions 예시
- name: Generate SBOM with Syft
 uses: anchore/sbom-action@v0
 with:
 image: myapp:latest
 format: spdx-json
 output-file: sbom.spdx.json
- name: Upload SBOM
 uses: actions/upload-artifact@v4
 with:
 name: sbom
 path: sbom.spdx.json

참고 자료

Syft GitHub: https://github.com/anchore/syft
Grype(취약점 스캐너): https://github.com/anchore/grype
SPDX 표준: https://spdx.dev/
CycloneDX 표준: https://cyclonedx.org/

Dependency-Track

Mon, 01 Jan 0001 00:00:00 +0000

Dependency-Track은 OWASP가 관리하는 오픈소스 SBOM 관리 및 취약점 분석 플랫폼입니다. 업로드된 SBOM(CycloneDX, SPDX)을 기반으로 컴포넌트별 취약점을 지속적으로 모니터링하고, 정책 위반 여부를 자동으로 평가합니다.

GitHub: https://github.com/DependencyTrack/dependency-track
공식 문서: https://docs.dependencytrack.org/
라이선스: Apache-2.0

주요 특징

SBOM 기반 지속 모니터링: SPDX 및 CycloneDX 형식의 SBOM을 업로드하면 컴포넌트별 최신 취약점을 자동으로 추적
다양한 취약점 데이터소스 연동: NVD, OSV, GitHub Advisories, VulnDB 등
정책 엔진: 라이선스 정책, 취약점 심각도 기준, 컴포넌트 사용 가능 여부를 규칙으로 정의하여 자동 평가
REST API: CI/CD 파이프라인과 통합하여 빌드 시 SBOM을 자동 업로드하고 결과를 피드백
웹 UI 대시보드: 프로젝트별 위험 점수, 취약점 현황, 라이선스 분포를 한눈에 파악
알림: Slack, 이메일, Webhook 등 다양한 채널로 신규 취약점 알림 발송

설치 방법

Docker Compose를 사용하는 방법이 가장 간편합니다.

오픈소스 관리 자동화 환경 구성: cdxgen + Dependency-Track

Mon, 01 Jan 0001 00:00:00 +0000

오픈소스 관리를 처음 시작하는 기업이 하루 안에 기본 자동화 환경을 갖출 수 있는 도구 조합으로 cdxgen + Dependency-Track을 권장합니다.

이 가이드는 설치·설정부터 라이선스·취약점 점검 환경 구성, 일상 운영까지 단계별로 안내합니다.

왜 cdxgen + Dependency-Track인가

오픈소스 관리의 핵심은 두 가지입니다.

무엇이 들어있는지 파악 — SBOM(Software Bill of Materials) 생성
위험 요소 지속 모니터링 — 취약점(CVE)·라이선스 정책 위반 탐지

cdxgen은 1번을, Dependency-Track은 2번을 담당합니다. 두 도구 모두 Apache-2.0 라이선스의 무료 오픈소스입니다.

전체 자동화 흐름

flowchart TD
 A["개발자 PC / CI·CD 파이프라인"] --> B["cdxgen 실행\n소스코드·컨테이너 이미지 스캔"]
 B -->|"CycloneDX SBOM (.json)"| C["Dependency-Track\n중앙 서버 자동 분석"]
 C --> D["취약점(CVE) 탐지\n→ 담당자 알림"]
 C --> E["라이선스 정책 위반\n→ 검토 요청"]

 style A fill:#2d3748,color:#fff
 style B fill:#2b6cb0,color:#fff
 style C fill:#2b6cb0,color:#fff
 style D fill:#c53030,color:#fff
 style E fill:#744210,color:#fff

이 조합을 선택한 이유

기준	내용
비용	두 도구 모두 무료 오픈소스 (Apache-2.0)
표준 준수	CycloneDX 형식 — ISO/IEC 5230 및 NTIA SBOM 요건 충족
광범위한 언어 지원	Java, Node.js, Python, Go, Rust 등 20개 이상
중앙 통합 관리	전사 프로젝트 취약점·라이선스 현황을 한 화면에서 파악
자동화 용이성	REST API 기반 — CI/CD 파이프라인 연동 간단

다른 도구와의 비교: FOSSology, SW360 등도 강력한 도구이지만 초기 설정 복잡도가 높습니다. 이 가이드의 조합은 하루 안에 기본 환경을 갖출 수 있도록 최소화했습니다. 각 도구의 상세 기능은 cdxgen 가이드와 Dependency-Track 가이드를 참고하세요.

SCANOSS

Mon, 01 Jan 0001 00:00:00 +0000

SCANOSS는 오픈소스 컴포넌트를 파일 단위뿐 아니라 스니펫(코드 조각) 단위까지 식별할 수 있는 소프트웨어 구성 분석(SCA) 도구입니다. 1억 개 이상의 파일을 인덱싱한 지식베이스(OSSKB, Open Source Knowledge Base)와 대조하여 라이선스·저작권 정보를 검출하고, CycloneDX·SPDX 형식의 SBOM을 자동으로 생성합니다.

GitHub: https://github.com/scanoss
공식 사이트: https://www.scanoss.com
라이선스: Apache-2.0

1. 주요 특징

스니펫 수준 매칭: 파일 전체가 아닌 코드 일부를 복사·수정한 경우도 출처 추적 가능
대규모 지식베이스: OSSKB에 1억 개 이상의 오픈소스 파일 인덱싱 — 주요 패키지 저장소와 GitHub 커버
SBOM 자동 생성: CycloneDX(JSON/XML) 및 SPDX 형식 출력 지원
CLI & REST API 이중 제공: scanoss-py(Python) CLI와 REST API를 모두 지원하여 자동화 통합이 용이
CI/CD 파이프라인 통합: GitHub Actions 등 CI 환경에서 커맨드 한 줄로 스캔 가능

2. 설치 방법

Python 3.8 이상 환경에서 pip로 설치합니다.

§3.1 프로그램 기반

Mon, 01 Jan 0001 00:00:00 +0000

§3.1.1 정책

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 1 — 기반 수립 단계에서 구축합니다. 전체 구축 로드맵 보기

1. 조항 개요

오픈소스 정책이 없는 기업은 개발자가 오픈소스 라이선스 의무를 인지하지 못한 채 소프트웨어를 배포하게 되며, 이는 저작권 침해 소송, 소스코드 강제 공개, 거래처 계약 해지 등 심각한 법적·사업적 위험으로 이어질 수 있다. §3.1.1은 이러한 위험을 예방하기 위해 오픈소스 라이선스 컴플라이언스를 관리하는 문서화된 정책을 수립하고, 조직 내 모든 프로그램 참여자가 정책의 존재를 인식할 수 있도록 전파할 것을 요구한다. 이 조항은 ISO/IEC 5230 프로그램 전체의 기반이 되며, 이후 모든 조항(역량·프로세스·산출물 등)은 이 정책 위에서 작동한다.

§3.2.1 외부 문의 대응

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 4 — 운영 체계 수립 단계에서 구축합니다. 전체 구축 로드맵 보기

1. 조항 개요

소프트웨어를 배포하는 기업은 제3자(고객, 오픈소스 저작권자, 연구자 등)로부터 오픈소스 라이선스 컴플라이언스에 관한 문의를 받을 수 있다. 이 문의에 제때 응답하지 못하면 저작권 침해 분쟁으로 확대될 위험이 있다. §3.2.1은 외부 문의를 접수할 수 있는 공개된 연락 수단을 마련하고, 내부적으로는 문의에 체계적으로 대응하기 위한 절차를 문서화하도록 요구한다. 이 조항은 공개 채널(입증자료 3.2.1.1)과 내부 대응 절차(입증자료 3.2.1.2) 두 가지를 모두 갖출 것을 요구한다.

§3.3.1 SBOM

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 3 — 프로세스 구축 단계에서 구축합니다. 전체 구축 로드맵 보기

1. 조항 개요

공급 소프트웨어에 어떤 오픈소스 컴포넌트가 포함되어 있는지 파악하지 못하면 라이선스 의무를 이행할 수 없고 보안 취약점 대응도 불가능하다. §3.3.1은 공급 소프트웨어를 구성하는 오픈소스 컴포넌트를 식별, 추적, 검토, 승인, 보관하는 절차를 수립하고, 그 절차가 실제로 이행되었음을 입증하는 컴포넌트 기록(SBOM)을 유지하도록 요구한다. 이 조항은 오픈소스 라이선스 컴플라이언스와 보안 보증의 핵심 인프라인 SBOM을 운영하는 기반이 된다.

§3.4.1 산출물

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 3 — 프로세스 구축 단계에서 구축합니다. 전체 구축 로드맵 보기

1. 조항 개요

라이선스 의무를 이행하려면 실제로 고지문, 소스코드 패키지 등 컴플라이언스 산출물을 준비하여 소프트웨어와 함께 제공해야 한다. §3.4.1은 식별된 라이선스가 요구하는 컴플라이언스 산출물을 준비하고 공급 소프트웨어와 함께 배포하는 절차, 그리고 산출물 사본을 일정 기간 보관하는 절차를 수립하도록 요구한다. 이 조항은 §3.3 검토·승인 단계의 결과물을 실제 배포와 보관으로 연결하는 단계다.

2. 해야 할 활동

라이선스별로 요구되는 컴플라이언스 산출물(NOTICES 파일, 소스코드 패키지, written offer 등)의 유형을 정의한다.
산출물을 준비하여 공급 소프트웨어와 함께 제공하는 절차를 문서화한다.
배포된 산출물의 사본을 일정 기간 보관하는 절차를 수립하고 문서화한다.
산출물 보관 기간을 정책에 명시한다 (업계 관행: 마지막 배포 후 최소 3년).
보관 절차가 올바르게 수행되었음을 입증하는 기록을 유지한다.

3. 요구사항 및 입증자료

조항 번호	요구사항 (KO)	입증자료
§3.4.1	공급 소프트웨어에 대해 식별된 컴플라이언스 산출물을 생성하기 위한 프로세스가 존재해야 한다.	3.4.1.1 식별된 라이선스가 요구하는 컴플라이언스 산출물을 준비하고, 이를 공급 소프트웨어와 함께 제공하기 위한 프로세스를 설명하는 문서화된 절차 3.4.1.2 공급 소프트웨어의 컴플라이언스 산출물 사본을 보관하기 위한 문서화된 절차. 이러한 절차가 올바르게 수행되었음을 입증하는 기록이 존재해야 함

영문 원문 보기

§3.4.1 Compliance Artifacts A process shall exist for creating the identified compliance artifacts for the supplied software.

Verification Material(s): 3.4.1.1 A documented procedure that describes the process under which the compliance artifacts are prepared and distributed with the supplied software as required by the identified licenses. 3.4.1.2 A documented procedure for archiving copies of the compliance artifacts of the supplied software - where the archive is planned to exist for a reasonable period of time since the last offer of the supplied software; at least 3 years is a common practice.

§3.5.1 기여

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 4 — 운영 체계 수립 단계에서 구축합니다. 외부 오픈소스 프로젝트 기여를 허용하지 않는 기업은 이 조항을 건너뛸 수 있습니다. 전체 구축 로드맵 보기

1. 조항 개요

많은 기업이 외부 오픈소스 프로젝트에 코드·문서·버그 리포트 등을 기여한다. 기여 활동은 커뮤니티 신뢰를 높이고 기술 영향력을 확대하지만, 회사 코드나 특허가 의도치 않게 공개될 수 있는 리스크도 수반한다. §3.5.1은 조직이 외부 오픈소스 기여를 허용하는 경우, 기여를 규율하는 문서화된 정책과 절차를 수립하고 프로그램 참여자가 그 존재를 인식하도록 할 것을 요구한다. 이 조항은 기여를 허용하지 않는 조직에는 적용되지 않으나, 허용하는 경우 세 가지 입증자료를 모두 갖추어야 한다.

§3.6.1 적합성

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 5 — 적합성 확인 및 유지 단계에서 구축합니다. Phase 1~4의 모든 입증자료를 갖춘 후 진행합니다. 전체 구축 로드맵 보기

1. 조항 개요

ISO/IEC 5230 인증을 받으려면 §3.1.4에서 정의한 프로그램이 이 규격의 모든 요구사항을 충족한다는 사실을 문서로 확인해야 한다. §3.6.1은 앞서 §3.1부터 §3.5까지의 모든 조항을 충족하였음을 공식적으로 선언하는 단계다. 이 조항은 규격 준수를 완결 짓는 최종 확인 절차로, 프로그램이 ISO/IEC 5230:2020 버전 2.1의 모든 요구사항을 만족한다는 조직의 공식 확인이 필요하다.

§4.1 프로그램 기반

Mon, 01 Jan 0001 00:00:00 +0000

§4.1.1 정책

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 1 — 기반 수립 단계에서 구축합니다. 전체 구축 로드맵 보기

1. 조항 개요

§4.1.1은 ISO/IEC 5230 §3.1.1(라이선스 컴플라이언스 정책)과 대응하는 조항이지만, 초점이 보안 보증으로 전환된다. 오픈소스 컴포넌트의 알려진 취약점과 새로 발견되는 취약점을 체계적으로 관리하는 정책이 문서화되어 있어야 하며, 그 정책이 조직 내부에 전파되어야 한다. ISO/IEC 5230 §3.1.1과의 핵심 차이점은 정책과 전파 절차 자체에 대한 정기 검토 프로세스를 요구한다는 점이다. 정책을 수립하는 것에 그치지 않고, 정책이 항상 유효하고 최신 상태를 유지하도록 검토 체계를 갖추어야 한다.

§4.2.1 접근성

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 4 — 운영 체계 수립 단계에서 구축합니다. 전체 구축 로드맵 보기

1. 조항 개요

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

§4.3.1 SBOM

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 3 — 프로세스 구축 단계에서 구축합니다. 전체 구축 로드맵 보기

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)을 수행할 수 없다.

§4.4.1 완전성

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 5 — 적합성 확인 및 유지 단계에서 구축합니다. Phase 1~4의 모든 입증자료를 갖춘 후 진행합니다. 전체 구축 로드맵 보기

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개 항목(★ 표시)을 추가로 확인하는 방식이 효율적이다.

0. OpenChain 살펴보기

Mon, 01 Jan 0001 00:00:00 +0000

이 섹션이 다루는 내용

OpenChain Project의 설립 배경, OpenChain 규격이 ISO/IEC 5230, ISO/IEC 18974 국제 표준으로 등록된 과정, 표준 인증의 세 가지 방법(자가 인증, 독립 평가, 제3자 인증), 글로벌·국내 기업의 적용 추세를 정리합니다. 이 섹션은 본 가이드의 도입부로, 다음 섹션부터 구체적인 준수 방법을 다룹니다.

1. OpenChain Project란?

오늘날 소프트웨어는 갈수록 그 규모와 복잡도가 커지고 있습니다. 하나의 소프트웨어를 개발하기 위해서는 자체 개발한 소프트웨어뿐 아니라 오픈소스, 타사 소프트웨어_{3rd party software}, 벤더의 SDK 등 소프트웨어 공급망에 걸친 다양한 소프트웨어가 사용될 수 있습니다.

폐쇄망 운영과 망분리 전환

Mon, 01 Jan 0001 00:00:00 +0000

이 페이지의 위치

이 가이드는 금융권의 오픈소스 활용·관리를 다룬다. 그 출발점이 폐쇄망이다. 반입·사내 미러·오프라인 취약점 관리는 식별, 사용 승인, 관리 등 모든 단계의 전제가 되므로, 여기에서 한 번 설명하고 각 단계 페이지에서는 “폐쇄망 적용 시” 박스로 이 페이지를 가리킨다.

여기서 만드는 문서: 반입 절차서와 반입 승인 기록, 망분리 예외 자체 위험평가서.

왜 폐쇄망을 먼저 다루는가

일반적인 오픈소스 실무는 인터넷 연결을 전제한다. 패키지 관리자로 의존성을 내려받고, 온라인 취약점 데이터베이스를 조회하며, 클라우드 기반 스캐너를 쓴다. 금융권의 중요 업무망과 핵심 시스템에서는 이 전제가 성립하지 않는다. 외부 통신이 차단된 환경에서는 오픈소스를 들여오는 일 자체가 통제 대상이 되고, 취약점 정보를 어떻게 얻을지가 먼저 풀어야 할 문제가 된다.

1. 조직

Mon, 01 Jan 0001 00:00:00 +0000

이 섹션이 다루는 요구사항

ISO/IEC 5230: 3.1.2.1, 3.1.2.2, 3.2.2.1
ISO/IEC 18974: 4.1.2.1, 4.1.2.2, 4.1.2.3, 4.2.2.1

먼저, 기업은 오픈소스 관리 업무를 담당할 조직을 구성해야 합니다.

조직 구성 시 고려해야 할 내용은 다음과 같습니다:

조직의 역할과 책임
각 역할의 필요 역량
각 역할을 담당할 조직/담당자

1. 조직의 역할과 책임 정의

ISO 표준은 공통적으로 다음과 같이 프로그램 내 여러 참여자의 역할과 책임을 기술한 문서를 요구합니다.

ISO/IEC 5230 - License Compliance

3.1.2.1 - A documented list of roles with corresponding responsibilities for the different participants in the program.
프로그램의 여러 참여자에 대한 역할과 각 역할의 책임을 나열한 문서

ISO/IEC 18974 - Security Assurance

4.1.2.1: A documented list of roles with corresponding responsibilities for the different Program Participants
여러 프로그램 참여자에 대한 각각의 책임을 나열한 문서

오픈소스 프로그램 매니저

오픈소스 관리 체계를 구축하기 위해서는 먼저 이를 책임지고 수행할 책임자가 필요합니다. 책임자는 오픈소스 프로그램 매니저 또는 오픈소스 컴플라이언스 담당자 등의 명칭으로 불리며, 여기서는 오픈소스 프로그램 매니저라는 용어를 사용합니다.

1. 조직 맥락과 리더십

Mon, 01 Jan 0001 00:00:00 +0000

1. 개요

ISO/IEC 42001 §4와 §5는 AI 관리 시스템의 기반이다. 조직이 어떤 AI 시스템을 운영하는지, 이해관계자가 누구인지, 최고경영진이 어떤 원칙으로 AI를 관리할지를 결정한다.

오픈소스 담당자 관점에서 §5.2(AI 정책)가 가장 중요한 교차점이다. AI 정책에 오픈소스 사용에 관한 원칙을 포함하면 ISO 5230 정책과 통합 운영이 가능하다.

2. §4 조직 맥락 — 오픈소스 관련 고려사항

§4.1 조직과 조직 맥락 이해

AI 관리 시스템의 목적에 영향을 미치는 내·외부 이슈를 파악할 때, 오픈소스 관련 외부 이슈를 포함한다:

3.1 정책

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 1 — 프로그램 기반 단계에서 구축한다. 전체 구축 로드맵 보기

1. 조항 개요

AI SBOM 정책이 없는 조직은 개발자가 모델과 데이터셋의 라이선스 의무를 인지하지 못한 채 AI 시스템을 배포하게 된다. AI에서는 추적할 대상이 코드를 넘어선다. 모델 가중치, 학습 데이터셋, 다른 모델에서 파생된 모델 트리가 각자 고유한 라이선스를 가지며, Llama 커뮤니티 라이선스나 RAIL 계열처럼 사용 목적을 제한하는 비표준 라이선스도 흔하다. 이런 의무를 놓치면 저작권 분쟁, 사용 제한 위반, 거래처 계약 해지로 이어진다.

3.10 거버넌스

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 4 — 거버넌스 단계에서 구축한다. 전체 구축 로드맵 보기

1. 조항 개요

거버넌스는 앞선 모든 조항을 하나로 묶어 AI 시스템 수명주기 전반에서 책임 있는 개발과 배포, 관리를 보장하는 틀이다. 정책(3.1)이 원칙을 세우고 라이선스 의무(3.5)와 AI SBOM(3.9)이 개별 프로세스를 만든다면, 거버넌스는 이들이 규제 변화와 모델 교체에도 일관되게 작동하도록 관리한다.

3.10은 AI 거버넌스 프레임워크, 정책, 관행을 갖출 것을 요구한다. 규격은 EU 인공지능법(EU AI Act), 히로시마 AI 프로세스(Hiroshima AI Process), 중국 글로벌 AI 거버넌스 이니셔티브(Global AI Governance Initiative) 같은 신흥 AI 법령의 준수를 강조하며, 윤리적 고려사항과 위험 관리, 투명성을 함께 다룬다. 핵심은 한 번 만든 프레임워크를 정기적으로 검토해 최신 규제와 모델 변화를 반영하는 것이다.

3.5 라이선스 의무

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 2 — AI 확장 프로세스 단계에서 구축한다. 전체 구축 로드맵 보기

1. 조항 개요

라이선스 의무는 AI SBOM 가이드가 ISO/IEC 5230에서 가장 크게 확장된 지점이다. 전통적 오픈소스 컴플라이언스가 코드의 라이선스를 검토했다면, AI에서는 검토 대상이 네 갈래로 늘어난다. AI 시스템의 코드, 모델 가중치, 데이터셋(학습·테스트·검증 데이터셋을 포함), 그리고 AI 시스템 자체의 라이선스다. 한 모델이 다른 여러 모델에서 파생되는 일이 흔해, 모델 트리(Model Tree)에 놓인 각 상위 모델이 저마다 고유한 라이선스를 가진다.

3.7 접근

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 3 — 운영 체계 단계에서 구축한다. 전체 구축 로드맵 보기

1. 조항 개요

공급망에서 AI 시스템을 주고받는 조직은 서로의 컴플라이언스를 확인해야 한다. 그러려면 외부에서 문의할 창구가 공개되어 있고, 그 문의에 조직이 대응할 준비가 되어 있어야 한다. 접근은 이 양방향을 보장한다.

3.7은 두 가지를 요구한다. 제3자가 AI SBOM 컴플라이언스 문의를 할 수 있는 수단을 공개적으로 명시하는 것과, 그 문의에 효과적으로 대응하는 내부 절차를 유지하는 것이다. AI에서는 모델과 데이터셋의 라이선스, 학습 데이터 출처, 모델 카드 같은 AI 고유 정보가 문의 대상에 더해진다.

AI 시스템의 오픈소스 관리

Mon, 01 Jan 0001 00:00:00 +0000

1. 개요

ISO/IEC 42001 §8.5(AI 시스템 생애주기)와 §8.6(AI 데이터 관리)는 AI 시스템 개발 단계에서 관리해야 할 요구사항을 다룬다. 오픈소스 관점에서는 AI 시스템에 사용하는 오픈소스 컴포넌트의 라이선스 컴플라이언스가 핵심이다.

2. §8.5 AI 시스템 생애주기 — 오픈소스 프레임워크 · 모델 관리

2.1 기획·설계 단계

AI 시스템 기획 단계에서 사용할 오픈소스 프레임워크와 모델을 선정할 때 라이선스를 사전에 검토한다.

라이선스 사전 검토 절차:

1. 사용 후보 컴포넌트 목록 작성
 (프레임워크명, 버전, 출처 URL)

2. 라이선스 확인
 - 프레임워크: PyPI, npm, GitHub README 확인
 - AI 모델: Hugging Face Model Card, 공식 저장소 확인

3. 라이선스 조건 검토 항목
 □ 상업적 사용 허용 여부
 □ 파생물(Fine-tuning 모델) 공개 의무 여부
 □ 저작권 고지 의무 여부
 □ 특허 조항 여부 (Apache 2.0의 명시적 특허 허여 등)
 □ MAU 또는 매출 기반 사용 제한 여부

4. 허용 불가 라이선스 식별 시 대안 컴포넌트 탐색

2.2 개발 단계

개발 중 새로운 오픈소스 컴포넌트를 추가할 때마다 라이선스를 확인하고 AI SBOM에 즉시 반영한다.

Appendix

Mon, 01 Jan 0001 00:00:00 +0000

Appendix 1. 담당자 현황

No	역할	책임	필요 역량	담당 조직	담당자
1	오픈소스 프로그램 매니저 (OSPM)	회사의 오픈소스 프로그램에 대한 총괄 책임을 담당합니다.	소프트웨어 개발 프로세스 이해 저작권 및 특허 이해 오픈소스 라이선스 컴플라이언스 전문 지식 커뮤니케이션 스킬	오픈소스 관리팀	[이름]
2	법무 담당	오픈소스 라이선스와 관련된 법적 위험을 평가하고 법적 자문을 제공합니다.	오픈소스 생태계 이해 소프트웨어 저작권 전문 지식 오픈소스 라이선스 전문 지식 법적 위험 평가 능력	법무팀	[이름]
3	IT 담당	오픈소스 분석 도구를 운영하고 자동화합니다.	오픈소스 라이선스 컴플라이언스 프로세스 이해 오픈소스 분석 도구 이해 IT 인프라 전문 지식 자동화 및 CI/CD 파이프라인 이해	IT팀	[이름]
4	보안 담당	오픈소스 보안 취약점 분석 도구를 운영합니다.	DevSecOps 이해 오픈소스 보안 취약점 분석 도구 이해 알려진 취약점 및 새로 발견된 취약점 전문 지식 위험 평가 및 관리 능력	보안팀	[이름]
5	개발 문화 담당	사내 개발자들이 오픈소스를 적극적으로 활용하도록 지원합니다.	소프트웨어 개발 프로세스 이해 오픈소스 라이선스 컴플라이언스 기본 지식 교육 및 트레이닝 설계 능력 오픈소스 커뮤니티 참여 경험	개발팀	[이름]
6	품질 담당	공급 소프트웨어 배포 시 오픈소스 라이선스 의무를 확인합니다.	소프트웨어 개발 프로세스 이해 오픈소스 라이선스 컴플라이언스 기본 지식 오픈소스 정책 이해 오픈소스 라이선스 기본 지식	품질보증팀	[이름]
7	OSRB (Open Source Review Board)	오픈소스 관리를 위한 정책과 프로세스를 수립 및 개선합니다.	오픈소스 정책 및 프로세스 전문 지식 협의체 운영 경험	OSRB	[이름]
8	OSPO (Open Source Program Office)	외부 오픈소스 프로젝트로의 기여와 사내 프로젝트 오픈소스 공개를 지원합니다.	오픈소스 커뮤니티 참여 경험 오픈소스 프로젝트 관리 능력	OSPO	[이름]

onot

Mon, 01 Jan 0001 00:00:00 +0000

오픈소스 컴플라이언스 산출물 중 하나인 오픈소스 고지문(NOTICE 파일)은 공급 소프트웨어에 포함된 오픈소스의 저작권과 라이선스 정보를 사용자에게 제공하기 위한 문서다. 고지문을 수동으로 작성하면 누락이나 오류가 발생하기 쉽다. onot은 이 과정을 자동화하는 도구다.

SK텔레콤은 사내에서 사용하는 오픈소스 고지문 자동 생성 도구를 onot이라는 이름으로 오픈소스로 공개하였다. 카카오에서도 주요 기능을 기여하는 방식으로 공동 개발에 참여하였다.

주요 특징

onot은 SPDX 문서 형식으로 작성된 SBOM을 입력받아 오픈소스 고지문 형식으로 자동 변환한다. Python 기반으로 가볍고 간단하게 사용할 수 있으며, 다음과 같은 특징을 가진다.

OWASP AIBOM Generator

Mon, 01 Jan 0001 00:00:00 +0000

개요

OWASP AIBOM Generator는 Hugging Face 모델 ID를 입력받아 모델 카드 메타데이터를 가져오고, CycloneDX 형식의 AI SBOM을 생성하는 오픈소스 도구다. OWASP Gen AI Security Project가 관리하며, 생성된 BOM이 얼마나 완전한지를 점수로 평가하는 기능이 특징이다.

cdxgen이 의존성을 빠르게 식별하되 라이선스를 비워 두는 것과 달리, 이 도구는 모델 카드에 적힌 라이선스와 작성자, 외부 참조를 채운다. 3.5 라이선스 의무가 요구하는 라이선스 검토의 출발점으로 쓰기 좋다.

주요 기능

Hugging Face 모델의 메타데이터를 가져와 CycloneDX 1.6과 1.7 형식 AIBOM을 생성한다.
생성된 BOM의 완전성을 점수(0~100)와 프로파일로 평가하고 섹션별로 분해해 보여준다.
모델 정보, 모델 카드, 라이선스, 외부 참조를 사람이 읽기 쉬운 화면으로 보여준다.
웹 UI와 명령줄(CLI) 두 가지로 쓸 수 있다.

사용법 A — 웹 UI

브라우저에서 모델 ID만 넣으면 되어 가장 간단하다. OWASP Gen AI Security Project가 제공하는 Hugging Face Space를 쓰거나, 저장소를 받아 로컬에서 띄운다.

오픈소스 정책

Mon, 01 Jan 0001 00:00:00 +0000

Note:

This sample open source policy was written with reference to the following two materials.

Author : OpenChain Korea Work Group Authors / CC BY 4.0

1. 목적 및 적용 범위

1.1 목적

이 정책은 회사가 오픈소스 소프트웨어를 안전하고 효과적으로 활용하기 위한 원칙과 절차를 제공합니다. 정책의 주요 목적은 다음과 같습니다:

오픈소스 라이선스 컴플라이언스:
- 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 라이선스 의무를 준수하고, 관련 법적 요구사항을 충족합니다.
오픈소스 보안 보증:
- 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안 취약점을 식별하고, 적절한 대응 조치를 통해 보안 위험을 최소화합니다.
외부 오픈소스 프로젝트로의 기여:
- 외부 오픈소스 프로젝트에 기여함으로써 오픈소스 커뮤니티와의 협업을 촉진하고, 회사의 지식재산을 보호합니다.
사내 프로젝트의 오픈소스화:
- 내부 프로젝트를 오픈소스로 공개하여 오픈소스 커뮤니티와의 협력을 증진시키고, 회사의 기술력을 홍보합니다.

이러한 원칙은 ISO/IEC 5230(오픈소스 라이선스 컴플라이언스) 및 ISO/IEC 18974(오픈소스 보안 보증)의 요구사항을 충족하도록 설계되었습니다.

자가점검 워크북

Mon, 01 Jan 0001 00:00:00 +0000

이 워크북은 자가점검 페이지의 점검 항목을 기록용 양식으로 옮긴 것이다. 점검만 하고 끝내지 않고, 부족한 부분의 담당자와 기한을 적어 개선 계획으로 잇기 위한 것이다.

쓰는 방법

각 항목의 충족 상태를 세 단계로 표시한다.

미충족: 관련 활동이나 문서가 없다.
부분 충족: 활동은 있으나 문서나 기록이 부족하다.
충족: 활동과 근거 문서를 모두 갖췄다.

부분 충족이나 미충족 항목에는 근거 문서가 무엇이어야 하는지, 누가 언제까지 갖출지를 적는다. 충족 항목에는 근거 문서의 이름과 위치를 적어, 그대로 ISO 자가 인증의 입증자료로 쓸 수 있게 한다.

프로그램 기반

Mon, 01 Jan 0001 00:00:00 +0000

구축 로드맵의 1단계다. 프로그램의 범위를 정하고(3.4), 정책을 수립하며(3.1), 참여자의 역량과 인지를 확보한다(3.2, 3.3). 이후의 모든 조항이 이 기반 위에서 작동한다.

TRUSCA

Mon, 01 Jan 0001 00:00:00 +0000

기업이 오픈소스 컴포넌트의 취약점과 라이선스를 관리하려면 SCA(Software Composition Analysis) 도구가 필요하다. 상용 제품이 여럿 있으나, 사내에 직접 설치해 운영할 수 있는 오픈소스 도구를 찾는 경우도 있다.

TRUSCA는 이러한 용도로 공개된 자체 호스팅 SCA 포털이다. Apache 2.0 라이선스로 배포하며, 취약점(CVE), 라이선스 컴플라이언스, SBOM 관리를 하나의 화면에서 다룬다. KWG 커뮤니티 활동에서 출발한 Trusted OSS 프로젝트가 개발하고 있다.

주요 특징

30여 개 언어 생태계의 컴포넌트 검출(cdxgen 기반), 직접 의존성과 전이 의존성 구분
Trivy 통합 데이터베이스(NVD, OSV, GitHub Advisory, EPSS, KEV) 기반 취약점 검출과 7단계 VEX 분류 절차, EPSS 점수 기반 우선순위 지정
라이선스 분류(허용, 조건부, 금지)와 의무사항 추적, 고지문(NOTICE) 자동 생성
SBOM 내보내기(CycloneDX JSON·XML, SPDX JSON·Tag-Value)와 외부에서 만든 SBOM 가져오기
컴포넌트 승인 절차(검토 대기, 검토 중, 승인, 반려), 감사 로그, 역할 기반 권한 관리
GitHub Action, GitLab CI 템플릿, Jenkinsfile 예시 제공. 심각한 취약점이나 금지 라이선스가 검출되면 빌드를 중단하도록 설정할 수 있다
한국어와 영어 화면 지원

설치

Docker Compose로 개발 환경을 띄울 수 있다.

§3.1.2 역량

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 2 — 역량 및 교육 단계에서 구축합니다. 전체 구축 로드맵 보기

1. 조항 개요

오픈소스 프로그램이 실제로 작동하려면 관련 역할을 맡은 사람들이 그 역할을 수행할 역량을 갖추어야 한다. 역할과 책임이 문서에만 적혀 있고 담당자가 오픈소스 라이선스나 보안 취약점 관리에 대한 기본 지식도 없다면, 정책과 프로세스는 유명무실해진다. §3.1.2는 프로그램에 관여하는 역할을 식별하고 각 역할에 필요한 역량을 정의하며, 참여자가 실제로 그 역량을 갖추었는지 평가하고 기록하도록 요구한다. 이 조항은 §3.1.1 정책에서 정의한 역할 구조를 구체적인 역량 체계로 발전시키는 단계다.

§3.2 관련 업무

Mon, 01 Jan 0001 00:00:00 +0000

§3.2.2 효과적 리소스

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 1 — 기반 수립 단계에서 구축합니다. 전체 구축 로드맵 보기

1. 조항 개요

오픈소스 프로그램이 실제로 작동하려면 역할을 정의하는 것만으로는 부족하다. 각 역할을 담당할 실제 인원이 배정되고, 업무 수행에 필요한 시간과 예산이 충분히 지원되어야 한다. §3.2.2는 프로그램 역할별 담당자를 문서로 명시하고, 인원 배치와 예산이 적절히 이루어졌음을 확인하며, 법률 자문 접근 방법과 내부 책임 할당 절차, 미준수 사례 처리 절차를 갖출 것을 요구한다. 이 조항은 5개의 입증자료 항목으로 구성되어 §3.1 프로그램 기반에서 정의한 역할 구조를 실제 운영 체계로 구현하는 단계다.

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

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 3 — 프로세스 구축 단계에서 구축합니다. 전체 구축 로드맵 보기

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.

§3.6.2 지속 기간

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 5 — 적합성 확인 및 유지 단계에서 구축합니다. 전체 구축 로드맵 보기

1. 조항 개요

ISO/IEC 5230 인증은 한 번 취득으로 영구히 유효하지 않다. 규격의 새 버전이 발행되면 이전 버전 기준으로 인증을 받은 프로그램은 새 버전 발행 후 18개월까지만 적합성이 유지된다. §3.6.2는 프로그램이 적합성 인증을 취득한 날로부터 최근 18개월 이내에 규격의 모든 요구사항을 충족하고 있음을 확인하는 문서를 유지하도록 요구한다. 이 조항은 오픈소스 컴플라이언스 프로그램이 형식적 인증에 그치지 않고 지속적으로 운영되는지 확인하는 장치다.

§4.1.2 역량

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 2 — 역량 및 교육 단계에서 구축합니다. ISO/IEC 5230 대비 참여자 목록(4.1.2.3), 주기적 검토 증거(4.1.2.5), 내부 모범 사례 일치 검증(4.1.2.6) 3개 항목이 추가됩니다. 전체 구축 로드맵 보기

★ 18974 전용 항목 — Documented Evidence 강도

§4.1.2.3, §4.1.2.5, §4.1.2.6은 ISO 18974 전용(★) 항목으로 Documented Evidence(문서화된 증거)를 요구한다. 단순 절차 문서로는 부족하며, 실제 수행 기록(참여자 목록, 검토 회의록, 내부 모범 사례 비교 결과)을 함께 보관해야 한다. 강도 차이의 자세한 설명은 §4.1.5 표준 관행 — Documented Evidence 안내를 참고한다.

§4.2 관련 업무

Mon, 01 Jan 0001 00:00:00 +0000

§4.2.2 효과적 리소스

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 1 — 기반 수립 단계에서 구축합니다. 전체 구축 로드맵 보기

★ 18974 전용 항목 — Documented Evidence 강도

§4.2.2.3은 ISO 18974 전용(★) 항목으로 Documented Evidence(문서화된 증거)를 요구한다. 취약점 해결 자원 접근 방법은 단순 절차 문서가 아니라 실제 자원 활용 이력(보안 자문 계약·계정 발급 기록·접근 로그 등)을 함께 보관해야 한다. 강도 차이의 자세한 설명은 §4.1.5 표준 관행 — Documented Evidence 안내를 참고한다.

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에서는 취약점 해결 전문성으로 대체된다. 라이선스 법률 자문이 아니라, 알려진 취약점을 실제로 해결할 수 있는 기술적·보안 전문성을 확보하고 그 접근 방법을 문서화해야 한다.

§4.3.2 보안 보증

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 3 — 프로세스 구축 단계에서 구축합니다. ISO/IEC 18974 전용 신규 조항으로, 취약점 탐지·해결 절차와 조치 기록을 수립합니다. 전체 구축 로드맵 보기

★ 18974 전용 항목 — Documented Evidence 강도

§4.3.2.1과 §4.3.2.2는 ISO 18974 전용(★) 항목으로 Documented Evidence(문서화된 증거)를 요구한다. 단순 “취약점 대응 절차 문서"가 아니라 각 CVE에 대한 실제 수행 기록(스캔 결과, CVSS 점수, 조치 이력, VEX 발행, 고객 통보 이력 등)을 보관해야 한다. 강도 차이의 자세한 설명은 §4.1.5 표준 관행 — Documented Evidence 안내를 참고한다.

§4.4.2 기간

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 5 — 적합성 확인 및 유지 단계에서 구축합니다. 전체 구축 로드맵 보기

1. 조항 개요

§4.4.2는 ISO/IEC 5230 §3.6.2(지속 기간)와 동일한 구조다. 적합성 인증을 취득한 후 지난 18개월 동안 이 규격의 모든 요구사항을 충족해 왔음을 확인하는 회고형 문서를 유지하도록 요구한다 (미래형 보장 선언이 아닌 과거 사실 확인 문서). 규격의 새 버전이 발행되면 18개월의 유예 기간 동안 이전 버전 기준 인증이 유지되며, 유예 기간 내에 최신 버전 기준으로 갱신하는 것을 권장한다.

거버넌스: 관리 조직과 승인 체계

Mon, 01 Jan 0001 00:00:00 +0000

이 페이지의 위치

거버넌스는 오픈소스 관리의 기반이다. 누가 책임지고, 누가 검토하며, 누가 승인하는지를 먼저 정해야 식별, 사용 승인, 관리 단계가 작동한다. FSEC 안내서도 관리 절차에 앞서 관리 조직 구성과 역할을 별도로 다룬다.

여기서 만드는 문서: 오픈소스 정책, 역할·책임 목록과 담당자 지정 기록.

금융권 거버넌스의 출발점

금융분야 오픈소스 소프트웨어 활용·관리 안내서(금융감독원·금융보안원, 2022, 이하 FSEC 안내서)는 관리 조직의 구성과 운영, 역할 사례를 제시한다. ISO/IEC 5230은 이를 입증자료로 요구한다. 문서화된 정책(3.1.1.1), 역할과 책임 목록(3.1.2.1), 역할 담당자 명시(3.2.2.1), 법률 자문 접근 방법(3.2.2.3)이 그것이다. 거버넌스는 이 입증자료들을 만들어 내는 활동이다.

2. 기획

Mon, 01 Jan 0001 00:00:00 +0000

1. 개요

ISO/IEC 42001 §6은 AI 시스템과 관련된 리스크와 기회를 체계적으로 파악하고 대응하는 방법을 요구한다. 특히 **§6.1.2(AI 리스크 평가)**와 **§6.1.4(AI 시스템 영향 평가)**는 오픈소스 컴포넌트로 인해 발생할 수 있는 리스크를 포함하는 데 직접 활용된다.

2. §6.1.2 AI 리스크 평가 — 오픈소스 리스크 포함 ★

ISO/IEC 42001은 AI 시스템과 관련된 리스크를 식별·분석·평가하는 프로세스를 요구한다. 오픈소스 담당자는 이 프로세스에 오픈소스 라이선스 리스크와 보안 취약점 리스크를 명시적으로 포함해야 한다.

오픈소스 관련 AI 리스크 유형

리스크 유형	원인	영향	대응 방법
라이선스 비준수	AI 모델의 커스텀 라이선스 조건 미확인	법적 분쟁, 서비스 중단	사용 전 라이선스 검토 의무화
GPL 오염	Copyleft 라이선스 AI 컴포넌트와 독점 코드 결합	소스 코드 공개 의무 발생	라이선스 호환성 사전 검토
모델 라이선스 조건 위반	MAU 제한, 용도 제한 조건 미충족	라이선스 취소, 손해배상	조건별 준수 여부 정기 점검
오픈소스 취약점	AI 프레임워크 또는 의존성의 CVE	시스템 침해, 데이터 유출	정기 SCA 스캔, 패치 적용
데이터셋 라이선스 위반	CC-BY-NC 데이터를 상업 서비스에 사용	저작권 침해	데이터셋 라이선스 재검토
공급망 리스크	외부 오픈소스 모델의 라이선스 변경	서비스 연속성 위협	공급망 모니터링 체계 구축

AI 리스크 평가서에 포함할 오픈소스 항목

## AI 리스크 평가서 — 오픈소스 리스크 섹션

### 평가 대상 AI 시스템: [시스템명]
### 평가 일자: YYYY-MM-DD

| # | 리스크 항목 | 현재 사용 컴포넌트 | 가능성 | 영향도 | 리스크 수준 | 대응 조치 |
|---|------------|-----------------|:----:|:----:|:---------:|---------|
| 1 | 라이선스 비준수 | [모델명 · 라이선스] | 중 | 상 | 높음 | 법무 검토 |
| 2 | OSS 취약점 | [프레임워크명 · 버전] | 중 | 상 | 높음 | SCA 스캔 |
| 3 | 데이터셋 라이선스 | [데이터셋명 · 라이선스] | 저 | 중 | 중간 | 라이선스 재확인 |

ISO/IEC 18974와의 연계

AI 시스템에 사용된 오픈소스 취약점 리스크는 ISO/IEC 18974의 §4.3.2(보안 보증) 요구사항과 직접 연결된다. 18974의 취약점 탐지·평가 프로세스를 AI 시스템에도 적용하면 별도의 리스크 평가 체계를 구축하지 않아도 된다.

관련 가이드: ISO/IEC 18974 — §4.3.2 보안 보증

2. 정책

Mon, 01 Jan 0001 00:00:00 +0000

이 섹션이 다루는 요구사항

ISO/IEC 5230: 3.1.1.1, 3.1.4.1, 3.2.1.1, 3.2.2.2, 3.2.2.3, 3.2.2.4, 3.2.2.5, 3.5.1.1
ISO/IEC 18974: 4.1.1.1, 4.1.4.1, 4.1.4.2, 4.1.4.3, 4.2.1.1, 4.2.2.2, 4.2.2.3, 4.2.2.4

금융권이라면

금융권은 정책에 폐쇄망 반입 통제, 망분리 예외 자체 위험평가, 외주·전자금융보조업자의 SBOM 제출 요구 같은 고유 항목을 더해야 한다. 금융 변형 정책의 골격과 절차는 금융분야 오픈소스 관리 실무 가이드에서 다룬다.

1. 오픈소스 정책 문서화

기업은 공급 소프트웨어 개발, 서비스, 배포에 관여하는 조직이 올바르게 오픈소스를 활용하기 위한 원칙으로 구성된 오픈소스 정책을 수립하여 문서화하고 이를 조직 내 전파해야 합니다.

3.2 역량

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 1 — 프로그램 기반 단계에서 구축한다. 전체 구축 로드맵 보기

1. 조항 개요

정책(3.1)이 무엇을 해야 하는지 정한다면, 역량은 그 일을 할 수 있는 사람을 보장한다. AI SBOM 컴플라이언스는 코드 라이선스만 다루던 오픈소스 컴플라이언스보다 넓은 지식을 요구한다. 모델 가중치와 데이터셋의 라이선스, 모델 카드 해석, 신흥 AI 규제, 비표준 라이선스의 사용 제한까지 판단해야 한다.

3.2는 프로그램의 성과에 영향을 미치는 역할과 책임을 식별하고, 각 역할에 필요한 역량을 정해 참여자가 그 역량을 갖추도록 보장할 것을 요구한다. 규격은 사용 사례와 관련된 경우 거버넌스, 보안, 안전, 프라이버시, 개발, 공급자 관리 기능의 역량을 갖추도록 명시한다.

3.6 투명성 의무

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 2 — AI 확장 프로세스 단계에서 구축한다. 전체 구축 로드맵 보기

1. 조항 개요

3.6은 규제로부터 부과되는 투명성 의무가 있는지 검토하는 절차를 갖출 것을 요구한다. 검토 대상에는 학습·테스트·검증 데이터셋이 포함되며, 모델의 의도된 용도를 고려한다. 학습 데이터의 사용 사례가 투명성 쟁점(예: 다운스트림 수령자에 대한 공개 의무)을 야기하면 적절한 위험 완화 조치를 취해야 한다. EU 인공지능법이 2026년 8월부터 투명성 의무를 본격 적용하면서 이 조항의 실무 비중이 커지고 있다.

3.8 효과적 자원 배분

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 3 — 운영 체계 단계에서 구축한다. 전체 구축 로드맵 보기

1. 조항 개요

역량(3.2)이 “누가 무엇을 할 수 있어야 하는가"를 정의한다면, 효과적 자원 배분은 그 역할에 실제로 사람과 시간, 예산을 붙여 프로그램이 작동하게 만든다. 정책과 절차가 문서로만 존재하고 자원이 없으면 컴플라이언스는 이름뿐이다.

3.8은 프로그램 과제에 책임을 배정하고 충분한 자원을 배분할 것을 요구한다. 입증자료는 다섯 가지로, 역할 담당자 명시, 인력과 재원 제공, 법률 전문성 접근, 내부 책임 배정 절차, 부적합 시정 절차를 다룬다. 규격은 ISO/IEC 42001 부속서 B(Annex B)의 자원 관련 절(B.4.2, B.4.6)과 인간 감독 판단 절(B.9.3)을 참조로 든다.

AI SBOM

Mon, 01 Jan 0001 00:00:00 +0000

1. AI SBOM이란?

AI SBOM(AI System Bill of Materials) 은 AI 시스템을 구성하는 모든 요소의 목록과 그 출처·라이선스를 문서화한 것이다. 소프트웨어 SBOM(ISO/IEC 5230 §3.3.1)의 개념을 AI 시스템으로 확장한 것으로, ISO/IEC 42001 §7.5(문서화된 정보) 요구사항의 핵심 산출물이다.

AI SBOM이 필요한 이유: 투명성과 규제 대응

AI SBOM은 AI 시스템의 투명성과 설명 가능성을 확보하는 핵심 수단이다. ISO/IEC 42001 Appendix C.2.11은 투명성과 설명 가능성을 AI 관리 시스템의 핵심 목표로 명시한다.

요구 주체	근거	AI SBOM 역할
ISO/IEC 42001	Appendix C.2.11 (투명성·설명 가능성)	AI 시스템 구성 투명성 확보
EU AI Act	고위험 AI 시스템 기술 문서 요건	학습 데이터·모델 출처 명시
EU Cyber Resilience Act(CRA)	AI 제품의 투명성 의무	컴포넌트 목록 및 취약점 추적
OpenChain AI Work Group	AI SBOM Compliance Guide	공급망 내 AI SBOM 표준 절차

ISO/IEC 42003과 AI SBOM

ISO/IEC 42001의 구현 가이드인 ISO/IEC 42003(개발 중)에 AI SBOM 관련 구체적 요구사항이 포함될 예정이다. OpenChain AI Work Group은 AI SBOM 가이드를 42003의 §6.2(AI 목표)와 Appendix C.2.11(투명성·설명 가능성)에 반영하는 것을 추진 중이다.

AI 확장 프로세스

Mon, 01 Jan 0001 00:00:00 +0000

구축 로드맵의 2단계다. AI SBOM 가이드가 ISO/IEC 5230에서 가장 크게 확장된 영역으로, 라이선스 의무(3.5)와 투명성 의무(3.6), AI SBOM 생성·관리(3.9)를 다룬다.

cdxgen

Mon, 01 Jan 0001 00:00:00 +0000

개요

cdxgen은 OWASP CycloneDX 프로젝트의 공식 SBOM 생성기다. 20개 이상의 언어와 패키지 매니저를 지원하고, 최신 버전에서 AI BOM 전용 모드를 제공한다. AI 애플리케이션의 의존성(PyTorch, Transformers 등)을 자동으로 식별하며, CI/CD 파이프라인에 연동하기 좋다.

AI SBOM 관점에서 cdxgen의 강점은 속도와 자동화다. 약점은 라이선스 정보를 기본 실행에서 채우지 않는다는 점이다. 아래 실행 결과에서 이 특성이 드러난다. OWASP AIBOM Generator가 모델 카드 메타데이터 중심이라면, cdxgen은 코드와 의존성 중심이다. 둘을 함께 쓰면 모델과 의존성을 모두 다룬다.

ISO/IEC 5230 준수 가이드

Mon, 01 Jan 0001 00:00:00 +0000

이 가이드는 ISO/IEC 5230(OpenChain License Compliance)의 각 요구사항 조항을 하나씩 풀어서 설명한다. 각 조항이 요구하는 입증자료가 무엇인지, 어떻게 준수할 수 있는지, 바로 활용할 수 있는 샘플 문서는 무엇인지 안내한다.

Author : OpenChain Korea Work Group / CC BY 4.0

대상 독자

오픈소스 컴플라이언스 담당자 및 오픈소스 프로그램 매니저
처음 오픈소스 관리 체계를 구축하는 신규 담당자
ISO/IEC 5230 인증 취득을 준비 중인 기업의 담당자
기존 오픈소스 관리 체계를 ISO 표준 기준으로 점검하고 싶은 실무자

이 가이드의 활용 방법

기업 오픈소스 관리 가이드와의 관계

이 가이드는 처음 구축하는 담당자와 인증을 준비하는 담당자 모두에게 활용할 수 있다. 아래 단계별 구축 로드맵을 따라가면 구축 순서와 각 단계에서 만들어야 할 산출물을 파악할 수 있고, 각 조항 페이지에서 구체적인 구현 방법과 샘플을 확인할 수 있다.

기업 오픈소스 관리 가이드 는 조직, 정책, 프로세스, 도구, 교육 영역을 실무 관점으로 설명하는 보완 가이드다. 두 가이드의 각 조항·섹션은 서로 교차 링크로 연결되어 있다.

오픈소스 프로세스

Mon, 01 Jan 0001 00:00:00 +0000

Note:

This sample open source process was written with reference to the following two materials.

Author : OpenChain Korea Work Group Authors / CC BY 4.0

[회사명](이하 “회사"라 함)는 소프트웨어를 포함하는 공급 소프트웨어를 개발하면서 오픈소스 소프트웨어를 적극적으로 활용합니다. 회사는 오픈소스 리스크를 최소화하기 위해 공급 소프트웨어를 배포하면서 (1) 오픈소스 라이선스가 부과하는 의무사항을 준수하기 위한 활동과 (2) 오픈소스 보안 취약점을 검출하고 후속 조치를 위한 적절한 활동을 수행해야 합니다. 이러한 활동을 보장하기 위해 오픈소스 프로세스를 따릅니다.

정책·절차 템플릿

Mon, 01 Jan 0001 00:00:00 +0000

여기 담은 양식은 금융권 고유 항목을 보강한 골격이다. 일반 오픈소스 정책과 프로세스 양식은 기존 정책·절차 템플릿 가이드를 쓰고, 금융권에서 추가로 필요한 반입 통제, 망분리 예외 위험평가, 외주 SBOM 요구는 아래 양식으로 채운다.

활용 안내

아래 골격은 그대로 쓰는 완성본이 아니라 채워 넣을 틀이다. 대괄호로 표시한 부분은 조직 상황에 맞게 바꾼다. 발행 전 사내 법무·보안 검토를 거친다.

금융 오픈소스 정책 (보강 항목)

기존 오픈소스 정책에 금융권 고유 항목을 더한다. 아래는 정책에 포함할 항목의 골격이다.

§3.1.3 인식

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 2 — 역량 및 교육 단계에서 구축합니다. 전체 구축 로드맵 보기

1. 조항 개요

역할과 역량을 갖춘 참여자라도 오픈소스 프로그램의 목적과 자신의 기여가 전체 컴플라이언스 체계에 어떤 의미를 갖는지 인식하지 못하면 형식적 참여에 그치게 된다. §3.1.3은 프로그램 참여자가 프로그램의 목표, 자신의 기여 방법, 그리고 프로그램을 준수하지 않을 경우 발생하는 결과를 실제로 인식하고 있음을 평가하고 기록할 것을 요구한다. 이 조항은 §3.1.2 역량(지식·기술 보유)의 다음 단계로, 참여자가 보유한 역량을 프로그램 목적과 연결하여 실질적 동기를 형성하는 단계다.

§3.3 콘텐츠 검토 및 승인

Mon, 01 Jan 0001 00:00:00 +0000

§4.1.3 인식

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 2 — 역량 및 교육 단계에서 구축합니다. 전체 구축 로드맵 보기

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.3 콘텐츠 검토 및 승인

Mon, 01 Jan 0001 00:00:00 +0000

식별: 쓰고 있는 오픈소스를 빠짐없이 찾기

Mon, 01 Jan 0001 00:00:00 +0000

이 페이지의 위치

식별은 관리의 출발점이다. 무엇을 쓰는지 모르면 취약점도 라이선스 의무도 관리할 수 없다. FSEC 안내서의 첫 절차이고, ISO/IEC 5230의 SBOM 관리(3.3.1)가 요구하는 활동이다.

여기서 만드는 문서: SBOM, 운영 자산 인벤토리.

무엇을 식별하는가

오픈소스를 식별한다는 것은 세 종류를 모두 찾아낸다는 뜻이다.

신규로 들여오는 오픈소스. 개발자가 새로 도입하는 라이브러리와 그 의존성.
이미 운영 중인 시스템에 들어 있는 오픈소스. 도입 시점에 기록하지 못한 레거시.
외주 개발사나 전자금융보조업자가 만든 산출물에 포함된 오픈소스. 외주 개발사(업무를 위탁받은 수탁자)와 전자금융보조업자(전자금융거래법상 금융회사를 위해 전자금융거래를 보조하는 자)는 법적으로 다른 범주지만, 산출물의 오픈소스를 식별해야 한다는 점은 같다.

직접 선언한 의존성만이 아니라 그것이 끌어오는 전이 의존성까지 펼쳐야 한다. 실제 위험은 대부분 직접 보지 않는 하위 의존성에 숨어 있다.

3. 지원

Mon, 01 Jan 0001 00:00:00 +0000

1. 개요

ISO/IEC 42001 §7은 AI 관리 시스템을 운영하는 데 필요한 역량, 인식, 커뮤니케이션, 문서화를 다룬다. 오픈소스 담당자 관점에서는 **§7.2(역량)**과 **§7.5(문서화된 정보)**가 핵심 교차점이다.

2. §7.2 역량 — AI 오픈소스 관리 역량 ★

ISO/IEC 42001은 AI 관련 역할을 수행하는 인원이 필요한 역량을 갖추도록 요구한다. 오픈소스 컴플라이언스 관점에서 AI 개발·운영 인원에게 다음 역량이 포함되어야 한다.

AI 오픈소스 관리 역량 요소

역량 영역	내용	관련 교육
AI 프레임워크 라이선스 이해	PyTorch·TensorFlow 등 주요 라이선스 조건 파악	오픈소스 라이선스 교육
AI 모델 라이선스 검토	커스텀 라이선스 조건(사용 제한, 파생물 처리) 분석	법무팀 협업 교육
AI SBOM 작성	SPDX 3.0 AI 프로파일 기반 AI SBOM 구성 방법	AI SBOM 실습
오픈소스 취약점 관리	AI 시스템 의존성 SCA 스캔 및 CVE 대응	DevSecOps 교육
오픈 데이터 라이선스	CC 계열 라이선스 조건 및 데이터셋 사용 규칙	데이터 라이선스 교육

기존 오픈소스 역량 체계와의 통합

ISO/IEC 5230 역량 체계 확장

기업이 ISO/IEC 5230 기반의 역량·교육 체계를 이미 운영 중이라면, 기존 오픈소스 교육 과정에 AI 특화 모듈을 추가하는 방식으로 확장한다.

추가 모듈 예시:

AI 모델 라이선스 이해 (1시간)
AI SBOM 작성 실습 (2시간)
AI 공급망 오픈소스 검증 방법 (1시간)

관련 가이드: 기업 오픈소스 관리 가이드 — 5. 교육

3. 프로세스

Mon, 01 Jan 0001 00:00:00 +0000

이 섹션이 다루는 요구사항

ISO/IEC 5230: 3.1.5.1, 3.2.1.2, 3.3.1.1, 3.3.2.1, 3.4.1.1, 3.5.1.2
ISO/IEC 18974: 4.1.2.5, 4.1.2.6, 4.1.5.1, 4.2.1.2, 4.3.1.1, 4.3.2.1, 4.3.2.2

오픈소스 프로세스는 소프트웨어 개발 및 배포 과정에서 기업이 오픈소스 정책을 준수할 수 있도록 하는 실행 가능한 절차입니다.

오픈소스 라이선스 컴플라이언스 측면에서는 공급 소프트웨어를 개발하고 배포하면서 사용한 오픈소스에 대해 각 라이선스가 요구하는 조건을 준수하기 위한 활동을 수행하여 오픈소스 고지문(Notice), 공개할 소스 코드 (Source Code) 등의 컴플라이언스 산출물을 생성하게 됩니다.

3.3 인지

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 1 — 프로그램 기반 단계에서 구축한다. 전체 구축 로드맵 보기

1. 조항 개요

역량(3.2)이 “할 수 있는가"를 다룬다면, 인지는 “왜 해야 하는지 아는가"를 다룬다. 참여자가 정책의 존재만 아는 것으로는 부족하다. 자신의 일이 프로그램에 어떻게 기여하는지, 지키지 않으면 무슨 일이 생기는지까지 알아야 컴플라이언스가 실제로 작동한다.

3.3은 프로그램 참여자가 네 가지를 인지하도록 보장할 것을 요구한다. AI SBOM 정책, 관련 사업 목표, 프로그램 효과성에 대한 자신의 기여, 그리고 프로그램 요구사항을 따르지 않을 경우의 영향이다. AI 에서는 미준수의 영향이 저작권 분쟁을 넘어 규제 위반과 사용 제한 위반으로 확장되므로, 참여자가 이 점을 분명히 인지하게 한다.

3.9 AI SBOM

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 2 — AI 확장 프로세스 단계에서 구축한다. 전체 구축 로드맵 보기

1. 조항 개요

AI SBOM(AI System Bill of Materials)은 AI 시스템을 구성하는 요소와 그 정보를 담은 목록이다. 전통적 SBOM이 소프트웨어 컴포넌트를 기록한다면, AI SBOM은 여기에 모델, 가중치, 데이터셋, 하이퍼파라미터를 더한다. 3.9는 AI SBOM을 생성하고 관리하는 절차를 갖출 것을 요구한다.

형식은 정해두지 않는다. 규격은 SPDX, CycloneDX, 또는 그 밖의 형식 등 어떤 것이든 무방하다고 명시한다. 다만 한 가지 의무가 있다. AI SBOM은 제3자로부터 유입되는 자재(inbound materials)를 반영해야 한다. 외부에서 도입한 사전학습 모델과 데이터셋이 빠지면 라이선스 의무(3.5)와 투명성 의무를 추적할 근거가 사라지기 때문이다.

AI 공급망 검증

Mon, 01 Jan 0001 00:00:00 +0000

1. 개요

ISO/IEC 42001 §8.8은 외부에서 조달하는 AI 시스템(모델, API, 서비스)을 사용할 때 적절한 평가와 검증을 수행할 것을 요구한다. 오픈소스 관점에서는 외부 오픈소스 AI 모델을 조달할 때 라이선스·보안·공급망 리스크를 검증하는 절차가 핵심이다.

2. 외부 AI 조달의 세 가지 유형

유형	예시	오픈소스 관련성
오픈소스 AI 모델 직접 사용	Llama, Mistral, Falcon 모델 가중치 다운로드	높음 — 라이선스 직접 적용
오픈소스 기반 AI 서비스	Hugging Face Inference API, Ollama	중간 — 기반 모델 라이선스 확인 필요
상용 AI API	OpenAI API, Google Vertex AI	낮음 — 서비스 약관 적용 (OSS 라이선스 직접 적용 안 됨)

유형 1·2가 오픈소스 라이선스 직접 적용 영역으로 §3~§4의 핵심 대상이며, 유형 3(상용 AI API)도 ISO/IEC 42001 §8.8이 동일하게 요구하므로 §5에서 별도로 다룬다.

ISO/IEC 18974 준수 가이드

Mon, 01 Jan 0001 00:00:00 +0000

이 가이드는 ISO/IEC 18974(OpenChain Security Assurance)의 각 요구사항 조항을 하나씩 풀어서 설명한다. 각 조항이 요구하는 입증자료가 무엇인지, 어떻게 준수할 수 있는지, 바로 활용할 수 있는 샘플 문서는 무엇인지 안내한다.

Author : OpenChain Korea Work Group / CC BY 4.0

대상 독자

오픈소스 보안 보증 체계를 처음 수립하는 기업의 보안 담당자 및 오픈소스 프로그램 매니저
DevSecOps 환경에서 오픈소스 취약점 관리 프로세스를 구축하는 엔지니어
ISO/IEC 5230 인증 취득 후 ISO/IEC 18974 추가 인증을 준비하는 기업 담당자

ISO/IEC 5230과의 관계

ISO/IEC 18974는 ISO/IEC 5230 위에 보안 레이어를 추가한다

ISO/IEC 5230(라이선스 컴플라이언스) 은 오픈소스 라이선스 의무 이행을 체계적으로 관리하는 기반 프로그램을 다룬다.

ISO/IEC 18974(보안 보증) 은 그 위에 취약점 탐지·평가·대응이라는 보안 레이어를 추가한다. 두 규격은 정책·역량·SBOM 등 핵심 인프라를 공유하며, 18974는 이를 보안 관점에서 확장하고 심화한다.

구분	ISO/IEC 5230	ISO/IEC 18974
목적	라이선스 컴플라이언스	보안 보증
입증자료	25개	25개
공통 기반 조항	—	16개 (5230과 대응)
18974 전용 조항	—	9개 (보안 특화)
핵심 추가 요소	—	취약점 탐지·대응·CVD 절차

감사 증적 목록

Mon, 01 Jan 0001 00:00:00 +0000

금융권은 내외부감사와 금융감독원의 정보기술(IT) 검사에 대비해 오픈소스 관리 활동의 증적을 보관해야 한다. 관리 단계의 점검 기록이 그대로 증적이 되므로, 따로 만들지 말고 평소 활동에서 나오는 기록을 체계적으로 모은다. 자세한 맥락은 관리를 참고한다.

증적 체크리스트

아래 증적은 ISO/IEC 5230·18974의 입증자료와 겹친다. ISO 자가 인증을 준비하며 만든 문서가 그대로 감사 증적이 된다. 보관 위치와 기간은 조직 규정에 맞게 정한다.

증적	생성 활동	관련 ISO 입증자료	보관 위치(예시)	비고
오픈소스 정책 문서와 개정 이력	거버넌스	5230 3.1.1.1	문서 관리 시스템	버전 이력 포함
역할·책임 문서, 담당자 지정 기록	거버넌스	5230 3.1.2.1, 3.2.2.1	문서 관리 시스템
SBOM과 갱신 이력	식별	5230 3.3.1.1, 3.3.1.2	SBOM 관리 도구	시스템별
취약점 점검 결과	이슈 파악·해결	18974 4.3.2.1, 4.3.2.2	취약점 관리 도구	날짜별
취약점 조치 기록(조치 불필요 판단 포함)	이슈 파악·해결	18974 4.3.2.2	취약점 관리 도구	VEX 포함
라이선스 검토 기록	이슈 파악·해결	5230 3.3.2.1	문서 관리 시스템
사용 승인 신청·검토·결정 기록	사용 승인	5230 3.1.5.1	승인 관리 도구	위원회 결정 근거
망분리 예외 자체 위험평가서	사용 승인	(전자금융감독규정)	문서 관리 시스템	정보보호위원회(CISO) 승인 이력, 재평가 이력
반입 승인 기록	폐쇄망 운영	—	문서 관리 시스템	검증 결과 포함
정기 재평가 결과	관리	18974 4.1.2.5	문서 관리 시스템	주기별
컴플라이언스 산출물(고지문 등)	관리	5230 3.4.1.1, 3.4.1.2	배포 산출물 저장소	배포 소프트웨어
외주 계약의 오픈소스 요구 조항과 제출 SBOM	사용 승인	(전자금융감독규정 제21조 내부통제)	계약 관리 시스템	전자금융보조업자

보관·관리 원칙

증적은 만드는 것만큼 지키는 것이 중요하다.

모델·컨테이너 스캐너 (Lab700x, Trivy, Syft)

Mon, 01 Jan 0001 00:00:00 +0000

이 페이지는 AI SBOM 생성을 보완하는 분석·식별 도구를 소개한다. 생성 도구(OWASP AIBOM Generator, cdxgen)가 “무엇이 들어 있는가"를 기록한다면, 이 도구들은 “그것이 안전한가"와 “어떤 버전인가"를 본다. 아래 명령과 기능은 각 도구의 공식 문서를 기준으로 정리했다(이 가이드에서 직접 실행한 도구는 OWASP AIBOM Generator와 cdxgen이다).

Lab700x AI SBOM Scanner — 모델 바이너리 정적 분석

AI 모델 파일 자체를 정적 분석해 정보를 추출하는 도구다. .safetensors, .pt(PyTorch), .pkl(Pickle) 같은 모델 바이너리를 실행하지 않고 직접 들여다본다(deep introspection).

주요 기능: 모델을 실행(Execute)하지 않고 내부 구조를 파악하므로, 모델 파일에 숨겨진 악성 코드(Pickle 인젝션 등)나 취약점, 라이선스 위반 요소를 배포 전에 검출한다.
AI SBOM에서의 역할: 외부에서 도입한 모델을 인입 게이트에서 검사하는 데 쓴다. 3.5 라이선스 의무의 인입 메타데이터 강제와 결합하면, 메타데이터 검증과 바이너리 안전성 검사를 함께 수행할 수 있다.

Pickle 형식 모델은 역직렬화 시 임의 코드가 실행될 수 있어 공급망 위험이 크다. 모델을 실행하지 않고 검사한다는 점이 이 도구의 핵심이다.

운영

Mon, 01 Jan 0001 00:00:00 +0000

구축 로드맵의 3단계다. 외부의 AI SBOM 컴플라이언스 문의에 대응하는 창구를 만들고(3.7), 프로그램에 책임과 인력, 재원을 배정한다(3.8).

AI SBOM 컴플라이언스 가이드

Mon, 01 Jan 0001 00:00:00 +0000

이 가이드는 OpenChain AI Work Group이 펴낸 AI System Bill of Materials — Compliance Management Guide for the Supply Chain(Version 1.0)의 각 요구사항을 하나씩 풀어서 설명한다. 각 조항이 요구하는 입증자료가 무엇인지, 어떻게 준수할 수 있는지, 바로 활용할 수 있는 샘플과 도구는 무엇인지 안내한다.

이 규격은 오픈소스 라이선스 컴플라이언스 표준 ISO/IEC 5230과 같은 구조(요구사항, 검증 자료, 근거)를 AI 공급망으로 옮긴 것이다. 코드뿐 아니라 모델 가중치, 학습 데이터셋, 모델 트리(Model Tree)의 라이선스와 투명성 의무까지 컴플라이언스 대상으로 끌어들인다.

§3.1.4 프로그램 범위

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 1 — 기반 수립 단계에서 구축합니다. 범위를 먼저 정해야 이후 정책·조직 구성의 적용 대상이 결정됩니다. 전체 구축 로드맵 보기

1. 조항 개요

오픈소스 프로그램이 조직 전체에 적용되는지, 특정 제품군이나 사업 단위에만 적용되는지 명확하지 않으면 컴플라이언스 활동의 경계가 모호해지고 책임 소재가 불분명해진다. §3.1.4는 오픈소스 프로그램이 어떤 소프트웨어·조직 단위·배포 채널에 적용되는지, 그리고 어디까지가 적용 범위 밖인지를 명확하게 정의한 문서화된 진술을 요구한다. 적용 범위는 조직의 규모와 비즈니스 모델에 따라 다를 수 있으며, 이 조항은 그 선택을 명시적으로 기록하도록 한다.

§3.4 컴플라이언스 산출물

Mon, 01 Jan 0001 00:00:00 +0000

§4.1.4 프로그램 범위

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 1 — 기반 수립 단계에서 구축합니다. 범위를 먼저 정해야 이후 정책·조직 구성의 적용 대상이 결정됩니다. ISO/IEC 5230 대비 성과 메트릭(4.1.4.2)과 지속적 개선 증거(4.1.4.3) 2개 항목이 추가됩니다. 전체 구축 로드맵 보기

★ 18974 전용 항목 — Documented Evidence 강도

§4.1.4.2·§4.1.4.3은 ISO 18974 전용(★) 항목으로 Documented Evidence(문서화된 증거)를 요구한다. 메트릭은 측정 결과 데이터, 지속적 개선은 검토·감사 회의록이 실제 보관되어야 한다. 강도 차이의 자세한 설명은 §4.1.5 표준 관행 — Documented Evidence 안내를 참고한다.

§4.4 규격 준수

Mon, 01 Jan 0001 00:00:00 +0000

이슈 파악과 해결: 취약점과 라이선스

Mon, 01 Jan 0001 00:00:00 +0000

이 페이지의 위치

식별로 무엇을 쓰는지 파악했다면, 그다음은 거기서 나오는 이슈를 풀어야 한다. 이슈는 두 종류다. 보안 취약점과 라이선스 의무다. FSEC 안내서의 두 번째 절차이고, ISO/IEC 18974의 취약점 탐지·해결(4.3.2)과 ISO/IEC 5230의 라이선스 사용 사례 처리(3.3.2)에 대응한다.

여기서 만드는 문서: 취약점 조치 기록(VEX 포함), 심각도별 대응 기한 기준.

취약점 탐지에서 조치까지

ISO/IEC 18974는 SBOM(Software Bill of Materials)에 담긴 각 오픈소스 컴포넌트에 보안 보증 활동을 적용하도록 요구한다. 탐지부터 해결까지의 전 과정을 절차로 만들고, 각 취약점에 대한 수행 기록을 남겨야 한다. 절차는 다음 흐름을 따른다. [ISO 요구]

3.4 프로그램 범위

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 1 — 프로그램 기반 단계에서 구축한다. 전체 구축 로드맵 보기

1. 조항 개요

프로그램 범위는 컴플라이언스가 어디까지 적용되는지를 정한다. 범위가 모호하면 어떤 AI 시스템에 SBOM을 만들어야 하는지, 어떤 모델의 라이선스를 검토해야 하는지가 불분명해진다. 범위를 먼저 선언해야 이후의 모든 조항이 적용 대상을 안다.

3.4는 각 프로그램에 대해 적용 범위를 선언할 것을 요구한다. 범위는 조직마다 다를 수 있다. 어떤 조직은 단일 제품 라인을, 어떤 조직은 부서 전체나 조직 전체를 대상으로 삼는다. AI에서는 자체 개발 모델뿐 아니라 외부에서 도입한 모델과 데이터셋, 사내 모델의 외부 공개까지 범위 판단에 들어온다.

4. 도구

Mon, 01 Jan 0001 00:00:00 +0000

이 섹션이 다루는 요구사항

ISO/IEC 5230: 3.3.1.2
ISO/IEC 18974: 4.3.1.2

1. 소스 코드 스캔 도구

오픈소스 프로세스의 오픈소스 식별 및 검사 단계에서는 소스 코드 스캔 도구를 사용할 수 있습니다. 소스 코드 스캔 도구는 공급 소프트웨어에 포함된 오픈소스를 식별하고, 라이선스 및 저작권 정보를 추출하는 데 도움을 줍니다. 이러한 도구는 무료로 사용할 수 있는 오픈소스 기반 도구부터 상용 도구까지 다양합니다. 각 도구는 특장점이 있지만, 어떤 도구도 모든 문제를 해결할 수 있는 완벽한 기능을 제공하지 않습니다. 따라서 기업은 공급 소프트웨어의 특성과 요구사항에 맞는 적합한 도구를 선택해야 합니다.

4. 운영

Mon, 01 Jan 0001 00:00:00 +0000

1. 개요

ISO/IEC 42001 §8은 AI 관리 시스템의 실제 운영 단계를 다룬다. 오픈소스 관점에서 §8은 가장 많은 교차점을 포함하는 섹션이다.

하위 조항	내용	오픈소스 교차
§8.1	운영 기획 및 통제	오픈소스 검토 프로세스 운영
§8.2~8.3	AI 리스크 평가·처리 (운영 시)	OSS 취약점 리스크 대응
§8.4	AI 시스템 영향 평가 (운영 시)	OSS 취약점의 시스템 영향
§8.5	AI 시스템 생애주기	★ OSS 프레임워크·모델 라이선스
§8.6	AI 시스템을 위한 데이터	★ 오픈 데이터셋 라이선스
§8.7	피드백 인터페이스	—
§8.8	외부 AI 시스템 조달	★ 외부 OSS 모델 공급망 검증

2. 세부 페이지

이 섹션의 오픈소스 교차 항목은 다음 세부 페이지에서 상세히 다룬다:

ISO/IEC 42001 가이드

Mon, 01 Jan 0001 00:00:00 +0000

이 가이드는 오픈소스 담당자 관점에서 ISO/IEC 42001(AI Management System)의 요구사항 중 오픈소스 관리와 교차하는 핵심 항목을 풀어서 설명한다. AI 시스템에서 오픈소스 프레임워크, 사전 훈련 모델, 학습 데이터셋을 사용할 때 무엇을 준수해야 하는지, AI SBOM은 어떻게 구성하는지 실무 중심으로 안내한다.

Author : OpenChain Korea Work Group / CC BY 4.0

ISO/IEC 42001이란?

ISO/IEC 42001:2023은 조직이 AI 시스템을 책임감 있고 투명하게 개발·운영·관리하기 위한 AI 관리 시스템(AIMS, AI Management System) 국제 표준이다.

항목	내용
정식 명칭	ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system
제정 기관	ISO/IEC JTC 1/SC 42 (인공지능)
제정 연도	2023
표준 계열	ISO 경영 시스템 표준 (ISO 9001, ISO 27001과 동일 구조)
적용 대상	AI 제품·서비스를 개발, 제공, 사용하는 모든 조직

ISO/IEC 5230 · 18974와의 차이

ISO/IEC 5230(라이선스 컴플라이언스)과 ISO/IEC 18974(보안 보증)는 OpenChain 프로젝트가 먼저 스펙을 만들고 ISO가 표준으로 채택한 것으로, 오픈소스 소프트웨어 관리에 특화되어 있다. OpenChain이 무료 자가 인증 체크리스트를 제공한다.

ISO/IEC 42001은 ISO/IEC JTC 1 SC 42가 독자적으로 제정한 AI 관리 시스템 표준으로, OpenChain과 무관하다. 오픈소스에 특화된 표준이 아니라 AI 거버넌스 전반을 다루며, 공식 자가 인증 체크리스트가 별도로 제공되지 않는다.

세 표준의 상세 비교는 표준 비교 페이지를 참고한다.

거버넌스

Mon, 01 Jan 0001 00:00:00 +0000

구축 로드맵의 4단계다. 앞선 조항을 하나로 묶어 AI 시스템 수명주기 전반의 거버넌스 프레임워크를 갖추고, 신흥 AI 규제를 반영해 정기적으로 검토한다(3.10).

도구 구축 레시피

Mon, 01 Jan 0001 00:00:00 +0000

이 레시피는 폐쇄망에서 SBOM(Software Bill of Materials) 생성과 지속 취약점 감시를 구축하는 예제다. 빠른 출발점으로 기존 cdxgen과 Dependency-Track 파이프라인 튜토리얼을 금융권 기준으로 정리했다. 특정 제품을 권하기보다, 오픈소스·온프레미스 도구로 구축하는 방법을 보여 주는 것이 목적이다.

폐쇄망 전제

아래 예제는 도구 이미지를 내려받는 단계를 포함한다. 폐쇄망에서는 이미지와 취약점 데이터베이스를 외부에서 받아 사내 컨테이너 레지스트리와 미러로 옮긴 뒤 내부에서만 받도록 구성한다. 반입 절차는 폐쇄망 운영을 참고한다.

Dependency-Track 구축

Dependency-Track은 SBOM을 등록해 두면 취약점 데이터베이스가 갱신될 때마다 영향받는 컴포넌트를 자동으로 다시 평가한다. 운영 시스템의 지속 모니터링에 쓴다. 아래는 API 서버와 프런트엔드를 함께 띄우는 docker-compose 예제다.

금융분야 오픈소스 관리 실무 가이드

Mon, 01 Jan 0001 00:00:00 +0000

금융권은 오픈소스를 점점 더 많이 쓰면서도 폐쇄망, 망분리 규제, 공급망 보안, 감사 대응이라는 고유한 조건 아래에서 관리해야 한다. 이 가이드는 금융분야 오픈소스 소프트웨어 활용·관리 안내서(금융감독원·금융보안원, 2022)가 제시한 관리 절차를 국제표준 ISO/IEC 5230·18974의 입증자료, 그리고 기존 KWG 실무 가이드와 연결해, 담당자가 무엇을 어떤 순서로 갖춰야 하는지를 실행 가능한 형태로 안내한다.

Author : OpenChain Korea Work Group / CC BY 4.0

본 가이드의 성격과 범위

이 가이드는 금융분야 오픈소스 소프트웨어 활용·관리 안내서(이하 FSEC 안내서)를 대체하지 않는다. 안내서가 정한 절차를 실제로 운영하도록 돕는 보조 자료다. 안내서가 비규제 자율 안내이듯, 이 가이드의 권고도 법적 의무가 아니라 모범 실무다.

범위는 안내서와 같다. 오픈소스의 활용과 관리(라이선스 준수, 보안 관리)에 집중하고, 자체 소프트웨어의 외부 공개나 오픈소스 프로젝트 기여는 다루지 않는다. 금융권의 공개 소극성을 반영한 결정이다.

§3.1.5 라이선스 의무

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 3 — 프로세스 구축 단계에서 구축합니다. 전체 구축 로드맵 보기

1. 조항 개요

오픈소스 컴포넌트를 소프트웨어에 포함할 때 가장 핵심적인 작업은 해당 컴포넌트에 적용된 라이선스가 부과하는 의무·제한·권리를 정확히 파악하는 것이다. 라이선스 의무를 검토하지 않고 배포하면 소스코드 강제 공개, 저작권 고지 누락, 특허 조항 위반 등 심각한 법적 리스크가 발생할 수 있다. §3.1.5는 식별된 모든 라이선스에 대해 의무·제한·권리를 검토하고 기록하는 절차를 수립하도록 요구한다. 이 절차는 §3.3.2 라이선스 컴플라이언스 프로세스의 토대가 된다.

§3.5 커뮤니티 참여

Mon, 01 Jan 0001 00:00:00 +0000

§4.1.5 표준 관행 구현

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 3 — 프로세스 구축 단계에서 구축합니다. ISO/IEC 18974 전용 신규 조항으로, 8가지 취약점 처리 방법 각각에 대한 문서화 절차를 수립합니다. 전체 구축 로드맵 보기

ISO 18974 전용(★) 항목의 강도 — Documented Evidence

ISO/IEC 18974는 ISO/IEC 5230과 달리 9개 전용 항목(★: §4.1.2.3, 4.1.2.5, 4.1.2.6, 4.1.4.2, 4.1.4.3, §4.1.5.1, 4.2.2.3, 4.3.2.1, 4.3.2.2)에 대해 “Documented Evidence”(문서화된 증거)를 요구한다. 이는 일반 항목의 documented procedure(문서화된 절차)·document(문서)보다 강한 증거 수준이다.

강도	ISO 표현	충족 수준	인증 심사
약	`document`	산출물 존재	형식 검토
중	`documented procedure`	문서화된 절차 + 절차 준수 의도	절차 본문 검토
강	`Documented Evidence`	절차 + 실제 수행 기록(증거 팩)	수행 이력·로그·티켓·이슈 추적 시스템 결과 등 실증 증거 검증

§4.1.5.1은 8가지 방법 각각에 대해 단순 “절차 문서"가 아니라 수행된 활동의 증거(스캔 로그, 티켓, 승인 이력, VEX 발행 기록 등)를 함께 보관해야 인증 심사를 통과할 수 있다.

사용 승인: 무엇을 어떤 근거로 허용하는가

Mon, 01 Jan 0001 00:00:00 +0000

이 페이지의 위치

식별과 이슈 해결을 거친 오픈소스를 실제로 쓸지 결정하는 단계다. 승인은 한 사람의 판단이 아니라 정해진 절차와 기록으로 이뤄져야 한다. FSEC 안내서의 세 번째 절차이고, ISO/IEC 5230의 라이선스 의무 검토(3.1.5)와 거버넌스에 연결된다.

여기서 만드는 문서: 승인 신청·검토·결정 기록, 외주 계약의 오픈소스 요구 조항.

사용 승인 워크플로

사용 승인은 “이 오픈소스를 이 용도로 써도 되는가"에 답하는 절차다. 답의 근거는 앞 단계에서 나온다. 식별로 무엇인지 알고, 이슈 파악·해결로 취약점과 라이선스 의무를 파악한 뒤, 그 결과를 놓고 승인 여부를 정한다.

5. 교육

Mon, 01 Jan 0001 00:00:00 +0000

이 섹션이 다루는 요구사항

ISO/IEC 5230: 3.1.1.2, 3.1.2.3, 3.1.3.1, 3.5.1.3
ISO/IEC 18974: 4.1.1.2 · 4.1.2.4 · 4.1.3.1

1. 교육

아무리 훌륭한 정책과 프로세스를 구축하였다고 해도 기업의 구성원이 아무도 신경쓰지 않는다면 무용지물일 것입니다. 오픈소스 정책과 오픈소스 프로세스가 기업에서 효과적으로 동작하기 위해서는 구성원 교육이 중요합니다.

기업은 모든 프로그램 참여자가 조직 내에 오픈소스 정책이 있다는 것을 인식하고 필요한 활동을 할 수 있도록 교육, 내부 위키 등 실질적인 수단을 제공해야 합니다. 여기서 프로그램 참여자란 기업이 소프트웨어를 개발하고 배포, 기여하는 데 관여하는 모든 직원을 의미하며, 소프트웨어 개발자, 배포 엔지니어, 품질 엔지니어 등을 포함합니다.

5. 성과 평가와 개선

Mon, 01 Jan 0001 00:00:00 +0000

1. 개요

ISO/IEC 42001 §9와 §10은 AI 관리 시스템이 의도한 결과를 달성하고 있는지 확인하고, 부족한 점을 개선하는 사이클을 다룬다. 오픈소스 관점에서는 **§9.1(모니터링·측정)**이 오픈소스 컴플라이언스 지표와 연계된다.

2. §9.1 모니터링 및 측정 — 오픈소스 컴플라이언스 지표 ★

ISO/IEC 42001은 AI 관리 시스템의 성과를 모니터링하고 측정할 것을 요구한다. 기존 오픈소스 컴플라이언스 지표를 AI 관리 시스템의 성과 지표에 통합한다.

오픈소스 관련 AI 성과 지표 예시

지표	측정 방법	목표	측정 주기
AI SBOM 최신화율	AI 배포 대비 AI SBOM 갱신 완료율	100%	배포 시마다
모델 라이선스 검토율	신규 도입 모델 대비 라이선스 검토 완료율	100%	분기별
Critical CVE 패치율	Critical CVE 발견 후 14일 이내 패치 완료율	95% 이상	월별
데이터셋 라이선스 기록율	AI SBOM 내 데이터셋 라이선스 기록 완료율	100%	분기별
OSS 라이선스 위반 건수	라이선스 위반 발견 건수 및 해결 소요 시간	0건 목표	월별
AI 공급망 검증율	외부 모델 조달 시 공급망 검증 완료율	100%	조달 시마다

ISO/IEC 5230 · 18974 지표와 통합

이미 ISO/IEC 5230 또는 18974 기반의 오픈소스 컴플라이언스 지표를 운영 중이라면, AI 관련 지표를 기존 오픈소스 대시보드에 추가하는 방식으로 통합 관리한다. 별도의 AI 전용 측정 체계를 구축할 필요가 없다.

ISO/IEC 5230 vs 18974 비교

Mon, 01 Jan 0001 00:00:00 +0000

1. 두 표준의 관계

ISO/IEC 5230과 ISO/IEC 18974는 모두 OpenChain 프로젝트가 주도하는 오픈소스 관련 국제 표준이지만, 서로 다른 문제를 다룬다. 5230은 오픈소스 라이선스 컴플라이언스(저작권 의무 이행, SBOM 관리, 컴플라이언스 산출물 배포)를 다루고, 18974는 오픈소스 보안 보증(취약점 탐지, 평가, 대응, CVD)을 다룬다. 두 표준은 완전한 상위·하위 집합 관계가 아니다. 정책, 역량, SBOM 등 9개 공통 조항을 공유하되, 5230에만 있는 조항(라이선스 컴플라이언스·산출물·기여)과 18974에만 있는 조항(표준 관행 구현·보안 보증)이 각각 존재한다.

두 표준을 동시에 준수하면 라이선스 의무 이행과 보안 취약점 관리를 하나의 통합 오픈소스 프로그램으로 운영할 수 있다. 공통 기반 문서(정책·역량 기록·SBOM 절차)는 한 번 작성으로 두 표준에 동시 활용되므로, 5230 인증 후 18974를 추가로 준비하는 데 드는 실질적 추가 작업량은 전체의 30~40% 수준이다.

Trusted OSS

Mon, 01 Jan 0001 00:00:00 +0000

Trusted OSS는 KWG 커뮤니티 활동에서 출발한 프로젝트로, 이 가이드의 저자가 공개했습니다. 문서는 CC BY 4.0, 코드는 MIT와 Apache 2.0으로 배포합니다.

사이트: https://trustedoss.github.io/

Trusted OSS는 다음 네 가지를 다룹니다.

자체 인증 산출물 생성

ISO/IEC 5230과 ISO/IEC 18974 자체 인증에 필요한 문서를 AI 에이전트와 대화하며 만듭니다. 조직 구성, 정책, 프로세스, SBOM 분석, 취약점 리포트, 교육 커리큘럼, 준수 선언문 초안까지 단계별로 생성합니다. 기업 오픈소스 관리 가이드가 설명하는 여섯 단계와 같은 순서를 따릅니다.

DevSecOps 파이프라인

CI/CD 파이프라인에 보안 검사를 넣는 방법을 다룹니다. SAST, DAST, SCA, 시크릿 탐지, 컨테이너 보안, IaC 보안을 단계별로 안내하고, 각 항목이 ISO/IEC 18974의 어느 조항과 연결되는지 매핑합니다.

도구

Mon, 01 Jan 0001 00:00:00 +0000

이 절은 AI SBOM 컴플라이언스를 자동화하는 오픈소스 도구를 다룬다. 각 도구의 주요 기능과 설치, 사용법을 실제 실행 결과와 함께 정리했다. 3.9 AI SBOM의 자동화 성숙도 맵에서 본 구분을 도구별로 구체화한 것이다.

정직하게 짚어 둘 경계가 있다. 도구는 BOM을 자동으로 생성하지만, 생성된 BOM의 라이선스가 정확한지, 누락된 자재는 없는지를 보장하지는 못한다. 아래 도구 비교에서 OWASP AIBOM Generator는 모델 카드의 라이선스를 채우고, cdxgen은 의존성을 빠르게 식별하되 라이선스 필드를 비워 둔다. 도구를 고를 때 이 차이를 본다.

§3.6 규격 준수

Mon, 01 Jan 0001 00:00:00 +0000

관리: 사내 운영 시스템의 지속 점검과 감사 대응

Mon, 01 Jan 0001 00:00:00 +0000

이 페이지의 위치

도입 시점에 한 번 점검하고 끝내면 관리가 아니다. 오픈소스 위험은 운영 내내 이어지고, 새 취약점은 도입 뒤에 공개된다. FSEC 안내서의 마지막 절차인 관리(모니터링) 단계이고, ISO/IEC 18974의 지속 모니터링에 대응한다. 금융권에서 비중이 가장 큰 단계다.

여기서 만드는 문서: 정기 재평가 기록, 감사 증적 묶음.

배포 소프트웨어와 사내 운영 시스템의 구분

오픈소스 관리의 초점은 흔히 외부로 배포하는 소프트웨어에 맞춰진다. 배포가 라이선스 의무를 일으키기 때문이다. 그러나 금융권에서 오픈소스가 가장 많이 쓰이는 곳은 외부로 배포되지 않는 사내 운영 시스템이다. 계정계와 정보계, 사내 금융 관리 시스템, 내부 서버가 그렇다. 이 가이드는 두 범위를 나눠 다룬다.

6. 준수 선언

Mon, 01 Jan 0001 00:00:00 +0000

이 섹션이 다루는 요구사항

ISO/IEC 5230: 3.6.1.1 · 3.6.2.1
ISO/IEC 18974: 4.4.1.1 · 4.4.2.1

ISO/IEC 5230과 ISO/IEC 18974의 모든 요구사항을 준수하는 오픈소스 프로그램(오픈소스 정책 / 프로세스 / 도구 / 조직)을 구축한 기업은 다음 두 가지를 문서화하여 명시해야 합니다.

(1) 표준 요구사항 충족 확인

ISO/IEC 5230과 ISO/IEC 18974는 다음과 같이 프로그램이 모든 요구사항을 충족함을 확인하는 문서를 요구합니다:

ISO/IEC 5230 - License Compliance

3.6.1.1 A document affirming the program specified in §3.1.4 satisfies all the requirements of this document.
3.1.4조에서 명시한 프로그램이 이 규격의 모든 요구사항을 충족함을 확인하는 문서

ISO/IEC 18974 - Security Assurance

4.4.1.1: Documented Evidence affirming the Program specified in §4.1.4 satisfies all the requirements of this document.
§4.1.4에 명시된 프로그램이 이 문서의 모든 요구 사항을 충족함을 확인하는 문서화된 증거.

이를 위해 기업은 다음과 같은 내용을 포함하는 문서를 작성해야 합니다:

자가점검: 우리 체계의 빈 곳 찾기

Mon, 01 Jan 0001 00:00:00 +0000

이 페이지의 위치

앞의 여섯 단계를 점검표로 모은 자리다. 항목을 하나씩 짚어 자사 체계의 빈 곳을 찾고, 부족한 부분을 다루는 섹션으로 이동한다. 분류는 FSEC 안내서의 자가점검 체크리스트(별첨1)를 참고했다.

여기서 만드는 문서: 자가점검 워크북(점검 결과와 개선 계획).

자가점검을 쓰는 방법

이 점검표는 통과·불합격을 가리는 시험이 아니다. 자사가 어디까지 갖췄는지 가늠하고 다음에 무엇을 할지 찾는 도구다. FSEC 안내서가 비규제 자율 점검이듯, 이 점검표도 모범 실무 기준이다. [FSEC 안내서]

각 항목은 관련 ISO 입증자료, 권장 도구, 자세히 다루는 가이드 섹션과 연결돼 있다. 충족하지 못한 항목이 있으면 연결된 섹션으로 가서 방법을 확인한다. 권장 도구는 예시이며 도구 이름의 첫 등장에 사용법 페이지를 링크했다. FSEC 안내서가 쓰는 다섯 분류, 곧 식별, 이슈 파악 및 해결, 승인, 관리, 기타의 순서를 따른다.

7. AI 컴플라이언스

Mon, 01 Jan 0001 00:00:00 +0000

이 섹션이 다루는 요구사항

ISO/IEC 42001: §5.2 (AI 정책), §6.1.2 (AI 리스크 평가), §7.5 (문서화), §8.5 (AI 생애주기), §8.6 (AI 데이터), §8.8 (외부 AI 조달)

AI 시스템은 오픈소스 프레임워크, 사전 훈련된 모델, 오픈 데이터셋을 광범위하게 활용합니다. 오픈소스 관리 체계(ISO/IEC 5230 · 18974)를 운영하는 기업은 AI 시스템 개발 단계에서도 오픈소스 컴플라이언스 원칙을 적용해야 합니다. 또한 AI 코딩 도구(GitHub Copilot, Claude Code, Cursor 등)를 활용하는 개발 환경에서도 라이선스 혼입과 취약 패키지 도입에 대한 새로운 관리 체계가 필요합니다.

산출물: 바로 쓰는 양식과 레시피

Mon, 01 Jan 0001 00:00:00 +0000

이 가이드는 본문과 함께 바로 쓸 수 있는 네 가지 산출물을 제공한다. 본문이 “무엇을 왜 하는지"를 설명한다면, 산출물은 “그것을 어떤 양식으로 남기는지"를 채워 준다. 각 산출물은 조직 상황에 맞게 고쳐 쓰는 것을 전제로 한다.

산출물	쓰임
자가점검 워크북	점검 항목, ISO 입증자료, 충족 상태·담당자·기한을 한 시트로 묶어 자사 체계의 빈 곳을 찾는다
정책·절차 템플릿	금융 변형 정책, 반입 절차, 사용 승인 양식, 망분리 예외 자체 위험평가서의 골격을 제공한다
감사 증적 목록	내외부감사와 감독 검사에서 요구되는 증적과 보관 위치를 체크리스트로 정리한다
도구 구축 레시피	폐쇄망 온프레미스 SBOM·취약점 도구를 docker-compose로 구축·연동하는 예제를 제공한다

활용 안내

산출물은 기존 정책·절차 템플릿 가이드를 금융 맥락으로 보강한 것이다. 일반 실무 양식은 기존 템플릿을, 금융권 고유 항목(반입 통제, 망분리 예외 위험평가, 외주 SBOM 요구)은 이 산출물을 함께 쓴다.

교육 슬라이드

Mon, 01 Jan 0001 00:00:00 +0000

교육 슬라이드

이 페이지에서는 기업 오픈소스 거버넌스 전 과정을 담은 교육 슬라이드를 제공합니다. 기업 오픈소스 관리 가이드 내용을 4시간 교육용으로 구성한 자료입니다.

전체 화면으로 보기

강의 구성

파트	제목	주요 내용
Part 0	도입	강의 목적·4시간 로드맵
Part 1	표준 이해	ISO/IEC 5230·18974·42001 + OpenChain
Part 2	6대 핵심 요소	조직·정책·프로세스·도구·교육·준수
Part 3	AI 컴플라이언스	글로벌 AI 규제·모델 라이선스·AI SBOM·공급망 보안
Part 4	라이브 데모	SBOM 생성 → Dependency-Track → VEX Triage
Part 5	마무리	회고·다음 단계·Q&A

슬라이드 수: 약 99장
예상 교육 시간: 4시간 (Part 3 AI 75분 확장)
대상: 기업 오픈소스 컴플라이언스 담당자, 법무팀, OSPO

라이선스

이 슬라이드는 CC-BY-4.0 라이선스로 공개됩니다. 기업 내부 교육 자료로 자유롭게 활용할 수 있습니다.