Software Bill of Materials

Software Bill of Materials (SBoM)

SBoM(Software Bill of Materials, 소프트웨어 자재 명세서)는 소프트웨어 시스템을 구성하는 컴포넌트들의 구조화된 목록이에요. 이 가이드에서는 SBoM이 무엇인지, 왜 중요한지, 그리고 Elixir 프로젝트에서 어떻게 생성하는지 설명합니다.

출처: Software Bill of Materials

본문

SBoM이란 무엇인가

SBoM은 소프트웨어 안의 모든 컴포넌트를 기계가 읽을 수 있는 형식으로 기록한 공식 문서예요. 쉽게 말해 애플리케이션의 상세한 "재료 목록"이라고 생각하면 됩니다. 일반적인 SBoM에는 다음이 포함돼요.

  • 의존성(Dependencies): 프로젝트가 사용하는 모든 라이브러리와 패키지
  • 버전(Versions): 각 컴포넌트의 정확한 버전
  • 소스 위치(Source locations): 각 컴포넌트를 어디서 얻었는지(Hex, GitHub 등)
  • 체크섬(Checksums): 무결성을 검증하는 암호학적 해시
  • 라이선스 정보(Licensing information): 각 컴포넌트가 배포되는 라이선스

SBoM 형식으로 널리 채택된 표준은 두 가지가 있어요.

  • CycloneDX: 보안 컨텍스트에 맞춰 설계된 가벼운 표준
  • SPDX: 원래 라이선스에 초점을 맞춘 더 포괄적인 표준

두 형식 모두 기계가 읽을 수 있고(JSON, XML) 자동화 도구가 소비하도록 설계되었습니다.

SBoM은 인증이 아니라 재고(inventory)입니다

SBoM은 소프트웨어가 안전하거나, 규정을 준수하거나, 취약점이 없다고 주장하지 않아요. 단지 추가 분석을 가능하게 하는 상세한 재고 목록을 제공할 뿐입니다. 보안·컴플라이언스 평가는 SBoM을 소비하는 별도의 도구가 수행합니다.

왜 SBoM을 생성하나요

프로젝트에 SBoM을 생성해야 하는 이유는 크게 세 가지입니다.

취약점 분석

라이브러리에서 보안 취약점(CVE)이 발견되면 프로젝트가 영향을 받는지 빨리 판단해야 해요. SBoM은 의존성의 완전한 목록을 제공해서 이를 가능하게 합니다. OWASP Dependency-Track 같은 도구는 SBoM을 취약점 데이터베이스와 계속 대조해 모니터링해요. 새 CVE가 발표되면 프로젝트가 영향을 받는 컴포넌트를 쓰고 있을 때 알림을 받습니다.

SBoM이 없으면 "CVE-2024-XXXXX에 영향받나요?"라는 질문에 답하려면 각 프로젝트를 수동으로 확인해야 하는데, 이는 시간이 오래 걸리고 오류가 나기 쉬워요.

규제 요구사항

일부 규정과 조달 정책은 SBoM을 요구합니다.

  • 미국 행정명령 14028(2021): 특히 지정된 중요 소프트웨어에 대해 미국 연방 정부에 공급되는 특정 소프트웨어에는 SBoM을 요구
  • EU 사이버 복원력 법(Cyber Resilience Act): EU 시장에 출시되는 디지털 요소가 있는 제품에 대해 컴포넌트 목록(SBoM으로 충족하는 경우가 많음) 요구사항 도입
  • 안전이 중요한 산업(의료 기기, 자동차, 항공우주): 인증 절차의 일부로 상세한 컴포넌트 목록을 요구하는 경우가 많음

고객이나 파트너도 자체 컴플라이언스 노력의 일환으로 SBoM을 요청할 수 있습니다.

라이선스 컴플라이언스

