[정보관리기술사 137회 1교시 5번] SBOM(Software Bill of Materials)과 소프트웨어 공급망 보안

I. 개요

SBOM이란 소프트웨어를 구성하는 컴포넌트·라이브러리·의존성의 완전한 목록과 메타데이터를 기계 판독 가능한 형태로 기술한 문서이다. 2020년 SolarWinds 공격, 2021년 Log4Shell(CVE-2021-44228) 취약점이 소프트웨어 공급망 전반에 연쇄 파급되면서, 미국 바이든 행정부는 2021년 행정명령 EO14028을 통해 연방 소프트웨어 납품사에 SBOM 제공을 의무화하였다.

II. SBOM 핵심 구성 요소 (NTIA 최소 요건)

III. SBOM 표준 형식 비교

IV. SCA(Software Composition Analysis)와의 연계

SBOM은 SCA 도구(Snyk, Black Duck, OWASP Dependency-Check)와 연계하여 CVE 데이터베이스와 자동 매핑함으로써 신규 취약점 공개 시 영향받는 시스템을 즉시 식별·패치 우선순위화할 수 있다. DevSecOps 파이프라인에서 빌드 단계 자동 SBOM 생성이 표준 관행으로 정착되고 있다.

V. 결론 및 기술사 관점

SBOM은 소프트웨어 투명성과 공급망 보안의 핵심 인프라다. 국내도 과기정통부·KISA 주도로 SBOM 가이드라인이 정비 중이며, 도입 시 자동화 생성(SBOM-as-Code) → 중앙 저장소 관리 → 취약점 연속 모니터링의 3단계 체계 구축이 실효성 있는 접근이다.

SBOM을 실제로 운영할 때 알아야 할 것

SBOM은 한 번 만들어 두는 문서가 아니라 빌드할 때마다 갱신되는 자산 목록입니다. 새 취약점이 공개됐을 때 “우리 제품 중 어디에 그 라이브러리가 들어 있는가”를 몇 분 안에 답할 수 있게 하는 것이 목적입니다. Log4Shell 때 많은 조직이 이 질문에 며칠씩 걸렸다는 점이 도입의 계기가 됐습니다.

형식은 크게 SPDX(Linux Foundation 주도, ISO/IEC 5962로 표준화)와 CycloneDX(OWASP 주도, 보안 용도에 특화)가 쓰입니다. 어느 쪽이든 기계가 읽을 수 있어야 취약점 데이터베이스와 자동으로 대조할 수 있습니다.

• 생성: CI 파이프라인에서 Syft, Trivy, CycloneDX 플러그인 같은 도구로 자동 생성하고 릴리스 산출물과 함께 보관합니다.
• 범위: 직접 의존성뿐 아니라 전이 의존성(의존성의 의존성)까지 포함해야 실효가 있습니다.
• 취약점 연계: NVD나 OSV 같은 데이터베이스와 대조하고, 영향 없음을 알리는 VEX(Vulnerability Exploitability eXchange) 문서를 함께 쓰면 불필요한 경보를 줄일 수 있습니다.
• 무결성: SBOM 자체가 변조되면 의미가 없으므로 서명과 해시로 보호합니다.
• 흔한 실패: 목록만 만들고 대응 절차(누가, 언제까지 패치하는가)가 없는 경우입니다.

※ 이 글은 학습·참고용 정리입니다. 제품 사양과 표준 개정 사항은 공식 문서에서 최신 내용을 확인하세요.