SBOM(Software Bill of Materials) 실무 가이드

• 1: SBOM 개요
• 1.1: SBOM의 수준과 분류
• 2: 표준과 형식
• 2.1: SBOM의 최소 요소
• 2.2: 식별자와 라이선스
• 3: 규제 동향
• 3.1: EU 사이버 복원력법(CRA)
• 3.2: 인도·한국 등 기타 관할권
• 4: 도입 로드맵
• 5: 도구와 자동화
• 6: 취약점 관리와 VEX
• 7: 공유와 거버넌스
• 8: 권장사항과 체크리스트

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.1 - SBOM의 수준과 분류

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

정보의 깊이에 따른 수준

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

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

생성 시점에 따른 분류

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

그림 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)에 근거합니다.

2 - 표준과 형식

SBOM이 기계 판독성을 요구하는 이상 표준 형식이 필요합니다. 미국 NTIA 최소 요소가 명시한 세 형식 가운데 실무를 양분하는 것은 SPDX와 CycloneDX입니다. 세 번째인 SWID 태그는 주로 자산 관리에서 쓰이며, 식별자로서의 역할은 식별자와 라이선스에서 다룹니다.

SPDX

SPDX(System Package Data Exchange)는 리눅스 재단(Linux Foundation) 산하 프로젝트입니다. 버전 2.2.1이 2021년 8월 ISO/IEC 5962:2021로 국제 표준이 되었습니다. 현행 ISO 표준이 가리키는 것은 어디까지나 2.2.1 버전이라는 점을 유의해야 합니다.

리눅스 재단은 2024년 4월 16일 SPDX 3.0을 발표하며 용도별 프로파일(Profile) 구조를 도입했습니다. 핵심 모델 위에 보안(Security), 빌드(Build), 데이터셋(Dataset), 인공지능(AI) 프로파일을 얹는 방식입니다. AI 프로파일은 모델 학습과 특성화 정보를, 데이터셋 프로파일은 데이터의 출처와 라이선스를, 보안 프로파일은 취약점의 식별과 심각도, 악용 가능성, 완화 계획을 담습니다. 같은 해 12월에는 패치 릴리스 3.0.1이 나왔습니다. SPDX 3.x의 ISO 재표준화 진행 여부는 2026년 6월 기준 확인되지 않았습니다.

CycloneDX

CycloneDX는 OWASP(Open Worldwide Application Security Project)에서 출발한 풀스택 BOM 표준입니다. 취약점 악용 가능성 교환(Vulnerability Exploitability eXchange, VEX)을 형식 안에서 네이티브로 지원하는 점이 특징입니다. 국제 표준화는 Ecma International의 기술위원회 TC54를 통해 이루어졌습니다. v1.6이 2024년 6월 ECMA-424 1판으로 발행되며 암호 자재 명세서(Cryptographic Bill of Materials, CBOM)와 증명(CycloneDX Attestations)을 더했고, v1.7이 2025년 10월 발표돼 2025년 12월 ECMA-424 2판으로 표준화되었습니다. v1.7은 사후양자 암호 대비, 구조화된 인용, 특허 객체 지원을 추가했습니다.

CycloneDX는 한 형식으로 소프트웨어(SBOM), 하드웨어(HBOM), 서비스(SaaSBOM), 머신러닝 모델(ML-BOM)을 모두 표현할 수 있습니다.

두 형식 비교

표 1. SBOM 양대 표준 형식 비교 (출처: ISO/IEC 5962:2021, Linux Foundation 2024, Ecma International ECMA-424. 수집일 2026-06-14)

두 표준은 설계 철학이 다릅니다. SPDX는 프로파일 방식으로 적용 범위를 넓히고, CycloneDX는 구성요소 타입과 부속 객체로 표현합니다. 그러나 둘 다 구성요소의 식별, 라이선스, 의존 관계를 담는다는 점에서 같은 문제를 겨냥합니다. 어느 쪽을 택하든 두 형식 사이의 변환 도구가 있으므로, 거래 상대가 요구하는 형식과 자사 도구 체인이 잘 지원하는 형식을 기준으로 고르면 됩니다. 라이선스 컴플라이언스 중심이면 SPDX가, 취약점 운영 중심이면 CycloneDX가 익숙한 출발점입니다.

다음으로 형식 안에 무엇을 반드시 담아야 하는지를 정한 최소 요소와, 구성요소를 일관되게 가리키는 식별자와 라이선스를 살펴봅니다.

출처

ISO/IEC (2021). ISO/IEC 5962:2021 — SPDX Specification V2.2.1. The Linux Foundation (2024). SPDX 3.0 Release. https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases. Ecma International. ECMA-424 — CycloneDX Bill of Materials Specification. https://ecma-international.org/publications-and-standards/standards/ecma-424/. CycloneDX (2025). CycloneDX v1.7 Released. https://cyclonedx.org/news/cyclonedx-v1.7-released/. (모두 접속: 2026-06-14)

2.1 - SBOM의 최소 요소

형식을 정했다면 그 형식 안에 무엇을 반드시 담아야 하는지가 다음 질문입니다. 이 최저선을 정의한 문서가 미국의 최소 요소(Minimum Elements) 계열입니다. 권고이긴 하지만 연방 조달의 사실상 기준이고, EU와 다른 관할권의 SBOM 요건도 대체로 이 골격을 참조합니다.

계보: NTIA 2021에서 CISA 2025로

미국 통신정보청(National Telecommunications and Information Administration, NTIA)은 행정명령 14028의 위임에 따라 2021년 7월 *The Minimum Elements For a Software Bill of Materials (SBOM)*를 발행했습니다. 이 문서는 최소 요소를 세 범주로 정리했습니다. 구성요소별로 추적할 데이터 필드, 기계 판독 형식을 요구하는 자동화 지원, 그리고 생성 빈도와 깊이 등을 다루는 관행과 프로세스입니다.

