SBOM

SBOM이란 무엇인가? (Software Bill of Materials 정리)

Victor Lee

28 Apr 2026 — 9 min read

최근 소프트웨어 보안과 공급망 관리에서 가장 뜨거운 키워드 중 하나인 SBOM(Software Bill of Materials)에 대해 자세히 알아보겠습니다.

1. 왜 SBOM이 중요한가요?

요즘 개발되는 소프트웨어는 처음부터 끝까지 직접 모든 코드를 작성하는 경우가 드뭅니다. 대부분 오픈소스와 외부 라이브러리를 조합하여 만들어집니다. 문제는 바로 여기서 시작됩니다.

"우리가 만든 서비스 안에 어떤 코드가 들어있는지 정확히 알고 계신가요?"

이 질문에 명확하게 답하지 못한다면, 치명적인 보안 사고가 발생했을 때 즉각적인 대응이 불가능해집니다.

대표적인 대규모 보안 사고 사례를 떠올려 볼까요?

Log4j 취약점 (Log4Shell): 전 세계 인터넷 서버를 공포에 떨게 한 보안 취약점
OpenSSL 취약점 (Heartbleed): 널리 사용되는 암호화 라이브러리의 치명적 버그

이런 사건이 터졌을 때 조직에서 가장 먼저 진땀을 빼며 확인해야 하는 부분은 바로 "우리 서비스에 취약한 저 라이브러리가 포함되어 있는가?"입니다. 이 질문에 빠르고 정확하게 답을 찾아주어 골든타임을 사수하게 해주는 시스템이 바로 SBOM입니다.

2. SBOM이란 무엇인가요?

SBOM(Software Bill of Materials)은 직역하면 '소프트웨어 자재 명세서'입니다. 즉, 소프트웨어를 구성하는 모든 구성 요소의 목록을 의미합니다.

"이 소프트웨어가 어떤 부품들로 만들어졌는지 상세히 기록한 명세서"

자동차나 전자기기를 떠올려 보시면 이해가 쉽습니다. 자동차를 만들 때 들어가는 부품의 명세서(엔진, 브레이크, 타이어, 나사 등)가 있는 것처럼, 복잡한 소프트웨어 환경에서도 내부를 구성하는 수많은 오픈소스 패키지, 외부 라이브러리, 모듈 등의 요소를 명확히 목록화하여 관리해야 한다는 개념입니다.

3. SBOM에는 어떤 정보가 포함될까요?

SBOM이 제 기능을 하려면 단순히 이름만 적혀 있어서는 안 됩니다. 명확한 추적과 관리를 위해 다음과 같은 필수 정보들이 포함되어야 합니다.

1) 기본 정보 (컴포넌트 정보)

패키지(컴포넌트) 이름: 라이브러리나 모듈의 정확한 명칭
버전(Version): 사용된 정확한 버전 정보 (취약점 판별의 핵심 기준)
공급자(Supplier/Vendor): 해당 구성 요소를 제공하거나 제작한 주체

2) 의존성 관계 (Dependency)

직접 의존성(Direct Dependency): 우리 프로젝트 코드에서 직접 가져다 쓰는 라이브러리
간접/전이 의존성(Transitive Dependency): 우리가 쓰는 라이브러리가 동작하기 위해 내부적으로 불러다 쓰는 또 다른 라이브러리 (보이지 않는 보안 위협이 되기 쉬움)

3) 고유 식별 및 추가 정보

해시(Hash) 값: 파일이 변조되지 않았음을 증명하는 무결성 검증 값 (예: SHA-256)
라이선스(License): 오픈소스 라이선스 정보 (GPL, MIT, Apache 등 컴플라이언스 관리용)
PURL (Package URL): 패키지의 정확한 위치와 정보를 식별하기 위한 표준화된 포맷
- 구조 예시: pkg:maven/org.apache.logging.log4j/log4j@2.14.1

4. SBOM 도입이 기업에 꼭 필요한 이유

단순히 목록을 만드는 것을 넘어, SBOM은 현대 데브옵스(DevOps) 및 보안 환경에서 필수적인 요소가 되었습니다.

취약점 대응 속도 향상 (Zero-Day 침해 사고 대비) 새로운 제로데이(Zero-Day) 보안 취약점이 발견되었을 때, 소스 코드를 다 뒤질 필요 없이 자사의 최신 SBOM을 검색하여 취약한 컴포넌트의 사용 여부를 즉시 판단할 수 있습니다.
소프트웨어 공급망 공격(Supply Chain Attack) 대응 정상적인 소프트웨어 업데이트에 악성 코드를 몰래 심어 유포하는 공급망 공격이 크게 늘어나고 있습니다. SBOM을 통해 소프트웨어에 포함된 모든 외부 코드의 출처를 투명하게 추적할 수 있습니다.
글로벌 규제 및 컴플라이언스 강화 미국 바이든 행정부의 사이버 보안 행정명령(EO 14028)을 시작으로, 전 세계 주요 국가와 주요 기업들이 소프트웨어 납품 시 SBOM 제출을 의무화하고 있습니다. 비즈니스 연속성을 위해서라도 선택이 아닌 필수가 되었습니다.

5. 대표적인 SBOM 표준 포맷

SBOM을 사람이 일일이 손으로 작성할 수는 없습니다. 보안 솔루션이 읽고 스캔할 수 있는(Machine-Readable) 형식이 필요한데, 시장을 주도하는 대표적인 3가지 표준 포맷이 존재합니다.

