소프트웨어 공급망 보안의 초석, SBOM(Software Bill of Materials)의 개념 및 관리 체계

 

1. 투명한 소프트웨어 생태계의 시작, SBOM의 개요

• 정의: 소프트웨어를 구성하는 모든 오픈소스 라이브러리, 모듈, 의존성 관계 및 라이선스 정보를 상세히 기록한 소프트웨어 구성 명세서.

• 등장 배경: * 공급망 공격 급증: Log4j 사태와 같이 오픈소스 취약점이 전 세계적 보안 위협으로 확산.

  • 복잡성 증가: 현대 SW의 80% 이상이 오픈소스를 활용함에 따라 가시성(Visibility) 확보가 필수적임.

  • 규제 강화: 미국 행정명령(EO 14028) 등 공공 조달 시 SBOM 제출 의무화 추세.

2. SBOM의 주요 구성 요소 및 표준 포맷

가. SBOM의 7가지 최소 필수 요소 (NTIA 권고안)

1. 공급자 이름 (Supplier Name): 컴포넌트를 생성한 주체.

2. 컴포넌트 이름 (Component Name): 소프트웨어 단위의 명칭.

3. 버전 (Version): 해당 컴포넌트의 특정 릴리스 정보.

4. 고유 식별자 (Unique Identifier): PURL, CPE 등 충돌 없는 식별자.

5. 의존성 관계 (Dependency Relationship): 상위-하위 컴포넌트 간의 포함 관계.

6. SBOM 작성자 (Author): 명세서를 생성한 주체나 도구.

7. 타임스탬프 (Timestamp): SBOM 정보가 기록된 일시.

나. 대표적인 SBOM 표준 포맷 비교

구분	SPDX (ISO/IEC 5962)	CycloneDX	SWID Tag
주관	Linux Foundation	OWASP	ISO/IEC 19770-2
특징	라이선스 준수에 특화, 매우 상세함	보안 취약점 및 공급망 분석에 최적화	XML 기반의 태그 방식
포맷	Tag/Value, JSON, YAML, RDF	JSON, XML, Protobuf	XML

3. SBOM 기반의 취약점 관리 프로세스

1. 생성 (Generation): 빌드 단계(CI/CD)에서 SCA(Software Composition Analysis) 도구를 통해 SBOM 자동 생성.

2. 검증 (Verification): 표준 포맷(CycloneDX 등) 준수 여부 및 무결성 확인.

3. 매핑 (Mapping): NVD(National Vulnerability Database) 등 취약점 DB와 SBOM을 대조하여 취약한 컴포넌트 식별.

4. 조치 (Remediation): 발견된 취약점(CVE)에 대해 패치, 업데이트 또는 대체 라이브러리 적용.

4. SBOM 활성화를 위한 과제 및 향후 전망

• VEX(Vulnerability Exploitability eXchange) 연계: 특정 취약점이 해당 SW 환경에서 실제 실행 가능한지(Exploitable) 정보를 공유하여 '오탐'에 의한 피로도 감소 필요.

• 자동화 체계 구축: 수동 작성을 지양하고, DevSecOps 파이프라인 내에서 실시간으로 SBOM이 갱신되는 체계 마련.

• 결언: SBOM은 단순히 목록을 만드는 것이 아니라, 소프트웨어 **'디지털 계보(Digital Pedigree)'**를 관리하는 것임. 향후 제로 트러스트(Zero Trust) 아키텍처와 결합하여 소프트웨어 신뢰성을 보장하는 필수 인프라로 정착될 것임.