SBOM과 오픈소스 취약점 관리 – 정보보호 전문가 실전 가이드

SBOM은 개발자, 보안 담당자, 법무팀 등 다양한 이해관계자에게 구성 요소의 가시성과 신뢰성 제공

 

목차
   ­ㄴ SBOM 개요
   ­ㄴ SBOM 표 예시 (CSV 또는 표 기반 시각화)
   ­ㄴ 실제 SBOM 예시 형태 (SPDX JSON 일부 예)
   ㄴ SBOM과 정보보호의 연관성
   ㄴ 오픈소스 취약점 이슈와 대응
   ㄴ SBOM을 활용한 오픈소스 보안 관리 전략
   ㄴ SBOM 도입 시 고려사항
   ㄴ 국내외 정책 및 규제 동향
   ㄴ  SBOM 운영 프로세스 및 실제 적용 사례

 

■ SBOM 개요    
   **SBOM(Software Bill of Materials)**은 소프트웨어를 구성하는 오픈소스 및 서드파티 라이브러리의 목록을 명세한 문서입니다. 즉, “이 소프트웨어 안에 어떤 부품이 들어있느냐”를 투명하게 보여주는 소프트웨어 구성 명세서입니다.
   ※ SBOM은 개발자, 보안 담당자, 법무팀 등 다양한 이해관계자에게 구성 요소의 가시성과 신뢰성을 제공합니다.

• 주요항목
  - 컴포넌트명 (name)
  - 버전 (version)
  - 해시값 (Hash/SHA256)
  - 라이선스 정보
  - 의존성 관계 (dependency tree)

 

■ SBOM 표 예시 (CSV 또는 표 기반 시각화)  

항목 (Field)	설명 (Description)	예시 값 (Sample)
Component Name	오픈소스 구성요소 또는 라이브러리 이름	log4j-core
Version	사용된 구성요소의 버전	2.17.1
Type	소프트웨어 구성 요소 유형 (library, application, framework 등)	library
Supplier	구성 요소를 제공한 공급자 또는 제작자	Apache Software Foundation
Package URL (purl)	구성 요소를 고유하게 식별하기 위한 표준 URL	pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1
License	해당 구성 요소의 라이선스 정보	Apache-2.0
Copyright	저작권 정보	Copyright 2021 Apache Software Foundation
Vulnerability Info	알려진 취약점 정보 (CVE 등)	CVE-2021-44228
Checksum (SHA-256)	파일 무결성 확인을 위한 해시	1a2b3c... (SHA-256 값)
Dependency Relationship	다른 구성요소와의 의존 관계 (optional)	direct / transitive

 

■ 실제 SBOM 예시 형태 (SPDX JSON 일부 예)   

{
  "name": "log4j-core",
  "versionInfo": "2.17.1",
  "supplier": "Organization: Apache Software Foundation",
  "downloadLocation": "https://repo.maven.apache.org/maven2/...",
  "licenseConcluded": "Apache-2.0",
  "copyrightText": "Copyright 2021 Apache Software Foundation",
  "externalRefs": [
    {
      "referenceCategory": "PACKAGE-MANAGER",
      "referenceType": "purl",
      "referenceLocator": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1"
    }
  ],
  "checksums": [
    {
      "algorithm": "SHA256",
      "checksumValue": "e6b1...cc9a"
    }
  ]
}

 

■ SBOM과 정보보호의 연관성   

   SBOM은 단순한 리스트 이상의 역할을 합니다. 특히 공급망 보안 측면에서 다음과 같은 기능을 수행합니다.

• 신뢰할 수 없는 코드 탐지 : 외부에서 유입된 의심스러운 오픈소스 식별
• 취약한 컴포넌트 선제 대응 : CVE와 매칭하여 위험 요소 조기 대응
• DevSecOps 연계 : 개발과 동시에 보안을 자동화하는 기반 요소

SBOM은 Zero Trust 아키텍처에서도 핵심 요소로 자리 잡고 있으며, 클라우드·컨테이너 환경에서도 사용 범위가 확대되고 있습니다.