프로젝트의 모든 의존성에는 라이선스가 붙어 있어요. SBoM은 각 패키지에 선언된 라이선스를 나열해서 라이선스 검토의 출발점을 제공합니다. 이를 통해 다음을 할 수 있어요.

  • 의존성 트리의 라이선스 개요 파악
  • 더 자세한 검토가 필요할 수 있는 패키지 표시
  • 인수, 감사, 법률 검토를 위한 실사(due diligence) 지원

참고로 패키지 레벨 라이선스 정보(mix_sbom이 제공하는 것)는 패키지가 선언한 것을 반영하며, 소스 파일에 실제로 포함된 모든 라이선스를 나타내지는 않아요. 철저한 라이선스 컴플라이언스를 위해서는 ORT 같은 파일 레벨 스캔 도구가 더 깊은 분석을 제공합니다.

mix_sbom으로 SBoM 생성하기

mix_sbom은 Elixir 프로젝트용 CycloneDX SBoM을 생성하는 EEF(Erlang Ecosystem Foundation) 프로젝트입니다.

설치

mix_sbom을 설치하는 방법은 여러 가지가 있어요.

  • 프로젝트 의존성으로: mix.exs에 sbom 추가
  • 전역 escript로: mix escript.install hex sbom 실행 (Elixir 1.19.4+ 필요)
  • 독립 실행 바이너리로: 릴리스 페이지에서 다운로드

독립 실행 바이너리는 CI 환경이나 프로젝트의 의존성을 수정하고 싶지 않을 때 유용해요. 로컬에 Elixir나 Erlang 설치가 필요 없습니다.

기본 사용법

독립 실행 바이너리로 프로젝트의 SBoM을 생성하려면:

$ mix_sbom cyclonedx /path/to/your/project

이 명령은 프로젝트의 완전한 의존성 트리를 담은 bom.cdx.json 파일을 CycloneDX 형식으로 만듭니다.

공통 옵션

가장 유용한 옵션은 다음과 같아요.

  • -o, --output PATH: 출력 파일 지정 (기본값: bom.cdx.json)
  • -t, --format FORMAT: 출력 형식 (json, xml, protobuf)
  • -s, --schema VERSION: CycloneDX 스키마 버전

예를 들어 XML 형식의 SBoM을 생성하려면:

$ mix_sbom cyclonedx --format xml --output sbom.xml /path/to/project

CI 통합

자동화된 SBoM 생성을 위해 mix_sbom은 GitHub Action을 제공합니다.

name: Generate SBoM
on:
  release:
    types: [published]
jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: erlef/mix_sbom@v0
        with:
          path: "."
          format: "json"
      - uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: bom.cdx.json

이 워크플로는 릴리스를 게시할 때마다 SBoM을 생성하고 이를 빌드 아티팩트로 업로드합니다. 추가 옵션은 액션 문서를 참고하세요.

ORT로 더 깊은 분석

mix_sbom은 각 의존성이 선언한 패키지 레벨 라이선스 정보를 제공해요. 하지만 일부 컴플라이언스 워크플로는 파일 레벨 스캔이 필요합니다. 예를 들어 패키지가 MIT 라이선스라 선언했는데 개별 파일에 다른 라이선스가 있거나, 자체 라이선스 조건을 가진 vendored 코드를 포함할 수 있어요.

**OSS Review Toolkit(ORT)**은 실제 소스 파일에서 라이선스 헤더와 저작권 표시를 스캔해서 이 문제를 해결합니다. ORT는 Mix 프로젝트를 지원하며 다음을 제공해요.

  • 파일 레벨 라이선스 감지: 소스 코드에서 라이선스 텍스트와 SPDX 식별자 스캔
  • 저작권 보유자 식별: 파일에서 저작권 표시 추출
  • 정책 적용: 허용/금지 라이선스에 대한 규칙 정의
  • 다중 생태계 지원: 여러 패키지 매니저에 걸친 프로젝트 분석

엄격한 컴플라이언스 요구사항이 있는 조직에서 ORT는 철저한 라이선스 감사에 필요한 더 깊은 분석으로 mix_sbom을 보완합니다.

자세한 내용은 ORT Mix 플러그인 문서를 참고하세요.

더 알아보기