ISO/IEC 42001 가이드

• 1: ISO 5230 · 18974 · 42001 비교
• 2: 1. 조직 맥락과 리더십
• 3: 2. 기획
• 4: 3. 지원
• 5: 4. 운영
• 5.1: AI 시스템의 오픈소스 관리
• 5.2: AI SBOM
• 5.3: AI 공급망 검증
• 6: 5. 성과 평가와 개선

1 - ISO 5230 · 18974 · 42001 비교

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 시스템이 오픈소스를 활용할 때 교차점이 발생한다.

2. 표준 기본 정보 비교

3. SC 42 패밀리 매핑

ISO/IEC 42001은 단일 표준이 아니라 ISO/IEC JTC 1/SC 42(인공지능) 위원회가 개발하는 AI 표준 패밀리의 핵심이다. 인증 심사·실무 적용 시 다음 표준들을 함께 참고하면 요구사항 충족도를 높일 수 있다.

3.1 인증 심사에서 자주 함께 참조되는 조합

3.2 오픈소스 컴플라이언스와 SC 42 패밀리 결합

4. 요구사항 형태 비교

세 표준은 요구사항을 표현하는 방식이 근본적으로 다르다.

ISO/IEC 5230 · 18974 방식: 입증자료 번호 체계

각 조항마다 기업이 제출해야 할 **입증자료(Verification Material)**를 번호로 명시한다.

§3.1.1 정책
  입증자료:
  - 3.1.1.1 문서화된 오픈소스 정책
  - 3.1.1.2 정책 전파 절차

입증자료가 있으면 ✅ 충족, 없으면 ❌ 미충족으로 명확하게 판단할 수 있다.

ISO/IEC 42001 방식: 경영 시스템 shall 요구사항

조항마다 “조직은 ~해야 한다(shall)“는 형태의 원칙적 요구사항을 제시하며, 어떤 문서나 기록으로 충족할지는 조직이 맥락에 맞게 결정한다.

§5.2 AI 정책
  "최고경영진은 AI 정책을 수립해야 한다(shall). 
   AI 정책은 조직의 목적에 적합해야 하며..."

이 때문에 ISO 42001은 ISO 5230/18974처럼 단순 체크리스트로 자가 인증을 하기 어렵고, 내부 갭 분석 또는 외부 인증기관의 심사가 필요하다.

5. 자가 인증 방법 비교

6. 오픈소스 관련성 비교

7. 어떤 표준부터 시작해야 하는가?

8. 세 표준 동시 운영 시 공통 기반

세 표준을 동시에 준수할 때 하나의 기반으로 활용 가능한 공통 요소:

2 - 1. 조직 맥락과 리더십

1. 개요

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

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

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

§4.1 조직과 조직 맥락 이해

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

• 오픈소스 AI 모델의 라이선스 정책 변화 (예: Llama 라이선스 조건 변경)
• 국내외 AI 관련 규제 및 오픈소스 의무 공개 요구
• AI 공급망에서의 오픈소스 컴포넌트 보안 취약점 리스크

글로벌 AI 규제 및 표준 매트릭스 (2026-05 기준)

다음 글로벌 규제와 표준이 AI 시스템의 오픈소스 관리와 직접 교차하므로 조직 맥락 분석에 반드시 반영한다. 본 매트릭스는 본 가이드 전체의 참조 기준이다.

§4.3 AI 관리 시스템 범위 결정

AI 관리 시스템의 범위를 정의할 때, 오픈소스를 활용하는 AI 시스템과 프로세스를 명시적으로 포함한다.

체크포인트:

• AI 관리 시스템 범위 문서에 오픈소스 프레임워크·모델·데이터셋을 활용하는 AI 시스템이 포함되어 있는가?
• 오픈소스 라이선스 관련 외부 이슈가 조직 맥락 분석에 포함되어 있는가?

3. §5.2 AI 정책 — 오픈소스 원칙 포함 ★

ISO/IEC 42001은 조직이 AI 정책을 수립할 것을 요구한다. 오픈소스 컴플라이언스 관점에서 AI 정책에 다음 내용을 포함하면 ISO 5230 정책과 일관성을 유지할 수 있다.

AI 정책에 추가할 오픈소스 관련 원칙

## AI 시스템에서의 오픈소스 사용 원칙

본 조직은 AI 시스템 개발 및 운영에 오픈소스를 사용할 때 다음 원칙을 준수한다.

1. **라이선스 컴플라이언스**  
   AI 시스템에 사용하는 모든 오픈소스 프레임워크, 사전 훈련 모델, 학습 데이터셋의
   라이선스 조건을 검토하고 이행한다.

2. **AI SBOM 관리**  
   AI 시스템을 구성하는 오픈소스 컴포넌트(프레임워크, 모델, 데이터셋)를
   AI SBOM으로 문서화하고 최신 상태로 유지한다.

3. **보안 취약점 관리**  
   AI 시스템에 사용된 오픈소스 컴포넌트의 보안 취약점을 주기적으로 점검하고
   식별된 취약점에 신속히 대응한다.

4. **공급망 검증**  
   외부에서 조달하는 오픈소스 AI 모델 및 AI 서비스의 구성 요소와 라이선스를 확인한다.

기존 오픈소스 정책과의 통합

체크포인트:

• AI 정책 또는 오픈소스 정책에 AI 시스템 오픈소스 사용 원칙이 포함되어 있는가?
• AI 정책이 최고경영진의 승인을 받고 조직 내부에 전파되어 있는가?
• 오픈소스 정책과 AI 정책 간 상충이 없는가?

