SBOM 관리

• 1: SBOM이란?
• 2: SBOM 표준

graph TD
    A[개발 시작] --> B[의존성 추가]
    B --> C{빌드/배포}
    C -->|자동화| D[SBOM 생성]
    D --> E[저장소 업로드]
    E --> F[취약점 분석]
    F --> G[보안 조치]

1 - SBOM이란?

SBOM의 정의

SBOM (Software Bill of Materials)은 소프트웨어를 구성하는 모든 컴포넌트, 라이브러리, 모듈 등의 목록과 그들 간의 의존성 관계를 기술한 정형화된 명세서입니다. 제조업에서 제품의 부품 목록을 관리하는 BOM(Bill of Materials) 개념을 소프트웨어 공학에 적용한 것입니다.

graph TD
    A[소프트웨어 제품] --> B[직접 의존성]
    B --> C[라이브러리 A v1.2.3]
    B --> D[라이브러리 B v2.0.1]
    B --> E[라이브러리 C v3.1.0]
    C --> F[전이적 의존성]
    F --> G[라이브러리 D v1.0.0]
    F --> H[라이브러리 E v2.5.0]
    D --> F

SBOM의 주요 구성 요소

컴포넌트 정보

각 소프트웨어 컴포넌트에 대한 기본 정보를 포함합니다.

• 이름(Name): 컴포넌트의 공식 명칭
• 버전(Version): 정확한 버전 번호
• 공급자(Supplier): 컴포넌트를 제공한 조직 또는 개인
• 라이선스(License): 적용되는 오픈소스 라이선스

고유 식별자

컴포넌트를 명확히 식별하기 위한 표준화된 식별자를 사용합니다.

Package URL (purl)

가장 일반적으로 사용되는 식별자 형식입니다.

pkg:maven/org.springframework/spring-core@5.3.20
pkg:npm/express@4.18.2
pkg:pypi/django@4.1.0

CPE (Common Platform Enumeration)

보안 취약점 데이터베이스와 연동하기 위해 사용됩니다.

cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*

의존성 관계

컴포넌트 간의 의존성 관계를 명시합니다.

• 직접 의존성(Direct Dependencies): 프로젝트가 직접 사용하는 라이브러리
• 전이적 의존성(Transitive Dependencies): 직접 의존성이 다시 의존하는 라이브러리

메타데이터

SBOM 자체에 대한 정보를 포함합니다.

• 생성 도구: SBOM을 생성한 도구의 이름과 버전
• 생성 시각: SBOM이 생성된 날짜와 시간
• 생성자: SBOM을 생성한 조직 또는 개인

왜 필요한가?

SBOM은 단순한 문서가 아니라 소프트웨어 투명성을 위한 핵심 데이터입니다.

1. 보안 취약점의 신속한 식별

새로운 취약점(예: Log4j 사태)이 발표되었을 때, 우리 서비스 중 어디에 해당 라이브러리가 쓰이고 있는지 즉시 파악할 수 있습니다. SBOM이 없다면 모든 서버와 코드를 일일이 전수 조사해야 하며, 대응 골든타임을 놓치게 됩니다.

2. 라이선스 리스크 관리

오픈소스 라이선스 위반은 법적 분쟁으로 이어질 수 있습니다. SBOM을 통해 프로젝트에 포함된 모든 라이선스를 식별하고, 호환되지 않는 라이선스(예: GPL과 상용 코드의 결합) 사용을 사전에 차단할 수 있습니다.

3. 소프트웨어 품질 및 노후화 관리

오래되고 지원이 중단된(EOL, End-of-Life) 컴포넌트를 식별하여 기술 부채를 관리하고 소프트웨어의 건전성을 유지할 수 있습니다.

4. 규제 준수

미국 연방 정부를 비롯한 다양한 조직에서 SBOM 제출을 의무화하고 있습니다.

• 미국 행정명령 14028 (연방 정부 공급사)
• EU Cyber Resilience Act
• 의료기기 FDA 승인

SBOM 생성

상세한 SBOM 생성 방법과 기술적 가이드는 다음 문서를 참고하시기 바랍니다.

• 공급사 가이드 (For Suppliers)
• SBOM 생성 방법

참고 자료

• NTIA SBOM Minimum Elements
• CISA SBOM Sharing Lifecycle
• Linux Foundation: SBOM Guide

2 - SBOM 표준

주요 SBOM 표준

현재 시장을 양분하고 있는 두 가지 주요 표준 형식이 있습니다. 두 형식 모두 널리 사용되지만, 탄생 배경과 주력 분야에 차이가 있습니다.

• SPDX: Software Package Data Exchange
• CycloneDX: OWASP 주관의 보안 중심 SBOM 표준

SPDX (Software Package Data Exchange)

개요

SPDX는 Linux Foundation이 주관하는 오픈소스 프로젝트로, 소프트웨어 패키지의 라이선스 및 저작권 정보를 표준화된 방식으로 표현하기 위해 개발되었습니다. (ISO/IEC 5962:2021)

주요 특징

1. SPDX는 원래 오픈소스 라이선스 정보 교환을 위해 개발되어, 라이선스 관련 정보가 매우 상세합니다.

