SBOM [Gemini] SPDX, CycloneDX

황제낙엽 2025.04.10 09:16 조회 수 : 1528

SBOM(Software Bill of Materials)에서 SPDX(Software Package Data Exchange)는 가장 중요한 핵심 내용 중 하나이며,
사실상 SBOM의 "표준 형식"이라고 할 수 있습니다.

SPDX는 Linux Foundation에서 관리하는 오픈 표준 형식으로, 소프트웨어 패키지, 라이선스, 저작권 및 보안 관련 정보를 교환하기 위한 목적으로 설계되었습니다.
SBOM을 생성하고 공유할 때 SPDX 형식을 사용하는 것은 여러 가지 중요한 의미를 가집니다.

SBOM에서 SPDX가 가지는 의미와 포함하는 내용은 다음과 같습니다.

  • 표준화된 데이터 형식: SPDX는 SBOM 정보를 일관되고 체계적인 방식으로 표현하기 위한 명확한 규격을 제공합니다.
    이를 통해 다양한 도구와 조직 간에 SBOM 데이터를 쉽게 공유하고 해석할 수 있습니다.
  • 라이선스 정보의 명확한 표현: SPDX는 소프트웨어 컴포넌트의 라이선스를 정확하고 표준화된 방식으로 기록하는 데 중점을 둡니다.
    SPDX License List라는 광범위한 라이선스 식별자를 제공하여 라이선스 충돌 위험을 줄이고 컴플라이언스를 용이하게 합니다.
  • 저작권 정보 관리: 각 소프트웨어 컴포넌트의 저작권 정보를 기록하여 지적 재산권 관리를 지원합니다.
  • 컴포넌트 식별: 각 소프트웨어 컴포넌트를 고유하게 식별하기 위한 다양한 메커니즘(예: Package URL - PURL)을 지원합니다.
  • 의존성 관계 표현: 소프트웨어 컴포넌트 간의 의존성 관계를 명확하게 나타내어 소프트웨어의 구조를 이해하는 데 도움을 줍니다.
  • 보안 관련 정보 포함: SPDX 3.0 버전부터는 보안 취약점 정보(예: CVE) 및 관련 메타데이터를 포함할 수 있도록 확장되어 SBOM을 통한 보안 위험 관리 기능을 강화합니다.
  • 확장성: SPDX는 다양한 사용 사례를 지원하기 위해 확장 가능한 구조를 가지고 있습니다.

SPDX 문서의 주요 섹션 및 포함 내용 (일반적인 예시):

  • SPDX 문서 정보 (SPDX Document Information): SPDX 버전, 생성자 정보, 생성 날짜, 문서 식별자 등 SBOM 문서 자체에 대한 메타데이터를 포함합니다.
  • 패키지 정보 (Package Information): 각 소프트웨어 패키지/컴포넌트에 대한 상세 정보 (이름, 버전, 다운로드 위치, 라이선스 정보, 저작권 정보, 설명, 고유 식별자 등)를 포함합니다.
  • 파일 정보 (File Information): 각 패키지에 포함된 소스 파일 및 기타 파일에 대한 정보 (이름, 라이선스 정보, 저작권 정보, 파일 고유 식별자 등)를 포함합니다.
  • 관계 (Relationships): 패키지, 파일, 문서 간의 의존성 및 기타 관계를 정의합니다 (예: "package A depends on package B", "file X is part of package A").
  • 라이선스 정보 (License Information): SPDX 문서에서 사용된 라이선스 선언 및 추출된 라이선스 텍스트를 포함합니다.
  • 주석 (Annotations): SPDX 문서의 특정 요소에 대한 추가적인 설명이나 의견을 포함합니다.