4. §5.3 역할, 책임, 권한

AI 관리 시스템에서 오픈소스 관련 역할과 책임을 명확히 한다.

5. 참고

• ISO/IEC 42001 가이드 홈
• 표준 비교 — ISO 5230 · 18974 · 42001
• 기업 오픈소스 관리 가이드 — 2. 정책
• 기업 오픈소스 관리 가이드 — 1. 조직

3 - 2. 기획

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 리스크 평가서에 포함할 오픈소스 항목

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

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

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

체크포인트:

• AI 리스크 평가 프로세스에 오픈소스 라이선스 리스크 항목이 포함되어 있는가?
• AI 리스크 평가 프로세스에 오픈소스 보안 취약점 리스크 항목이 포함되어 있는가?
• 리스크 평가 결과가 문서화되어 있는가?
• 리스크 수준에 따른 처리 계획이 수립되어 있는가?

3. §6.1.4 AI 시스템 영향 평가 — ISO/IEC 42005 활용 ★

AI 시스템이 개인, 그룹, 사회에 미칠 수 있는 영향을 평가할 때, 오픈소스 컴포넌트로 인한 영향도 포함한다.

3.1 ISO/IEC 42005 기반 영향 평가 8개 영역

3.2 AI 시스템 영향 평가서 템플릿

## AI 시스템 영향 평가서 (ISO/IEC 42001 §6.1.4 + ISO/IEC 42005)

### 1. 시스템 개요
- 시스템명 / 버전 / 평가 일자 / 평가자
- 의도된 사용 사례 / 비대상 사용 사례
- 사용된 오픈소스 모델 · 데이터셋 · 프레임워크 (AI SBOM 참조)

### 2. 이해관계자 식별
- 직접 사용자 / 간접 영향 그룹 / 규제 당국 / 데이터 주체

### 3. 영역별 영향 분석 (42005 8개 영역)
- 영역 1 (영향받는 개인·그룹): __________
- 영역 2 (사회적·환경적): __________
- ... (8개 영역 모두 작성)

### 4. 오픈소스 컴포넌트 관련 영향
- 보안 취약점으로 인한 영향: __________
- 저작권 문제로 인한 서비스 중단 영향: __________
- 학습 데이터 출처 투명성: __________

### 5. 완화 조치
- 식별된 위험별 완화 조치 / 책임자 / 기한

### 6. 평가 결과 · 승인
- 잔여 위험 수준 / 배포 승인 여부 / 다음 재평가 일자

체크포인트:

• AI 시스템 영향 평가 항목에 오픈소스 컴포넌트 관련 보안·법적 영향이 포함되어 있는가?
• 영향 평가가 AI 시스템 배포 전과 주요 변경 시 수행되는가?
• ISO/IEC 42005의 8개 평가 영역을 모두 다루고 있는가?
• 평가 결과가 이해관계자에게 적절히 공개되는가(완화 조치 포함)?

4. §6.2 AI 목표

오픈소스 컴플라이언스와 연계한 측정 가능한 AI 목표를 수립한다.

오픈소스 관련 AI 목표 예시

- AI SBOM 최신화율: 분기별 100% 유지
- 오픈소스 취약점 패치 완료율: Critical CVE 발견 후 14일 이내 패치율 95% 이상
- AI 모델 라이선스 검토 완료율: 신규 모델 도입 시 100% 사전 검토
- 데이터셋 라이선스 기록율: AI SBOM 내 데이터셋 라이선스 100% 기록

5. 참고

• ISO/IEC 42001 가이드 홈
• ISO/IEC 18974 — §4.3.2 보안 보증
• 기업 오픈소스 관리 가이드 — 3. 프로세스
• ISO 5230 · 18974 · 42001 비교 — SC 42 패밀리 매핑

4 - 3. 지원

1. 개요

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

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

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

AI 오픈소스 관리 역량 요소

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

체크포인트:

• AI 개발 인원이 AI 프레임워크·모델 라이선스 조건을 이해하고 있는가?
• AI SBOM 작성 방법에 대한 교육이 제공되고 있는가?
• 역량 평가 기록이 문서화되어 있는가?

3. §7.5 문서화된 정보 — AI SBOM ★

ISO/IEC 42001 §7.5는 AI 관리 시스템 운영에 필요한 문서화된 정보를 수립·유지하도록 요구한다. 오픈소스 관점에서 AI SBOM(AI System Bill of Materials) 은 §7.5의 핵심 산출물이다.

AI SBOM이란?

AI SBOM은 소프트웨어 SBOM(ISO 5230의 §3.3.1)을 AI 시스템으로 확장한 개념으로, AI 시스템을 구성하는 모든 요소와 그 출처·라이선스를 문서화한 목록이다.

AI SBOM 구성 요소

AI SBOM
  ├── 1. AI 프레임워크 · 라이브러리
  │       name, version, license, hash
  │
  ├── 2. 사전 훈련 모델 (Pre-trained Model)
  │       name, version, license, modelCard URL
  │       primaryPurpose (inference / training / fine-tuning)
  │
  ├── 3. 학습 데이터셋
  │       name, version, license, datasetType
  │       knownBias (편향 정보, 있는 경우)
  │
  └── 4. 파인튜닝 데이터 (해당 시)
          name, license, source

AI SBOM 작성 방법 상세: AI SBOM 가이드

SPDX 3.0 AI 프로파일 간략 예시

