AI SBOM 컴플라이언스 가이드

• 1: 프로그램 기반
• 1.1: 3.1 정책
• 1.2: 3.2 역량
• 1.3: 3.3 인지
• 1.4: 3.4 프로그램 범위
• 2: AI 확장 프로세스
• 2.1: 3.5 라이선스 의무
• 2.2: 3.6 투명성 의무
• 2.3: 3.9 AI SBOM
• 3: 운영
• 3.1: 3.7 접근
• 3.2: 3.8 효과적 자원 배분
• 4: 거버넌스
• 4.1: 3.10 거버넌스
• 5: 도구
• 5.1: OWASP AIBOM Generator
• 5.2: cdxgen
• 5.3: 모델·컨테이너 스캐너 (Lab700x, Trivy, Syft)

1 - 프로그램 기반

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

1.1 - 3.1 정책

1. 조항 개요

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

3.1은 이 위험을 예방하기 위해 AI SBOM 컴플라이언스를 관리하는 문서화된 정책을 수립하고, 프로그램 참여자가 그 존재를 인식하도록 전파할 것을 요구한다. 이 정책은 사업 전략, 관할 구역의 법적 요구사항, 사용 사례에 맞는 위험 수준을 반영해야 한다. 이후 모든 조항(역량, 라이선스 의무, AI SBOM, 거버넌스 등)은 이 정책 위에서 작동한다.

2. 해야 할 활동

• AI SBOM 컴플라이언스를 관리하는 정책 문서를 작성하고 공식화한다.
• 정책에 적용 범위(외부 배포 AI 시스템, 외부 모델·데이터셋 도입, 사내 모델 공개 등)를 정의한다.
• 정책에 사업 전략, 관할 구역의 법적 요구사항, 사용 사례별 위험 수준을 반영한다.
• 모델과 데이터셋에 허용하거나 금지하는 라이선스 목록을 정책에 포함한다. ([본 가이드 권고] 비표준 라이선스의 준수를 사후에 자동 추적하기 어려우므로 도입 시점에 정책으로 결정한다.)
• 프로그램 참여자(개발, 법무, 보안, 데이터 담당 등)에게 정책을 전파하는 절차를 수립하고 문서화한다.
• 전파 사실을 증명할 기록(교육 이수, 공지 이력 등)을 보관한다.
• 정기적으로 정책을 검토하고 변경 시 재전파하는 절차를 정책에 포함한다.

3. 요구사항 및 입증자료

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

3.1.1 문서화된 AI SBOM 정책

준수 방법

AI SBOM 정책은 조직이 AI 시스템의 라이선스와 투명성 의무를 관리하기 위한 원칙과 절차를 담은 공식 문서다. 정책에는 목적, 적용 범위, 역할과 책임, 모델과 데이터셋의 라이선스 검토 원칙, AI SBOM 관리, 투명성 의무 대응, 검토 주기 등이 포함되어야 한다. 이 문서 자체가 입증자료 3.1.1이므로 버전과 승인 이력을 기록해 공식 문서로 관리한다.

기존에 ISO/IEC 5230 오픈소스 정책을 갖춘 조직이라면 새 정책을 따로 만들기보다 기존 정책에 AI 관련 절을 더하는 편이 효율적이다. 모델과 데이터셋이 라이선스 검토 대상에 포함된다는 점, 비표준 라이선스를 어떻게 다루는지, AI SBOM을 어떤 형식으로 관리하는지를 추가한다.

정책은 한 번 수립하고 방치하는 문서가 아니다. AI 규제 환경이 빠르게 바뀌므로 최소 연 1회 정기 검토를 실시하고 변경 이력을 기록한다.

고려사항

• AI 고유 범위 명시: 코드뿐 아니라 모델 가중치, 학습·테스트·검증 데이터셋, 모델 트리의 파생 관계가 라이선스 검토 대상임을 정책에 분명히 적는다.
• 라이선스 허용·금지 목록: 상업적 사용 가부와 행동 사용 제한을 기준으로 모델과 데이터셋의 라이선스를 허용 목록과 금지 목록으로 나눠 정책에 선반영한다. ([본 가이드 권고])
• 승인 절차: 법무팀 또는 AI 거버넌스 책임자가 최종 승인하고, 승인 날짜와 승인자를 기록한다.
• 버전 관리: 문서 버전과 변경 이력을 유지해 감사 시 이전 버전과 비교할 수 있게 한다.
• 정기 검토: 연 1회 이상 검토하며, 검토 완료 날짜와 검토자를 기록한다.

샘플

아래는 AI SBOM 정책의 적용 범위와 라이선스 허용·금지 목록 샘플이다. 이 텍스트가 입증자료 3.1.1의 핵심 구성 요소가 된다. 라이선스별 실제 조건은 각 라이선스 원문으로 확인한 뒤 조직의 사용 사례에 맞춰 분류한다.

## 1. 목적 및 적용 범위

이 정책은 회사가 AI 시스템을 안전하고 책임 있게 개발·배포하기 위한 컴플라이언스 원칙과
절차를 정의한다. ISO/IEC 5230(오픈소스 라이선스 컴플라이언스)과 OpenChain AI SBOM
컴플라이언스 가이드의 요구사항을 충족하도록 설계되었다.

적용 범위:
- 외부로 배포하는 모든 AI 시스템, 모델, 서비스.
- 외부에서 도입하는 사전학습 모델과 데이터셋.
- 사내 모델을 외부에 공개하는 활동.

## 2. 모델·데이터셋 라이선스 분류

도입하는 모델과 데이터셋의 라이선스는 아래 분류에 따라 검토한다. 분류에 없는
라이선스는 도입 전 AI 거버넌스 책임자의 검토를 거친다.

- 허용(상업적 사용 가능, 행동 제한 없음): Apache-2.0, MIT, BSD, CC-BY-4.0 등
- 조건부 허용(검토 후 사용): Llama 커뮤니티 라이선스, Gemma 사용 약관,
  OpenRAIL 계열 등 사용 목적·규모 제한이 있는 라이선스
- 금지(비상업 한정 등): CC-BY-NC 데이터셋을 상업 제품에 사용하는 경우 등

3.1.2 정책 인지 절차

준수 방법

정책 문서를 작성하는 것만으로는 부족하다. 프로그램 참여자가 정책의 존재를 실제로 인식하도록 전파 절차를 수립하고 문서화해야 한다. 이 전파 절차 문서 자체가 입증자료 3.1.2다. AI 시스템은 개발자뿐 아니라 데이터 담당, 법무, 보안이 함께 관여하므로, 이들 모두에게 정책이 닿도록 채널을 설계한다.

신규 입사자에게는 온보딩에 AI SBOM 정책 안내를 포함하고, 기존 직원에게는 사내 위키 게시와 이메일 공지를 활용한다. 전파 사실을 증명하기 위해 공지 이력, 교육 이수 기록 등의 증거를 최소 3년간 보관한다.

고려사항

• 복수 채널 활용: 사내 위키, 이메일 공지, 온보딩 교육 등 둘 이상의 채널을 활용한다.
• AI 관여 직무 포함: 데이터셋 담당자와 모델 운영자도 전파 대상에 포함한다.
• 정책 변경 시: 변경 사항을 참여자에게 즉시 공지하는 별도 절차를 둔다.
• 증거 보관: 공지 이력과 교육 이수 확인서를 최소 3년간 보관한다.

샘플

아래는 정책 전파 공지 이메일 샘플이다. 전송 이력을 보관하면 입증자료 3.1.2의 증거가 된다.

제목: [AI 컴플라이언스] AI SBOM 정책 안내 및 숙지 요청

수신: AI 시스템 개발·운영·데이터 관련 임직원
발신: AI 컴플라이언스 담당자

안녕하세요.

당사의 AI SBOM 컴플라이언스 정책이 제정(또는 개정)되었습니다.
AI 모델과 데이터셋을 사용, 도입, 또는 배포하는 업무에 관여하는 모든 임직원은
아래 정책 문서를 확인하고 숙지해 주시기 바랍니다.