결론적으로, SBOM에서 SPDX는 단순한 데이터 형식을 넘어, 소프트웨어 구성 요소와 관련된 다양한 정보를 표준화된 방식으로 표현하고 교환하기 위한 핵심적인 프레임워크입니다.
SPDX 형식을 따르는 SBOM은 상호 운용성을 높이고, 자동화된 분석 및 처리의 기반을 제공하여 소프트웨어 보안 및 컴플라이언스 관리를 효율적으로 수행할 수 있도록 돕습니다.

 


 

SBOM(Software Bill of Materials)에서 CycloneDX는 SPDX와 함께 가장 널리 사용되는 오픈 표준 SBOM 형식 중 하나입니다.
OWASP (Open Web Application Security Project)에서 개발 및 유지 관리하며, 특히 보안 측면에 초점을 맞춘 풍부한 기능을 제공합니다.

CycloneDX의 주요 특징 및 포함 내용은 다음과 같습니다.

  • 보안 중심 설계: CycloneDX는 소프트웨어 구성 요소뿐만 아니라, 해당 구성 요소와 관련된 보안 취약점, 서비스, 데이터 흐름, 인프라 정보까지 포괄적으로 표현할 수 있도록 설계되었습니다.
    이는 SBOM을 활용하여 소프트웨어의 보안 위험을 보다 효과적으로 관리하는 데 도움을 줍니다.
  • 경량성과 확장성: XML 및 JSON 형식을 지원하여 데이터 크기가 비교적 작고 파싱이 용이합니다.
    또한, 다양한 유형의 정보를 담을 수 있도록 확장 가능한 구조를 가지고 있습니다.
  • 다양한 컴포넌트 유형 지원: 오픈소스 라이브러리, 상용 컴포넌트, 하드웨어, 서비스, 데이터베이스 등 다양한 유형의 소프트웨어 및 하드웨어 구성 요소를 SBOM에 포함할 수 있습니다.
  • 취약점 정보 통합: CycloneDX는 OWASP Dependency-Check와 같은 취약점 스캐너 결과와 통합하여 SBOM 내에 발견된 보안 취약점 정보를 포함할 수 있습니다.
    이를 통해 어떤 컴포넌트가 위험한지, 어떤 취약점이 존재하는지 등을 명확하게 파악할 수 있습니다.
  • 라이선스 정보 포함: 소프트웨어 컴포넌트의 라이선스 정보를 기록하여 라이선스 준수를 지원합니다.
    SPDX와 마찬가지로 표준화된 라이선스 식별자를 사용할 수 있습니다.
  • 의존성 관계 표현: 컴포넌트 간의 의존성 관계를 명확하게 표현하여 소프트웨어의 구조와 잠재적인 영향 범위를 파악하는 데 도움을 줍니다.
  • 서비스 및 데이터 흐름 정보: 네트워크 서비스, API 엔드포인트, 데이터 흐름 정보 등을 SBOM에 포함하여 애플리케이션의 런타임 컨텍스트와 보안 아키텍처를 이해하는 데 유용합니다.
  • 하드웨어 정보 포함: 소프트웨어뿐만 아니라, 해당 소프트웨어가 실행되는 하드웨어 구성 요소에 대한 정보도 SBOM에 포함할 수 있습니다.
  • 다양한 도구 지원: CycloneDX 형식의 SBOM을 생성, 검증, 분석하는 다양한 오픈소스 및 상용 도구들이 존재합니다.

CycloneDX 문서의 주요 섹션 및 포함 내용 (일반적인 예시):

  • bom: CycloneDX 문서의 루트 요소이며, SBOM 메타데이터를 포함합니다 (스키마 버전, 생성 정보 등).
  • components: 소프트웨어를 구성하는 각 컴포넌트의 목록을 포함합니다.
    각 컴포넌트는 이름, 버전, 설명, 라이선스 정보, 저작권 정보, PURL 등의 식별자를 가질 수 있습니다.
  • dependencies: 컴포넌트 간의 의존성 관계를 정의합니다.
  • vulnerabilities: 해당 소프트웨어 컴포넌트와 관련된 보안 취약점 정보를 포함합니다 (CVE ID, 설명, 심각도 등).
  • services: 애플리케이션이 사용하는 네트워크 서비스 및 API 엔드포인트 정보를 포함합니다.
  • externalReferences: 컴포넌트와 관련된 외부 참조 정보 (예: 웹사이트, 다운로드 URL 등)를 포함합니다.
  • metadata: SBOM 문서 자체에 대한 추가적인 메타데이터를 포함합니다.

