IT Study/보안 및 프라이버시

🔐 SBOM(Software Bill of Materials)

cs_bot 2025. 4. 1. 17:05

1. SBOM(Software Bill of Materials)의 개요

  • SBOM(Software Bill of Materials)은 소프트웨어를 구성하는 모든 오픈소스, 서드파티, 자체 개발 모듈의 리스트를 명세한 문서임
  • 물리 제품의 제조공정에서 사용되는 자재 명세서(BOM: Bill of Materials)에 대응되는 개념으로, 소프트웨어 공급망의 구성 요소를 투명하게 식별하기 위한 목적에서 등장함
  • 보안 취약점 대응, 라이선스 관리, 의존성 파악, 공급망 위험 분석 등의 목적으로 중요성이 점점 강조됨
  • 특히 2021년 미국 바이든 행정부의 행정명령 14028(Improving the Nation’s Cybersecurity) 이후, 연방기관에 납품되는 소프트웨어에 SBOM 제출이 의무화되면서 글로벌 이슈로 부상함

2. SBOM의 구성 요소

  • Component Name: 소프트웨어 구성요소의 이름으로, 식별 가능한 유일한 명칭
  • Version: 해당 구성요소의 버전 정보
  • Supplier: 해당 소프트웨어를 제공하는 개발사 또는 공급자 정보
  • Dependency Relationship: 각 구성요소 간의 의존성 정보 명시
  • Licenses: 오픈소스 및 서드파티 구성요소의 라이선스 정보
  • Hash: 무결성 확인을 위한 해시 값(MD5, SHA-1, SHA-256 등)
  • Unique Identifier (e.g., PURL, SPDX Identifier): 국제 표준 식별자를 통해 구성요소를 명확히 식별

3. SBOM의 주요 활용 목적

  • 보안 취약점 대응

    • 구성요소 중 취약점(CVE)이 발견된 경우, 해당 컴포넌트의 포함 여부를 신속히 파악 가능
    • 보안 패치 적용 여부, 대응 속도 향상에 기여함

  • 라이선스 관리

    • 각 구성요소의 오픈소스 라이선스를 확인하여 GPL, LGPL, Apache 등과 같은 제약 조건 준수 여부를 판단함
    • 상용 제품에 포함 시 법적 분쟁을 사전에 방지할 수 있는 근거 자료로 활용됨

  • 규제 및 컴플라이언스 대응

    • 정부 및 기업의 컴플라이언스 요구사항 대응을 위한 문서 자료로 활용됨
    • 공급망 리스크 분석이나 감사 대응 시 중요한 근거 자료로 활용됨

  • 운영 관리

    • 구성요소 변경 시 영향 분석(Impact Analysis) 수행 가능
    • 배포 시점의 구성요소 상태 추적 및 재현성 확보

4. SBOM의 생성 방식

  • 수동 작성

    • 개발자가 직접 작성하며, 정확성이 높지만 시간과 인력이 많이 소요됨
    • 소규모 프로젝트 또는 초기 단계에서 유용함

  • 자동화 도구 활용

    • SCA(Software Composition Analysis) 도구 사용을 통해 코드, 바이너리, 패키지 정보를 자동 분석하여 SBOM 생성
    • 예시: CycloneDX, SPDX, Syft, Anchore, Black Duck, FOSSA 등
    • CI/CD 파이프라인에 통합하여 지속적인 SBOM 생성 가능함

5. SBOM 관련 표준

  • SPDX (Software Package Data Exchange)

    • Linux Foundation 주도, ISO/IEC 5962:2021로 국제표준화
    • 구성요소의 식별, 관계, 라이선스 등을 표현할 수 있는 상세한 스키마 제공

  • CycloneDX

    • OWASP에서 제안한 경량화된 SBOM 표준
    • DevSecOps, 컨테이너, 마이크로서비스 환경에 최적화된 구조 제공
    • JSON, XML, Protocol Buffers 포맷 지원

  • SWID (Software Identification Tags)

    • ISO/IEC 19770-2에서 정의된 형식으로, 상용 소프트웨어를 포함한 식별 및 라이선스 관리를 목표로 함
    • 정부기관 중심으로 사용됨

6. SBOM과 SCA(Software Composition Analysis)의 관계

  • SCA 도구는 소스코드, 바이너리, 패키지 등을 분석하여 오픈소스 및 서드파티 소프트웨어의 존재 여부를 탐지함
  • SBOM은 이러한 분석 결과를 구조화된 문서로 표현한 결과물임
  • 즉, SCA는 SBOM 생성을 위한 주요 도구이며, 보안 위협 탐지와 함께 SBOM 생성 자동화를 지원함

7. SBOM 도입 시 고려사항

  • 정확성: 포함된 모든 구성요소를 누락 없이 식별해야 하며, 오탐이나 누락 발생 시 보안 리스크 증가
  • 자동화: 수작업이 아닌 자동화를 통해 지속적으로 최신 상태 유지 필요
  • 버전관리: 제품 버전별로 SBOM을 별도 유지해야 하며, 이력 관리 기능 요구됨
  • 통합 관리: CI/CD 파이프라인, 보안 대응 시스템, 라이선스 관리 시스템과의 연동 필요

8. 사례 및 적용 분야

  • 정부 조달 소프트웨어: 미국 국토안보부, 국방부 등에서 SBOM 제출 요구
  • 산업 제어 시스템(ICS): 에너지, 제조 산업에서 구성요소의 취약점 파악을 위해 활용
  • 의료기기: FDA의 사이버 보안 가이드라인에 따라 SBOM 제출 요구
  • 금융 및 클라우드 서비스: 공급망 보안 관리 및 보안 인증 획득을 위한 필수 요소로 SBOM 도입 확산 중

9. SBOM의 한계 및 향후 과제

  • SBOM의 범위 한정성: 실행 중에 동적으로 로드되는 컴포넌트나 외부 API 등은 SBOM에 포함되지 않는 경우가 많음
  • 취약점 데이터베이스 의존성: CVE와 같은 DB에 등록되지 않은 신규 취약점은 탐지 불가능함
  • 버전 동기화 문제: 실제 배포된 소프트웨어와 SBOM 간의 버전 불일치 문제 발생 가능
  • 국제표준 간의 호환성: SPDX, CycloneDX 간 상호 호환성 문제 해결 필요

10. 결론

  • SBOM은 소프트웨어 공급망의 투명성과 보안성을 확보하기 위한 핵심 수단으로 자리잡고 있음
  • 오픈소스 보안, 라이선스 준수, 규제 대응, 운영 효율화를 동시에 달성할 수 있는 기반 자료로 활용 가능함
  • 향후 자동화된 SCA 도구, 국제 표준화, 보안 정책과의 통합을 통해 SBOM 활용도는 지속적으로 확대될 전망임