표준과 형식
SBOM을 기계 판독 가능하게 표현하는 두 표준 형식 SPDX와 CycloneDX를 비교합니다.
SBOM이 기계 판독성을 요구하는 이상 표준 형식이 필요합니다. 미국 NTIA 최소 요소가 명시한 세 형식
가운데 실무를 양분하는 것은 SPDX와 CycloneDX입니다. 세 번째인 SWID 태그는 주로 자산 관리에서
쓰이며, 식별자로서의 역할은 식별자와 라이선스에서 다룹니다.
SPDX
SPDX(System Package Data Exchange)는 리눅스 재단(Linux Foundation) 산하 프로젝트입니다. 버전 2.2.1이
2021년 8월 ISO/IEC 5962:2021로 국제 표준이 되었습니다. 현행 ISO 표준이 가리키는 것은 어디까지나
2.2.1 버전이라는 점을 유의해야 합니다.
리눅스 재단은 2024년 4월 16일 SPDX 3.0을 발표하며 용도별 프로파일(Profile) 구조를 도입했습니다.
핵심 모델 위에 보안(Security), 빌드(Build), 데이터셋(Dataset), 인공지능(AI) 프로파일을 얹는
방식입니다. AI 프로파일은 모델 학습과 특성화 정보를, 데이터셋 프로파일은 데이터의 출처와 라이선스를,
보안 프로파일은 취약점의 식별과 심각도, 악용 가능성, 완화 계획을 담습니다. 같은 해 12월에는 패치
릴리스 3.0.1이 나왔습니다. SPDX 3.x의 ISO 재표준화 진행 여부는 2026년 6월 기준 확인되지 않았습니다.
CycloneDX
CycloneDX는 OWASP(Open Worldwide Application Security Project)에서 출발한 풀스택 BOM 표준입니다.
취약점 악용 가능성 교환(Vulnerability Exploitability eXchange, VEX)을 형식 안에서 네이티브로
지원하는 점이 특징입니다. 국제 표준화는 Ecma International의 기술위원회 TC54를 통해 이루어졌습니다.
v1.6이 2024년 6월 ECMA-424 1판으로 발행되며 암호 자재 명세서(Cryptographic Bill of Materials, CBOM)와
증명(CycloneDX Attestations)을 더했고, v1.7이 2025년 10월 발표돼 2025년 12월 ECMA-424 2판으로
표준화되었습니다. v1.7은 사후양자 암호 대비, 구조화된 인용, 특허 객체 지원을 추가했습니다.
CycloneDX는 한 형식으로 소프트웨어(SBOM), 하드웨어(HBOM), 서비스(SaaSBOM), 머신러닝 모델(ML-BOM)을
모두 표현할 수 있습니다.
두 형식 비교
| 구분 | SPDX | CycloneDX |
|---|
| 주관 | Linux Foundation | OWASP / Ecma TC54 |
| 국제표준 | ISO/IEC 5962:2021 (v2.2.1 기준) | ECMA-424 1판(v1.6, 2024-06), 2판(v1.7, 2025-12) |
| 최신 사양 | 3.0(2024-04), 3.0.1(2024-12) | 1.7(2025-10) |
| 확장 방식 | 용도별 프로파일(보안, 빌드, 데이터셋, AI) | 구성요소 타입과 부속 객체, VEX 네이티브 |
| 강점 | 라이선스 표현과 법적 컴플라이언스 이력 | 취약점·VEX 통합, 보안 운영 친화 |
표 1. SBOM 양대 표준 형식 비교 (출처: ISO/IEC 5962:2021, Linux Foundation 2024, Ecma International ECMA-424. 수집일 2026-06-14)
두 표준은 설계 철학이 다릅니다. SPDX는 프로파일 방식으로 적용 범위를 넓히고, CycloneDX는 구성요소
타입과 부속 객체로 표현합니다. 그러나 둘 다 구성요소의 식별, 라이선스, 의존 관계를 담는다는 점에서
같은 문제를 겨냥합니다. 어느 쪽을 택하든 두 형식 사이의 변환 도구가 있으므로, 거래 상대가 요구하는
형식과 자사 도구 체인이 잘 지원하는 형식을 기준으로 고르면 됩니다. 라이선스 컴플라이언스 중심이면
SPDX가, 취약점 운영 중심이면 CycloneDX가 익숙한 출발점입니다.
다음으로 형식 안에 무엇을 반드시 담아야 하는지를 정한 최소 요소와,
구성요소를 일관되게 가리키는 식별자와 라이선스를 살펴봅니다.
출처
ISO/IEC (2021). ISO/IEC 5962:2021 — SPDX Specification V2.2.1. The Linux Foundation (2024).
SPDX 3.0 Release. https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases.
Ecma International. ECMA-424 — CycloneDX Bill of Materials Specification.
https://ecma-international.org/publications-and-standards/standards/ecma-424/. CycloneDX (2025).
CycloneDX v1.7 Released. https://cyclonedx.org/news/cyclonedx-v1.7-released/. (모두 접속: 2026-06-14)
1 - SBOM의 최소 요소
NTIA 2021 최소 요소에서 CISA 2025 개정 초안까지, SBOM에 반드시 담아야 할 데이터 필드를 정리합니다.
형식을 정했다면 그 형식 안에 무엇을 반드시 담아야 하는지가 다음 질문입니다. 이 최저선을 정의한
문서가 미국의 최소 요소(Minimum Elements) 계열입니다. 권고이긴 하지만 연방 조달의 사실상 기준이고,
EU와 다른 관할권의 SBOM 요건도 대체로 이 골격을 참조합니다.
계보: NTIA 2021에서 CISA 2025로
미국 통신정보청(National Telecommunications and Information Administration, NTIA)은 행정명령 14028의
위임에 따라 2021년 7월 *The Minimum Elements For a Software Bill of Materials (SBOM)*를 발행했습니다.
이 문서는 최소 요소를 세 범주로 정리했습니다. 구성요소별로 추적할 데이터 필드, 기계 판독 형식을
요구하는 자동화 지원, 그리고 생성 빈도와 깊이 등을 다루는 관행과 프로세스입니다.
이후 커뮤니티 작업의 주관은 사이버보안·인프라보안국(Cybersecurity and Infrastructure Security
Agency, CISA)으로 옮겨갔고, 두 갈래의 개정이 나왔습니다. 하나는 속성을 정의하는 참조 문서인
Framing Software Component Transparency의 3판(2024-09)으로, 기준 속성에 라이선스(License)와
저작권 고지(Copyright Notice)를 추가했습니다. 다른 하나는 최소 요소 문서 자체의 개정으로, CISA는
2025년 8월 2025 Minimum Elements for a Software Bill of Materials를 공개 의견수렴 초안으로 내놓았고
의견수렴은 2025년 10월 3일 마감됐습니다. 2026년 6월 기준 이 개정안은 아직 초안 상태이며 최종본
발표일은 확인되지 않았습니다.
NTIA 2021의 데이터 필드와 세 범주
NTIA 2021 최소 요소가 정한 구성요소별 데이터 필드는 일곱 개입니다.
| 데이터 필드 | 내용 |
|---|
| 공급자명(Supplier Name) | 구성요소를 제공한 주체 |
| 구성요소명(Component Name) | 구성요소 또는 라이브러리의 이름 |
| 버전(Version) | 구성요소의 버전 식별자 |
| 기타 고유 식별자(Other Unique Identifiers) | PURL, CPE 등 식별자 |
| 의존 관계(Dependency Relationship) | 상위 구성요소와의 포함 관계 |
| SBOM 작성자(Author of SBOM Data) | 이 SBOM을 생성한 주체 |
| 타임스탬프(Timestamp) | 생성 일시 |
세 범주는 다음과 같습니다.
- 데이터 필드: 위 일곱 항목으로, 구성요소를 추적·식별하기 위한 기본 정보입니다.
- 자동화 지원: 자동 생성과 기계 판독성을 위한 표준 형식으로 SPDX, CycloneDX, SWID를 명시했습니다.
- 관행과 프로세스: 생성 빈도, 깊이, 알려진 미상(known unknowns)의 처리, 배포와 전달, 접근 통제,
오류 수용 방식을 다룹니다.
CISA 2025 초안이 더한 것
CISA 2025 최소 요소 초안은 도구가 성숙한 현실을 반영해 데이터 필드를 늘렸습니다. 신규로 추가된
핵심 요소는 네 가지입니다.
| 신규 필드 | 목적 |
|---|
| 구성요소 해시(Component Hash) | 암호학적 해시로 무결성과 정확한 식별을 보장 |
| 라이선스(License) | 법적 컴플라이언스 추적의 1차 데이터 |
| 도구명(Tool Name) | 어떤 도구로 생성했는지 기록 |
| 생성 맥락(Generation Context) | 수명주기의 어느 단계에서 만들었는지 기록 |
기존 항목도 손질했습니다. SBOM 작성자(SBOM Author)와 소프트웨어 생산자(Software Producer)의 역할을
구분하고, “기타 고유 식별자"를 “소프트웨어 식별자(Software Identifiers)“로 갱신했으며, 별도였던
접근 통제 요소는 배포·전달 항목으로 통합했습니다. 라이선스가 Framing 3판에서 기준 속성으로 들어오고
2025 초안에서 데이터 필드로 굳어진 흐름은, SBOM이 보안 인벤토리를 넘어 오픈소스 라이선스
컴플라이언스의 1차 데이터로 자리 잡고 있음을 보여줍니다. 도구명과 생성 맥락, 해시가 함께 들어온
배경에는 “신뢰할 수 없는 도구가 만든 SBOM은 신뢰할 수 없다"는 문제의식이 있습니다. 도구 무결성은
5. 도구와 자동화에서 다룹니다.
실무 권고
최소 요소는 말 그대로 최저선입니다. 조직은 자사 용도에 맞춰 필드를 더할 수 있고, 더해야 합니다.
취약점 식별을 위해 CVE 참조와 패치 상태를, 라이선스 관리를 위해 SPDX 라이선스 식별자와 저작권
고지를, 수명주기 관리를 위해 출시일과 지원 종료(End-of-Life) 일자를 함께 담아 두면 SBOM 하나로
여러 운영 질문에 답할 수 있습니다. 새로 SBOM을 도입한다면 NTIA 일곱 필드를 기본으로 하되 CISA
2025 초안의 네 신규 필드, 특히 해시와 라이선스를 처음부터 포함하는 편이 나중에 다시 만드는 수고를
줄입니다.
출처
NTIA (2021). The Minimum Elements For a Software Bill of Materials (SBOM).
https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf. CISA (2024).
Framing Software Component Transparency, Third Edition.
https://www.cisa.gov/resources-tools/resources/framing-software-component-transparency-2024.
CISA (2025). 2025 Minimum Elements for a Software Bill of Materials (SBOM) (공개 의견수렴 초안).
https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom.
(모두 접속: 2026-06-14)
2 - 식별자와 라이선스
구성요소를 일관되게 가리키는 PURL·CPE·SWID 식별자와, SPDX 라이선스 식별자 표기 방법을 정리합니다.
같은 구성요소를 두고 SBOM마다 이름을 다르게 적으면 자동 대조가 무너집니다. “Apache Tomcat"과
“tomcat”, “Apache Software Foundation Tomcat"이 같은 것인지 기계가 알 길이 없기 때문입니다. 그래서
구성요소를 일관되게 가리키는 식별자 체계와, 라이선스를 표준 코드로 표기하는 규약이 필요합니다.
세 가지 식별자: PURL, CPE, SWID
실무에서 함께 쓰이는 세 식별자는 역할이 갈립니다. 배타적이지 않으므로, 가능하면 함께 기재하는 것이
권장됩니다.
| 식별자 | 운영 주체 | 주된 용도 |
|---|
| PURL(Package URL) | 커뮤니티(purl-spec) | 패키지 관리자 생태계 안의 구성요소를 정확히 지목 |
| CPE(Common Platform Enumeration) | NIST | 제품을 일관된 이름으로 표기해 해당 CVE를 조회 |
| SWID(Software Identification Tag) | ISO/IEC 19770-2 | 제품·버전·생산 주체를 구조화한 메타데이터 |
표 1. SBOM에서 함께 쓰이는 식별자 (출처: purl-spec, NIST NVD, ISO/IEC 19770-2. 수집일 2026-06-14)
패키지 URL은 다음과 같은 형식으로 패키지 관리자 생태계 안의 구성요소를 가리킵니다.
pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1
pkg:npm/lodash@4.17.21
pkg:pypi/requests@2.31.0
pkg: 뒤에 생태계 유형(maven, npm, pypi 등), 네임스페이스, 이름, 버전이 이어집니다. 같은 구성요소를
어디서나 같은 문자열로 가리킬 수 있어, 취약점 데이터베이스나 라이선스 데이터베이스와 자동으로
연결됩니다.
CPE는 2000년대 중반 MITRE가 개발해 현재 NIST가 운영합니다. 제품을 정해진 이름 규칙으로 표기해,
그 제품에 해당하는 취약점(CVE)을 조회하는 데 쓰입니다. SWID는 ISO/IEC 19770-2로 표준화된 태그
형식으로 제품과 버전, 생산·배포 주체를 구조화해 기술하며 자산 관리에서 주로 활용됩니다. CISA 2025
최소 요소 초안이 “기타 고유 식별자"를 “소프트웨어 식별자"로 갱신한 것도 이 식별자 생태계의 성숙을
반영합니다.
라이선스 표기: SPDX 라이선스 식별자
라이선스 관리는 SBOM의 초기 활용처 가운데 하나입니다. 각 구성요소가 어떤 라이선스로 배포되는지를
정확히 기록해야 의무 위반과 충돌을 미리 막을 수 있습니다. 자유 서술로 적으면 대조가 안 되므로, 표준
코드를 씁니다.
SPDX 라이선스 식별자는 각 라이선스에 Apache-2.0, MIT, GPL-3.0-only
같은 고유 코드를 부여합니다. 여러 라이선스가 함께 적용될 때는 라이선스 표현식(license expression)으로
조합합니다.
Apache-2.0 OR MIT
GPL-2.0-only WITH Classpath-exception-2.0
(MIT AND BSD-3-Clause)
OR는 선택 가능한 복수 라이선스, AND는 동시에 적용되는 복수 라이선스, WITH는 예외 조항과의
결합을 나타냅니다.
실무에서 지켜야 할 원칙은 다음과 같습니다.
- 제품 전체의 라이선스뿐 아니라 모든 개별 구성요소의 라이선스를 함께 볼 수 있어야 합니다.
- 표준 목록에 없는 라이선스를 만나면 출처를 나타내는 접두사를 붙인 식별자(예:
LicenseRef- 접두사)를 부여해 추적합니다. - 라이선스 텍스트를 사소하게 수정했더라도 의미가 크게 달라지지 않으면 원본과 같은 식별자를 씁니다.
- 라이선스의 호환성을 분석해, 서로 다른 라이선스의 구성요소를 결합할 때 생길 충돌을 미리 식별합니다.
라이선스 필드가 도구로 자동 추출되더라도 그 정확도는 별개의 문제입니다. 비표준 라이선스의 정확한
식별, 듀얼 라이선스 처리, 행동 사용 제한이 붙은 라이선스의 준수 여부는 여전히 사람과 정책의 몫입니다.
자동화의 경계는 5. 도구와 자동화에서 다룹니다.
출처
Package URL 명세 https://github.com/package-url/purl-spec. NIST. Common Platform Enumeration (CPE)
https://nvd.nist.gov/products/cpe. ISO/IEC 19770-2:2015. SPDX License List
https://spdx.org/licenses/. SPDX License Expressions
https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/. (모두 접속: 2026-06-14)