CycloneDX vs SPDX 차이 (SBOM 실무 기준)

요즘 보안 이슈 때문인지 SBOM 요구하는 업체들이 많아졌다.
젠킨스에 syft 를 활용해서 릴리즈별로 SBOM 파일을 함께 생성하도록 자동화 구축해놨는데 하면서 공부한 내용을 정리한다. 

SBOM(Software Bill of Materials)을 만들다 보면
CycloneDX와 SPDX 중 무엇을 써야 하는지 항상 헷갈린다.

결론부터 말하면:

보안·취약점 중심이면 CycloneDX
라이선스·법적 검증 중심이면 SPDX

아래에서 실무 기준으로 명확하게 정리해보자.

---

1️⃣ CycloneDX와 SPDX는 왜 나왔을까?

📌 SPDX (Software Package Data Exchange)

• 리눅스 재단 주도
• 목적:
  👉 오픈소스 라이선스 컴플라이언스
• “이 소프트웨어에 무슨 오픈소스가 들어갔고, 라이선스 문제가 없는가?”

📌 CycloneDX

• OWASP 주도
• 목적:
  👉 보안 취약점 관리
• “이 소프트웨어에 취약한 컴포넌트가 있는가?”

👉 출발점부터 관심사가 다르다

---

2️⃣ 핵심 차이 한눈에 비교

구분CycloneDXSPDX

주관	OWASP	Linux Foundation
주 목적	보안 / 취약점 관리	라이선스 / 법적 검증
주요 사용처	SCA, 보안 점검	오픈소스 컴플라이언스
표현 방식	JSON, XML	Tag/Value, JSON, RDF
취약점(CVE)	✅ 매우 강함	⚠️ 제한적
라이선스 표현	기본 제공	✅ 매우 상세
CI/CD 연계	매우 좋음	상대적으로 단순

---

3️⃣ CycloneDX 특징 (보안 관점)

✅ 장점

• CVE, CPE, 해시 정보 표현에 강함
• Snyk, Dependency-Track, Grype 등 보안 도구와 궁합 좋음
• CI/CD 파이프라인에서 자동 분석에 적합

 

{ "bomFormat": "CycloneDX", "specVersion": "1.5", "components": [...] }

👉 **“이 빌드가 지금 안전한가?”**를 보기 좋음

❌ 단점

• 라이선스 법적 표현은 SPDX보다 단순
• 계약/감사 문서로는 부족한 경우 있음

---

4️⃣ SPDX 특징 (라이선스 관점)

✅ 장점

• 라이선스 표현이 매우 엄격하고 표준화됨
• 법무팀, 감사 대응에 적합
• Tag/Value 포맷은 사람이 읽기 쉬움

 

SPDXVersion: SPDX-2.3 PackageName: openssl PackageLicenseDeclared: OpenSSL

👉 **“이걸 써도 법적으로 문제없는가?”**에 최적

❌ 단점

• 취약점 정보 표현이 제한적
• 보안 자동화 파이프라인에는 다소 무거움

---

5️⃣ 실무에서는 이렇게 쓴다 (중요)

✅ ① 보안 점검 / DevSecOps

👉 CycloneDX

• CI/CD
• 취약점 스캔
• 운영 서버 보안 점검

✅ ② 고객사 / 금융권 / 공공기관 제출

👉 SPDX

• 오픈소스 사용 내역 제출
• 라이선스 검증
• 법적 리스크 관리

✅ ③ 실제 현업 BEST PRACTICE

둘 다 만든다

 

- CycloneDX → 내부 보안 관리 - SPDX → 외부 제출 / 계약 대응

요즘은 Syft, Trivy 같은 도구들이 둘 다 지원한다.

---

6️⃣ 어떤 포맷을 선택해야 할까?

이렇게 판단하면 된다

• ❓ “우리 서버에 취약점 있나?”
  → CycloneDX
• ❓ “이 오픈소스 써도 문제 없나?”
  → SPDX
• ❓ “금융권 / 대기업 / RFP 제출?”
  → SPDX 필수
• ❓ “CI 자동화 + 보안?”
  → CycloneDX 필수

---

🔚 마무리

SBOM은 “형식”보다
어디에 제출하고, 무엇을 검증하려는지가 더 중요하다.

요즘은 “SBOM 생성 여부” 자체가 요구사항인 경우가 많기 때문에
두 포맷의 차이를 알고 있는 것만으로도 큰 강점이 된다.