이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.

SBOM 개요

SBOM이 무엇이고 왜 필요한지, 소프트웨어 공급망 위협과 SBOM이 주는 이점을 정리합니다.

1: SBOM의 수준과 분류

SBOM이란 무엇인가

소프트웨어 자재 명세서(Software Bill of Materials, SBOM)는 한 소프트웨어 제품을 구성하는 모든 구성요소와 라이브러리, 그리고 그것들 사이의 의존 관계를 기계가 읽을 수 있는 형태로 나열한 목록입니다. 제조업의 부품표(Bill of Materials)를 소프트웨어로 옮긴 개념입니다. 완성차 한 대에 어떤 부품이 어느 공급사에서 들어왔는지 적은 명세서가 있듯, SBOM은 애플리케이션 하나에 어떤 오픈소스와 상용 구성요소가 어떤 버전으로 들어갔는지를 기록합니다.

현대 소프트웨어는 대부분 직접 작성한 코드보다 외부에서 가져온 구성요소로 채워집니다. 그 외부 구성요소에는 취약점이 있을 수 있고, 라이선스 의무가 따라붙으며, 또 그 구성요소가 다시 다른 구성요소에 의존합니다. SBOM은 이 의존성의 사슬을 가시화해, 보안과 라이선스 관리와 자산 관리가 공통으로 참조할 데이터 계층을 제공합니다.

왜 필요한가: 공급망 신뢰의 붕괴

SBOM을 정책 의제로 끌어올린 계기는 두 건의 공급망 사건이었습니다. 2020년 12월 드러난 솔라윈즈(SolarWinds) 사건에서 공격자는 오리온(Orion) 소프트웨어의 정상 업데이트 경로 자체를 오염시켰습니다. 그 업데이트를 신뢰하고 설치한 수많은 조직에 백도어가 함께 퍼졌습니다. 공급망 상류 한 곳의 침해가 하류 전체로 번지는 구조였습니다.

1년 뒤인 2021년 12월에는 자바 로깅 라이브러리 Log4j의 원격 코드 실행 취약점(CVE-2021-44228, 통칭 Log4Shell)이 공개되었습니다. 이 사건이 드러낸 문제는 침해 자체가 아니라 가시성의 부재였습니다. Log4j는 무수한 제품에 간접 의존성으로 깊숙이 박혀 있었던 탓에, 정작 “우리 제품 어디에 이 라이브러리가 들어 있는가"라는 질문에 즉답할 수 있는 조직이 드물었습니다. 모든 소프트웨어가 구성요소 목록을 기계가 읽을 수 있는 형태로 미리 갖추고 있었다면, 영향 범위 파악은 질의 한 번으로 끝났을 것입니다. 이 경험이 SBOM 의제에 직접적인 동력을 주었습니다.

이후 SBOM은 권고를 넘어 제도로 들어왔습니다. 미국은 2021년 행정명령 14028로 연방 납품 소프트웨어에 SBOM을 요구하는 길을 열었고, 유럽연합은 사이버 복원력법(Cyber Resilience Act, CRA)으로 SBOM 작성을 법적 의무로 규정했습니다. 자세한 규제 지형은 3. 규제 동향에서 다룹니다.

SBOM이 주는 이점

SBOM의 가치는 보안 한 가지에 그치지 않습니다. 구성요소 목록이라는 같은 데이터를 여러 용도가 함께 활용합니다.

취약점 관리와 사고 대응: 새 취약점이 공개되면 영향받는 구성요소를 즉시 조회해 대응 우선순위를 정할 수 있습니다.
공급망 위험 관리: 외부 구성요소의 출처와 신뢰도를 평가해 조달과 공급사 관리에 반영합니다.
라이선스 컴플라이언스: 각 구성요소의 라이선스를 추적해 의무 위반과 충돌을 미리 방지합니다.
규제 준수: 투명성 요건을 충족하고, 규제 보고와 감사에 필요한 증빙을 제공합니다.
자산 관리와 운영 효율: 무엇을 쓰고 있는지 정확히 알게 되어 수명주기 관리가 쉬워집니다.

누가 만들고 누가 쓰는가

SBOM의 가치는 한 조직이 홀로 만드는 데서 나오지 않고 공급망을 따라 흐를 때 실현됩니다. CISA의 Framing Software Component Transparency 3판은 SBOM을 둘러싼 행위자를 세 관점으로 정리합니다. 소프트웨어를 만드는 생산자(Produce), 어떤 소프트웨어를 쓸지 고르는 선택자(Choose), 그것을 운영하는 운영자(Operate)입니다. 한 조직이 세 역할을 겸하는 일이 흔합니다. 자사 제품을 개발하면서 외부 라이브러리를 도입하고 인프라를 운영하는 기업이 그렇습니다.

이 구도의 핵심은 공급자와 소비자 관계의 연쇄입니다. 상류의 생산자가 SBOM을 만들어 하류로 전달하면, 하류의 선택자는 그 SBOM으로 도입 전 위험을 평가하고, 운영자는 새 취약점이 공개되었을 때 영향 범위를 즉시 조회합니다. Log4Shell이 보여준 것은 바로 이 연쇄의 단절이었습니다. 생산자가 구성요소 목록을 넘기지 않았기에 운영자가 자신의 자산에 어떤 라이브러리가 들었는지 알 수 없었습니다.

행위자별로 이해는 미묘하게 어긋납니다. 소비자는 더 깊고 완전한 SBOM을 원하고, 생산자는 영업 비밀과 공격 표면 노출을 우려해 공개 범위를 줄이려 합니다. 규제가 의무의 최저선을 어디에 두는지, 공개 범위를 어떻게 조정하는지는 이 긴장을 푸는 장치입니다. 공유와 공개 범위 문제는 7. 공유와 거버넌스에서 다룹니다.