SPDXVersion: SPDX-3.0
DataLicense: CC0-1.0

# AI 프레임워크
- SPDXID: SPDXRef-pytorch
  name: pytorch
  versionInfo: "2.2.0"
  licenseConcluded: BSD-3-Clause
  primaryPurpose: library

# 사전 훈련 모델
- SPDXID: SPDXRef-llama3
  name: meta-llama/Llama-3.1-8B
  versionInfo: "3.1"
  licenseConcluded: LicenseRef-Llama-Community
  primaryPurpose: inference
  modelCard: "https://huggingface.co/meta-llama/Llama-3.1-8B"

# 학습 데이터셋 (파인튜닝 시)
- SPDXID: SPDXRef-dataset-alpaca
  name: tatsu-lab/alpaca
  licenseConcluded: CC-BY-4.0
  dataCollectionProcess: "Stanford Alpaca 52K instruction dataset"

체크포인트:

• AI 시스템에 사용된 모든 프레임워크·모델·데이터셋이 AI SBOM에 기록되어 있는가?
• AI SBOM이 AI 시스템 변경 시마다 최신 상태로 갱신되는가?
• AI SBOM에 각 컴포넌트의 라이선스 정보가 포함되어 있는가?

4. §7.3 인식

AI 시스템 관련 역할을 수행하는 인원이 오픈소스 컴플라이언스의 중요성을 인식하도록 한다.

체크포인트:

• AI 개발 인원이 AI 시스템 오픈소스 컴플라이언스 미준수 시의 리스크를 인지하고 있는가?

5. 참고

• ISO/IEC 42001 가이드 홈
• AI SBOM 가이드
• ISO/IEC 5230 — §3.3.1 SBOM
• ISO/IEC 18974 — §4.3.1 SBOM
• 기업 오픈소스 관리 가이드 — 5. 교육
• AI Work Group

5 - 4. 운영

1. 개요

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

2. 세부 페이지

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

3. §8.1 운영 기획 — 오픈소스 검토 프로세스 통합

AI 시스템 개발 프로세스에 오픈소스 컴플라이언스 검토 단계를 통합한다.

flowchart TD
    A[기획 단계] --> A1["OSS 프레임워크·모델 목록 작성\n라이선스 사전 검토"]
    A1 --> B[개발 단계]
    B --> B1["컴포넌트 추가 시 라이선스 확인\nAI SBOM 초안 작성\nSCA 스캔"]
    B1 --> C[테스트·검증 단계]
    C --> C1["AI SBOM 검토\n라이선스 의무 이행 확인\nCritical CVE 해결 확인"]
    C1 --> D[배포 단계]
    D --> D1["AI SBOM 최종본 보관\n라이선스 고지문 포함 확인"]

체크포인트:

• AI 시스템 개발 프로세스에 오픈소스 컴플라이언스 검토 단계가 포함되어 있는가?
• 오픈소스 검토 없이 AI 시스템이 배포되는 것을 방지하는 게이트가 있는가?

4. 참고

• ISO/IEC 42001 가이드 홈
• 기업 오픈소스 관리 가이드 — 3. 프로세스
• 기업 오픈소스 관리 가이드 — AI 컴플라이언스

5.1 - AI 시스템의 오픈소스 관리

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에 즉시 반영한다.

SCA(소프트웨어 구성 분석) 도구 활용:

기존 오픈소스 스캔 도구를 AI 프로젝트 저장소에도 동일하게 적용한다.

# FOSSLight를 이용한 AI 프로젝트 스캔 예시
fosslight -p ./ai-project-dir -o ./ai-sbom-output

# cdxgen으로 Python AI 프로젝트 SBOM 생성
cdxgen -t python ./ai-project-dir -o ai-sbom.json

관련 도구 가이드:

• FOSSLight
• cdxgen

2.3 주요 AI 프레임워크 라이선스 상세

2.4 주요 오픈소스 AI 모델 라이선스 비교

체크포인트 — §8.5:

• AI 시스템 개발에 사용된 모든 프레임워크의 라이선스가 검토되었는가?
• 사용 중인 사전 훈련 모델의 라이선스 조건(상업적 사용, MAU 제한 등)이 확인되었는가?
• 라이선스 의무(저작권 고지 등)가 배포 산출물에 포함되어 있는가?
• SCA 스캔이 수행되어 보안 취약점이 식별되었는가?

3. §8.6 AI 데이터 관리 — 학습 데이터셋 라이선스 ★

AI 시스템 학습에 사용한 데이터셋에 오픈 데이터 라이선스가 적용된 경우 해당 라이선스 조건을 이행해야 한다.

3.1 주요 오픈 데이터 라이선스 의무

3.2 모델 카드(Model Card) 작성

CC-BY 계열 데이터셋을 학습에 사용한 경우 모델 카드에 출처를 명시한다.

## Model Card — [모델명]

### Training Data

이 모델은 다음 데이터셋을 사용하여 학습되었습니다:

| 데이터셋 | 라이선스 | 출처 |
|---------|---------|------|
| Wikipedia (2024-01) | CC-BY-SA 4.0 | https://dumps.wikimedia.org/ |
| Common Crawl (CC-MAIN-2023) | 조건 없음 | https://commoncrawl.org/ |
| [내부 데이터셋] | 자체 소유 | 내부 |

체크포인트 — §8.6:

• 학습 데이터셋 목록과 라이선스가 AI SBOM에 기록되어 있는가?
• CC-BY 계열 데이터 사용 시 모델 카드 또는 공개 문서에 출처가 명시되어 있는가?
• CC-BY-NC 데이터가 상업 서비스에 사용되고 있지 않은가?
• CC-BY-SA 데이터를 학습에 사용한 경우 법무팀과 파생 모델 라이선스를 협의했는가?

4. 참고

• 운영 섹션 홈
• AI SBOM 가이드
• AI 공급망 검증
• ISO/IEC 5230 — §3.3 콘텐츠 검토
• ISO/IEC 18974 — §4.3.2 보안 보증
• 기업 오픈소스 관리 가이드 — AI 컴플라이언스

5.2 - AI SBOM

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 vs 소프트웨어 SBOM

2. AI SBOM 구성 요소

AI SBOM
  │
  ├── 1. AI 프레임워크 · 라이브러리
  │       (일반 소프트웨어 SBOM과 동일한 항목)
  │       - name, version, license, PURL, hash
  │
  ├── 2. 사전 훈련 모델 (Pre-trained Model)
  │       - name, version, license
  │       - primaryPurpose (inference / training / fine-tuning / evaluation)
  │       - modelCard URL (모델 카드 링크)
  │       - baseModel (파인튜닝 시 원본 모델)
  │
  ├── 3. 학습 데이터셋
  │       - name, version, license
  │       - dataCollectionProcess (수집 방법)
  │       - dataType (text / image / audio / etc.)
  │       - knownBias (알려진 편향, 있는 경우)
  │
  ├── 4. 파인튜닝 데이터 (해당 시)
  │       - name, license, source
  │       - dataType
  │
  └── 5. Fact Sheet (AI 시스템 카드) ★
          - 편향(bias) 정보 및 한계 사항
          - 데이터 출처 및 데이터 가용성
          - 모델 성능 및 평가 결과 요약
          - 의도된 사용 목적 및 금지 사용 목적
          - 안전성·보안 관련 알려진 이슈

3. AI SBOM 표준 형식 명세 (SPDX 3.0 · CycloneDX 1.6)

AI SBOM 표준 형식은 두 가지가 사실상 산업 표준으로 자리잡았다. 두 형식은 보완 관계이며, 조직은 한쪽 또는 양쪽 모두를 채택할 수 있다.

OpenChain Korea Work Group의 AI Work Group은 두 형식을 모두 지원하는 AI SBOM 가이드를 개발했다.

3.1 SPDX 3.0 AI Profile 핵심 필드 12종

SPDX 3.0 AI Profile은 AIPackage 클래스를 통해 AI 모델 메타데이터를 표현한다. AI 특화 필드 중 자주 사용되는 핵심 12개는 다음과 같다.

보조 필드(필요 시): domain(적용 도메인), energyConsumption(에너지 소비량), standardCompliance(준수 표준 목록), useSensitivePersonalInformation(민감 개인정보 사용 여부). 상속 필드(name, packageVersion, downloadLocation, suppliedBy, primaryPurpose, releaseTime)는 일반 SBOM과 동일하게 작성한다.

3.2 SPDX 3.0 AI SBOM 작성 예시

spdxVersion: SPDX-3.0
SPDXID: SPDXRef-DOCUMENT
name: "MyAI-Service AI SBOM"
dataLicense: CC0-1.0
created: "2026-04-01T00:00:00Z"
createdBy:
  - type: Tool
    identifier: "cdxgen-10.0"

packages:
  # 1. AI 프레임워크
  - SPDXID: SPDXRef-pytorch
    name: torch
    versionInfo: "2.2.0"
    supplier: "Organization: Meta AI"
    downloadLocation: "https://pypi.org/project/torch/2.2.0/"
    licenseConcluded: BSD-3-Clause
    primaryPurpose: library

  - SPDXID: SPDXRef-transformers
    name: transformers
    versionInfo: "4.40.0"
    supplier: "Organization: Hugging Face"
    downloadLocation: "https://pypi.org/project/transformers/4.40.0/"
    licenseConcluded: Apache-2.0
    primaryPurpose: library

  # 2. 사전 훈련 모델
  - SPDXID: SPDXRef-llama3-8b
    name: meta-llama/Llama-3.1-8B-Instruct
    versionInfo: "3.1"
    supplier: "Organization: Meta AI"
    downloadLocation: "https://huggingface.co/meta-llama/Llama-3.1-8B-Instruct"
    licenseConcluded: LicenseRef-Meta-Llama-Community-License
    primaryPurpose: inference
    # AI 프로파일 확장 필드
    modelCard: "https://huggingface.co/meta-llama/Llama-3.1-8B-Instruct"
    hyperparameter:
      contextWindow: 131072

  # 3. 파인튜닝 데이터셋
  - SPDXID: SPDXRef-dataset-alpaca-korean
    name: beomi/KoAlpaca-v1.1a
    versionInfo: "1.1a"
    downloadLocation: "https://huggingface.co/datasets/beomi/KoAlpaca-v1.1a"
    licenseConcluded: CC-BY-NC-4.0
    primaryPurpose: trainData
    dataCollectionProcess: "Korean instruction-following dataset"

relationships:
  - spdxElementId: SPDXRef-llama3-8b
    relationshipType: TRAINED_ON
    relatedSpdxElement: SPDXRef-dataset-alpaca-korean

3.3 CycloneDX 1.6 ML-BOM 핵심 필드 (modelCard 4영역)