이후 커뮤니티 작업의 주관은 사이버보안·인프라보안국(Cybersecurity and Infrastructure Security Agency, CISA)으로 옮겨갔고, 두 갈래의 개정이 나왔습니다. 하나는 속성을 정의하는 참조 문서인 Framing Software Component Transparency의 3판(2024-09)으로, 기준 속성에 라이선스(License)와 저작권 고지(Copyright Notice)를 추가했습니다. 다른 하나는 최소 요소 문서 자체의 개정으로, CISA는 2025년 8월 2025 Minimum Elements for a Software Bill of Materials를 공개 의견수렴 초안으로 내놓았고 의견수렴은 2025년 10월 3일 마감됐습니다. 2026년 6월 기준 이 개정안은 아직 초안 상태이며 최종본 발표일은 확인되지 않았습니다.

NTIA 2021의 데이터 필드와 세 범주

NTIA 2021 최소 요소가 정한 구성요소별 데이터 필드는 일곱 개입니다.

세 범주는 다음과 같습니다.

• 데이터 필드: 위 일곱 항목으로, 구성요소를 추적·식별하기 위한 기본 정보입니다.
• 자동화 지원: 자동 생성과 기계 판독성을 위한 표준 형식으로 SPDX, CycloneDX, SWID를 명시했습니다.
• 관행과 프로세스: 생성 빈도, 깊이, 알려진 미상(known unknowns)의 처리, 배포와 전달, 접근 통제, 오류 수용 방식을 다룹니다.

CISA 2025 초안이 더한 것

CISA 2025 최소 요소 초안은 도구가 성숙한 현실을 반영해 데이터 필드를 늘렸습니다. 신규로 추가된 핵심 요소는 네 가지입니다.

기존 항목도 손질했습니다. SBOM 작성자(SBOM Author)와 소프트웨어 생산자(Software Producer)의 역할을 구분하고, “기타 고유 식별자"를 “소프트웨어 식별자(Software Identifiers)“로 갱신했으며, 별도였던 접근 통제 요소는 배포·전달 항목으로 통합했습니다. 라이선스가 Framing 3판에서 기준 속성으로 들어오고 2025 초안에서 데이터 필드로 굳어진 흐름은, SBOM이 보안 인벤토리를 넘어 오픈소스 라이선스 컴플라이언스의 1차 데이터로 자리 잡고 있음을 보여줍니다. 도구명과 생성 맥락, 해시가 함께 들어온 배경에는 “신뢰할 수 없는 도구가 만든 SBOM은 신뢰할 수 없다"는 문제의식이 있습니다. 도구 무결성은 5. 도구와 자동화에서 다룹니다.

실무 권고

최소 요소는 말 그대로 최저선입니다. 조직은 자사 용도에 맞춰 필드를 더할 수 있고, 더해야 합니다. 취약점 식별을 위해 CVE 참조와 패치 상태를, 라이선스 관리를 위해 SPDX 라이선스 식별자와 저작권 고지를, 수명주기 관리를 위해 출시일과 지원 종료(End-of-Life) 일자를 함께 담아 두면 SBOM 하나로 여러 운영 질문에 답할 수 있습니다. 새로 SBOM을 도입한다면 NTIA 일곱 필드를 기본으로 하되 CISA 2025 초안의 네 신규 필드, 특히 해시와 라이선스를 처음부터 포함하는 편이 나중에 다시 만드는 수고를 줄입니다.

출처

NTIA (2021). The Minimum Elements For a Software Bill of Materials (SBOM). https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf. CISA (2024). Framing Software Component Transparency, Third Edition. https://www.cisa.gov/resources-tools/resources/framing-software-component-transparency-2024. CISA (2025). 2025 Minimum Elements for a Software Bill of Materials (SBOM) (공개 의견수렴 초안). https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom. (모두 접속: 2026-06-14)

2.2 - 식별자와 라이선스

같은 구성요소를 두고 SBOM마다 이름을 다르게 적으면 자동 대조가 무너집니다. “Apache Tomcat"과 “tomcat”, “Apache Software Foundation Tomcat"이 같은 것인지 기계가 알 길이 없기 때문입니다. 그래서 구성요소를 일관되게 가리키는 식별자 체계와, 라이선스를 표준 코드로 표기하는 규약이 필요합니다.

세 가지 식별자: PURL, CPE, SWID

실무에서 함께 쓰이는 세 식별자는 역할이 갈립니다. 배타적이지 않으므로, 가능하면 함께 기재하는 것이 권장됩니다.

표 1. SBOM에서 함께 쓰이는 식별자 (출처: purl-spec, NIST NVD, ISO/IEC 19770-2. 수집일 2026-06-14)

패키지 URL은 다음과 같은 형식으로 패키지 관리자 생태계 안의 구성요소를 가리킵니다.

pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1
pkg:npm/lodash@4.17.21
pkg:pypi/requests@2.31.0

pkg: 뒤에 생태계 유형(maven, npm, pypi 등), 네임스페이스, 이름, 버전이 이어집니다. 같은 구성요소를 어디서나 같은 문자열로 가리킬 수 있어, 취약점 데이터베이스나 라이선스 데이터베이스와 자동으로 연결됩니다.