- 정책 문서: [사내 포털 링크]
- 주요 내용: 모델·데이터셋 라이선스 분류, 라이선스 의무 검토 절차,
             AI SBOM 관리, 투명성 의무 대응
- 정책 버전: v1.0 (시행일: YYYY-MM-DD)

문의: AI 컴플라이언스 담당자(ai-compliance@company.com)

5. 참고

• 라이선스 의무 검토 절차: 3.5 라이선스 의무
• 오픈소스 정책의 기본 구조: ISO/IEC 5230 준수 가이드 — 3.1.1 정책
• AI 라이선스 관리 전략: 기업 오픈소스 관리 가이드 — AI 컴플라이언스

1.2 - 3.2 역량

1. 조항 개요

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

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

2. 해야 할 활동

• 프로그램의 성과에 영향을 미치는 역할과 그 책임을 식별해 문서화한다.
• 각 역할에 필요한 역량(거버넌스, 보안, 안전, 프라이버시, 개발, 공급자 관리)을 정의한다.
• AI 고유 역량(모델·데이터셋 라이선스, 모델 카드 해석, AI 규제)을 역할별 역량에 추가한다.
• 교육, 훈련, 경험을 근거로 참여자가 역량을 갖추도록 한다.
• 역량 평가 증거를 보존하고, 목록을 최신으로 유지하도록 정기 점검한다.

3. 요구사항 및 입증자료

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

3.2.1 역할과 책임 목록

준수 방법

프로그램에 관여하는 역할과 각 역할의 책임을 문서로 정리한다. AI SBOM 프로그램은 일반 오픈소스 역할에 더해 AI 거버넌스와 모델·데이터셋 검토 역할을 포함한다. 책임을 구체적으로 적어야 이후 역량 정의(3.2.2)와 책임 배정(3.8.4)이 명확해진다.

샘플

| 역할 | 책임 |
|------|------|
| AI 거버넌스 책임자 | 프레임워크 승인, 규제 의무 판단, 정기 검토 주관 |
| AI SBOM 검증 담당 | AI SBOM 생성·검토·승인, 인바운드 자재 반영 |
| 라이선스 검토 담당 | 모델·데이터셋·모델 트리 라이선스 의무 판단 |
| 데이터 담당 | 학습·검증 데이터셋 출처와 라이선스 관리 |

3.2.2 역할별 필요 역량

준수 방법

각 역할이 갖춰야 할 역량을 정의한다. 규격이 든 여섯 기능(거버넌스, 보안, 안전, 프라이버시, 개발, 공급자 관리) 가운데 역할과 사용 사례에 해당하는 것을 정하고, AI 고유 역량을 더한다. 예를 들어 라이선스 검토 담당에게는 비표준 라이선스(Llama 커뮤니티, OpenRAIL)의 사용 제한을 해석하는 역량이 필요하다.

샘플

| 역할 | 필요 역량 |
|------|----------|
| AI 거버넌스 책임자 | 거버넌스, AI 규제(EU 인공지능법·한국 AI 기본법) 이해, 위험 관리 |
| AI SBOM 검증 담당 | 개발, SPDX·CycloneDX 형식, 모델 카드 해석, 생성 도구 운영 |
| 라이선스 검토 담당 | 공급자 관리, 오픈소스·비표준 라이선스 해석, 모델 트리 추적 |
| 데이터 담당 | 프라이버시, 데이터셋 라이선스, 출처 관리 |

3.2.3 역량 평가 증거

준수 방법

각 참여자가 역할에 필요한 역량을 실제로 갖췄는지 평가하고 그 증거를 보존한다. 교육 이수, 자격, 실무 경험이 근거가 된다. AI 규제와 라이선스는 빠르게 바뀌므로 목록을 정기적으로 점검해 최신 상태로 유지한다.

고려사항

• 평가 근거 다양화: 교육 이수만이 아니라 실무 산출물(예: 라이선스 검토 기록)도 역량 증거로 활용한다.
• 정기 점검: 신규 규제 시행이나 새 라이선스 유형 등장 시 역량 요건을 재검토한다.
• 공백 보완: 평가에서 역량 공백이 드러나면 교육이나 외부 전문성으로 보완한다(3.8 자원).

샘플 (역량 평가 기록부)

| 참여자(직무) | 역할 | 평가 항목 | 평가 근거 | 결과 | 평가일 |
|-------------|------|----------|----------|------|--------|
| 이OO | AI SBOM 검증 담당 | CycloneDX ML-BOM 작성 | 사내 교육 + 실무 산출물 | 충족 | 2026-03-10 |
| 박OO | 라이선스 검토 담당 | 비표준 라이선스 해석 | OSS 법무 경력 5년 | 충족 | 2026-03-10 |

5. 참고

• 역할에 자원을 붙이는 절차: 3.8 효과적 자원 배분
• 참여자 인지 확보: 3.3 인지
• ISO/IEC 5230 역량 본보기: ISO/IEC 5230 준수 가이드 — 3.1.2 역량

1.3 - 3.3 인지

1. 조항 개요

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

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

2. 해야 할 활동

• 참여자가 AI SBOM 정책과 그 위치를 알도록 한다.
• 관련 사업 목표(신뢰 확보, 규제 준수, 공급망 요구 충족)를 전달한다.
• 각자의 업무가 프로그램에 어떻게 기여하는지 알린다.
• 미준수의 영향(규제 위반, 계약 해지, 사용 제한 위반)을 알린다.
• 참여자의 인지를 평가하고 그 증거를 보존한다.

3. 요구사항 및 입증자료

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

3.3.1 참여자 인지 평가 증거

준수 방법

참여자가 네 가지 인지 요소를 실제로 이해하는지 평가하고 증거를 남긴다. 정책 전파(3.1.2)가 “알렸다"를 증명한다면, 인지 평가는 “이해했다"를 증명한다. 평가는 교육 후 확인 퀴즈, 인식 확인 서명, 면담 등으로 한다. 규격이 검증 자료에 명시한 세 요소(프로그램 목표, 자신의 기여, 부적합의 영향)가 평가에 빠지지 않도록 한다.

고려사항

• 네 요소 모두 포함: 정책 인지에 더해 목표, 기여, 부적합 영향을 평가 항목에 모두 넣는다. 하나라도 빠지면 인증 심사에서 지적될 수 있다.
• AI 고유 영향 강조: 미준수의 영향에 규제 위반(EU 인공지능법, 한국 AI 기본법)과 비표준 라이선스 사용 제한 위반을 포함한다.
• 역할별 차등: 데이터 담당과 개발자는 각자의 기여가 다르므로 평가 내용을 역할에 맞춘다.
• 증거 보관: 평가 결과와 확인 서명을 보존해 입증자료로 활용한다.

샘플 (인지 평가 기록부)

| 참여자(직무) | 정책 인지 | 목표 인지 | 기여 인지 | 부적합 영향 인지 | 평가 방법 | 평가일 |
|-------------|:--------:|:--------:|:--------:|:---------------:|----------|--------|
| 이OO (개발) | 충족 | 충족 | 충족 | 충족 | 교육 후 확인 | 2026-03-10 |
| 박OO (데이터) | 충족 | 충족 | 충족 | 충족 | 면담 + 서명 | 2026-03-11 |

확인 서명 양식 예시:

본인은 당사의 AI SBOM 컴플라이언스 정책과 프로그램 목표, 본인의 기여, 그리고 미준수 시의
영향(규제 위반·라이선스 사용 제한 위반·계약 해지)을 안내받고 이해하였습니다.

성명: ____  직무: ____  서명: ____  일자: ____

5. 참고

• 정책과 전파 절차: 3.1 정책
• 역할별 역량: 3.2 역량
• ISO/IEC 5230 인식 본보기: ISO/IEC 5230 준수 가이드 — 3.1.3 인식

1.4 - 3.4 프로그램 범위