CycloneDX 1.6 ML-BOM은 컴포넌트의 modelCard 필드에 AI 모델 메타데이터를 표현한다. modelCard는 4개 영역으로 구성된다.

(1) modelParameters — 모델 구성 (7필드)

(2) quantitativeAnalysis — 성능 분석 (2필드)

(3) considerations — 윤리·운영 고려사항 (7필드)

(4) properties — 자유 형식 key-value

조직 내부 메타데이터(승인자·심사 일자 등)를 추가로 기록할 수 있다.

3.4 CycloneDX 1.6 ML-BOM 작성 예시

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "machine-learning-model",
      "bom-ref": "model-llama3.1-8b",
      "name": "Meta Llama 3.1 8B Instruct",
      "version": "3.1",
      "supplier": { "name": "Meta AI" },
      "licenses": [
        { "license": { "name": "Llama 3.1 Community License" } }
      ],
      "modelCard": {
        "bom-ref": "card-llama3.1-8b",
        "modelParameters": {
          "approach": { "type": "supervised" },
          "task": "text-generation",
          "architectureFamily": "transformer",
          "modelArchitecture": "Decoder-only Transformer",
          "datasets": [ { "ref": "ds-meta-pretrain-15T" } ],
          "inputs": [ { "format": "text/plain" } ],
          "outputs": [ { "format": "text/plain" } ]
        },
        "quantitativeAnalysis": {
          "performanceMetrics": [
            { "type": "MMLU", "value": "0.78" },
            { "type": "HumanEval", "value": "0.65" }
          ]
        },
        "considerations": {
          "users": [ "Enterprise developers" ],
          "useCases": [ "Customer support chatbot (EN/KO)" ],
          "technicalLimitations": [ "Hallucinates on dates after 2024-12" ],
          "ethicalConsiderations": [
            { "name": "Prompt injection", "mitigation": "Input filtering" }
          ],
          "environmentalConsiderations": {
            "energyConsumptions": [
              {
                "activity": "inference",
                "energyMeasure": { "value": 0.5, "unit": "kWh" }
              }
            ]
          }
        }
      }
    }
  ]
}

4. AI SBOM 생성 도구

4.1 cdxgen (CycloneDX 형식)

cdxgen은 Python AI 프로젝트의 의존성을 분석하여 CycloneDX 형식의 SBOM을 생성한다. AI 특화 필드는 별도로 추가해야 한다.

# Python AI 프로젝트 SBOM 생성
cdxgen -t python ./my-ai-project -o ai-sbom.json

# requirements.txt 기반 생성
cdxgen -t pypi -r requirements.txt -o ai-sbom.json

도구 가이드: cdxgen 사용 가이드

4.2 Syft (컨테이너 이미지 분석)

AI 서비스를 컨테이너로 배포하는 경우 Syft로 컨테이너 이미지 전체의 SBOM을 생성한다.

# AI 서비스 컨테이너 이미지 SBOM 생성
syft my-ai-service:latest -o spdx-json=ai-container-sbom.json

도구 가이드: Syft 사용 가이드

4.3 Dependency-Track (AI SBOM 관리 및 취약점 추적)

생성된 AI SBOM을 Dependency-Track에 업로드하면 지속적으로 취약점을 모니터링할 수 있다.

# Dependency-Track에 AI SBOM 업로드
curl -X "POST" "http://dtrack:8080/api/v1/bom" \
  -H "X-Api-Key: ${DTRACK_API_KEY}" \
  -F "bom=@ai-sbom.json" \
  -F "projectName=MyAI-Service" \
  -F "projectVersion=1.0.0"

도구 가이드: Dependency-Track 사용 가이드

5. AI SBOM 운영 절차

AI SBOM 수명주기 관리

AI 시스템 개발 착수
  └─ AI SBOM 초안 작성 (프레임워크·모델 확정 시)
       └─ 개발 중 컴포넌트 추가 시 즉시 갱신
            └─ 배포 전 AI SBOM 최종 검토
                 └─ 배포 시 AI SBOM 보관 (버전별)
                      └─ 운영 중 신규 취약점 발견 시 AI SBOM 연계 대응
                           └─ 모델 라이선스 변경 모니터링 → 필요시 AI SBOM 갱신

체크포인트:

• 모든 배포 버전의 AI SBOM이 생성·보관되어 있는가?
• AI SBOM에 프레임워크·모델·데이터셋이 모두 포함되어 있는가?
• 각 컴포넌트의 라이선스가 정확하게 기록되어 있는가?
• AI SBOM을 기반으로 취약점 모니터링이 수행되고 있는가?
• 모델 서명(OpenSSF Model Signing · Sigstore) 검증 결과가 AI SBOM에 기록되어 있는가?
• 학습 빌드 provenance(SLSA for AI L1 이상)가 attestation으로 보관되어 있는가?

6. AI Work Group 가이드 연계

OpenChain Korea Work Group의 AI Work Group은 AI SBOM Compliance Guide를 개발·발표했다. 이 가이드는 SPDX 3.0 AI 프로파일을 활용한 AI SBOM 작성 방법을 상세히 안내한다.

• AI Work Group 활동 및 가이드: 리소스 — AI Work Group

7. 참고

• 운영 섹션 홈
• ISO/IEC 5230 — §3.3.1 SBOM
• ISO/IEC 18974 — §4.3.1 SBOM
• 도구 — cdxgen
• 도구 — Syft
• 도구 — Dependency-Track
• AI Work Group

5.3 - AI 공급망 검증

1. 개요

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

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

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