CPE는 2000년대 중반 MITRE가 개발해 현재 NIST가 운영합니다. 제품을 정해진 이름 규칙으로 표기해, 그 제품에 해당하는 취약점(CVE)을 조회하는 데 쓰입니다. SWID는 ISO/IEC 19770-2로 표준화된 태그 형식으로 제품과 버전, 생산·배포 주체를 구조화해 기술하며 자산 관리에서 주로 활용됩니다. CISA 2025 최소 요소 초안이 “기타 고유 식별자"를 “소프트웨어 식별자"로 갱신한 것도 이 식별자 생태계의 성숙을 반영합니다.

라이선스 표기: SPDX 라이선스 식별자

라이선스 관리는 SBOM의 초기 활용처 가운데 하나입니다. 각 구성요소가 어떤 라이선스로 배포되는지를 정확히 기록해야 의무 위반과 충돌을 미리 막을 수 있습니다. 자유 서술로 적으면 대조가 안 되므로, 표준 코드를 씁니다.

SPDX 라이선스 식별자는 각 라이선스에 Apache-2.0, MIT, GPL-3.0-only 같은 고유 코드를 부여합니다. 여러 라이선스가 함께 적용될 때는 라이선스 표현식(license expression)으로 조합합니다.

Apache-2.0 OR MIT
GPL-2.0-only WITH Classpath-exception-2.0
(MIT AND BSD-3-Clause)

OR는 선택 가능한 복수 라이선스, AND는 동시에 적용되는 복수 라이선스, WITH는 예외 조항과의 결합을 나타냅니다.

실무에서 지켜야 할 원칙은 다음과 같습니다.

• 제품 전체의 라이선스뿐 아니라 모든 개별 구성요소의 라이선스를 함께 볼 수 있어야 합니다.
• 표준 목록에 없는 라이선스를 만나면 출처를 나타내는 접두사를 붙인 식별자(예: LicenseRef- 접두사)를 부여해 추적합니다.
• 라이선스 텍스트를 사소하게 수정했더라도 의미가 크게 달라지지 않으면 원본과 같은 식별자를 씁니다.
• 라이선스의 호환성을 분석해, 서로 다른 라이선스의 구성요소를 결합할 때 생길 충돌을 미리 식별합니다.

라이선스 필드가 도구로 자동 추출되더라도 그 정확도는 별개의 문제입니다. 비표준 라이선스의 정확한 식별, 듀얼 라이선스 처리, 행동 사용 제한이 붙은 라이선스의 준수 여부는 여전히 사람과 정책의 몫입니다. 자동화의 경계는 5. 도구와 자동화에서 다룹니다.

출처

Package URL 명세 https://github.com/package-url/purl-spec. NIST. Common Platform Enumeration (CPE) https://nvd.nist.gov/products/cpe. ISO/IEC 19770-2:2015. SPDX License List https://spdx.org/licenses/. SPDX License Expressions https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/. (모두 접속: 2026-06-14)

3 - 규제 동향

SBOM을 둘러싼 규제는 관할권마다 위상이 다릅니다. 미국은 연방 조달을 지렛대로 삼는 행정명령 경로, 유럽연합은 직접 효력을 갖는 법률 경로, 그 밖의 국가들은 대체로 권고 가이드라인 단계에 있습니다. 이 절에서는 미국을 먼저 다루고, EU 사이버 복원력법과 인도·한국 등 기타 관할권을 이어서 다룹니다.

관할권별 위상 한눈에 보기

표 1. 주요 관할권의 SBOM 규제 위상 (출처: 각 항목 1차 출처. 수집일 2026-06-14)

미국: 연방 조달을 지렛대로

미국의 SBOM 정책은 행정명령에서 출발합니다. 솔라윈즈 사건 직후인 2021년 5월 12일, 행정명령 14028(“Improving the Nation’s Cybersecurity”)이 서명되어 연방관보 86 FR 26633으로 공포되었습니다. 이 명령의 Section 10(j)는 SBOM을 “소프트웨어를 만드는 데 사용된 다양한 구성요소의 세부 정보와 공급망 관계를 담은 공식 기록"으로 정의했고, Section 4(f)는 상무부 장관이 NTIA와 협조해 60일 이내에 SBOM 최소 요소를 발행하도록 지시했습니다. SBOM이 연구 공동체의 권고에서 연방 조달의 요건 후보로 격상된 순간입니다.

이 위임에 따라 NTIA가 2021년 7월 최소 요소를 발행했고, 이후 작업 주관은 CISA로 옮겨갔습니다. CISA는 행정관리예산국(Office of Management and Budget, OMB) 메모 M-22-18에 따라 NTIA 최소 요소를 갱신할 권한을 갖고, 도구화와 운영화에 초점을 두고 있습니다. 그 결과가 2024년 Framing Software Component Transparency 3판과 2025년 최소 요소 개정 초안입니다. 두 문서의 데이터 필드 변화는 최소 요소에서 다룹니다.

미국 경로의 성격을 정확히 이해하는 것이 중요합니다. 행정명령 14028은 연방정부에 소프트웨어를 공급하는 사업자에게 SBOM 제공을 요구하는 지침의 근거이지, 모든 소프트웨어에 적용되는 일반 법령이 아닙니다. CISA의 두 문서도 스스로 새로운 연방 요건을 창설하지 않는다고 밝힙니다. 규범의 위상은 여전히 조달 기준과 기술 참조에 머물러 있습니다. 그럼에도 연방 조달이라는 거대한 시장이 작동하는 탓에, 미국에 소프트웨어를 납품하는 기업에는 사실상의 요건으로 기능합니다.

그림 1. 미국 SBOM 정책 문서의 계보 (출처: 행정명령 14028, NTIA 2021, CISA 2024·2025. 수집일 2026-06-14)

출처