1. 조항 개요

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

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

2. 해야 할 활동

• 프로그램이 적용되는 대상(외부 배포 AI 시스템, 외부 모델·데이터셋 도입, 사내 모델 공개 등)을 정한다.
• 적용에서 제외하는 대상과 그 근거를 기록한다.
• 범위 진술을 정책 문서의 적용 범위와 일관되게 유지한다.
• 사업 환경 변화에 따라 범위를 정기적으로 검토하고 갱신한다.

3. 요구사항 및 입증자료

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

3.4.1 프로그램 범위 진술

준수 방법

프로그램의 범위와 한계를 성문으로 진술한다. 무엇이 적용 대상이고 무엇이 제외인지, 제외라면 그 근거가 무엇인지를 분명히 적는다. AI SBOM 프로그램은 적용 대상을 자재 유형과 활동으로 나눠 선언하면 명확하다. 아래 표는 범위를 정리하는 예다.

표 1. AI SBOM 프로그램 범위 선언 예

고려사항

• 정책과의 일관성: 범위 진술은 3.1 정책의 적용 범위와 어긋나지 않아야 한다.
• 제외의 근거: 제외 대상은 근거를 적는다. 내부 실험용 모델이라도 외부 배포로 전환되면 범위에 들어오므로, 전환 시점의 검토 절차를 둔다. ([본 가이드 권고])
• 정기 검토: 신규 제품 라인이나 새 AI 서비스가 생기면 범위를 갱신한다.

샘플 (범위 진술서)

## AI SBOM 컴플라이언스 프로그램 범위

### 적용 대상
이 프로그램은 회사가 외부로 배포하는 모든 AI 시스템과 모델, 서비스, 그리고 외부에서
도입하는 사전학습 모델과 데이터셋에 적용된다. 사내 모델을 외부에 공개하는 활동도
포함한다.

### 적용 제외
내부 실험·연구 목적으로만 사용하고 외부에 배포하지 않는 모델은 적용에서 제외한다.
다만 외부 배포로 전환될 경우 도입 검토 절차를 거쳐 범위에 포함한다.

### 검토 주기
범위는 사업 환경 변화에 따라 연 1회 이상 검토하고 갱신한다.

5. 참고

• 정책의 적용 범위: 3.1 정책
• 범위 안 자재의 AI SBOM: 3.9 AI SBOM
• ISO/IEC 5230 범위 본보기: ISO/IEC 5230 준수 가이드 — 3.1.4 프로그램 범위

2 - AI 확장 프로세스

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

2.1 - 3.5 라이선스 의무

1. 조항 개요

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

3.5는 이 라이선스들을 검토해 AI 시스템의 의도된 용도에 비추어 각 라이선스가 부여하는 의무, 제한, 권리를 판단하는 절차를 갖출 것을 요구한다. 검토는 상위(업스트림)에서 물려받는 의무와 하위(다운스트림)로 넘기는 의무를 모두 다룬다.

2. 해야 할 활동

• 코드, 가중치, 데이터셋, AI 시스템 자체의 라이선스를 식별하는 절차를 수립한다.
• 모델 트리의 상위 모델별 라이선스를 추적하고, 각 라이선스의 의무·제한·권리를 문서화한다.
• 소스 코드와 의존성은 자동 스캔 도구로 1차 식별한다. ([본 가이드 권고])
• 모델 가중치와 데이터셋, 비표준 라이선스는 법무 또는 거버넌스 검토로 판단한다. ([본 가이드 권고])
• 외부에서 모델이나 데이터셋을 도입할 때 라이선스 메타데이터를 함께 받는 인입 절차를 둔다. ([본 가이드 권고])
• 검토 결과(의무, 제한, 권리)를 AI SBOM에 기록해 추적한다.

3. 요구사항 및 입증자료

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

3.5.1 라이선스 의무 검토·문서화 절차

준수 방법

검토 절차는 자재 유형에 따라 자동화 수준이 다르다는 점을 전제로 설계한다. 소스 코드와 의존성 라이선스는 FOSSology, ScanCode, OSS Review Toolkit 같은 자동 스캔 도구로 상당 부분 식별할 수 있다. 그러나 모델 가중치와 데이터셋의 라이선스, 그리고 모델 트리의 파생 관계는 이런 도구의 적용 범위 밖이거나 정확도가 낮다. 비표준 라이선스의 사용 목적 제한은 사람의 해석이 필요하다. 따라서 자동 스캔으로 1차 식별하고, 모델과 데이터셋과 비표준 라이선스는 법무 또는 거버넌스 검토로 넘기는 분업 구조가 현실적이다.

아래 그림은 자재가 들어올 때 라이선스 의무를 판단하는 의사결정 흐름이다.

flowchart TD
    A([AI 시스템 자재 입력]) --> B{자재 유형}
    B -->|코드·의존성| C[자동 SCA 스캔\nScanCode·ORT]
    B -->|모델·데이터셋| D[라이선스 메타데이터 확인\n모델 카드·데이터시트]
    C --> E{라이선스 식별?}
    D --> E
    E -->|표준 허용 라이선스| F[의무·제한·권리 분류]
    E -->|비표준·불명확| G[법무·거버넌스 검토\n사용 목적 제한 해석]
    G --> F
    F --> H{의도된 용도와\n충돌?}
    H -->|예| I[위험 완화 또는\n자재 교체]
    H -->|아니오| J[AI SBOM에 기록\n업스트림·다운스트림 의무]
    I --> J
    J --> K([정기 재검토])

    style A fill:#2d3748,color:#fff
    style G fill:#744210,color:#fff
    style I fill:#c53030,color:#fff
    style J fill:#2b6cb0,color:#fff

그림 1. 라이선스 의무 검토 의사결정 흐름

고려사항

• 인입 게이트에서 메타데이터 강제: 라이선스 의무가 누락되는 가장 큰 원인은 모델이 다운스트림 으로 전파되며 출처와 라이선스 정보가 소실되는 라이선스 드리프트(license drift)다. 한 연구는 모델에서 애플리케이션으로 넘어가는 전이에서 제한 조항의 상당수가 사라진다고 보고한다 (arXiv:2509.09873). 다운스트림에서 복원하려 애쓰기보다, 사내 모델·데이터셋 레지스트리에서 라이선스 메타데이터가 없는 자재의 인입을 막는 편이 효과적이다. ([본 가이드 권고])
• 비표준 라이선스는 정책으로 선결정: Llama 커뮤니티 라이선스나 OpenRAIL 계열의 행동 사용 제한은 준수 여부를 사후에 자동 추적하기 어렵다. 3.1 정책의 허용·금지 목록으로 도입 시점에 결정한다. ([본 가이드 권고])
• 모델 트리 추적: 도입 모델이 어떤 상위 모델에서 파생되었는지를 모델 카드로 확인하고, 상위 모델의 라이선스 의무가 하위로 전파되는지 검토한다.
• 데이터셋 사용 제한 확인: CC-BY-NC 같은 비상업 라이선스 데이터셋을 상업 제품의 학습에 사용했는지 점검한다. 데이터셋 라이선스 누락과 오기재가 흔하므로 원문으로 대조한다.
• 자동화 한계 인지: 자동 스캔 도구의 결과를 최종 판단으로 삼지 않는다. 도구는 식별을 돕고, 의무의 해석과 충돌 판단은 사람이 맡는다.

샘플

아래는 라이선스 의무 검토 절차서의 핵심 부분 샘플이다. 이 절차 문서가 입증자료 3.5.1이 된다.

## AI 라이선스 의무 검토 절차

### 1. 검토 대상
- AI 시스템 코드 및 의존성
- 모델 가중치 (도입 모델, 파인튜닝 모델)
- 데이터셋 (학습·테스트·검증)
- 모델 트리 상위 모델의 라이선스