다음 절에서는 SBOM이 담는 정보의 깊이에 따른 수준과 분류를 살펴봅니다.

출처

이 절의 사실 근거는 본 가이드의 배경 조사 자료에 정리돼 있습니다. 행정명령 14028(86 FR 26633, 2021-05-12), CVE-2021-44228(NVD), CISA Framing Software Component Transparency 3판(2024-09-03)을 1차 출처로 삼았습니다. 전체 출처는 3. 규제 동향과 각 절 하단을 참고하십시오.

1 - SBOM의 수준과 분류

SBOM이 담는 정보의 깊이에 따른 수준과, 생성 시점에 따른 분류를 정리합니다.

SBOM이라고 다 같은 SBOM이 아닙니다. 얼마나 깊은 의존성까지 담는가에 따라 수준이 나뉘고, 소프트웨어 수명주기의 어느 시점에 만들었는가에 따라 분류가 갈립니다. 두 축을 구분해 두면 “어떤 SBOM을 요구하고 어떤 SBOM을 만들지"를 명확히 정할 수 있습니다.

정보의 깊이에 따른 수준

수준	설명
Top-Level SBOM	제품에 직접 통합되거나 사용되는 구성요소의 요약. 구성요소 이름, 버전 등 필수 정보를 담습니다.
Transitive SBOM	직접 의존성뿐 아니라 그 의존성이 다시 의존하는 간접(전이) 의존성까지 포함합니다.
n-Level SBOM	최상위 개요를 넘어 임의의 깊이(N단계)까지 계층적으로 정보를 담습니다.
Delivery SBOM	출시나 배포 패키지에 포함된 모든 구성요소와 라이브러리를 기술합니다.
Complete SBOM	시스템에 존재하는 모든 구성요소와 의존성, 메타데이터의 완전한 목록입니다.

조직은 하나의 수준만 고집할 필요가 없습니다. 소비자에게 전달하는 SBOM은 민감 정보를 빼고 보안 요구를 충족하는 수준으로 맞추되, 내부적으로는 완전한 수준의 SBOM을 유지해 취약점 업데이트를 추적하는 방식이 일반적입니다. 이렇게 하면 영업 비밀과 지식재산 노출 우려를 줄이면서도 공급망 투명성과 내부 복원력을 동시에 확보할 수 있습니다.

규제가 정한 의무의 최저선도 수준의 언어로 표현됩니다. EU 사이버 복원력법은 “최소한 제품의 최상위 의존성(top-level dependencies)을 포괄하는” SBOM을 요구합니다. 전체 의존성 트리를 끝까지 펼칠 의무는 아니지만, 그것이 권장 관행의 방향임은 분명합니다.

생성 시점에 따른 분류

미국 CISA의 Types of Software Bill of Materials (SBOM) 문서는 SBOM을 소프트웨어 개발 수명주기(Software Development Life Cycle, SDLC)의 단계에 맞춰 여섯 유형으로 구분합니다. 같은 제품이라도 어느 시점에 만들었는가에 따라 담기는 정보와 정확도가 달라집니다.

flowchart TD
    A["Design SBOM<br/>설계 단계<br/>계획된 구성요소를 기록"] --> B["Source SBOM<br/>개발 환경<br/>소스 파일과 의존성"]
    B --> C["Build SBOM<br/>빌드 과정<br/>소스·의존성·사전빌드 구성요소"]
    C --> D["Analyzed SBOM<br/>빌드 후 산출물 검사<br/>최종 결과물 분석"]
    D --> E["Deployed SBOM<br/>설치·구성 시점<br/>배포 환경 반영"]
    E --> F["Runtime SBOM<br/>실행 중 모니터링<br/>동적 로드 의존성 포함"]

그림 1. SDLC 단계에 따른 SBOM 분류 (출처: CISA Types of Software Bill of Materials (SBOM), 2023)

Design SBOM: 구성요소가 실제로 존재하기 전 설계 단계에서 계획된 구성요소를 기록합니다.
Source SBOM: 개발 환경을 반영하며 소스 파일과 의존성을 담습니다.
Build SBOM: 빌드 과정에서 생성되며 소스, 의존성, 사전 빌드된 구성요소 정보를 포함합니다.
Analyzed SBOM: 빌드 후 최종 산출물을 검사해 생성합니다.
Deployed SBOM: 특정 시스템에 설치·구성된 소프트웨어 목록으로, 배포 환경을 함께 고려합니다.
Runtime SBOM: 실행 중인 구성요소를 모니터링해, 동적으로 로드되는 의존성과 외부 상호작용까지 담습니다.

빌드 시점에 생성하는 Build SBOM이 정확도와 자동화 면에서 가장 널리 권장됩니다. 빌드 도구가 실제로 무엇을 묶었는지를 그대로 기록하기 때문입니다. 생성 시점과 자동화는 5. 도구와 자동화에서 자세히 다룹니다.

출처

CISA (2023). Types of Software Bill of Materials (SBOM). https://www.cisa.gov/resources-tools/resources/types-software-bill-materials-sbom (접속: 2026-06-14). 여섯 SBOM 유형(Design, Source, Build, Analyzed, Deployed, Runtime) 분류의 1차 근거입니다. 속성과 성숙도 단계는 CISA (2024). Framing Software Component Transparency, Third Edition. https://www.cisa.gov/resources-tools/resources/framing-software-component-transparency-2024. EU 사이버 복원력법의 최상위 의존성 요건은 Regulation (EU) 2024/2847, Annex I Part II(1)에 근거합니다.