The White House (2021). Executive Order 14028 — Improving the Nation’s Cybersecurity, 86 FR 26633. https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity. OMB (2022). M-22-18. https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf. CISA SBOM 자료 허브 https://www.cisa.gov/sbom. (모두 접속: 2026-06-14)

3.1 - EU 사이버 복원력법(CRA)

SBOM을 명시적 법적 의무로 규정한 최초의 주요 입법이 EU 사이버 복원력법(Cyber Resilience Act, CRA, Regulation (EU) 2024/2847)입니다. 미국이 연방 조달이라는 시장을 통해 SBOM을 사실상 강제하는 데 비해, CRA는 디지털 요소를 갖춘 제품 전반에 수평적으로 적용되는 직접 효력 법률입니다.

SBOM 의무의 법적 위치

CRA에서 SBOM 의무는 Annex I Part II(취약점 처리 요건) 제(1)항에 있습니다. 제조자는 제품에 포함된 취약점과 구성요소를 식별·문서화해야 하며, 그 수단으로 “통용되는 기계 판독 가능 형식의, 최소한 제품의 최상위 의존성(top-level dependencies)을 포괄하는 소프트웨어 자재 명세서를 작성"할 것을 명시합니다.

실무에서 중요한 두 가지가 미국 경로와 다릅니다.

• 의무 범위가 최상위 의존성이다: 전체 의존성 트리를 끝까지 펼칠 의무가 아니라, 최소한 최상위 의존성을 포괄하면 됩니다. 다만 그 이상으로 깊이 작성하는 것이 권장 방향임은 분명합니다.
• 공개 의무가 아니라 보관·제출 의무다: SBOM을 일반 공중에 공개할 의무는 없습니다. 시장 감시 당국(market surveillance authority)이 이유를 제시해 요청할 때 제출할 수 있도록 보관하면 됩니다.

SBOM 작성이 권고가 아니라 과징금 체계를 갖춘 법적 의무라는 점이 CRA의 핵심입니다.

시행 일정

그림 1. EU CRA 단계적 시행 일정 (출처: Regulation (EU) 2024/2847. 수집일 2026-06-14)

CRA는 2024년 11월 20일 관보에 게재되어 2024년 12월 10일 발효했습니다. 적용은 단계적입니다. Article 14의 악용 취약점과 중대 사고 보고 의무가 2026년 9월 11일부터, SBOM을 포함한 본질적 사이버보안 요건의 전면 적용이 2027년 12월 11일부터입니다.

형식 시행규칙의 부재와 실무 참조점

CRA 차원의 공식 SBOM 형식 시행규칙은 2026년 6월 현재 발표되지 않았습니다. 어떤 스키마와 필드를 써야 CRA에 정합하는지를 EU 전역 구속 규범으로 정한 문서는 아직 없다는 뜻입니다.

현재 실무의 참조점은 독일 연방정보보안청(Bundesamt für Sicherheit in der Informationstechnik, BSI)이 2025년 8월 발간한 기술 가이드라인 TR-03183-2 v2.1.0입니다. 이 문서는 CycloneDX와 SPDX 양쪽에 대해 CRA 정합 SBOM의 구체적 필드 매핑을 제공합니다. 다만 이는 독일 가이드라인이지 EU 전역의 구속력 있는 규범은 아니라는 점에 유의해야 합니다.

오픈소스에 대한 고려

CRA는 상업적 활동을 적용 기준으로 삼아, 상업 활동 없이 무상으로 배포되는 비상업 오픈소스를 원칙적으로 제외합니다. 오픈소스 유지보수자에게 제조자 수준의 의무를 그대로 지우지 않으려는 장치입니다. 다만 오픈소스를 제품에 통합해 상업적으로 공급하는 제조자에게는 의무가 그대로 적용되므로, 오픈소스 구성요소의 SBOM을 확보하고 관리하는 일은 여전히 제조자의 몫입니다.

출처

European Parliament and Council (2024). Regulation (EU) 2024/2847 — Cyber Resilience Act. OJ L, 2024/2847, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng. European Commission, DG CNECT. Cyber Resilience Act. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act. BSI. Technical Guideline TR-03183-2. (모두 접속: 2026-06-14)

3.2 - 인도·한국 등 기타 관할권

미국과 유럽연합 밖의 관할권은 대체로 권고 단계에 있습니다. 법적 강제나 제재는 없으나, 조달과 계약 관행에 영향을 주는 모범 사례로 기능합니다.

인도: CERT-In 기술 가이드라인

인도 침해사고대응팀(Indian Computer Emergency Response Team, CERT-In)은 *Technical Guidelines on Software Bill of Materials (SBOM)*를 발행했습니다. 정부기관, 공공부문, 필수 서비스, 소프트웨어 생산·서비스 기업을 대상으로 한 자발적(voluntary) 가이드라인으로, SBOM의 가치와 모범 사례, 최소 요소, 취약점 추적 절차를 다룹니다. 법적 강제력은 없지만 정부 조달과 계약 관행에 영향을 줍니다.

CERT-In은 2025년 7월 이 가이드라인을 양자 BOM(QBOM), 암호 BOM(CBOM), AI BOM(AIBOM), 하드웨어 BOM(HBOM)까지 포괄하도록 확장했습니다. 자재 명세서 개념이 소프트웨어를 넘어 암호와 AI, 하드웨어로 번지는 흐름을 보여주는 사례입니다. AI BOM으로의 확장은 5. 도구와 자동화와 별도 가이드인 AI SBOM 컴플라이언스 가이드에서 더 다룹니다.

이 가이드의 초판이 바로 이 CERT-In 문서의 한국어 번역에서 출발했습니다. 현재 판은 그 골격을 미국과 유럽연합의 현행 1차 출처로 갱신하고 범용 실무 관점으로 넓힌 것입니다.