### 2. 검토 단계
1) 자동 식별: 코드와 의존성은 SCA 도구로 라이선스를 스캔한다.
2) 메타데이터 수집: 모델과 데이터셋은 모델 카드·데이터시트에서 라이선스를 수집한다.
   메타데이터가 없으면 인입을 보류한다.
3) 분류: 식별된 라이선스를 정책의 허용·조건부·금지 목록에 대조한다.
4) 법무 검토: 비표준·불명확 라이선스는 법무·거버넌스 검토로 의무를 해석한다.
5) 기록: 업스트림·다운스트림 의무, 제한, 권리를 AI SBOM에 기록한다.

### 3. 책임과 주기
- 1차 식별: 개발 담당
- 의무 해석: 법무·AI 거버넌스 책임자
- 재검토: 모델·데이터셋 교체 시, 그리고 최소 분기 1회

5. 참고

• 라이선스 허용·금지 목록 정책: 3.1 정책
• 검토 결과를 기록할 AI SBOM: 3.9 AI SBOM
• 자동 스캔 도구: 도구 — FOSSology, SCANOSS
• AI 모델·데이터셋 라이선스 전략: 기업 오픈소스 관리 가이드 — AI 컴플라이언스

2.2 - 3.6 투명성 의무

1. 조항 개요

라이선스 의무(3.5)가 “이 자재를 쓸 권리가 있는가"를 묻는다면, 투명성 의무는 “이 자재에 대해 무엇을 공개해야 하는가"를 묻는다. 두 의무는 다른 출처에서 온다. 라이선스 의무는 저작권자가 계약으로 부과하고, 투명성 의무는 규제가 법으로 부과한다.

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

2. 해야 할 활동

• 도입·개발하는 AI 시스템에 적용되는 투명성 규제를 식별하는 절차를 둔다.
• 학습·테스트·검증 데이터셋에 공개 의무가 걸리는지 의도된 용도를 기준으로 검토한다.
• 다운스트림 수령자에 대한 공개 의무가 있으면 위험 완화 조치를 정한다.
• 취한 투명성 조치를 문서화한다.
• 규제기관이 정한 최신 투명성 의무를 정기적으로 갱신해 반영한다. ([본 가이드 권고])

3. 요구사항 및 입증자료

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

3.6.1 투명성 의무 검토·문서화 절차

준수 방법

투명성 의무는 규제마다 다르므로, 먼저 어떤 규제가 적용되는지부터 식별한다. 적용 규제가 정해지면 각 규제가 요구하는 공개 항목을 도출하고, 그 항목을 AI SBOM이나 모델 카드에 반영한다. 라이선스 의무와 달리 투명성 의무는 “공개"가 핵심이므로, 산출물이 외부에 전달될 수 있는 형태로 정리되어야 한다.

아래 표는 AI SBOM과 교차하는 주요 투명성 의무다. 규제 일정과 전체 맥락은 3.10 거버넌스의 규제 매트릭스에서 함께 관리한다.

표 1. AI SBOM과 교차하는 투명성 의무 (2026-06 기준)

다음 그림은 자재의 의도된 용도에서 투명성 의무를 도출하는 검토 흐름이다.

flowchart TD
    A([모델·데이터셋과 의도된 용도]) --> B[적용 규제 식별\nEU 인공지능법·한국 AI 기본법 등]
    B --> C{투명성 의무\n존재?}
    C -->|없음| D[검토 결과 기록\n의무 없음 근거]
    C -->|있음| E[공개 항목 도출\n데이터 요약·라벨링·출처]
    E --> F{다운스트림\n공개 쟁점?}
    F -->|있음| G[위험 완화 조치\n요약 공개·계약 고지]
    F -->|없음| H[AI SBOM·모델 카드에 반영]
    G --> H
    H --> I([조치 문서화\n정기 갱신])

    style A fill:#2d3748,color:#fff
    style E fill:#2b6cb0,color:#fff
    style G fill:#744210,color:#fff
    style I fill:#22543d,color:#fff

그림 1. 투명성 의무 검토 흐름

고려사항

• 데이터셋 출처가 핵심: 투명성 의무의 다수가 학습 데이터에 걸린다. 데이터셋의 출처와 라이선스가 AI SBOM에 기록되어 있어야 공개 의무를 이행할 수 있다. AI SBOM(3.9)과 직접 연결된다.
• 의도된 용도가 기준: 같은 모델이라도 사용 사례에 따라 투명성 의무가 달라진다. 고위험 용도나 일반 공중 대상 서비스는 의무가 무거워진다.
• 다운스트림 공개 의무: 외부에 모델이나 시스템을 공급할 때 수령자에게 알려야 할 정보가 있는지 검토한다. 위험 완화는 학습 데이터 요약 공개나 계약상 고지로 이행할 수 있다.
• 규제 변화 반영: EU 인공지능법은 2026년 8월부터 투명성 의무를 적용하므로, 시점에 맞춰 절차를 갱신한다. 갱신 책임은 거버넌스(3.10)가 관리한다.

샘플 (투명성 의무 검토 절차)

아래는 투명성 의무 검토 절차서의 핵심 부분 샘플이다. 이 절차 문서가 입증자료 3.6.1이 된다.

## 투명성 의무 검토 절차

### 1. 적용 규제 식별
AI 시스템의 의도된 용도와 배포 지역을 기준으로 적용 규제를 식별한다.
(예: EU 시장 배포 → EU 인공지능법, 국내 고영향 AI → 한국 AI 기본법)

### 2. 공개 항목 도출
규제별 투명성 의무를 공개 항목으로 정리한다.
- 학습 데이터 요약 (EU 인공지능법 Article 53)
- AI 생성·상호작용 표시 (EU 인공지능법 Article 50, 한국 AI 기본법)
- 데이터 출처 공개 (한국 AI 기본법)

### 3. 다운스트림 검토
외부 공급 시 수령자에게 전달할 정보를 검토하고, 필요한 위험 완화 조치를 정한다.

### 4. 반영과 문서화
도출한 공개 항목을 AI SBOM과 모델 카드에 반영하고, 취한 조치를 기록한다.

### 5. 책임과 주기
- 검토: 법무·AI 거버넌스 책임자
- 갱신: 규제 시행 일정 변경 시, 그리고 최소 반기 1회

5. 참고

• 라이선스 의무와의 구분: 3.5 라이선스 의무
• 공개 항목을 담을 AI SBOM: 3.9 AI SBOM
• 규제 일정과 거버넌스: 3.10 거버넌스
• AI 모델 라이선스와 표시 의무: 기업 오픈소스 관리 가이드 — AI 컴플라이언스

2.3 - 3.9 AI SBOM

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 SBOM 영역은 “생성은 도구로 자동화되지만, 정확성과 준수 판단은 사람이 채운다"는 경계가 가장 뚜렷한 곳이다. 이 페이지는 그 경계를 따라 절차를 안내한다.

2. 해야 할 활동

• AI 시스템의 구성요소(모델, 데이터셋 등)에 대한 식별, 추적, 검토, 승인, 보관 절차를 수립한다.
• AI SBOM 형식을 정한다(SPDX 3.0 AI Profile 또는 CycloneDX ML-BOM 권장). ([본 가이드 권고])
• 제3자에게서 유입되는 모델과 데이터셋을 AI SBOM에 반드시 포함한다.
• 생성 도구를 CI/CD에 연동해 AI SBOM을 반복 생성한다. ([본 가이드 권고])
• 생성된 AI SBOM의 라이선스와 출처 필드가 정확한지 사람이 검토한다. ([본 가이드 권고])
• 절차가 준수되었음을 입증하는 기록(생성 이력, 승인 이력)을 보관한다.

3. 요구사항 및 입증자료

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

3.9.1 AI SBOM 관리 절차 (식별, 추적, 검토, 승인, 보관)

준수 방법

AI SBOM 절차는 생성, 검토, 승인, 보관의 네 단계로 설계한다. 생성 단계는 도구로 자동화하고, 검토와 승인 단계는 사람이 맡는다. 도구가 모델 카드의 라이선스 필드를 그대로 옮겨 적더라도, 그 라이선스가 실제 사용 사례에 맞는지, 누락이나 오기재는 없는지는 도구가 판단하지 못하기 때문이다.