1) SPDX (Software Package Data Exchange)

특징: 오픈소스 라이선스 정보를 투명하게 관리하기 위해 리눅스 재단(Linux Foundation) 주도로 만들어진 포맷입니다. (ISO/IEC 42056 국제 표준)
강점: 라이선스 호환성 검증과 법적/컴플라이언스 대응에 매우 강력합니다.

SPDX JSON 예시 보기

{
  "spdxVersion": "SPDX-2.3",
  "name": "my-application",
  "packages": [
    {
      "name": "log4j",
      "versionInfo": "2.14.1",
      "supplier": "Organization: Apache",
      "licenseDeclared": "Apache-2.0"
    }
  ]
}

2) CycloneDX

특징: 웹 애플리케이션 보안 전문 커뮤니티인 OWASP에서 만든 보안 역량 중심의 포맷입니다.
강점: 보안 취약점 스캐닝 및 소프트웨어 공급망 보호 모델 분석에 최적화되어 있습니다. 기존의 컴포넌트를 넘어 클라우드 서비스(SaaS), 머신러닝 모델(AI BOM) 등 최신 IT 환경으로 지원 영역을 빠르게 확장 중입니다.

CycloneDX JSON 예시 보기

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [
    {
      "type": "library",
      "name": "log4j",
      "version": "2.14.1",
      "purl": "pkg:maven/org.apache.logging.log4j/log4j@2.14.1"
    }
  ]
}

3) SWID (Software Identification Tags)

특징: ISO/IEC 19770-2 단말기 S/W 관리 표준 기반의 태그 형식입니다.
강점: 조직 내부의 소프트웨어 설치 현황 파악, 상용 보안 자산 관리(ITAM) 측면에 초점이 맞춰져 있습니다.

📊 SBOM 3대 포맷 비교 한눈에 보기

비교 항목	SPDX	CycloneDX	SWID
주도 기관	Linux Foundation	OWASP	ISO
핵심 강점	라이선스 추적 및 컴플라이언스 관리	보안 취약점 식별 및 공급망 분석	IT 시스템 자산 및 패키지 관리
주요 활용도	개발 파이프라인 및 오픈소스 정책 점검	DevSecOps 보안 진단 도구 연동	엔터프라이즈 데스크톱/서버 자산 추적

6. 대표적인 SBOM 생성 및 관리 도구

실제 프로젝트에 연결하여 SBOM을 자동으로 추출할 때 널리 쓰이는 유용한 도구들입니다.

Syft (by Anchore): 컨테이너 이미지 경로나 파일 시스템에서 가장 빠르고 정확하게 SBOM(SPDX, CycloneDX 포맷 모두 지원)을 추출해 내는 가장 유명한 오픈소스 CLI 도구입니다.
Trivy (by Aqua Security): 원래는 강력하고 빠른 보안 취약점 스캐너지만, 자체 SBOM 도출 기능도 매우 뛰어납니다.
CycloneDX CLI & 플러그인: (Maven, npm, 파이썬 PIP 등) 각 언어별 패키지 매니저 빌드 시스템에 직접 플러그인 형태로 붙여서, 빌드와 동시에 자연스럽게 SBOM을 생성할 수 있습니다.

[💡 Syft 실행 명령어 예시] 컨테이너 이미지(my-app:latest)를 스캔하여 SBOM을 CycloneDX JSON 포맷으로 생성하는 명령

syft my-app:latest -o cyclonedx-json > sbom.json

7. 현업 도입 시 고려사항 (Best Practice)

단순히 syft 명령어를 쳐서 SBOM JSON 파일을 한 번 만드는 것으로 보안이 완성되지 않습니다. 실용적으로 위험을 방어하려면 다음 과정이 설계되어야 합니다.

빌드 파이프라인(CI/CD) 내 자동화: 애플리케이션 코드가 수정되어 새롭게 빌드되고 배포될 때마다 자동으로 최신 상태의 SBOM 동기화가 이뤄져야 합니다.
취약점 DB(CVE) 연동 모니터링: 생성된 SBOM 리스트를 지속적으로 스캐닝하는 플랫폼(예: OWASP Dependency-Track)에 등록하여, 새로운 취약점이 떠오를 때마다 슬랙 알림을 받도록 구성해야 합니다.
무결성 검증 (서명 체계 연동): 제공받거나 유포하는 SBOM 데이터 파일 자체가 중간에 변조되지 않았음을 확인하기 위해, 시그스토어(Sigstore/Cosign) 등 암호화 무결성 서명 모델을 함께 적용하는 가장 안전한 옵션이 됩니다.

📌 한 줄 요약 및 마무리

"SBOM은 소프트웨어의 재료 명세서이며, 보안 대응의 골든타임을 확보하고 서비스의 무결성을 지키는 핵심 사이버 예방 백신입니다."

점점 더 복잡해지고 파편화되는 소프트웨어 스택 속에서, "우리가 어떤 부품을 가져다 쓰고 있는지 명확히 아는 것"이 보안 위협 관리의 첫걸음입니다. 아직 SBOM 인벤토리 관리를 경험해 보지 않으셨다면, 가장 작은 사이드 프로젝트에서 시작해 스캐너 도구를 한번 실행해 보는 것을 적극 추천해 드립니다!

#SBOM #보안 #IT보안