결론적으로, CycloneDX는 보안에 중점을 둔 현대적인 SBOM 형식으로, 소프트웨어 구성 요소뿐만 아니라 보안 취약점, 서비스, 데이터 흐름 정보까지 통합하여 소프트웨어의 보안 상황을 종합적으로 파악하고 관리하는 데 매우 유용합니다.
SPDX와 함께 SBOM 생성을 위한 주요 표준으로 널리 채택되고 있습니다.

 

번호 제목 글쓴이 날짜 조회 수
공지 [계속 추가중] SBOM 용어 정의 황제낙엽 2025.04.10 21564
공지 [계속 추가중] Keycloak 용어 및 설정 옵션 정의 황제낙엽 2024.02.02 20404
146 SPDX 2.3, 계속 써도 되나요? — 3.0으로 넘어갈 때를 판단하는 실무 기준 황제낙엽 2026.08.11 54
145 같은 OSS 지만 여러 버전을 등록해야 하는 경우 황제낙엽 2026.04.24 1972
144 [FOSSLight Dependency Scanner] Android Project 의 Dependency Scan 을 위한 Android SDK 설치와 설정 황제낙엽 2026.04.23 1843
143 FOSSLight Hub 의 REST API 이용 (v2) 황제낙엽 2026.03.19 2500
142 [FOSSLight/검토용] 개발그룹의 sbom-info.yaml 분석 및 피드백 절차 황제낙엽 2026.03.16 1982
141 [FOSSLight/관리용] Project Identification 진행에서 최종 SBOM SPDX 문서 추출 황제낙엽 2026.02.09 1916
140 [FOSSLight] 'Download Location' 컬럼 값에 'Different from DB' 라는 푸른색 메세지가 출력 file 황제낙엽 2026.02.06 3612
139 [FOSSLight] Project Identification 진행시의 신규 OSS 등록 처리 방법 황제낙엽 2026.02.06 3750
138 [FOSSLight Hub] License 정보를 직접 등록시 필요한 항목 목록 황제낙엽 2026.02.06 3579
137 [FOSSLight Hub] Open Source 정보를 직접 등록시 필요한 항목 목록 황제낙엽 2026.02.06 3352
136 [OSS] Microsoft.Web.WebView2 황제낙엽 2026.02.06 3351
135 [FOSSLight] fosslight 프로젝트의 'Pre-Review' > 'Open Source' 팝업창의 세 버튼에 대한 용도 황제낙엽 2026.02.06 3572
134 [FOSSLight/검토용] prechecker convert 결과 Hub 등록후 Identification 처리 file 황제낙엽 2026.02.05 3289
133 python venv 설치, fosslight source scanner , binary scanner 설치, 버전 확인 황제낙엽 2026.02.02 3507
132 SPDX 템플릿 다운로드 및 온라인 변환기 황제낙엽 2026.01.22 3869
131 SBOM(Software Bill of Materials) 및 소프트웨어 공급망 보안 관련 주요 정부 기관 및 단체 황제낙엽 2026.01.22 3605
130 [FOSSLight] online guide link 황제낙엽 2026.01.14 1844
129 identification 에서 출력하는 warning, error 메세지 황제낙엽 2025.12.29 1427
128 sbom-info.yaml 을 이용한 dependency scan excel 작성 file 황제낙엽 2025.12.29 3578
127 binary scan 결과물에 대해 취약점이 없는데 왜 SBOM에 넣어야 하나? 황제낙엽 2025.12.17 3484