3. 오픈소스 AI 모델 조달 전 검증 체크리스트

외부 오픈소스 AI 모델을 도입하기 전 다음 항목을 검증한다.

3.1 라이선스 검증

## 오픈소스 AI 모델 라이선스 검증 체크리스트

### 기본 라이선스 정보
- [ ] 라이선스 유형 확인: ___________________
      (Apache 2.0 / MIT / Llama Community / Gemma ToU / 기타)
- [ ] 라이선스 원문 출처 URL: ___________________
- [ ] 라이선스 버전 확인 (동일 모델의 이전 버전과 다를 수 있음)

### 상업적 사용 조건
- [ ] 상업적 사용 허용 여부: ✅ 허용 / ⚠️ 조건부 / ❌ 불허
- [ ] 사용자 수(MAU) 제한 조건: ___________________
      (예: Llama 3 — MAU 7억 초과 시 Meta 허가 필요)
- [ ] 매출 기반 제한 조건: ___________________

### 파생물(Fine-tuning) 조건
- [ ] 파인튜닝 허용 여부: ✅ 허용 / ⚠️ 조건부 / ❌ 불허
- [ ] 파인튜닝 모델 공개 의무 여부: ___________________
- [ ] 파인튜닝 모델 라이선스 요건: ___________________

### 재배포 조건
- [ ] 모델 가중치 재배포 허용 여부: ✅ 허용 / ⚠️ 조건부 / ❌ 불허
- [ ] 재배포 시 라이선스 문서 포함 의무: ___________________

### 표시(Attribution) 의무
- [ ] 저작자 표시 필요 여부: ✅ 필요 / ❌ 불필요
- [ ] 표시 방법 및 위치: ___________________
      (서비스 UI, 문서, API 응답 등)

### 법무 검토 필요 여부
- [ ] 표준 SPDX 라이선스가 아닌 경우 법무팀 검토 완료: ✅ / 해당 없음
- [ ] 법무팀 검토 일자: ___________________
- [ ] 검토 의견: ___________________

3.2 보안 검증

### 보안 검증 항목
- [ ] 공식 배포 채널에서 다운로드 확인
      (공식 GitHub, Hugging Face 공식 계정)
- [ ] 공식 namespace와 정확 일치 확인 (typo-squatting 방어 — 상세 사례·방어 통제는 §6.1 참조)
- [ ] 파일 해시(SHA256) 검증 완료 및 AI SBOM에 기록
- [ ] 모델 가중치 형식 확인
      (Safetensors 우선; `.pt`·`.bin` pickle 형식은 격리 환경에서 검증 후 운영)
- [ ] 알려진 취약점(CVE) 조회 완료
      (NVD, OSV.dev 검색 결과: ___________________)
- [ ] 모델 가중치의 악성 코드 · 백도어 삽입 여부 검토
      (신뢰할 수 없는 출처의 모델은 사용 금지, 평가 데이터셋으로 백도어 트리거 점검)
- [ ] 라이선스 변경 모니터링 채널 등록
      (GitHub Watch, 공식 뉴스레터 등)

3.3 공급망 리스크 평가

### 공급망 리스크 평가 항목
- [ ] 모델 공급자의 신뢰도 확인
      (개인 / 연구기관 / 기업 — 오픈소스 커뮤니티 평판)
- [ ] 모델 유지보수 활성도 확인
      (마지막 업데이트 일자, 이슈 대응 현황)
- [ ] 라이선스 변경 이력 확인
      (과거 라이선스 조건 변경 사례 여부)
- [ ] 대안 모델 식별
      (라이선스 변경 또는 서비스 중단 시 대안)

4. 주요 오픈소스 AI 모델 라이선스 리스크 요약

5. 상용 AI API §8.8 평가 체크리스트

OpenAI · Anthropic · Google Vertex AI · AWS Bedrock · Azure OpenAI 등 상용 AI API는 오픈소스 라이선스가 직접 적용되지 않지만, ISO/IEC 42001 §8.8은 동일하게 외부 공급 AI 시스템에 대한 평가를 요구한다. 다음 세 영역을 도입 전 검토한다.

5.1 데이터 처리 · 학습 사용 검증

### 데이터 처리 검증 항목
- [ ] 입력 데이터의 학습 사용 여부 (opt-in / opt-out 정책)
      (Enterprise/API 플랜은 기본 opt-out인지 확인)
- [ ] 출력 데이터 보존 기간 (zero-retention 옵션 가능 여부)
- [ ] API 호출 로그 저장 위치(국가) — 개인정보보호법 국외 이전 검토
- [ ] 데이터 처리 리전 선택 가능 여부 (EU·KR 리전 등)
- [ ] BAA(Business Associate Agreement) 체결 가능 여부 (의료 분야)
- [ ] 민감정보 · 영업비밀 입력 차단 정책 수립 여부

5.2 IP indemnification (지식재산 면책) 비교

생성형 AI 출력물의 저작권 침해 리스크에 대비해 주요 제공자는 IP 보증 정책을 운영한다. 플랜별 적용 범위와 조건이 다르므로 약관 원문과 최신 정책 페이지를 직접 확인한다.

공통 면책 요건: 콘텐츠 필터 활성화, 출력물 사후 검수, 의도적 침해 시도 없음, 입력 데이터에 대한 적법한 권리 보유(사용자가 prompt에 입력한 자료의 저작권·라이선스 적법성 보장). 면책 청구 가능 손해 범위(법무 자문 비용·합의금 등)는 제공자별로 다르므로 법무팀과 사전 협의. 실제 약관은 자주 변경되므로 도입 전 약관 원문을 직접 확인한다.