• 표준화된 라이선스 식별자 (SPDX License List)
• 라이선스 표현식 (예: Apache-2.0 OR MIT)
• 저작권 정보 및 파일별 라이선스

2. 패키지뿐만 아니라 개별 파일 레벨의 정보도 포함할 수 있습니다.

• 파일별 해시값
• 파일별 라이선스
• 파일별 저작권 정보

SPDX 문서 구조

{
  "SPDXID": "SPDXRef-DOCUMENT",
  "spdxVersion": "SPDX-2.3",
  "name": "Example-SBOM",
  "documentNamespace": "https://example.com/sbom-2023-001",
  "creationInfo": {
    "created": "2023-01-15T10:30:00Z",
    "creators": ["Tool: SPDX-Tools-2.3"]
  },
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-1",
      "name": "spring-core",
      "versionInfo": "5.3.20",
      "licenseDeclared": "Apache-2.0",
      "externalRefs": [
        {
          "referenceType": "purl",
          "referenceLocator": "pkg:maven/org.springframework/spring-core@5.3.20"
        }
      ]
    }
  ]
}

장점

• ISO 국제 표준으로 공식 인정
• 라이선스 정보가 매우 상세
• 파일 레벨까지 추적 가능
• 성숙한 도구 생태계

단점

• 보안 취약점 정보가 선택사항
• 구조가 다소 복잡
• 보안 중심 프로젝트에는 부족할 수 있음

CycloneDX

개요

CycloneDX는 OWASP(Open Web Application Security Project)에서 개발한 SBOM 표준으로, 애플리케이션 보안에 중점을 둡니다.

주요 특징

1. 처음부터 보안 취약점 관리를 위해 설계되었습니다.

• 취약점 정보 (Vulnerabilities)
• 보안 분석 결과 (Security Analysis)
• 위협 정보 (Threats)

2. SPDX에 비해 구조가 간결하고 이해하기 쉽습니다.

• 필수 정보에 집중
• JSON, XML 형식 지원
• 작은 파일 크기

3. 다양한 사용 사례를 지원하는 확장 기능을 제공합니다.

• SaaS BOM
• Hardware BOM
• AI/ML BOM
• Cryptography BOM

CycloneDX 문서 구조

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2023-01-15T10:30:00Z",
    "tools": [
      {
        "name": "cyclonedx-maven-plugin",
        "version": "2.7.9"
      }
    ],
    "component": {
      "type": "application",
      "name": "MyApp",
      "version": "1.0.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "spring-core",
      "version": "5.3.20",
      "purl": "pkg:maven/org.springframework/spring-core@5.3.20",
      "licenses": [
        {
          "license": {
            "id": "Apache-2.0"
          }
        }
      ]
    }
  ]
}

장점

• 보안 취약점 정보 기본 포함
• 구조가 간결하고 이해하기 쉬움
• 보안 도구와의 통합이 우수
• 활발한 커뮤니티 및 도구 개발

단점

• ISO 표준은 아님 (사실상 표준)
• 파일 레벨 정보는 제한적
• 라이선스 표현이 SPDX보다 단순

SPDX vs CycloneDX 비교

선택 가이드

CycloneDX 선택이 적합한 경우

다음과 같은 경우 CycloneDX를 권장합니다.

• 보안이 최우선: 취약점 관리가 주요 목적
• 빠른 시작: 간결한 구조로 빠르게 도입
• DevSecOps: CI/CD에 통합하여 자동화
• 현대적인 애플리케이션: 클라우드, 컨테이너 환경

SPDX 선택이 적합한 경우

다음과 같은 경우 SPDX를 권장합니다.

• 라이선스 컴플라이언스 중시: 상세한 라이선스 정보 필요
• 파일 레벨 추적: 소스코드 파일별 정보 필요
• ISO 표준 준수: 공식 표준 인증 필요
• 레거시 시스템: 기존 SPDX 도구 사용 중

SK텔레콤 권장사항

SK텔레콤의 내부 프로젝트는 CycloneDX (JSON) 형식을 기본 권장합니다. 이는 내부 취약점 관리 시스템과의 연동성이 CycloneDX가 더 우수하기 때문입니다. 단, 외부 파트너사가 SPDX를 제출하는 경우에도 호환성을 지원합니다.

상호 변환

SPDX와 CycloneDX 간 변환 도구가 제공됩니다.

SPDX → CycloneDX

# cyclonedx-cli 사용
cyclonedx convert --input-file sbom.spdx.json \
  --output-file sbom.cdx.json --input-format spdx \
  --output-format json

CycloneDX → SPDX

# spdx-tools 사용
java -jar tools-java-1.1.0-jar-with-dependencies.jar \
  Convert bom.cdx.json bom.spdx.json

SBOM 생성

상세한 SBOM 생성 방법과 기술적 가이드는 다음 문서를 참고하시기 바랍니다.

• 공급사 가이드 (For Suppliers)
• SBOM 생성 방법

참고 자료

• SPDX Specification
• CycloneDX Specification
• NTIA SBOM Formats Comparison