💻 computer science

The State of the SBOM Tool Ecosystems: A Comparative Analysis of SPDX and CycloneDX

이 논문은 수백 개의 도구와 수천 개의 이슈 보고서를 분석함으로써 SPDX와 CycloneDX SBOM 도구 생태계를 비교하며, SPDX가 더 크고 성숙한 도구 세트와 폭넓은 채택을 자랑하는 반면, CycloneDX는 더 강력한 개발자 참여와 특정 프로젝트 건강 지표를 보여줌으로써 두 형식의 상호 보완적인 강점을 강조합니다.

원저자: Zhimin Zhao, Abdul Ali Bangash, Tongxu Ge, Arshdeep Singh, Zitao Wang, Bram Adams

게시일 2026-06-12

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Zhimin Zhao, Abdul Ali Bangash, Tongxu Ge, Arshdeep Singh, Zitao Wang, Bram Adams

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

당신이 거대한 레스토랑을 운영하는 셰프라고 상상해 보세요. 고객들을 안전하고 행복하게 유지하기 위해서는 당신이 제공하는 모든 요리에 어떤 재료가 들어갔는지 정확히 알아야 합니다. 밀가루의 브랜드는 무엇인지, 우유의 유통기한은 언제인지, 그리고 혹시 사용된 향신료 중 최근 오염 문제가 발생한 농장에서 온 것이 있는지도 알아야 합니다.

소프트웨어 세계에서 이 "재료 목록"을 **소프트웨어 자재 명세서(SBOM)**라고 부릅니다. 이는 소프트웨어 프로그램이 사용하는 모든 코드와 라이브러리를 나열한 문서입니다.

하지만 단순히 목록을 가지고 있는 것만으로는 충분하지 않습니다. 그 목록을 작성하고, 검사하고, 업데이트할 수 있는 적절한 도구가 필요합니다. 현재 이 목록을 작성하기 위한 두 가지 주요 "언어" 또는 형식인 SPDX와 CycloneDX가 있습니다. 이들은 서로 다른 브랜드의 레시피 북이라고 생각하면 됩니다. 하나(SPDX)는 2010년부터 존재해 온 매우 전통적인 방식이고, 다른 하나(CycloneDX)는 2017년에 시작된 더 새롭고 현대적인 방식입니다.

이 논문은 이 두 가지 레시피 북을 둘러싼 도구 생태계를 비교한 대규모 연구입니다. 연구진은 단순히 레시피를 본 것이 아니라, 셰프들이 이 목록을 작성하고 관리하는 데 도움을 주는 주방 도구(소프트웨어 프로그램)를 살펴보았습니다.

연구 결과는 다음과 같으며, 이해하기 쉽게 정리했습니다.

1. 도구 주방: 누가 무엇을 가지고 있는가?

연구진은 수백 개의 도구(오픈 소스 및 유료/독점 도구 모두 포함)를 조사하여 어떤 작업을 수행할 수 있는지 확인했습니다.

"올라운더" vs. "전문가": 연구진은 유료(독점) 도구들이 목록을 작성하고, 분석하고, 시각화하고, 수정까지 거의 모든 것을 할 수 있는 마스터 셰프와 같다는 것을 발견했습니다. 무료(오픈 소스) 도구들은 매우 유용하지만, 기능이 다소 제한적입니다. 이들은 목록을 작성(빌드)하는 데는 뛰어나지만, 화려한 시각화나 심층적인 분석에는 어려움을 겪는 경우가 많습니다.
형식의 분리:
- CycloneDX 도구들은 "빌더(Builders)"와 같습니다. 소프트웨어가 구축되는 동안 목록을 자동으로 생성하는 데 탁월합니다.
- SPDX 도구들은 "사서(Librarians)"와 같습니다. 목록을 비교하고, 한 형식을 다른 형식으로 변환하며, 법적 라이선스 세부 정보를 처리하는 데 매우 강점이 있습니다.

2. 커뮤니티 분위기: 누가 더 활발한가?

연구진은 이 도구들의 배후에 있는 커뮤니티의 "건강 상태"(얼마나 많은 사람이 기여하는지, GitHub에서 별(star)을 얼마나 받았는지, 버그를 얼마나 빨리 수정하는지 등)를 확인했습니다.