아래 그림은 AI SBOM 생성에서 보관까지의 흐름이다.

flowchart TD
    A([AI 시스템 자재]) --> B[생성: SBOM 도구 실행\ncdxgen·OWASP AIBOM Generator]
    B --> C[형식 산출\nSPDX 3.0 AI Profile\n또는 CycloneDX ML-BOM]
    C --> D{인바운드 자재\n포함?}
    D -->|누락| E[제3자 모델·데이터셋\n추가 수집]
    E --> C
    D -->|포함| F[검토: 라이선스·출처\n필드 사람 확인]
    F --> G{정확·완전?}
    G -->|아니오| H[보강 또는 정정]
    H --> F
    G -->|예| I[승인: 거버넌스 책임자]
    I --> J([보관: 버전·이력 관리\n취약점 모니터링])

    style A fill:#2d3748,color:#fff
    style B fill:#2b6cb0,color:#fff
    style F fill:#744210,color:#fff
    style J fill:#22543d,color:#fff

그림 1. AI SBOM 생성에서 보관까지의 절차

도구 매핑

각 단계에 활용할 수 있는 오픈소스 도구다. “자동화 수준"은 그 작업을 도구가 어디까지 대신하는지를 나타낸다.

각 도구의 설치와 사용법, 실행 화면은 도구 절에서 자세히 다룬다(OWASP AIBOM Generator, cdxgen, 모델·컨테이너 스캐너).

cdxgen으로 AI BOM을 생성하는 명령은 다음과 같다. Hugging Face 모델 URL과 purl, Modelfile, GGUF 아티팩트를 직접 입력할 수 있다(cdxgen AI-BOM 문서).

# AI 프로젝트 디렉토리에서 AI BOM 생성
cdxgen -t ai -o aibom.json .

# AI/ML 메타데이터(formulation)를 포함해 생성
cdxgen -t ai --include-formulation -o aibom.json .

OWASP AIBOM Generator는 Hugging Face 모델을 입력받아 CycloneDX 형식 AIBOM을 만들고 완전성 점수를 매긴다. OWASP Gen AI Security Project가 관리하며 Hugging Face Space로도 제공된다 (OWASP AIBOM Generator).

직접 실행 — cdxgen으로 생성해 보기

사전학습 모델(facebook/bart-large-cnn)을 불러오는 요약 앱(transformers, torch 의존)에 cdxgen을 실제로 돌린 결과다. 도구가 의존성 5건을 자동으로 식별해 CycloneDX 1.7 형식 BOM을 만든다.

$ cdxgen -t python --include-formulation -o aibom.json .
CycloneDX Generator 12.5.1 (Node.js)

생성된 components — 5건 (CycloneDX 1.7):
  transformers     4.44.2    pkg:pypi/transformers@4.44.2      license: 비어 있음
  torch            2.4.0     pkg:pypi/torch@2.4.0             license: 비어 있음
  numpy            1.26.4    pkg:pypi/numpy@1.26.4            license: 비어 있음
  tokenizers       0.19.1    pkg:pypi/tokenizers@0.19.1       license: 비어 있음
  huggingface-hub  0.24.6    pkg:pypi/huggingface-hub@0.24.6   license: 비어 있음

생성된 BOM의 컴포넌트 한 건은 다음과 같다. 식별 근거(evidence)는 채워지지만 licenses 필드는 비어 있다.

{
  "name": "transformers",
  "version": "4.44.2",
  "purl": "pkg:pypi/transformers@4.44.2",
  "type": "library",
  "evidence": {
    "identity": [
      { "field": "purl", "confidence": 0.5,
        "methods": [{ "technique": "manifest-analysis", "value": "requirements.txt" }] }
    ]
  }
}

그림 2. cdxgen 12.5.1 실행 출력 (실행일 2026-06-13, -t python --include-formulation)

형식 샘플 (CycloneDX ML-BOM)

아래는 CycloneDX 1.6 ML-BOM의 모델 컴포넌트 구조를 줄인 예시다. 키 구조는 CycloneDX 공식 스펙의 machine-learning-model 컴포넌트와 modelCard를 따른다. 라이선스가 비표준(SPDX ID가 없는 경우)이면 name으로 적는다.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "bom-ref": "model-llama31-8b",
      "type": "machine-learning-model",
      "group": "meta-llama",
      "name": "Llama-3.1-8B",
      "version": "1.0",
      "licenses": [
        { "license": { "name": "Llama 3.1 Community License" } }
      ],
      "modelCard": {
        "modelParameters": {
          "task": "text-generation",
          "architectureFamily": "llama",
          "datasets": [
            { "type": "dataset", "name": "사전학습 공개 코퍼스", "classification": "public" }
          ]
        },
        "considerations": {
          "useCases": ["사내 문서 요약"],
          "technicalLimitations": ["환각 가능성", "한국어 성능 편차"]
        }
      }
    }
  ]
}

SPDX 3.0을 쓴다면 AI 프로파일(AI Profile)과 데이터셋 프로파일(Dataset Profile)이 같은 정보를 표현한다(SPDX 3.0 AI Profile). 형식의 구체 필드와 생성 도구의 기술 상세는 ISO/IEC 42001 가이드 — AI SBOM에서 다룬다.

고려사항

• 인바운드 자재 반영(규격 의무): 외부에서 도입한 모델과 데이터셋이 AI SBOM에 빠지지 않도록, 인입 시점에 SBOM 항목을 생성하는 절차를 둔다. 이것은 shall 수준의 의무다.
• 생성은 도구, 검토는 사람: 생성 도구는 모델 카드에 적힌 라이선스를 그대로 옮긴다. 모델 카드 자체에 라이선스가 누락되거나 잘못 적힌 경우가 흔하므로, 생성된 AI SBOM의 라이선스와 출처 필드를 사람이 원문과 대조해 검토한다.
• 형식 일관성: 조직 내에서 SPDX와 CycloneDX 중 하나를 기본 형식으로 정해 도구와 저장소를 일관되게 운영한다. 두 형식 모두 모델과 데이터셋을 1급 구성요소로 다룬다.
• CI/CD 연동: AI SBOM은 한 번 만들고 끝나는 산출물이 아니다. 모델이나 데이터셋이 바뀔 때마다 다시 생성되도록 파이프라인에 연동한다.

3.9.2 절차 준수 입증 기록

준수 방법

입증자료 3.9.2는 절차가 실제로 지켜졌음을 보여주는 기록이다. AI SBOM 파일 자체와 함께, 언제 누가 생성하고 검토하고 승인했는지의 이력을 남긴다. CI/CD에서 자동 생성한다면 빌드 로그와 생성된 SBOM 아티팩트가 기록이 되고, Dependency-Track 같은 관리 도구에 업로드한 이력도 증거가 된다.

고려사항

• 생성 이력 보존: 공급한 AI 시스템의 버전별로 그 시점의 AI SBOM을 보관해 추적성을 확보한다.
• 승인 기록: 검토와 승인을 누가 했는지 기록한다. 거버넌스(3.10)의 수명주기 검토와 연결된다.

5. 참고

• 라이선스 의무 검토 절차: 3.5 라이선스 의무
• AI SBOM 형식·생성 도구 기술 상세: ISO/IEC 42001 가이드 — AI SBOM
• SBOM 관리 도구: Dependency-Track, cdxgen + Dependency-Track 연동
• 거버넌스와 수명주기 검토: 3.10 거버넌스

3 - 운영

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

3.1 - 3.7 접근

1. 조항 개요

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

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

2. 해야 할 활동

• 제3자가 AI SBOM 컴플라이언스 문의를 할 수 있는 수단(예: 공개 이메일 주소)을 공개한다.
• 공개 수단을 제품 고지문이나 웹사이트 등 외부에서 찾을 수 있는 곳에 게시한다.
• 외부 문의를 접수·분류·대응하는 내부 절차를 문서화한다.
• 대응 담당자와 처리 기한을 정한다.
• 문의와 대응 이력을 기록한다.