한국: SW 공급망 보안 가이드라인

한국은 과학기술정보통신부와 국가정보원, 한국인터넷진흥원(KISA) 등이 2024년 5월 SW 공급망 보안 가이드라인 1.0을 발표했습니다. SBOM 생성과 취약점 점검 절차, 미국 국립표준기술연구소(NIST)의 안전한 소프트웨어 개발 프레임워크(Secure Software Development Framework, SSDF) 활용을 권고하는 내용입니다.

다만 이는 행정 가이드라인 수준이며, EU 사이버 복원력법처럼 제조물 차원의 강제 보고 의무를 부과하는 법령은 현행 한국 법체계에 아직 없습니다. 그럼에도 EU와 미국에 소프트웨어를 수출하는 한국 기업은 해당 시장의 요건을 직접 충족해야 하므로, SBOM 역량 확보는 국내 규제와 무관하게 실질적 필요입니다.

실무 시사점

관할권마다 위상은 다르지만 요구하는 데이터의 골격은 수렴합니다. 한 번 잘 만든 SBOM 체계는 여러 관할권의 요건을 함께 충족할 수 있습니다. 수출 대상 시장 가운데 가장 엄격한 요건(현재로서는 EU CRA)을 기준으로 체계를 설계하면, 다른 관할권의 권고는 대체로 그 안에 포섭됩니다.

출처

Indian Computer Emergency Response Team (CERT-In). Technical Guidelines on Software Bill of Materials (SBOM), CIGU-2024-0002. https://www.cert-in.org.in/. 과학기술정보통신부·국가정보원·한국인터넷진흥원 (2024). SW 공급망 보안 가이드라인 1.0. https://www.kisa.or.kr/. (모두 접속: 2026-06-14)

4 - 도입 로드맵

조직에 SBOM 체계를 들이는 일은 한 번에 끝나지 않습니다. 기반을 세우고(기초), 생성과 통합을 정착시키고(발전), 운영을 성숙시키는(확장) 단계적 접근이 현실적입니다. 아래 단계 구분은 미국 NTIA와 인도 CERT-In 가이드라인이 공통으로 제시하는 골격이며, 활동의 순서는 예시일 뿐 조직의 보안 요구와 일정, 자원에 맞춰 조정할 수 있습니다.

그림 1. SBOM 도입 3단계 (출처: NTIA 2021, CERT-In 기술 가이드라인 재구성. 수집일 2026-06-14)

1단계: 기초 다지기

첫 SBOM은 대개 조달 과정에서 공급사로부터 받게 됩니다. 이 단계의 목적은 조직 안에서 SBOM을 다루는 방법 자체를 수립하는 것입니다.

• 중요 자산 식별과 계획 수립: 역할과 책임, 일정, 자원 요구를 정의하는 계획을 세우고, 새 프로세스에 대한 이해관계자의 동의를 얻습니다.
• 형식과 최소 요구사항 결정: SBOM을 만들기 전에 형식(SPDX 또는 CycloneDX)과 최소 데이터 요구를 정합니다. 공급망 전반에서 일관되게 처리할 표준 구조를 보장하기 위해서입니다.
• 보안 요구와 저장소·도구 식별: 분류와 처리 절차를 정하고, SBOM을 위한 안전한 저장소를 마련합니다.
• 조달 과정에서 SBOM 확보: 구매 주문서나 계약서에 공급사의 SBOM 제공 요구를 명시하고, 어떤 요소를 언제 어떤 방법으로 제공할지를 지정합니다.

2단계: 생성과 통합

이 단계는 안전한 구성 관리를 확립하고, 고유 식별자로 구성요소를 일관되게 가리키며, 생성 자체를 개발 과정에 녹여 넣는 활동입니다.

• 고유 식별자 부여: 공급사나 구성요소의 이름이 바뀌거나 같은 이름으로 다른 버전이 나와도 추적이 끊기지 않도록, PURL 같은 식별자로 각 구성요소를 고정합니다.
• 공급사 SBOM과 내부 SBOM 매핑: 공급사가 제공한 SBOM을 기반으로 내부 SBOM을 작성하고, 작성자와 타임스탬프를 남겨 무결성과 갱신 이력을 관리합니다.
• SSDLC와 CI/CD 통합: 안전한 소프트웨어 개발 수명주기(Secure Software Development Life Cycle, SSDLC)와 지속적 통합·배포(CI/CD) 파이프라인에 SBOM 생성을 통합합니다. 빌드 시점에 자동으로 생성하면 정확도와 적시성이 함께 올라갑니다. 도구 선택은 5. 도구와 자동화를 참고하십시오.
• 안전한 구성 관리: 접근 통제와 암호화, 정기 감사를 적용해 SBOM을 안전하게 관리합니다.

3단계: 운영 성숙과 확장

마지막 단계는 SBOM을 취약점 관리와 사고 대응에 본격적으로 엮고, 체계를 지속적으로 갱신하는 활동입니다.

• 취약점 추적 강화: SBOM의 구성요소를 취약점 데이터베이스와 상호 참조해 영향과 완화 조치를 평가하는 절차를 갖춥니다. 자세한 방법은 6. 취약점 관리에서 다룹니다.
• 사고 대응 통합: 새로 공개된 취약점에 대해 조직이 취약한지, 이미 침해됐는지를 SBOM으로 신속히 판단하는 절차를 마련합니다.
• 정기 검토와 인식 유지: 구성요소와 의존성이 최신 기록과 일치하는지 주기적으로 점검하고, 새 형식과 데이터 요소, 산업 동향에 대한 조직의 인식을 유지합니다.