CycloneDX는 에너지 넘치는 신입입니다: 전체적인 CycloneDX 도구의 수는 더 적지만, 이들을 둘러싼 커뮤니티는 훨씬 더 활발합니다. 더 많은 기여자가 있고, 더 많은 "별(좋아요)"을 받았으며, 버그를 수정하는 속도도 SPDX 커뮤니티보다 훨씬 빠릅니다(약 67% 빠름). 마치 활기차고 빠른 속도의 스타트업처럼 느껴집니다.
SPDX는 숙련된 베테랑입니다: 도구의 수가 더 많고 매우 성숙하고 안정적인 생태계를 갖추고 있습니다. 하지만 움직임은 다소 느립니다. 버그를 수정하는 데 시간이 더 걸리지만, 법적 및 라이선스 문제에 매우 강력한 초점을 맞추고 있습니다. 이는 그들이 소프트웨어 라이선스를 추적하는 도구로 시작했기 때문에 타당한 결과입니다.

3. 어떤 문제를 해결하고 있는가?

연구팀은 수천 개의 "버그 보고서"(불만 사항 또는 도움 요청)를 검토하여 사람들이 무엇 때문에 어려움을 겪고 있는지 살펴보았습니다.

CycloneDX는 "버그"로 고군분투합니다: 더 새롭기 때문에, 가장 흔한 불만 사항은 무언가 고장 나거나 제대로 작동하지 않는 것에 관한 것입니다. 커뮤니티는 이러한 기초적인 문제를 해결하느라 바쁩니다.
SPDX는 "새로운 기능"으로 고군분투합니다: 더 오래되고 안정적이기 때문에, 가장 흔한 요청은 새로운 기능이나 개선 사항에 관한 것입니다. 사람들은 "왜 이게 고장 났나요?"라고 묻기보다는 "이 새로운 멋진 기능을 추가해 줄 수 있나요?"라고 더 많이 묻습니다.
라이선스 속도: 만약 소프트웨어 라이선스 관련 문제가 있다면, SPDX가 훨씬 더 빠르게 해결합니다. 일반적인 소프트웨어 버그라면, CycloneDX가 훨씬 더 빠르게 해결합니다.

4. 누가 무엇을 사용하는가?

연구진은 가장 인기 있는 250개의 소프트웨어 프로젝트를 조사하여 어떤 "레시피 북"을 사용하는지 확인했습니다.

"멋진" 프로젝트들: Go나 Python(보안 및 클라우드 컴퓨팅에 자주 사용됨)과 같은 현대적인 언어로 작성된 프로젝트들은 CycloneDX를 선호하는 경향이 있습니다. 이 프로젝트들은 보통 매우 활발하며, 기여자가 많고, 빠르게 움직입니다.
"엔터프라이즈" 프로젝트들: Java 및 C#(대기업에서 주로 사용됨)으로 작성된 프로젝트들은 SPDX를 선호하는 경향이 있습니다. 이 프로젝트들은 종종 엄격한 컴플라이언스(준수)와 법적 규칙에 집중합니다.

결론

이 논문은 SPDX와 CycloneDX 사이의 선택이 단순히 형식을 고르는 것이 아니라, 당신의 필요에 맞는 적절한 생태계를 고르는 문제라고 결론짓습니다.

만약 당신이 빠르고 보안 중심적인 프로젝트(예: 클라우드 앱)를 구축하고 있으며, 버그를 빠르게 수정하고 현대적인 개발 환경과 잘 통합되는 도구가 필요하다면, CycloneDX와 그 활발한 커뮤니티가 최선의 선택이 될 수 있습니다.
만약 당신이 법적 준수가 가장 중요한 대기업에 있으며, 형식을 변환하고 라이선스를 처리하는 데 뛰어난 도구가 필요하다면, SPDX와 그 성숙하고 안정적인 생태계가 더 나은 선택일 것입니다.

요약하자면: CycloneDX는 빠르고 민첩한 버그 수정 기계이며, SPDX는 신뢰할 수 있고 법률에 정통한 베테랑입니다. 둘 다 필수적이지만, 서로 다른 목적을 위해 존재합니다.

기술 요약: SBOM 도구 생태계의 현황

문제 정의

현대 소프트웨어 공급망은 제3자 종속성에 크게 의존하며, 이는 보안이 취약한 구성 요소(예: Log4Shell, SolarWinds)에 취약점이 존재할 경우 심각한 보안 및 신뢰성 리스크를 초래합니다. 소프트웨어 자재 명세서(SBOM)는 투명성과 책임성을 위한 핵심 메커니즘으로 부상하여 2021년 미국 행정 명령에 의해 의무화되었고 전 세계적으로 채택되었으나, 그 효용성은 이를 생성, 분석 및 관리하는 도구들에 크게 의존합니다.