5.3 서비스 약관 변경 · 가용성 모니터링

### 약관 · 가용성 모니터링 항목
- [ ] 약관 변경 알림 채널 등록 (이메일 알림 · 변경 로그 페이지 RSS)
- [ ] 가격 변경 정책 확인 (계약상 사전 통지 기간)
- [ ] SLA 가용성 보장 수준 (예: 99.9%)
- [ ] 서비스 종료(EOL) 정책 — 마이그레이션 기간 확보
- [ ] 대체 제공자 식별 (벤더 락인 방지 — 동등 모델 매핑 표 유지)
- [ ] 출력물 책임 한계 조항 검토 (Hallucination · Bias 면책 조항)

6. 모델 공급망 공격 방어

오픈소스 모델 가중치 파일과 모델 허브(Hugging Face·PyTorch Hub 등)는 2024년 이후 새로운 공격 표면으로 확인되었다. 도입 전 다음 공격 유형을 인지하고 방어 통제를 적용한다.

6.1 알려진 공격 유형

6.2 권장 방어 통제

### 모델 공급망 방어 통제 체크리스트
- [ ] 모델 가중치는 Safetensors 형식 우선 (pickle 회피)
- [ ] 모델 파일 hash(SHA-256) 핀고정 + AI SBOM에 기록
- [ ] OpenSSF Model Signing · Sigstore 서명 검증 도입 (§6.3)
- [ ] SLSA for AI 빌드 레벨 평가 (§6.4)
- [ ] 모델 격리 환경(샌드박스)에서 1차 검증 후 운영 환경 반영
- [ ] 신규 모델 도입 시 보안팀 사전 검토 의무화
- [ ] 모델 허브 계정 typo-squatting 점검 자동화 (CI 단계)
- [ ] 모델 라이선스 본문 · 가중치 hash · 다운로드 일자를 함께 보관

6.3 OpenSSF Model Signing 도입 절차

OpenSSF Model Signing은 Sigstore(keyless OIDC 서명) · X.509 인증서 · 공개키 세 가지 방식을 지원하는 ML 모델 서명 표준이다. 2026년 기준 정식 패키지명은 model-signing(v1.1+)이다.

(1) 설치

# 기본 설치 (Sigstore 사용)
pip install model-signing

# X.509(PKCS #11 HSM) 지원 포함
pip install model-signing[pkcs11]

(2) 모델 서명 (Sigstore keyless 방식, 권장)

# 모델 디렉토리 전체에 대한 다이제스트 계산 후 Sigstore로 서명
# → Sigstore Fulcio가 OIDC 신원으로 단기 인증서 발급, Rekor 투명성 로그에 기록
# → model.sig 파일 생성
model_signing sign sigstore /path/to/llama-3.1-8b

(3) 모델 검증 (서명자 신원 확인)

# Google OIDC 사용 예시
model_signing verify sigstore /path/to/llama-3.1-8b \
  --signature model.sig \
  --identity "release-bot@example.com" \
  --identity_provider "https://accounts.google.com"

# GitHub Actions OIDC 사용 예시 (CI 환경에서 가장 흔함)
model_signing verify sigstore /path/to/llama-3.1-8b \
  --signature model.sig \
  --identity "https://github.com/myorg/myrepo/.github/workflows/release.yml@refs/heads/main" \
  --identity_provider "https://token.actions.githubusercontent.com"

정확한 CLI 구문은 sigstore/model-transparency 공식 README를 도입 시점에 재확인합니다(서브커맨드/옵션명이 버전별로 변경될 수 있음).

(4) 자체 키 사용 (오프라인 환경)

# 서명 (RSA/EC 등 자체 키 페어)
model_signing sign key /path/to/model --private_key signing.key

# 검증
model_signing verify key /path/to/model --signature model.sig --public_key signing.pub

(5) AI SBOM과 연계

서명 검증 결과(서명자 identity · 발급 일자 · Rekor 로그 인덱스)를 AI SBOM hashes · attestation 필드에 기록하여 감사 추적성을 확보한다. CycloneDX 1.6에서는 컴포넌트의 signature 필드에 직접 첨부할 수 있다.

6.4 SLSA for AI 빌드 레벨

SLSA(Supply-chain Levels for Software Artifacts)의 빌드 트랙은 ML 모델 빌드 파이프라인에도 동일하게 적용된다. SLSA for AI는 이를 모델 학습 · 파인튜닝 · 변환 과정에 매핑한 사용 사례다.

SLSA 정식 안정 버전은 v1.0(2023-04 GA)이며 v1.1 draft가 진행 중이다. 도입 시점에 SLSA 공식 사양의 최신 안정 버전을 확인한다.

ML 모델 provenance에 포함할 핵심 항목

• 학습 데이터 hash(데이터셋 버전 · 라이선스)
• 학습 코드 git commit · CI/CD 빌더 ID
• 하이퍼파라미터 · 학습 환경(GPU 타입 · 라이브러리 버전)
• 베이스 모델 ID · hash(파인튜닝의 경우)
• 빌드 시작 · 종료 시간 · 빌더 신원

적용 권장 순서