출발점 정하기

세 단계를 순서대로 밟되, 처음부터 완벽을 노릴 필요는 없습니다. 가장 중요한 제품 한두 개를 골라 빌드 파이프라인에서 SBOM을 자동 생성하고, 그것을 취약점 스캐너에 물려 보는 것이 현실적인 첫걸음입니다. 체계가 한 제품에서 작동하는 것을 확인한 뒤 포트폴리오 전체로 넓히면, 시행착오의 비용을 줄일 수 있습니다.

출처

NTIA (2021). The Minimum Elements For a Software Bill of Materials (SBOM). CERT-In. Technical Guidelines on Software Bill of Materials (SBOM). CISA SBOM 자료 허브 https://www.cisa.gov/sbom. (모두 접속: 2026-06-14)

5 - 도구와 자동화

SBOM 워크플로우는 단일 도구로 완결되지 않습니다. 생성, 취약점 대조, 수명주기 관리의 세 역량이 서로 다른 도구로 나뉘며, 어느 하나도 세 영역을 완벽히 덮지 못한다는 것이 최근 도구 비교 분석의 공통 결론입니다. 도구를 조합해 파이프라인을 구성한다고 보는 편이 정확합니다.

생성·관리·스캔의 분업

그림 1. SBOM 도구의 세 역할 (출처: 도구 비교 분석 정리, 2026-01. 수집일 2026-06-14)

생성 영역에서는 Anchore의 Syft가 “SBOM 생성 한 가지를 가장 잘하는 전용 도구"로 평가받습니다. 서명 도구 cosign과 결합한 증명(attestation) 워크플로우가 성숙해 있습니다. OWASP CycloneDX의 cdxgen은 다중 언어와 컨테이너 이미지를 폭넓게 지원하고, AI BOM 전용 모드를 갖춘 점이 특징입니다.

관리 영역에서는 OWASP Dependency-Track이 조직 전체 애플리케이션 포트폴리오의 구성요소 사용 현황과 보안·라이선스 컴플라이언스를 모니터링하는 플랫폼으로 자리 잡았습니다. 라이선스 컴플라이언스 중심의 또 다른 선택지로 Eclipse SW360이 있습니다.

스캔 영역에서는 Grype가 SBOM을 입력으로 받아 취약점을 대조하고, Aqua Security의 Trivy가 스캐너이면서 SBOM 생성도 겸합니다.

표 1. SBOM 도구의 역할별 분류 (출처: 도구 비교 분석 정리, 2026-01. 수집일 2026-06-14)

자동화는 어디까지 되는가

자동화가 잘 되는 영역과 사람이 채워야 하는 영역을 정직하게 구분하는 것이 중요합니다.

표 2. SBOM 작업의 자동화 성숙도 (출처: 도구 비교 분석 정리. 수집일 2026-06-14)

생성은 도구가 잘합니다. 빌드 파이프라인에 Syft나 cdxgen을 넣으면 구성요소 목록은 자동으로 채워집니다. 그러나 생성된 SBOM의 라이선스 필드가 정확한지, 비표준 라이선스의 의무를 지키는지, 다운스트림으로 의무가 전파되며 누락되지 않았는지는 도구가 자동으로 보장하지 못합니다. 이 영역은 정책과 사람의 검토로 메웁니다.

도구 자체가 공격 표면이다

자동화 도구를 신뢰하기 전에 도구 자체의 무결성을 확인해야 합니다. 2026년 1월, 한 SBOM 도구가 짧은 기간에 두 차례 공급망 공격에 연루돼 하위 프로젝트로 피해가 번진 사례가 보고됐습니다. 이를 근거로 일부 파이프라인 운영자가 해당 도구를 제거하기도 했습니다.

SBOM 생성 도구 자체가 공급망 위험의 대상이 된다는 사실은, 생성과 검증 단계에서 해시와 서명, 증명을 결합할 것을 요구합니다. CISA 2025 최소 요소 초안이 도구명과 생성 맥락, 구성요소 해시를 신규 필드로 넣은 배경에도 이 문제의식이 있습니다. “신뢰할 수 없는 도구가 만든 SBOM은 신뢰할 수 없다"는 역설을 피하려면, 도구 버전을 고정하고 출처를 검증하며 생성물에 서명하는 절차가 필요합니다.

출처

Anchore. Syft https://github.com/anchore/syft, Grype https://github.com/anchore/grype. OWASP. cdxgen https://github.com/CycloneDX/cdxgen, Dependency-Track https://dependencytrack.org/. Aqua Security. Trivy https://github.com/aquasecurity/trivy. Eclipse SW360 https://www.eclipse.org/sw360/. (모두 접속: 2026-06-14)

6 - 취약점 관리와 VEX

SBOM의 가장 직접적인 활용처가 취약점 관리입니다. 구성요소 목록이 있으면 새 취약점이 공개될 때 영향받는 자산을 즉시 조회할 수 있습니다. 그러나 SBOM에 구성요소를 나열하면 그 구성요소의 과거 CVE가 모두 따라붙어 오탐(false positive)이 폭증한다는 문제가 생깁니다. 이 문제를 푸는 것이 취약점 악용성 교환(Vulnerability Exploitability eXchange, VEX)입니다.

SBOM 기반 취약점 추적

추적의 기본 흐름은 간단합니다. SBOM의 각 구성요소를 PURL이나 CPE 같은 식별자로 취약점 데이터베이스(NVD, CVE)와 대조해, 알려진 취약점을 매핑합니다. 공급사는 SBOM에 취약점 정보를 미리 매핑해 향상된 SBOM을 고객에게 제공할 수 있고, 소비자는 API나 데이터 피드로 자체 SBOM을 취약점 데이터와 연결해 대응 우선순위를 정합니다.