3. 요구사항 및 입증자료

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

3.7.1 공개된 외부 문의 수단

준수 방법

누구나 찾을 수 있는 공개 연락 수단을 명시한다. 역할 기반 이메일 주소(개인이 아닌 직무 주소)가 안정적이다. 게시 위치는 제품 고지문, 회사 웹사이트의 오픈소스·AI 정책 페이지, 모델 카드의 연락처 항목 등이다. 응답 기한을 함께 안내하면 신뢰를 높인다.

샘플

AI 컴플라이언스 문의: ai-compliance@company.com

당사가 제공하는 AI 시스템의 구성요소, 모델·데이터셋 라이선스, AI SBOM에 관한
문의를 받습니다. 접수 후 영업일 기준 14일 이내에 1차 회신을 드립니다.

(게시 위치: 제품 고지문, 회사 웹사이트 AI 정책 페이지, 모델 카드 연락처)

3.7.2 내부 문의 대응 절차

준수 방법

외부 문의를 접수해 답변하기까지의 내부 절차를 문서화한다. 접수, 분류, 담당 배정, 검토, 회신, 기록의 단계를 정하고 각 단계의 기한을 둔다. AI SBOM 문의는 모델 카드나 라이선스 검토 기록을 참조해야 하므로, AI SBOM 검증 담당과 라이선스 검토 담당이 함께 대응한다.

아래 그림은 외부 문의 대응 흐름이다.

flowchart TD
    A([외부 문의 접수\nai-compliance@]) --> B[분류\nAI SBOM·라이선스·투명성]
    B --> C[담당 배정\n검증·법무 담당]
    C --> D[검토\nAI SBOM·모델 카드 확인]
    D --> E{법무 검토\n필요?}
    E -->|예| F[법무 자문]
    E -->|아니오| G[회신 작성]
    F --> G
    G --> H([발송·종결\n이력 기록])

    style A fill:#2d3748,color:#fff
    style D fill:#2b6cb0,color:#fff
    style F fill:#744210,color:#fff
    style H fill:#22543d,color:#fff

그림 1. 외부 AI SBOM 컴플라이언스 문의 대응 흐름

고려사항

• 기한 설정: 1차 회신 기한(예: 14일)과 최종 답변 기한(예: 60일)을 정한다.
• AI 고유 정보 보호: 문의에 답하며 모델 가중치나 학습 데이터 같은 민감 정보를 어디까지 공개할지 기준을 둔다. 영업 비밀과 투명성 의무(3.6) 사이의 경계를 정한다. ([본 가이드 권고])
• 이력 보관: 문의 내용과 회신, 처리 기간을 기록해 입증자료로 보존한다.

샘플 (대응 절차 개요)

## AI SBOM 컴플라이언스 문의 대응 절차

1. 접수: ai-compliance@ 로 들어온 문의를 등록한다.
2. 분류: AI SBOM 요청 / 라이선스 문의 / 투명성 의무 문의로 분류한다.
3. 담당 배정: 분류에 따라 AI SBOM 검증 담당 또는 라이선스 검토 담당에게 배정한다.
4. 검토·회신: 관련 AI SBOM과 모델 카드를 확인해 회신한다. 민감 정보는 공개 기준에
   따른다. 필요 시 법무 검토를 거친다.
5. 기록: 문의·회신·처리 기간을 보관한다.

기한: 1차 회신 14일, 최종 답변 60일.

5. 참고

• 대응 담당의 역할과 자원: 3.8 효과적 자원 배분
• 회신에 쓰이는 AI SBOM: 3.9 AI SBOM
• 공개 범위와 투명성 의무: 3.6 투명성 의무
• ISO/IEC 5230 외부 문의 본보기: ISO/IEC 5230 준수 가이드 — 3.2.1 외부 문의 대응

3.2 - 3.8 효과적 자원 배분

1. 조항 개요

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

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

2. 해야 할 활동

• 프로그램 과제의 성공적 실행을 위해 책임(accountability)을 배정한다.
• 과제에 충분한 시간과 재원을 배분한다.
• AI SBOM 컴플라이언스에 관한 법률 전문성을 필요한 사람이 이용할 수 있게 한다.
• 정책과 과제를 검토·갱신하는 절차를 둔다.
• 부적합 사례를 검토하고 시정하는 절차를 둔다.

3. 요구사항 및 입증자료

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

3.8.1 역할 담당자 식별 문서

준수 방법

프로그램 역할을 맡은 사람이나 그룹, 기능을 이름과 함께 문서로 식별한다. 개인 이동에 대비해 직무명을 함께 적는 편이 안정적이다. AI SBOM 프로그램에는 일반 오픈소스 역할에 더해 AI 거버넌스 책임자와 AI SBOM 검증 담당, 모델·데이터셋 라이선스 검토 담당이 필요하다.

샘플

| 역할 | 담당자(직무) | 연락처 |
|------|-------------|--------|
| AI 거버넌스 책임자 | 김OO (AI 윤리·거버넌스 리드) | ai-gov@company.com |
| AI SBOM 검증 담당 | 이OO (플랫폼 엔지니어) | sbom@company.com |
| 라이선스 검토 담당 | 박OO (오픈소스 법무) | oss-legal@company.com |
| 보안 담당 | 최OO (제품 보안) | psirt@company.com |

3.8.2 인력 배치와 재원 제공

준수 방법

식별된 역할에 실제로 인력이 배치되고 예산이 할당되었음을 보인다. 투입 비율(예: 30%)과 연간 예산 근거를 기록한다. AI SBOM 컴플라이언스는 모델·데이터셋 검토와 도구 운영에 시간이 들므로, 역할별 투입을 현실적으로 산정한다.

고려사항

• 투입 비율 명시: 겸직이면 AI SBOM 업무에 할당된 시간 비율을 적는다.
• 도구 예산: AI SBOM 생성·관리 도구와 법무 자문 비용을 예산에 포함한다.

샘플

| 역할 | 담당자 | 투입 비율 | 연간 예산 근거 | 승인자/승인일 |
|------|--------|----------|---------------|--------------|
| AI 거버넌스 책임자 | 김OO | 30% | 인건비 + 규제 자문 | CTO / 2026-01-15 |
| AI SBOM 검증 담당 | 이OO | 50% | 인건비 + 도구 운영 | CTO / 2026-01-15 |

3.8.3 법률 전문성 접근

준수 방법

AI SBOM 컴플라이언스에 관한 법률 전문성을 필요한 사람이 이용할 수 있게 한다. 비표준 라이선스 해석과 규제 의무 판단은 법무의 몫이므로, 내부 법무 또는 외부 법무법인 가운데 접근 경로를 명시한다. 에스컬레이션 기준(어떤 사안을 법무로 올리는가)을 함께 정한다.

샘플

- 내부: 오픈소스 법무 담당 (박OO) — 1차 라이선스 검토
- 외부: ○○ 법무법인 AI·IP 팀 — 비표준 라이선스 분쟁, 규제 해석
- 에스컬레이션 기준: 정책의 금지·조건부 목록에 없는 라이선스, 다운스트림 공개 의무 판단,
  규제 신규 적용 사안

3.8.4 내부 책임 배정 절차

준수 방법

AI SBOM 컴플라이언스의 내부 책임을 배정하는 절차를 문서화한다. 책임이 모호하면 누락이 생기므로, 업무별로 실행(R), 승인(A), 자문(C), 통보(I)를 구분하는 RACI 매트릭스가 효과적이다.

샘플 (RACI 매트릭스)

R 실행, A 승인, C 자문, I 통보

3.8.5 부적합 검토·시정 절차

준수 방법