1. L1 우선 도입: 학습 파이프라인에 provenance 자동 생성(예: GitHub Actions 빌더가 in-toto attestation 자동 출력)
2. L2 단계: provenance에 Sigstore 서명 추가 (§6.3 도구 활용)
3. L3 단계: hardened build 환경(예: GitHub Actions hosted runner의 격리 워크플로우, GCP/AWS 격리 빌더) 채택
4. AI SBOM에 SLSA 레벨 기록(properties.slsaLevel)

7. 외부 AI 모델 조달 프로세스

flowchart TD
    A[도입 필요 모델 식별] --> B[후보 모델 목록 작성]
    B --> C[라이선스 검증]
    C --> D{커스텀 라이선스?}
    D -- Yes --> E[법무팀 검토]
    D -- No --> F[보안 검증]
    E --> F
    F --> G[공급망 리스크 평가]
    G --> H[도입 승인]
    H --> I[AI SBOM 등록]
    I --> J[라이선스 모니터링 등록]

체크포인트:

• 외부 오픈소스 AI 모델 도입 전 라이선스 검증 절차가 수행되었는가?
• 커스텀 라이선스 모델의 경우 법무팀 검토가 완료되었는가?
• 도입된 외부 모델이 AI SBOM에 등록되어 있는가?
• 외부 모델 라이선스 변경을 모니터링하는 채널이 있는가?
• 라이선스 조건 위반 시 대응할 대안 모델이 식별되어 있는가?
• 상용 AI API 도입 시 §5(데이터 처리·IP 보증·약관 모니터링) 평가가 수행되었는가?
• 모델 가중치 파일 hash · 형식(Safetensors 우선) · namespace가 검증되었는가?

8. 참고

• 운영 섹션 홈
• AI 시스템의 오픈소스 관리
• AI SBOM 가이드
• ISO/IEC 18974 — §4.3.2 보안 보증
• 기업 오픈소스 관리 가이드 — AI 컴플라이언스
• AI Work Group

6 - 5. 성과 평가와 개선

1. 개요

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

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

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

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

체크포인트:

• AI 시스템 오픈소스 컴플라이언스 관련 성과 지표가 정의되어 있는가?
• 지표가 정해진 주기에 측정·기록되고 있는가?
• 목표 미달 시 개선 조치가 수립되는가?

3. §9.2 내부 감사

AI 관리 시스템이 ISO 42001 요구사항을 충족하는지 정기적으로 내부 감사를 수행한다. 오픈소스 컴플라이언스 항목을 내부 감사 체크리스트에 포함한다.

AI 오픈소스 내부 감사 체크리스트

## AI 시스템 오픈소스 컴플라이언스 내부 감사 체크리스트
### 감사 대상: [AI 시스템명]  / 감사 일자: YYYY-MM-DD

#### AI SBOM
- [ ] AI SBOM이 최신 배포 버전을 반영하고 있는가?
- [ ] 모든 프레임워크·모델·데이터셋이 AI SBOM에 포함되어 있는가?
- [ ] 각 컴포넌트의 라이선스 정보가 정확하게 기록되어 있는가?

#### 라이선스 컴플라이언스
- [ ] 모든 오픈소스 AI 컴포넌트의 라이선스 조건이 검토되었는가?
- [ ] 라이선스 의무(저작권 고지, 변경 고지 등)가 이행되었는가?
- [ ] 상업적 사용 제한이 있는 모델을 상업 서비스에 사용하고 있지 않은가?

#### 보안 취약점 관리
- [ ] 최근 분기 내 SCA 스캔이 수행되었는가?
- [ ] 식별된 Critical/High CVE가 적시에 패치되었는가?
- [ ] 취약점 처리 이력이 기록되어 있는가?

#### AI 공급망
- [ ] 외부 조달 AI 모델의 라이선스 검증이 완료되었는가?
- [ ] 외부 모델의 라이선스 변경 사항이 모니터링되고 있는가?

4. §9.3 경영 검토

최고경영진의 AI 관리 시스템 경영 검토 시, 오픈소스 컴플라이언스 현황을 보고 항목에 포함한다.

경영 검토 보고 항목 예시:

• AI SBOM 관리 현황 (최신화율, 커버리지)
• 오픈소스 라이선스 위반 발생 현황 및 조치
• AI 시스템 보안 취약점 현황 및 패치율
• AI 공급망 오픈소스 리스크 현황

5. §10.1 부적합 및 시정 조치

오픈소스 컴플라이언스 위반이 발견된 경우 다음 절차를 따른다:

1. 즉각 조치: 위반 사항 격리 또는 임시 조치 (예: 해당 기능 서비스 중단)
2. 원인 분석: 왜 위반이 발생했는지 근본 원인 파악
3. 시정 조치: 위반 해결 (라이선스 준수, 컴포넌트 교체 등)
4. 재발 방지: 프로세스 개선 (검토 절차 강화, 교육 등)
5. 기록 보존: 위반 내용, 조치, 결과를 문서화

6. §10.2 지속적 개선

AI 시스템 오픈소스 관리 체계를 지속적으로 개선하기 위한 방향:

• 새로운 AI 모델 라이선스 유형에 대한 검토 기준 업데이트
• AI SBOM 생성 자동화 도구 도입 (cdxgen, Syft 등 활용)
• AI Work Group의 최신 가이드 반영

7. 참고

• ISO/IEC 42001 가이드 홈
• 기업 오픈소스 관리 가이드 — 6. 준수 선언
• ISO/IEC 5230 — §3.6 준수
• 도구 — cdxgen (AI SBOM 생성)
• 도구 — Syft (컨테이너 이미지 분석)
• 도구 — Dependency-Track (취약점 추적)