효과를 높이려면 개발 초기로 점검을 앞당기는 시프트 레프트(shift-left) 접근이 권장됩니다. 보안 도구를 개발 파이프라인에 통합해, 빌드와 패키징 같은 이른 단계에서 SBOM 데이터를 자동 분석하면 취약점을 출시 전에 잡을 수 있습니다.

VEX: 악용 가능성을 가려낸다

VEX는 제조자가 “이 취약점이 우리 제품에서 실제로 악용 가능한가"를 단언해 소비자의 우선순위 판단을 돕는 문서입니다. SBOM이 “무엇이 들어 있는가"를 답한다면, VEX는 “그 안의 알려진 취약점이 이 제품에서 영향을 주는가"를 답합니다. 구성요소에 취약점이 있더라도 해당 코드 경로가 호출되지 않으면 악용 불가능할 수 있는데, 이때 VEX가 그 상태를 명시해 불필요한 대응을 줄입니다.

VEX 문서는 특정 제품의 취약점 상태를 다음 네 가지로 표기합니다.

• Not affected(영향 없음): 이 취약점에 대한 수정이 필요하지 않습니다.
• Affected(영향 있음): 수정하거나 완화하는 조치가 권장됩니다.
• Fixed(수정됨): 해당 제품 버전에 취약점 수정이 포함돼 있습니다.
• Under Investigation(조사 중): 영향 여부가 아직 확인되지 않았으며, 추후 갱신됩니다.

VEX는 단일 형식이 아니라 CSAF VEX, OpenVEX, CycloneDX VEX가 공존합니다. CycloneDX는 VEX를 형식 안에서 네이티브로 표현하는 점이 특징입니다.

CSAF: 권고를 구조화한다

공통 보안 권고 프레임워크(Common Security Advisory Framework, CSAF) 2.0은 보안 권고를 기계 판독 가능하게 구조화한 표준으로, VEX 프로파일을 포함합니다. OASIS가 2022년 11월 정식 표준으로 승인했습니다. VEX가 악용 가능성 상태를 알린다면, CSAF는 취약점 설명, 영향받는 버전, 심각도 평가(CVSS 점수), 권장 완화 단계까지 담은 상세 권고를 전달합니다.

채택의 실질적 전환점은 Red Hat이었습니다. Red Hat 제품보안팀은 2023년 자사 데이터베이스의 모든 CVE에 대해 CSAF·VEX 파일을 공개하기 시작했고, 이후 정식 운영으로 전환해 상시 발행합니다.

사례: Log4Shell

2021년 12월 공개된 Log4j 취약점(Log4Shell)은 SBOM과 VEX, CSAF가 어떻게 맞물리는지를 보여주는 사례입니다.

그림 1. Log4Shell 대응에서 SBOM·VEX·CSAF의 연계 (출처: CERT-In 기술 가이드라인 재구성. 수집일 2026-06-14)

취약점이 공개되자 관리자는 악용 가능 상태를 알리는 VEX를 냈고, 이어 취약점 설명과 영향받는 버전, CVSS 10.0(최고 심각도), 완화 단계를 담은 CSAF 권고를 발표했습니다. Log4j를 구성요소로 포함한 조직은 이 VEX와 CSAF 데이터를 자신의 SBOM에 통합해, 시스템의 영향받는 부분을 식별하고 대응 우선순위를 정했습니다. SBOM이 미리 갖춰져 있었다면 “어디에 Log4j가 있는가"를 질의 한 번으로 답할 수 있었다는 점이 이 사례의 핵심입니다.

출처

OASIS Open (2022). CSAF 2.0. https://www.oasis-open.org/2022/11/21/new-version-of-csaf-standard/. CISA. Vulnerability Exploitability eXchange (VEX). https://www.cisa.gov/sbom. OpenVEX https://github.com/openvex. NVD. CVE-2021-44228. https://nvd.nist.gov/vuln/detail/CVE-2021-44228. Red Hat (2023). VEX files now available. (모두 접속: 2026-06-14)

7 - 공유와 거버넌스

SBOM은 공급망을 따라 전달돼야 가치가 생기지만, 동시에 영업 비밀과 공격 표면을 담은 민감 자료이기도 합니다. 누구에게 무엇을 어떻게 공유할지를 정하는 거버넌스가 없으면, 과도한 공개로 위험을 키우거나 과도한 폐쇄로 가치를 잃습니다.

접근 통제와 공개 범위

SBOM 데이터에 대한 접근은 역할 기반 접근 통제(Role-Based Access Control, RBAC)로 관리합니다. 이해관계자별로 접근 요구가 다르므로, 일반 사용자에게는 읽기 전용을, 관리자에게는 편집과 갱신을, 민감 정보에는 제한된 접근을 부여합니다.

공개 범위는 두 버전을 유지하는 방식이 일반적입니다.

• 공개 SBOM: 모든 이해관계자와 공유 가능한 비민감 정보를 담습니다.
• 비공개 SBOM: 취약점 같은 민감 정보를 담으며 승인된 당사자만 접근합니다.

규제도 이 구분을 반영합니다. EU 사이버 복원력법은 SBOM을 일반 공중에 공개할 의무를 두지 않고, 시장 감시 당국의 요청에 대비해 보관하도록 합니다. 소비자는 더 완전한 SBOM을 원하고 생산자는 공개를 줄이려는 긴장 속에서, 공개·비공개 분리는 양쪽을 절충하는 실무 장치입니다.

안전한 공유 채널

SBOM을 전달할 때는 무결성과 기밀성을 함께 지켜야 합니다.