부적합 사례(예: 금지 라이선스 모델 도입, AI SBOM 누락, 투명성 의무 미이행)를 검토하고 시정하는 절차를 둔다. 심각도에 따라 처리 기한을 달리한다. AI에서는 모델이 이미 배포된 뒤 라이선스 문제가 드러나는 경우가 있으므로, 회수나 교체를 포함한 시정 경로를 마련한다.

샘플 (시정 절차와 심각도 기준)

시정 절차: 식별·보고 → 심각도 평가 → 원인 분석 → 시정 조치 → 재발 방지 → 기록

| 심각도 | 예시 | 처리 기한 |
|--------|------|----------|
| 높음 | 금지 라이선스 모델이 외부 배포 제품에 포함 | 즉시 대응(48시간 내 격리·교체 검토) |
| 중간 | AI SBOM에 인바운드 모델 누락 | 7일 내 보강 |
| 낮음 | 모델 카드 메타데이터 일부 미기재 | 다음 정기 검토 시 처리 |

5. 참고

• 역할별 역량 정의: 3.2 역량
• 부적합 시정과 연결되는 거버넌스 검토: 3.10 거버넌스
• ISO/IEC 5230 자원 배분 본보기: ISO/IEC 5230 준수 가이드 — 3.2.2 효과적 리소스

4 - 거버넌스

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

4.1 - 3.10 거버넌스

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 법령의 준수를 강조하며, 윤리적 고려사항과 위험 관리, 투명성을 함께 다룬다. 핵심은 한 번 만든 프레임워크를 정기적으로 검토해 최신 규제와 모델 변화를 반영하는 것이다.

2. 해야 할 활동

• AI 시스템 수명주기 전반을 다루는 거버넌스 프레임워크 문서를 작성한다.
• 프레임워크에 신흥 AI 규제 추적, 위험 관리, 투명성, 윤리적 고려를 포함한다.
• 프레임워크를 정기적으로 검토하고 갱신하는 절차를 둔다.
• AI 시스템과 학습 데이터의 지속적 사용에 따르는 위험을 모니터링한다.
• 모델 트리 변경, 규제 시행, OSAID 분류 변화 같은 사건을 거버넌스에 반영한다. ([본 가이드 권고])

3. 요구사항 및 입증자료

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

3.10.1 AI 거버넌스 프레임워크와 정기 검토 절차

준수 방법

거버넌스 프레임워크는 세 가지를 담는다. 신흥 규제를 추적해 의무를 도출하는 부분, AI 시스템 수명주기를 모니터링하는 부분, 그리고 프레임워크 자체를 정기적으로 검토하는 절차다. 규제는 빠르게 바뀌므로 프레임워크는 고정된 문서가 아니라 갱신을 전제한 살아있는 체계여야 한다.

규격이 거명한 세 축은 성격이 다르다. EU 인공지능법은 조문 단위의 구체적 의무를 부과하고, 히로시마 AI 프로세스는 자발적 투명성 보고를 운영하며, 중국 이니셔티브는 정책 선언에 가깝다. 거버넌스는 이 차이를 구분해 각각을 추적한다.

아래 표는 AI SBOM 관점에서 추적해야 할 주요 규제다. 전체 규제 매트릭스와 ISO/IEC 42001 맥락은 ISO/IEC 42001 가이드 — 조직 맥락과 리더십에서 다룬다.

표 1. AI SBOM과 교차하는 주요 AI 규제 (2026-06 기준)

수명주기 모니터링은 개발에서 폐기까지의 흐름에 거버넌스 점검점을 두는 것이다. 아래 그림은 AI SBOM을 축으로 한 수명주기 거버넌스를 보여준다.

flowchart TD
    A([모델·데이터셋 도입]) --> B[개발: AI SBOM 생성\n라이선스·출처 기록]
    B --> C[검토: 의무·위험·규제 적합성\n거버넌스 책임자 승인]
    C --> D[배포: 공급 시스템에\nAI SBOM 동반]
    D --> E[운영 모니터링\n취약점·라이선스 변경 감시]
    E --> F{변화 발생?}
    F -->|모델 트리 변경| B
    F -->|신규 규제 시행| G[프레임워크 갱신]
    F -->|이상 없음| E
    G --> H([정기 검토\n분기·연간])
    H --> C

    style A fill:#2d3748,color:#fff
    style C fill:#744210,color:#fff
    style G fill:#c53030,color:#fff
    style H fill:#22543d,color:#fff

그림 1. AI SBOM을 축으로 한 수명주기 거버넌스

고려사항

• 규제 추적 책임 지정: 신흥 규제를 누가 추적하고 의무를 도출하는지 거버넌스에 명시한다. EU 인공지능법은 2026년 8월과 2027년에 단계적으로 의무가 확대되므로 시점을 관리한다.
• 모델 트리 변경 관리: 도입 모델이 새 버전으로 바뀌거나 상위 모델이 교체되면 라이선스 의무가 달라질 수 있다. 변경을 거버넌스 검토 사건으로 등록한다. ([본 가이드 권고])
• OSAID 분류 갱신: “오픈소스 AI"와 “오픈 웨이트(Open Weight)“의 구분(OSAID 1.0)은 모델 라이선스 판단에 영향을 준다. 분류 기준 변화를 정기 검토에 포함한다.
• 검토 주기 명시: 분기 단위로 모델과 데이터셋 변경을, 연 단위로 규제와 프레임워크 전반을 검토한다. 검토 완료일과 검토자를 기록한다.
• 다른 조항과의 연결: 거버넌스는 투명성 의무(3.6)의 규제 검토와 AI SBOM(3.9)의 수명주기 관리를 상위에서 묶는다. 중복 절차를 만들지 말고 연결한다.

샘플 (거버넌스 프레임워크와 연간 검토 계획)

아래는 거버넌스 프레임워크 문서와 정기 검토 계획의 핵심 부분 샘플이다. 이 문서가 입증자료 3.10.1이 된다.

## AI 거버넌스 프레임워크

### 1. 범위와 목적
AI 시스템의 도입·개발·배포·운영·폐기 전 수명주기에 걸쳐 라이선스, 투명성, 위험,
규제 준수를 관리한다.

### 2. 거버넌스 구조
- AI 거버넌스 책임자: 프레임워크 승인, 규제 의무 최종 판단
- 규제 추적 담당: 신흥 AI 규제 모니터링, 의무 도출
- AI SBOM 검증 담당: 생성·검토·승인 절차 운영
- 법무: 비표준 라이선스와 규제 해석

### 3. 정기 검토 계획
| 주기 | 검토 항목 | 담당 | 산출물 |
|------|----------|------|--------|
| 분기 | 모델·데이터셋 변경, 모델 트리 라이선스 | AI SBOM 검증 담당 | 변경 검토 기록 |
| 반기 | 비표준 라이선스 분류, OSAID 갱신 | 법무 | 분류 갱신본 |
| 연간 | 규제 시행 일정, 프레임워크 전반, 정책 정합성 | AI 거버넌스 책임자 | 프레임워크 개정본 |

### 4. 변경 관리
모델 트리 변경, 신규 규제 시행, 라이선스 정책 변경이 발생하면 정기 검토를 기다리지
않고 임시 검토를 소집한다. 검토 결과와 조치는 변경 이력에 기록한다.

5. 참고

• 정책 기반: 3.1 정책
• 투명성 의무와 규제 검토: 3.6 투명성 의무
• AI SBOM 수명주기 관리: 3.9 AI SBOM
• 전체 규제 매트릭스와 ISO/IEC 42001 맥락: ISO/IEC 42001 가이드 — 조직 맥락과 리더십

5 - 도구

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

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

도구 한눈에 보기

각 도구는 생성, 분석, 관리 단계 중 일부를 자동화한다. 한 도구로 전부 해결되지 않으므로, AI SBOM을 생성하는 도구(OWASP AIBOM Generator, cdxgen)와 보안을 분석하는 도구(Lab700x, Trivy), 관리하는 도구(Dependency-Track)를 조합한다.

5.1 - OWASP AIBOM Generator