■ 오픈소스 취약점 이슈와 대응    

   대다수의 소프트웨어는 수십~수백 개의 오픈소스 라이브러리를 포함합니다. 이들 중 일부는 다음과 같은 이유로 심각한 보안 위협이 될 수 있습니다

• CVE 미등록 상태로 은폐된 취약점 존재
• 유지보수 종료로 패치 불가능한 컴포넌트
• 의도적으로 악성 코드가 삽입된 오픈소스 백도어 사례 (예: xz 백도어 사건)
  

  ※ 대표 사례
     - Log4j 취약점 (CVE-2021-44228) : 전 세계 수백만 개 시스템에 영향
     - Spring4Shell (CVE-2022-22965) : 스프링 프레임워크 기반 서비스 전체 노출
     - XZ 백도어 : 주요 리눅스 배포판에 사전 삽입된 공급망 공격 사례

오픈소스는 보안 취약점이 발견되더라도 자동으로 알림이 오지 않기 때문에, SBOM은 이를 추적하고 관리하는 핵심 도구입니다

 

■ SBOM을 활용한 오픈소스 보안 관리 전략     

   보안 담당자는 SBOM을 통해 다음과 같은 보안 전략을 수립할 수 있습니다

• 취약한 라이브러리 자동 식별 : CVE/CWE와 연동하여 위험도 파악
• 패치 우선순위 결정 : 활용 범위와 외부 노출 여부에 따라 대응 속도 차등화
• 신뢰 출처 확인 : 공식 저장소 여부 및 hash값 검증으로 무결성 확보
• 자동화된 SCA 도구 연계 : Snyk, Anchore, Trivy 등과 연동하여 실시간 관리

  ※ TIP : SBOM 단독으로는 exploitability까지 확인 불가 → VEX와 함께 사용하면, 실제로 공격 가능한지 여부까지 파악 가능

 

■ SBOM 도입 시 고려사항    

   SBOM 생성 및 활용 시 다음과 같은 사항을 고려해야 합니다

1. SBOM 생성 도구
   - Syft (Anchore)
   - Trivy (Aqua)
   - CycloneDX (OWASP)
   - SPDX (Linux Foundation)

2. 포맷 선택 기준

포맷	특징
SPDX	ISO/IEC 표준 채택, 법적 라이선스 명시 용이
CycloneDX	보안 위협 대응 중심, VEX와의 통합 지원
SWID	에이전트 기반 상용 SW에 적합

3. CI/CD 통합

   - GitHub Actions, GitLab CI, Jenkins 등에 자동화 플러그인 존재
   - 빌드시 SBOM 자동 생성 → 저장소에 등록 방식으로 연동

■ 국내외 정책 및 규제 동향    

   SBOM 도입은 선택이 아닌 필수로 바뀌고 있습니다

• 미국 : EO 14028 이후 연방정부 납품 SW는 SBOM 필수
• NIST : SP 800-218 (SSDF)에서 SBOM 요구사항 명시
• EU : CRA(Cyber Resilience Act)에서 제조사 SBOM 제출 의무화
• 대한민국
  - KISA : 오픈소스 보안 가이드 권고 강화
  - ISMS-P : 오픈소스 컴포넌트 관리 항목 포함될 가능성
  - 금융권 : 전자금융감독규정 해석상 취약점 선제 대응 요구 증가

■ SBOM 운영 프로세스 및 실제 적용 사례    

※ 운영 프로세스 예시
   - 소스코드 분석 → SBOM 생성 → 저장소 등록 → 취약점 연동(CVE) → 패치 또는 교체

  ※ 사례
     - 미국 금융권 : 내부 레거시 시스템부터 SBOM 도입, 취약점 트래킹 자동화
     - 국내 IT기업 : SCA 도구 + VEX 연계, SBOM 자동화 운영
     - 정부기관 : 공개 소프트웨어 등록 시 SBOM 제출 권고 시행 중

240513-(요약본)_SW_공급망_보안_가이드라인.pdf

3.14MB

240525-(전체본)_SW_공급망_보안_가이드라인_최종 수정본.pdf

10.14MB

감사합니다.