• 전송 시 HTTPS 같은 보안 프로토콜을 쓰고, 디지털 서명이나 암호화로 무결성과 기밀성을 보장합니다.
• 접근 통제와 감사 기능을 갖춘 공유 플랫폼을 사용합니다.
• 시스템 간 자동 교환이 필요하면 API 연동을, 산업·커뮤니티 단위 공유에는 전용 저장소를 활용합니다.

문서에는 디지털 서명을 붙여 수신자가 진위와 변조 여부를 확인할 수 있게 하고, 어떤 정보를 공개·비공개로 둘지를 명확히 표시합니다.

역할과 책임

SBOM 프로그램은 여러 부서가 함께 책임지는 구조라야 작동합니다. 관리 후원자, 프로젝트 리더, 시스템·설계 엔지니어, 조달 전문가, 운영 담당자를 포함하고, 보안 요구에 따라 IT와 사이버보안, 유지보수 인력을 더합니다. 역할이 흩어지면 책임도 흩어지므로, 명확한 소유권을 정하는 것이 출발점입니다.

거버넌스 구축에서 핵심 활동은 다음과 같습니다.

• 주요 이해관계자 식별: 개발, IT 운영, 보안, 조달, 법무, 비즈니스 리더십의 대표를 포함하고 사이버보안 전문가를 반드시 넣습니다.
• 책임 정의와 소유권 부여: SBOM 생성과 소비, 취약점 모니터링, 공급사 참여, 보안 데이터 관리를 누가 맡을지 정하고, 사이버보안 전문가를 프로그램 소유자 또는 공동 소유자로 지정합니다.
• 거버넌스 체계 수립: 조직 전반의 이해관계자가 참여하는 거버넌스 기구가 정책과 표준, 프로세스를 개발하고 데이터 보호 통제를 구현합니다.
• 교육과 모니터링: SBOM 보안 요구와 안전한 데이터 처리를 교육하고, 정기 감사로 프로그램의 보안 태세를 지속적으로 평가하며 진화하는 위협과 컴플라이언스 요구에 맞춰 조정합니다.

출처

CISA (2024). Framing Software Component Transparency, Third Edition. CERT-In. Technical Guidelines on Software Bill of Materials (SBOM). Regulation (EU) 2024/2847 — Cyber Resilience Act, Annex I Part II. (모두 접속: 2026-06-14)

8 - 권장사항과 체크리스트

앞선 절에서 다룬 내용을 실무 권장사항과 점검표로 정리합니다. 처음 도입하는 조직은 체크리스트를 순서대로 따라가고, 이미 운영 중인 조직은 빠진 항목을 점검하는 용도로 쓰면 됩니다.

핵심 권장사항

조달과 생성

• 소프트웨어를 조달할 때 계약과 구매 조건에 SBOM 제공 요구를 명시합니다. 어떤 요소를 어떤 형식으로 언제 제공할지까지 지정합니다.
• SBOM은 SPDX 또는 CycloneDX 형식으로 생성합니다. 거래 상대의 요구와 자사 도구 체인을 기준으로 고릅니다.
• 빌드 시점에 SSDLC와 CI/CD 파이프라인에서 SBOM을 자동 생성해 정확도와 적시성을 확보합니다.
• 새 구성요소가 도입되거나 기존 구성요소가 갱신될 때 SBOM을 다시 만드는 워크플로우를 둡니다.

데이터 품질

• 구성요소명, 버전, 라이선스, 고유 식별자 같은 메타데이터를 빠짐없이 담습니다. 최소 요소는 최저선일 뿐이므로 자사 용도에 맞춰 필드를 더합니다.
• 구성요소를 PURL이나 CPE로 고정해, 이름이나 버전이 바뀌어도 추적이 끊기지 않게 합니다.
• 생성 도구의 버전을 고정하고 출처를 검증하며, 생성물에 해시와 서명을 붙여 무결성을 보장합니다.

취약점과 라이선스

• SBOM을 취약점 데이터베이스와 권고에 연결해 보안 상태를 지속적으로 가시화합니다.
• 패치나 완화를 적용하면 자체 SBOM에 반영합니다.
• VEX와 CSAF로 취약점의 악용 가능성 상태를 교환하고, 위험 기반으로 대응 우선순위를 정합니다.
• 모든 구성요소의 라이선스 호환성을 분석해 결합 시 생길 충돌을 미리 식별합니다.

보관과 운영

• SBOM을 암호화와 접근 통제로 안전하게 저장·전송하고, 공개·비공개 범위를 명확히 구분합니다.
• 정기 감사로 SBOM의 정확성과 완전성을 점검합니다.
• 개발자부터 보안팀까지 SBOM의 역할에 대한 교육과 인식 프로그램을 운영합니다.

도입 점검표

단계별로 무엇을 했는지 점검하는 체크리스트입니다.

다음 단계

AI 시스템을 개발하거나 공급망으로 주고받는다면, 이 가이드의 SBOM 역량 위에 모델과 데이터셋, 학습 연산이라는 AI 고유 계층을 얹어야 합니다. 일반 SBOM의 구성요소와 라이선스, 취약점 관리 실무가 AI BOM의 소프트웨어 계층으로 그대로 이어집니다. 자세한 내용은 별도 가이드인 AI SBOM 컴플라이언스 가이드에서 다룹니다.

출처

NTIA (2021). The Minimum Elements For a Software Bill of Materials (SBOM). CISA (2024). Framing Software Component Transparency, Third Edition. CERT-In. Technical Guidelines on Software Bill of Materials (SBOM). Regulation (EU) 2024/2847 — Cyber Resilience Act. (모두 접속: 2026-06-14)