개요

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를 쓰거나, 저장소를 받아 로컬에서 띄운다.

먼저 입력 화면에서 Hugging Face 모델 ID(예: facebook/bart-large-cnn)를 넣고 생성을 누른다.

그림 1. OWASP AIBOM Generator 입력 화면 (GenAI Security Project, 캡처 2026-06-13)

생성이 끝나면 결과 화면에 AIBOM 요약, 완전성 평가, 다운로드 버튼(CycloneDX 1.6과 1.7), AI 모델 정보, 모델 카드가 표시된다. 화면 상단의 완전성 평가는 BOM이 식별에 필요한 최소 항목을 갖췄는지 한눈에 보여준다.

그림 2. 생성 결과 화면 — 모델 정보, 라이선스(MIT), 완전성 평가(Basic) (캡처 2026-06-13)

결과 화면은 사람이 읽는 보기(Human-Friendly View)와 함께 필드 체크리스트, 점수 보고서, JSON 보기 탭을 제공한다. 라이선스 의무 검토와 AI SBOM 보관에 필요한 항목을 화면에서 바로 확인하고 CycloneDX 파일로 내려받는다.

사용법 B — 명령줄(CLI)

CI/CD에 넣거나 여러 모델을 일괄 처리할 때는 CLI가 편하다. 설치 후 모델 ID를 인자로 준다.

# 설치 (Python 가상환경 권장)
pip install "git+https://github.com/GenAI-Security-Project/aibom-generator"

# 모델 ID로 AIBOM 생성
aibom facebook/bart-large-cnn -o aibom.json

아래는 실제 실행 결과다. CycloneDX 1.6과 1.7을 생성하고 스키마 검증을 통과하며, 완전성 점수를 섹션별로 보여준다.

$ aibom facebook/bart-large-cnn -o aibom.json

✅ Successfully generated CycloneDX 1.6 SBOM — Schema Validation (1.6): Valid
✅ Successfully generated CycloneDX 1.7 SBOM — Schema Validation (1.7): Valid

📊 Completeness Score: 58.7/100   Profile: Basic
   - Required Fields:        20/20
   - Metadata:                8/20
   - Component Basic:        17.1/20
   - Component Model Card:    6.7/30
   - External References:    10/10

그림 3. CLI 실행 출력 (aibom CLI, 모델 facebook/bart-large-cnn, 실행 2026-06-13)

생성된 BOM의 모델 컴포넌트는 라이선스와 모델 카드가 채워진다. cdxgen 출력과 달리 licenses 필드가 비어 있지 않다.

{
  "type": "machine-learning-model",
  "name": "bart-large-cnn",
  "purl": "pkg:huggingface/facebook/bart-large-cnn",
  "licenses": [{ "license": { "id": "MIT" } }],
  "authors": [{ "name": "facebook" }],
  "modelCard": { "modelParameters": { }, "considerations": { } }
}

실행 결과가 보여주는 것

참고

• AI SBOM 생성과 관리 절차: 3.9 AI SBOM
• 라이선스 의무 검토: 3.5 라이선스 의무
• 다른 생성 도구: cdxgen
• 공식: OWASP AIBOM Generator

5.2 - cdxgen

개요

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

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

주요 기능

• 소스 코드와 컨테이너 이미지에서 의존성을 식별해 CycloneDX SBOM을 생성한다.
• AI BOM 모드(-t ai)로 AI/ML 메타데이터(formulation)를 포함한다.
• Hugging Face 모델 URL, Modelfile, GGUF 아티팩트를 직접 입력으로 받는다.
• Dependency-Track 서버에 SBOM을 자동 제출해 지속 관리할 수 있다.

설치

# 일회성 실행 (Node.js 필요)
npx @cyclonedx/cdxgen@latest --version

# 전역 설치
npm install -g @cyclonedx/cdxgen

사용법 — AI BOM 생성

AI 프로젝트 디렉토리에서 AI BOM 모드로 실행한다.

# AI BOM 생성
cdxgen -t ai -o aibom.json .

# AI/ML 메타데이터(formulation)를 포함해 생성
cdxgen -t ai --include-formulation -o aibom.json .

아래는 사전학습 모델(facebook/bart-large-cnn)을 불러오는 요약 앱(transformers, torch 의존)에 cdxgen을 실제로 돌린 결과다. 의존성 5건을 자동 식별해 CycloneDX 1.7 BOM을 만든다.

$ cdxgen -t python --include-formulation -o aibom.json .
CycloneDX Generator 12.5.1 (Node.js)

생성된 components — 5건 (CycloneDX 1.7):
  transformers     4.44.2    pkg:pypi/transformers@4.44.2      license: 비어 있음
  torch            2.4.0     pkg:pypi/torch@2.4.0             license: 비어 있음
  numpy            1.26.4    pkg:pypi/numpy@1.26.4            license: 비어 있음
  tokenizers       0.19.1    pkg:pypi/tokenizers@0.19.1       license: 비어 있음
  huggingface-hub  0.24.6    pkg:pypi/huggingface-hub@0.24.6   license: 비어 있음

그림 1. cdxgen 실행 출력 (cdxgen 12.5.1, 실행 2026-06-13)

생성된 컴포넌트 한 건은 다음과 같다. 식별 근거(evidence)는 채워지지만 licenses 필드는 비어 있다.

{
  "name": "transformers",
  "version": "4.44.2",
  "purl": "pkg:pypi/transformers@4.44.2",
  "type": "library",
  "evidence": {
    "identity": [
      { "field": "purl", "confidence": 0.5,
        "methods": [{ "technique": "manifest-analysis", "value": "requirements.txt" }] }
    ]
  }
}

실행 결과가 보여주는 것

참고

• AI SBOM 생성과 관리 절차: 3.9 AI SBOM
• 모델 메타데이터 중심 생성기: OWASP AIBOM Generator
• SBOM 관리: Dependency-Track, cdxgen + Dependency-Track 연동
• 공식: cdxgen AI-BOM 문서

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

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

Trivy — LLM 추론 서버 컨테이너 스캔

Aqua Security의 오픈소스 스캐너로, 컨테이너 이미지와 파일시스템의 취약점을 점검한다. 최근 AI 모델 인프라 인식을 추가했다.

• 주요 기능: Ollama, LocalAI 같은 LLM 추론 서버 컨테이너를 스캔해, 포함된 오픈소스 라이브러리와 컨테이너 취약점을 수집한다.
• 사용법:

# 컨테이너 이미지 스캔 (취약점)
trivy image ollama/ollama:latest

# SBOM(CycloneDX) 생성
trivy image --format cyclonedx --output sbom.json ollama/ollama:latest

AI 모델을 컨테이너로 배포하는 환경에서 추론 서버의 취약점과 구성요소를 SBOM으로 남기는 데 쓴다.

Syft — AI 패키지와 가상환경 식별

Anchore의 SBOM 생성기로, 컨테이너와 파일시스템, 가상환경을 스캔한다.

• 주요 기능: Python 가상환경을 분석해 PyTorch, Transformers 등 AI 가동에 쓰인 패키지의 정확한 버전을 수집한다. SPDX와 CycloneDX 형식으로 출력한다.
• 사용법:

# 디렉토리 스캔 후 CycloneDX 출력
syft scan dir:. -o cyclonedx-json=sbom.json

# 컨테이너 이미지 스캔
syft scan registry:python:3.11-slim -o spdx-json

cdxgen과 역할이 비슷하므로, 이미 Anchore 도구 모음(Syft, Grype)을 쓰는 조직이라면 Syft로 AI 애플리케이션의 의존성 SBOM을 생성하고 Grype로 취약점을 점검하는 조합이 자연스럽다.

도구 조합 권고

한 도구로 전부 해결되지 않는다. 실무에서는 역할을 나눠 조합한다.

참고

• AI SBOM 생성과 관리 절차: 3.9 AI SBOM
• 생성 도구 실행 결과: OWASP AIBOM Generator, cdxgen