SPDX(2010년 수립)와 CycloneDX(2017년 도입)라는 두 가지 지배적인 SBOM 형식이 존재함에도 불구하고, 이들 형식을 둘러싼 도구 생태계의 건전성, 성숙도 및 기능적 역량에 대한 실증적 이해가 부족한 실정입니다. 실무자들은 표준화의 부족, 도구 성숙도의 차이, 특정 유스케이스(예: 빌드 자동화 vs 라이선스 준수)를 가장 잘 지원하는 형식에 대한 데이터 부재로 인해 적절한 도구를 선택하는 데 어려움을 겪고 있습니다. 기존 연구들은 규격 자체나 제한적인 실무자 설문에 집중해 왔으며, 실제 도구 생태계에 대한 정량적 분석에는 공백을 남겨두었습니다.

방법론

저자들은 네 가지 연구 질문(RQ)을 통해 SPDX와 CycloneDX 생태계를 비교하는 포괄적인 실증 연구를 수행하였으며, 다단계 데이터 수집 및 분석 접근 방식을 활용하였습니다.

도구 수집 및 분류 (RQ1):
- 데이터 소스: 2024년 1월 27일 기준, CycloneDX(219개 도구) 및 SPDX(47개 도구)의 공식 도구 센터.
- 필터링: 수동 검증을 통해 108개의 오픈 소스(OSS) 및 와 62개의 상용 도구를 식별했습니다. 78개의 도구가 두 형식을 모두 지원(Dual-Format)하는 것으로 나타났습니다.
- 분석: 두 명의 저자가 NTIA 도구 분류 체계(생성(Produce), 소비(Consume), 변환(Transform) 카테고리)를 사용하여 187개 도구(CycloneDX 140개, SPDX 47개)를 수동으로 분류했습니다. 상호 검사 신뢰도(Krippendorff's $\alpha$ = 0.872)를 확립했습니다.
생태계 건전성 분석 (RQ2):
- 데이터셋: GitHub의 기여 포크(contributing forks)를 포함하여 OSS 데이터셋을 확장함으로써, 총 171개의 CycloneDX 및 470개의 SPDX 저장소를 확보했습니다.
- 지표: CHAOSS 커뮤니티 건전성 지표(Stars, Watchers, Forks, Contributors, Pull Requests, Releases, Commits)를 사용하여 평가했습니다.
- 정규화: 성숙도 차이를 고려하기 위해 모든 지표를 저장소 연령(일수)으로 정규화했습니다. 통계적 유의성은 Bonferroni 보정을 적용한 Mann-Whitney U 검정으로 테스트되었습니다.
이슈 보고 분석 (RQ3):
- 데이터셋: 90개의 CycloneDX 및 191개의 SPDX 도구 저장소로부터 36,990개의 이슈 보고서(2018년 이후)를 추출했습니다.
- 체계 구축: 태그된 이슈로부터 14개의 고유한 이슈 카테고리를 도출했습니다.
- 분류: 층화 무작위 샘플(379개 이슈, $\alpha$ = 0.768)에 대해 LLM 기반 주석 방식(mistralai/devstral-small-2-2 사용)을 인간 주석과 비교하여 검증했습니다. 모델은 33,840개의 이슈를 모두 분류했습니다.
- 지표: 카테고리별 이슈 발생 빈도 및 해결 시간을 분석했습니다.
프로젝트 채택 분석 (RQ4):
- 데이터셋: CI 파이프라인에서 SBOM 도구를 사용하는 2,426개의 GitHub 프로젝트를 식별했습니다("빌드" 유스케이스에 집중).
- 선택: CycloneDX 도구만을 사용하는 상위 250개 스타(star) 프로젝트와 SPDX 도구만을 사용하는 상위 250개 스타 프로젝트를 비교했습니다.
- 분석: 프로젝트 건전성 지표와 프로그래밍 언어 분포(GPL vs. DSL)를 비교했습니다.

주요 기여 및 결과

1. 유스케이스 커버리지 (RQ1)

상용 vs. OSS: 상용 도구는 OSS 도구보다 더 넓은 범위의 유스케이스(1.14배 더 많음)를 지원합니다. 구체적으로 상용 도구는 분석(Analyze) 및 보기(View/시각화) 측면에서 강점을 보이며, OSS 도구는 지원(Support/통합 및 API) 측면에서 뛰어납니다.
형식 간 차이:
- CycloneDX 전용 도구는 빌드(Build) 및 지원(Support) 유스케이스와 강한 양의 상관관계를 보이지만, 차이점 비교(Diff) 지원이 부족합니다.
- SPDX 전용 도구는 변환(Translate/형식 변환) 및 **차이점 비교(Diff)**와 밀접한 관련이 있으나, 데이터셋 내에서 빌드(Build) 도구 지원은 제한적입니다(단, Microsoft가 GitHub 네이티브 SPDX 생성을 제공한다는 점을 논문은 언급함).
- 이중 형식(Dual-format) 도구는 가져오기(Import) 유스케이스에서 흔히 발견되지만, 지원(Support) 기능은 부족합니다.

2. 도구의 커뮤니티 건전성 (RQ2)

참여도: 전체 저장소 수는 더 적음에도 불구하고(171개 vs. 470개), CycloneDX 도구는 현저히 높은 커뮤니티 참여도를 보입니다. Stars, Watchers, Forks, Contributors, Pull Requests의 중앙값이 더 높습니다.
활동성: CycloneDX 도구는 더 높은 커밋 활동과 릴리스 빈도를 나타냅니다.
재방문 기여자: 대부분의 커밋 횟수 그룹에서 재방문 기여율의 차이는 미미했으나, SPDX 도구는 1,000회 이상의 커밋을 보유한 기여자로부터 더 많은 기여를 끌어내는 경향이 있어, 특정 고용량 기여자들의 깊은 장기적 참여를 시사합니다.

3. 이슈 발생 및 해결 (RQ3)

이슈 볼륨: CycloneDX 도구는 SPDX보다 정규화된 이슈 보고서(Open 및 Closed 모두)의 평균 수가 더 많습니다.
해결 속도: CycloneDX 도구가 이슈를 현저히 빠르게 해결합니다 (평균 해결 시간이 67.69% 낮음).
- CycloneDX: 버그 수정 및 결함(Bug Fixes and Defects)(41.90%)이 주를 이룹니다. 이를 SPDX보다 174% 빠르게 해결합니다.
- SPDX: 기능 개발 및 개선(Feature Development and Enhancement)(36.25%)이 주를 이룹니다. 라이선스(Licensing) 관련 이슈를 CycloneDX보다 51.85% 더 빠르게 해결하며, 이는 라이선스 중심의 형식인 SPDX의 기원을 반영합니다.
시사점: CycloneDX 생태계는 빠른 버그 수정 및 안정화 단계에 있는 것으로 보이며, SPDX 생태계는 기능 확장 및 복잡한 라이선스 준수에 집중하고 있습니다.

4. 프로젝트 채택 패턴 (RQ4)

프로젝트 건전성: CycloneDX 도구를 사용하는 프로젝트는 SPDX 도구를 사용하는 프로젝트에 비해 높은 커뮤니티 건전성 지표(더 많은 stars, forks, contributors, commits)를 보여줍니다.
언어 선호도:
- CycloneDX는 Go 및 Python 프로젝트에서 널리 사용됩니다 (보안 중심의 DevOps 및 마이크로서비스와 연관됨).
- SPDX는 Java 및 C# 프로젝트에서 널리 사용됩니다 (기업용 컴플라이언스 및 공식 라이선스 요구사항과 일치함).
활동 상관관계: 커밋 횟수가 높은 프로젝트는 보기, 차이점 비교, 가져오기(소비(Consume) 카테고리)를 지원하는 도구를 사용하는 경향이 있으며, 활동성이 낮은 프로젝트는 편집, 병합, 분석(생성/변환 카테고리)을 선호합니다.

의의 및 주장

본 논문은 SBOM 형식의 선택이 단독으로 이루어져서는 안 되며, 반드시 주변 도구 생태계의 성숙도와 건전성을 고려해야 한다고 주장합니다.

보안 중심 DevOps를 위해: CycloneDX가 빠른 빌드 자동화, 버그 해결, 높은 커뮤니티 참여가 필요한 Go/Python 프로젝트에 더 적합할 수 있음을 시사합니다.
기업용 컴플라이언스를 위해: SPDX는 라이선스 준수, 형식 변환 및 차이점 비교를 우선시하는 Java/C# 프로젝트에 여전히 강력한 선택지이며, 보다 성숙한(비록 활동성은 낮지만) 생태계의 지원을 받습니다.
도구 개발자를 위해: 본 연구는 특정 격차를 식별합니다. OSS 도구는 분석(Analyze) 및 보기(View) 역량(현재 상용 도구가 주도함)을 개선해야 하며, SPDX 도구 개발자는 기능 백로그를 줄이는 데 집중해야 하고, CycloneDX 개발자는 현재의 높은 버그 수정 처리량을 유지해야 합니다.
규제 영향: 분석 결과, 2021년 미국 정부의 의무화 조치 이후 이슈 활동에서 가시적인 변곡점이 관찰되었으며, 이는 규제 이벤트가 오픈 소스 개발 역학을 생태계 규모에서 어떻게 재편하는지를 보여줍니다.

저자들은 두 형식 모두 필수적이지만, 그 도구 생태계는 서로 다른 진화 단계와 우선순위를 가지고 있다고 결론짓습니다. 이러한 차이점을 이해함으로써 실무자는 자신의 프로젝트 요구사항, 언어 스택 및 컴플라이언스 요구사항에 부합하는 정보에 입각한 결정을 내릴 수 있습니다.