Brain375. SBOM (Software Bill of Materials) - 소프트웨어 구성 요소 명세서
핵심 인사이트 (3줄 요약)
- 본질: SBOM (Software Bill of Materials)은 소프트웨어 제품에 포함된 모든 구성 요소(서드파티 라이브러리, OSS 컴포넌트, 내부 모듈 등)의 목록으로, 각 구성 요소의 이름, 버전, 라이선스, 출처 등의 메타데이터를 포함한다. 이는 식품의 원재료 표시와類似하여,万一 보안 사고 시 영향 범위를 신속하게 파악할 수 있게 한다.
- 가치: Log4j 취약점(CVE-2021-44228) 상황에서 SBOM을 보유한 기업은 영향받는 시스템을 수시간 내에 파악하고 패치를 적용한 반면, SBOM이 없던 기업은数주간 영향 범위를 파악하느라時間을 허비했다. SBOM은 공급망 보안의 "谁知道？"를 묻는 도구이다.
- 융합: US Presidential Executive Order on Cybersecurity (2021)에 따라 연방정부 软件供应商에 SBOM 제공이 의무화되었으며, SPDX (ISO/IEC 5962), CycloneDX 등의 표준 포맷으로 제공되며, SCA 도구와 결합하여 활용된다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
-
개념: SBOM은 전통적 제조업의 BOM (Bill of Materials)에서 유래했다. 자동차 제조사가 차량에 사용되는 모든 부품(本土生産、国外導入)을 목록화하여管理するように, 소프트웨어에서도 모든 구성 요소(라이브러리, 프레임워크, SDK 등)를 목록화하여管理해야 한다. 이를 통해 구성 요소의 출처, 라이선스, 보안 취약점 등을 투명하게 파악할 수 있다.
-
필요성: 현대 소프트웨어는 평균적으로 代码의 70~80%가 서드파티 구성 요소로 이루어져 있다. 그러나 이러한 구성 요소에 대해"무엇이 포함되어 있고, 어디서 왔으며, 어떤 취약점이 있는가?"라는 질문에即座에 답할 수 있는 기업은 매우 드물다. SBOM은 이러한"알파지"를 해소하고, 보안 사고 시 신속한 대응을 가능하게 한다.
-
💡 비유: SBOM은 **'음식물 원재료 이력 관리 시스템'**과 같다.盒便当当製作者가 사용하는 모든 材料(鸡蛋, 밥, 고등어 등)의 원산지(OSS 출처), 유통 경로(버전), 유효 기간(지원 기간)을全都記載하여管理한다.万一 食品中毒 사고(보안 사고)가 발생하면, 即座에 문제가 된 材料를 추적하여迅速하게市場 회수하고환자를 치료할 수 있다.
-
등장 배경 및 발전 과정:
- 2000년대 초: 금융권에서 운용risk 관리를 위해 소프트웨어 구성 요소 목록化管理 시도
- 2018년: NTIA (National Telecommunications and Information Administration)에서 SBOM의 최소 요소 정의
- 2021년: 미국 대통령 행정 명령에 따라 SBOM 의무화, 글로벌 확산
- 현재: SPDX (ISO/IEC 5962), CycloneDX 등 표준화된 SBOM 포맷 확산
-
📢 섹션 요약 비유: SBOM은 **'여권으로 보는 입국 기록'**과 같다. 여권에는過去에 방문한 국가들의 입出境 기록이记载되듯이, SBOM에는ソフトウェアが過去に組み合わせたOSS/라이브러리들의情報が記載된다. 이를 통해万一 문제 국가(취약한 라이브러리)를 방문(사용)했는지 여부를即座에 확인할 수 있다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
SBOM 3대 핵심 요소 (NTIA 최소 요소)
┌─────────────────────────────────────────────────────────────────┐
│ SBOM 최소 3要素 (NTIA Minimum Elements) │
├─────────────────────────────────────────────────────────────────┤
│ │
│ [1. 데이터 필드 (Data Fields)] ★기본 정보 │
│ - Component Name: 구성 요소 이름 (e.g., "log4j-core") │
│ - Version: 버전 번호 (e.g., "2.14.1") │
│ - Package URL (PURL): 패키지 유일 식별자 │
│ - SPDX ID: SPDX 포맷의 유일 식별자 │
│ - Supplier: 공급자/배포자 이름 │
│ │
│ [2. 연결 정보 (Relationships)] ★구성 요소 간 관계 │
│ - 명시적으로 포함됨 (INCLUDE) │
│ - 의존함 (DEPENDENCY_OF) │
│ - 선택적 포함 (OPTIONAL_INCLUDE) │
│ - 빌드 시 포함 (BUILD_INCLUDE) │
│ │
│ [3. 기계 판독 가능성 (Machine-Readable)] ★自动化 │
│ - 사람만 읽을 수 있는 형식(XML, JSON)이 아닌, 도구가 자동으로解析할 수 있는 형식 │
│ - 형식: SPDX, CycloneDX, SWID │
│ │
└─────────────────────────────────────────────────────────────────┘
SBOM 포맷 3가지 비교
┌─────────────────────────────────────────────────────────────────┐
│ SBOM 포맷 비교 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ [1. SPDX (Software Package Data Exchange)] ★ISO/IEC 5962 │
│ - Linux Foundation 주도의 표준 포맷 │
│ - JSON, TAG:VALUE, RDF 등 다양한 형식 지원 │
│ - 라이선스,著作権 정보 포함에 최적화 │
│ - 예시: SPDX-ID: SPDXRef-123 │
│ │
│ [2. CycloneDX] ★OWASP 标准 │
│ - 웹 애플리케이션 보안에 특화된 포맷 │
│ - JSON, XML, Protobuf 지원 │
│ - 취약점 (Vulnerability) 정보 통합에 강점 │
│ - 예시: bom.metaData. Timestamp │
│ │
│ [3. SWID (Software Identification Tag)] │
│ - ISO/IEC 19770-2에 따른 표준 │
│ - 설치된 소프트웨어 식별에 사용 │
│ - 기업 내 자산 관리(Asset Management)와 연계 │
│ │
└─────────────────────────────────────────────────────────────────┘
SBOM 생성 방법
[SBOM 생성 방법 4가지]
1. [Package Managers 활용]
└─ npm, Maven, Gradle 등의 패키지管理器에서 생성
例: npm install 후 package-lock.json → SBOM 변환
2. [SCA 도구 활용]
└─ FOSSA, Snyk, Black Duck 등이 자동 SBOM 생성
- 의존성 트리分析 + 라이선스/취약점 정보附加
3. [Repository Analysis]
└─ GitHub Dependency Graph, GitLab Dependency List
-Repo에 포함된 모든 의존성 자동 分析
4. [빌드 시스템 Integration]
└─ CI/CD 파이프라인 내에서 빌드 시SBOM 자동 생성
- Jenkins + SPDX Maven Plugin 등
[다이어그램 해설] SBOM은 구성 요소의 기본 정보(데이터 필드), 구성 요소 간 관계(연결 정보), 그리고 이를処理할 수 있는形式(기계 판독 가능성)의 3要素로 구성된다. SBOM 포맷으로는 SPDX, CycloneDX, SWID가 대표적이며, 이들은 각각 다른強みを持っている.
Ⅲ. 구현 및 실무 응용 (Implementation & Practice)
SBOM 활용 Use Cases
┌─────────────────────────────────────────────────────────────────┐
│ SBOM 활용 주요 Use Cases │
├─────────────────────────────────────────────────────────────────┤
│ │
│ [Use Case 1: 취약점 대응] │
│ 상황: CVE-2021-44228 (Log4j) 취약점 공개 │
│ SBOM 활용: │
│ 1. 저장된 SBOM에서 "log4j-core" 검색 │
│ 2. 버전 "2.0 ~ 2.14.1" 사용 여부 확인 │
│ 3. 영향 받는 서비스/팀 즉시 파악 │
│ 4. 패치된 버전 적용 │
│ 효과: 수시간 내 영향 범위 파악 vs. SBOM 없으면 수 주 │
│ │
│ [Use Case 2: 라이선스 컴플라이언스] │
│ 상황: GPL-3.0 라이선스 코드 포함 여부 감사 │
│ SBOM 활용: │
│ 1. SBOM에서 GPL-3.0 라이선스 목록抽出 │
│ 2. 해당 구성 요소를 제거하거나 별도 라이선스 조치 시행 │
│ │
│ [Use Case 3: 규제 대응] │
│ 상황: 정부 软件구매時 SBOM 제출 의무 │
│ SBOM 활용: │
│ 1.政府采购시 SBOMفورى 제공 │
│ 2. 규제 기관에서 SBOM 검증 │
│ │
│ [Use Case 4: 인수인계 / M&A] │
│ 상황: 인수 대상 회사의 소프트웨어 구성 파악 │
│ SBOM 활용: │
│ 1. 인수 대상의 SBOM 확보 │
│ 2. 기술 부채, 보안 취약점, 라이선스 위험성 사전 파악 │
│ │
└─────────────────────────────────────────────────────────────────┘
SBOM 관리 Lifecycle
[SBOM 관리 4단계 Lifecycle]
Step 1: 생성 (Generation)
├─ 빌드 시 자동 생성
├─ SCA 도구 활용
└─Package Manager 의존성 추출
↓
Step 2: 저장 (Storage)
├─SBOM 저장소 구축 (專門 DB 또는 빌드 아티팩트와 함께 저장)
├─ SBOM 업데이트 정책 수립 (버전별, 일별 등)
└─ 액세스 통제
↓
Step 3: 분석 (Analysis)
├─ 취약점 스캐닝 연동
├─ 라이선스 컴플라이언스 확인
└─ 의존성 변화 추적
↓
Step 4: 공유 (Sharing)
├─ 규제 기관에 제출
├─ 고객/파트너사에 제공
└─ 내부 팀과 공유
SBOM 생성 도구 예시
| 도구 | 지원 언어/플랫폼 | SBOM 포맷 | 특징 |
|---|---|---|---|
| Syft | Go, Java, Python, JS 등 | SPDX, CycloneDX | CLI 기반, 컨테이너 이미지対応 |
| CycloneDX SBOM Generator | Java, .NET, JS, Python | CycloneDX | Maven/Gradle 플러그인 |
| SPDX SBOM Generator | Java, Python, JS | SPDX | CI/CD 통합 용이 |
| GitHub Dependency Graph | 모든 GitHubRepo | CycloneDX (Beta) | GitHub 내장 기능 |
| Trivy | 컨테이너 이미지 | CycloneDX, SPDX | 보안 스캐닝 + SBOM 생성 |
Ⅳ. 품질 관리 및 테스트 (Quality & Testing)
SBOM 품질 관리 포인트
| 관리 요소 | 설명 | 중요도 |
|---|---|---|
| 정확성 | 구성 요소 정보가 실제와 일치하는가? | ★★★★★ |
| 완전성 | 모든 구성 요소가 포함되었는가? (전이적 의존성 포함) | ★★★★★ |
| 시의성 | 최신 버전의 SBOM인가? | ★★★★☆ |
| 일관성 | SBOM 간 포맷이 표준을 따르는가? | ★★★★☆ |
| 검증 가능성 | SBOM 자체의 무결성을 검증할 수 있는가? | ★★★☆☆ |
SBOM 무결성 보장 방법
[SBOM 무결성 보장 방법]
1. [서명 (Signing)]
├─ SBOM 문서에 디지털 서명
├─ 서명 검증 없이는 SBOM 내용 변경 감지 가능
└─ 例: Sigstore, GPG 서명
2. [체크섬 (Checksum)]
├─ SBOM 파일의 SHA-256 해시 유지
└─ 파일 변경 시 해시값 변경으로 감지
3. [버전 관리]
├─ Git 등 버전 관리 시스템에 SBOM 저장
└─ 변경 이력 추적 가능
4. [증빙 (Attestation)]
├─ SBOM 생성 과정 자체를증빙 (Provenance)
└─ SLSA와 결합하여 빌드 과정의 무결성 보장
- 📢 섹션 요약 비유: SBOM 무결성 관리는 **'여권에 붙이는政府对 인증貼紙'**와 같다. 여권( SBOM)이 정부 기관에서 발부될 때(서명), 해당 기관의봉인(무결성)이 되어内容が改竄되지 않았음이 보장된다. 만약 여권에 붙은認証貼紙가 없으면(무결성 검증 없음), 그 여권의 내용이 진본인지信用할 수 없게 된다.
Ⅴ. 최신 트렌드 및 결론 (Trends & Conclusion)
최신 동향
- 규제 의무화 확대: 미국에 이어 EU, 한국 등各国政府에서 SBOM 의무화를 추진中
- SBOM + VEX 통합: SBOM (구성 요소 명세)과 VEX (Vulnerability Exploitability Exchange)를 결합하여 취약점 정보를 강화
- 생성 자동화: CI/CD 파이프라인에SBOM 생성을 기본으로 내장하여 개발자 개입 없이 자동 생성
- AI 활용: AI 기반 SBOM 分析 및 취약점 영향도 예측
한계점 및 보완
- 표준화 미흡: 아직 SBOM 포맷이 표준화되는 단계에 있어 포맷 간 상호운용성 부족
- 관리 오버헤드: SBOM을 항상最新으로 유지하는 것이 추가 管理 비용 발생
- 가시성 한계: 동적으로 로드되는 플러그인, 컨테이너 내부 의존성 등은 완벽한 파악 어려움
- 신뢰 문제: SBOM 자체가 조작되지 않았다는 보장이 필요
SBOM (Software Bill of Materials)은 소프트웨어 공급망 보안의 핵심 요소로, 구성 요소의 투명성을 확보하고 보안 사고 시 신속한 대응을 가능하게 한다. SBOM을 효과적으로 활용하기 위해서는 표준화된 포맷(SPDX, CycloneDX)을 사용하여 상호운용성을 확보하고, CI/CD 파이프라인에SBOM 생성을 자동화하며, SBOM의 무결성을 서명이나 체크섬으로 보장해야 한다. 기술사는 SBOM을 공급망 보안 전략의 핵심 구성 요소로 활용하여, 조직의 소프트웨어 구성 요소에 대한完全な 가시성을 확보하는 데 기여해야 한다.
- 📢 섹션 요약 비유: SBOM은 **'군대 지휘관의 작전 지도'**와 같다. 작전 지도에는友軍(内製 코드), 同盟국군(OSS 라이브러리),敌军(악성 코드)의 위치가 모두표시되어 있다.作戰중에 적군이 발견되면(취약점 발생), 지도를 보고即座에友軍의 위치(영향 범위)를 확인하고,友軍에支援을 요청하며(패치 적용), 新たな攻撃 가능성을 분석하는 것이 가능하다.
참고
- 모든 약어는 반드시 전체 명칭과 함께 표기:
API (Application Programming Interface) - 일어/중국어 절대 사용 금지 (한국어만 사용)
- 각 섹션 끝에 📢 요약 비유 반드시 추가
- ASCII 다이어그램의 세로선 │와 가로선 ─ 정렬 완벽하게
- 한 파일당 최소 800자 이상의 실질 내용