고객이 SBOM을 요구할 때: 공급업체를 위한 가이드

이 가이드는 제조 공급망 안의 공급업체를 위한 것입니다. ECU, 디스플레이, 컨트롤러, 게이트웨이, 드라이브, 임베디드 Linux 스택, 펌웨어 모듈 등입니다. 소프트웨어를 판매하고 고객이 일회성 요청을 보냈다면 고객 SBOM 요청에 답하는 방법부터 보세요. 그 경우를 다룹니다.

지금 OEM이 요청하는 이유

OEM의 SBOM 요청은 대개 OEM의 규제가 계약을 통해 공급업체에 도달한 것입니다. 어떤 규제인지에 따라 OEM이 무엇을 갖춰야 하는지, 그중 얼마나 공급업체에 전가되는지가 결정됩니다.

Cyber Resilience Act

Cyber Resilience Act, Regulation (EU) 2024/2847에 따르면 디지털 요소를 포함한 제품에는 "별도로 시장에 출시되는 소프트웨어 또는 하드웨어 구성 요소"가 포함됩니다(제3조 제1호). EU에 단독으로 판매하는 구성 요소는 그 자체로 제품이며, 공급업체가 그 제조자로서 자체 SBOM 의무를 집니다. 부속서 I 제II부 제1항은 "일반적으로 사용되는 기계 판독 가능한 형식으로, 최소한 제품의 최상위 종속성을 포함하는" SBOM을 요구합니다. 구성 요소가 다른 제품에 통합될 용도라면, 지침에는 "통합자가 필수 요구 사항을 준수하는 데 필요한 정보"도 담아야 합니다(부속서 II 제8항 (f)).

OEM에도 공급업체에 닿는 의무가 있습니다. OEM은 "제3자로부터 조달한 구성 요소를 통합할 때 실사를 수행"해야 하고 (제13조 제5항), 통합한 구성 요소에서 취약점을 발견하면 그 구성 요소를 제조하거나 유지보수하는 개인 또는 기관에 보고해야 합니다(제13조 제6항). 2026년 7월 집행위원회의 CRA 지침은 실사 증거가 "구성 요소 제조자로부터 받은 문서로 구성될 수 있다"고 하며 SBOM은 언급하지 않습니다. 실무에서는 OEM이 요청하는 문서가 SBOM인 경우가 많습니다. 보고 의무는 2026년 9월 11일부터, 규정 전체는 2027년 12월 11일부터 적용됩니다. 교체하는 구성 요소와 같은 사양으로 만든 예비 부품은 제외됩니다(제2조 제6항). 규정의 나머지 내용은 CRA란 무엇인가와 CRA 가이드를 참조하세요.

차량

CRA는 차량 형식 승인 규정인 Regulation (EU) 2019/2144의 적용을 받는 제품에는 적용되지 않습니다(제2조 제2항 (c)). 형식 승인 차량용 구성 요소는 대신 차량 규정에 따라 시장에 출시되며, 그 규정들은 SBOM을 전혀 언급하지 않습니다.

UN Regulation No. 155(사이버보안)는 제조사가 "공급업체 관련 위험이 식별되고 관리되고 있음을 입증하기 위해 공급망 전반에서" 정보를 수집하고 검증할 것(5.1.1(a)), 사이버보안 관리 시스템이 "계약된 공급업체, 서비스 제공자 또는 제조사의 하위 조직과 존재할 수 있는 의존 관계를 어떻게 관리할지" 보여 줄 것(7.2.2.5), 그리고 "승인 대상 차량 형식에 대해 공급업체 관련 위험을 식별하고 관리"할 것(7.3.2)을 요구합니다.
UN Regulation No. 156(소프트웨어 업데이트)는 모든 초기 및 업데이트 소프트웨어 버전을 고유하게 식별할 수 있어야 하며(7.1.1.2), 모든 RX Software Identification Number(RXSWIN)에 대해 "RXSWIN과 관련된 모든 소프트웨어를 기술하는 감사 가능한 등록부"를 갖출 것(7.1.2.3)을 요구합니다.
ISO/SAE 21434는 OEM과 공급업체 간 사이버보안 작업을 분산 활동으로 구성하며, 분담 내용은 사이버보안 인터페이스 합의서(cybersecurity interface agreement)로 정합니다.
Auto-ISAC SBOM Informational Report(2025년 2월)는 업계 자체의 지침입니다.

자동차 분야에서 SBOM은 법적 요구 사항이 아니라 계약 요구 사항으로 들어옵니다.

산업 자동화

IEC 62443-4-1은 산업 자동화 및 제어 시스템 제품 공급업체에 적용됩니다. SBOM을 명시하지는 않지만, 관행 6인 보안 관련 문제 관리(DM-1~DM-6)와 관행 7인 보안 업데이트 관리(SUM-1~SUM-5, "Dependent component or operating system security update documentation"인 SUM-3 포함)에서 SBOM이 증거로 쓰입니다.

기계류

Machinery Regulation (EU) 2023/1230은 2027년 1월 20일부터 적용되며 SBOM을 언급하지 않습니다. 손상(corruption) 방지에 관한 필수 요구 사항(부속서 III, 1.1.9)은 준수에 핵심적인 소프트웨어를 식별하고 보호할 것, 기계가 "안전하게 작동하는 데 필요한 설치된 소프트웨어를 식별"할 수 있을 것, 그리고 그 소프트웨어에 대한 개입의 증거를 수집할 것을 요구합니다. 디지털 요소를 포함한 기계는 형식 승인 차량과 달리 CRA도 적용받기 때문에, 기계 OEM이 지금 공급업체에 SBOM을 요청하고 있습니다. 기계 제조사를 위한 CRACI와 산업용 IoT를 참조하세요.

NIS2와 인증받은 고객

반도체 분야처럼 필수 기관이나 중요 기관에 공급한다면, NIS2 제21조 제2항 (d)는 고객에게 공급망 보안을 다루도록 요구합니다. SBOM은 명시하지 않습니다. 고객은 이를 설문으로 바꾸며, ISO/IEC 27001 Annex A 통제 5.21과 8.8에서 SBOM이 증거로 쓰입니다. ISO 27001, SOC 2, NIS2 증거로서의 SBOM을 참조하세요.

제도별 비교

제도	적용 대상	SBOM 명시?	공급업체에 닿는 것
Cyber Resilience Act	별도로 판매되는 구성 요소를 포함해 EU 시장의 디지털 요소를 포함한 제품	예, 부속서 I 제II부 (1)	구성 요소를 직접 시장에 출시하면 직접 적용, 그 외에는 OEM의 실사(제13조 제5항)와 취약점 보고(제13조 제6항)를 통해
UN R155 및 R156	형식 승인을 받으려는 차량 제조사	아니요	공급업체 위험 관리(R155 7.2.2.5, 7.3.2)와 소프트웨어 식별(R156), 계약을 통해
ISO/SAE 21434	도로 차량 사이버보안 엔지니어링, OEM과 공급업체	공개된 설명에는 없음	분산 활동과 사이버보안 인터페이스 합의서
IEC 62443-4-1	산업 자동화 및 제어 시스템 제품 공급업체	아니요	제품 공급업체라면 직접 적용, SBOM은 DM과 SUM의 증거
Machinery Regulation	EU 시장의 기계류와 관련 제품	아니요	소프트웨어 식별과 보호(부속서 III 1.1.9), CRA가 함께 적용
NIS2	필수 기관과 중요 기관	아니요	공급망 보안 설문과 계약 조건(제21조 제2항 (d), 제3항)

경로가 무엇이든 고객에게 필요한 것은 같습니다. 납품하는 모든 소프트웨어 버전의 정확한 SBOM입니다.

OEM이 일반적으로 요청하는 것

요구 사항은 OEM마다 다르지만 같은 목록으로 수렴합니다. 첫 납품 전에 SBOM을 이 목록과 대조해 보세요.

요구 사항	일반적인 기대치
형식	CycloneDX 또는 SPDX, JSON 또는 XML, 최소 사양 버전 지정. BSI TR-03183-2는 CycloneDX 1.6 이상 또는 SPDX 3.0.1 이상을 정합니다.
필드	CISA 2026 Minimum Elements 또는 BSI TR-03183-2에 맞춤: 작성자, 타임스탬프, 그리고 구성 요소별 이름, 버전, 제작자, 식별자
식별자	생태계에 있으면 package URL, 없으면 CPE. 구성 요소를 취약점 데이터베이스와 매칭하기 위함
라이선스	SPDX 라이선스 식별자. OEM의 라이선스 전문가가 이를 보고 카피레프트와 기타 라이선스 위험을 판단합니다.
해시	납품한 각 바이너리의 해시. OEM이 SBOM이 받은 파일을 설명하는지 확인할 수 있도록 함. BSI는 SHA-512를 요구합니다.
깊이	최상위만이 아니라 전이적 종속성까지
단위	납품하는 소프트웨어 버전 또는 부품 번호당 SBOM 하나
전달과 응답	전달 채널, 그리고 취약점 문의에 대한 응답 시간

많은 OEM은 수신 시 이 항목들을 자동으로 확인합니다. 고객이 무엇을 어떤 도구로 확인하는지는 SBOM 품질 체크리스트를, 파일에서 필드가 어떻게 보이는지는 SBOM 예시를 참조하세요.

오픈소스가 거의 없거나 전혀 없을 때의 SBOM

모델 기반 코드 생성으로 만든 독점 펌웨어를 탑재한 베어메탈 ECU나 컨트롤러는 정직한 SBOM이 짧을 수 있습니다. 독점 애플리케이션, 자체 부트로더, 실리콘 벤더의 라이브러리나 캘리브레이션, 그리고 암호화 라이브러리 같은 오픈소스가 있다면 그것입니다. 그것도 유효한 답입니다. 원칙은 다음과 같습니다.

독점 구성 요소는 자체 식별자로 나열하세요: 이름, 버전, 제작자로서 자사.
내용을 볼 수 없는 벤더 라이브러리 같은 알려진 미지 항목을 명시하세요.
철저해 보이려고 SBOM을 부풀리지 말고, 작다는 이유로 오픈소스 라이브러리를 빼지 마세요.

Linux 기반 디스플레이와 게이트웨이는 정반대입니다. 커널, 부트로더, 기본 시스템 패키지를 포함해 수백에서 수천 개의 구성 요소가 있습니다(커넥티드 기기 참조). 자사 애플리케이션과 라이브러리 몇 개만 나열한 SBOM은 수신 팀이 가장 먼저 문제로 지적합니다. Yocto로 빌드한다면 스캐너가 Yocto 빌드의 내용을 놓치는 이유를 참조하세요.

계약: 첫 납품 전에 합의할 사항

조건	중요한 이유
대상 제품과 소프트웨어 버전	변형 모델이나 서비스 릴리스에 SBOM이 필요했는지를 두고 나중에 다투지 않도록
형식과 사양 버전	고객의 수신 파이프라인이 다른 것은 거부할 수 있음
필드와 따르는 프레임워크	"BSI TR-03183-2 v2.1.0"이나 "CISA 2026 Minimum Elements"는 테스트할 수 있지만 "완전한 SBOM"은 테스트할 수 없음
전달 시점	릴리스마다, OEM에 출하하는 소프트웨어 버전마다, 수정할 때마다
전달 채널	OEM의 공급업체 포털, 보안 파일 교환, 또는 NDA하의 이메일
기밀 유지	SBOM을 기밀 정보로 명시한 NDA 또는 기존 공급 계약
사용 제한	취약점 관리와 컴플라이언스 용도로만, 동의 없는 제3자 공유 금지
양방향 취약점 통지	OEM은 구성 요소에서 발견한 취약점을 보고하고(CRA 제13조 제6항), 공급업체는 자사가 발견한 취약점을 통지
VEX에 대한 기대	어떤 형식인지, 새 CVE를 얼마나 빨리 평가하는지
보관	각 버전의 SBOM을 제품 지원 기간에 맞춰 얼마나 오래 보관할지
정확성과 알려진 미지 항목	SBOM이 다룰 수 있는 것과 없는 것에 대한 정직한 조항은 양측을 보호함

CISA의 SBOM Sharing Primer도 자동차 사례를 같은 방식으로 설명합니다. SBOM 요청은 "표준 정보 교환 계약(예: 비밀 유지 계약, 사이버보안 인터페이스 합의서, 개발 인터페이스 합의서)에 포함될 것"이라는 것입니다.

IP를 노출하지 않고 공유하기

SBOM은 소스 코드가 아닙니다. 구성 요소의 이름, 버전, 제작자, 라이선스, 해시, 관계를 나열할 뿐, 코드, 알고리즘, 캘리브레이션 데이터, 설계는 담지 않습니다.

CRA는 제조자에게 SBOM 공개 의무를 지우지 않습니다(전문 제77항). SBOM은 시장 감시 당국의 합리적 요청이 있을 때 제출합니다(부속서 VII 제8항).
CISA의 공유 지침은 독점 소프트웨어의 일반적인 채널로 NDA하의 이메일, 고객의 공급업체 포털이나 보안 문서 교환, 또는 접근이 통제된 자체 포털을 제시하며, 기밀 유지와 접근은 계약으로 규율합니다.
실용적인 방법: 계약에 따라 OEM별로 완전한 SBOM 하나, 내부 프로젝트 이름을 드러내지 않는 독점 부품 식별자, 그리고 SBOM을 다시 보내지 않고도 취약점 상태를 업데이트할 수 있는 별도의 VEX 문서.

얼마나 자주, 그리고 납품 후에는

납품하는 모든 소프트웨어 버전마다 새 SBOM, OEM이 플래싱하거나 등록하는 것과 같은 식별자로. 차량의 경우 R156 소프트웨어 식별과 연결됩니다.
수정된 SBOM: 보낸 SBOM에서 오류를 발견했을 때.
VEX 선언 또는 보안 권고: 취약점을 평가했을 때.

"CVE-X의 영향을 받습니까?"라는 후속 질문은 다음 대형 취약점과 함께 옵니다. 납품 버전별로 답할 준비를 해 두세요. 각 버전의 SBOM을 보관했을 때만 가능합니다.

VEX: 고객이 다음으로 기대할 것

VEX 문서는 제품이 취약점의 영향을 받는지 밝힙니다. CISA의 Minimum Requirements for VEX(2023년 4월)는 네 가지 상태를 정의합니다: not_affected, affected, fixed, under_investigation. not_affected 선언에는 다섯 가지 근거 중 하나나, 그렇지 않으면 영향 설명(impact statement)을 넣어야 합니다.

component_not_present
vulnerable_code_not_present
vulnerable_code_not_in_execute_path
vulnerable_code_cannot_be_controlled_by_adversary
inline_mitigations_already_exist

affected 선언에는 조치 설명(action statement), 즉 고객이 무엇을 해야 하는지가 필요합니다. VEX 형식은 세 가지입니다: CSAF 2.0 VEX 프로필, CycloneDX VEX, OpenVEX. Yocto의 SPDX 3.0 출력에는 기본적으로 VEX 데이터가 포함됩니다(SPDX_INCLUDE_VEX 변수).

예시. Linux 기반 디스플레이가 OpenSSL 3.0.8을 탑재해 출하됩니다. CVE-2023-0464는 정책 제약이 포함된 X.509 인증서 체인을 검증할 때 리소스를 과도하게 사용하는 문제를 설명합니다. 정책 처리는 기본적으로 비활성화되어 있고, 디스플레이 소프트웨어는 이를 활성화하지 않습니다. 공급업체는 다음과 같은 예시 OpenVEX 선언을 보냅니다.

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/display-fw-5.3.0-2023-0464",
  "author": "Example Displays Product Security",
  "timestamp": "2026-11-11T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-0464" },
      "products": [{ "@id": "pkg:generic/example/[email protected]" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "X.509 policy processing is disabled by default and the firmware never enables it."
    }
  ]
}

SBOM을 반복 가능하게 생성하기

빌드 방식	현실적인 SBOM 생성 방법
CI에서 빌드하는 소프트웨어	납품 소프트웨어를 만드는 빌드에서 SBOM을 생성하고 릴리스와 함께 보관
Yocto 기반 임베디드 Linux	Yocto 자체 SPDX 출력(`create-spdx`)을 쓰되 누락 항목을 확인하거나, Yocto 빌드를 기록
모델 기반 도구로 만든 베어메탈 펌웨어	텍스트 편집기가 아닌 생성기 라이브러리나 도구로, 릴리스마다 유지하고 보내기 전에 검증
통합하는 서드파티 바이너리	자사 공급업체에 SBOM을 요청하고, 받을 때까지 바이너리 분석으로 대체

경로가 무엇이든 보내기 전에 파일을 검증하세요. SBOM 품질 체크리스트는 고객이 실행할 가능성이 높은 검증기를 정리했고, CycloneDX vs SPDX는 형식 선택을 돕고, SBOM 생성 표준화는 팀 간 방식을 통일하는 방법을 다룹니다.

CRACI의 역할

GitHub Actions로 빌드하는 공급업체의 경우, CRACI는 GitHub 호스팅 러너를 대체하고 모든 빌드에서 SBOM을 기록하므로 납품하는 모든 버전에 이미 SBOM이 있습니다.

SBOM에는 전이적 종속성을 포함해 빌드가 실제로 가져온 것이 담기며, 패키지별 package URL과 모든 구성 요소의 선언 라이선스가 포함됩니다.
각 작업의 SBOM에는 완전성 상태가 붙으므로, 보내기 전에 무엇을 보내는지 알 수 있습니다.
SBOM은 CycloneDX 또는 SPDX로 내보내며, CRACI는 VEX를 지원합니다.
모니터링 중인 SBOM은 새 취약점이 공개될 때마다 재평가되며, 빌드 이력은 보존 기간 내에서 어떤 빌드에 취약한 종속성이 들어 있었는지 보여 줍니다.
Yocto 빌드는 CRACI 러너에서 실행되고 기록됩니다.
서드파티 SBOM을 추가할 수 있어, 구매한 구성 요소도 자체 빌드와 함께 모니터링됩니다.

CRACI가 답이 아닌 경우

CI가 없거나 GitLab, Jenkins, 빌드 서버에서 빌드하는 경우. 현재 CRACI는 GitHub Actions만 지원하며, 다른 CI 시스템은 로드맵에 있습니다.
펌웨어를 패키지를 가져오지 않는 모델 기반 도구로 생성하는 경우. 빌드 기록기의 효용이 적습니다.
여러 OEM을 위한 공유 포털에서 SBOM을 호스팅하거나 SBOM에 서명해야 하는 경우. CRACI는 둘 다 제공하지 않습니다.
빌드를 자체 인프라에서 실행해야 하는 경우. 고객 호스팅 러너는 로드맵에 있습니다.
고객이 ISO 27001 인증서나 NIS2 설문 답변처럼 조직의 보안 관리에 대한 증거를 원하는 경우. SBOM은 그중 일부의 증거일 뿐 인증이 아닙니다. CRACI 자체의 ISO 27001 인증서는 CRACI의 서비스를 다루며, 공급업체의 서비스를 다루지 않습니다.

공급업체를 위한 SBOM: 자주 묻는 질문

OEM 고객이 SBOM을 요청했습니다. 반드시 제공해야 하나요?

법보다는 계약이 요구하는 경우가 많습니다. 디지털 요소를 포함한 구성 요소를 직접 EU 시장에 출시한다면 Cyber Resilience Act가 자체 SBOM을 요구합니다. 그렇지 않으면 의무는 OEM에 있으며, OEM은 실사와 공급 계약을 통해 이를 공급업체에 전가합니다.

제조사에 판매하는 구성 요소에도 CRA가 적용되나요?

구성 요소를 별도로 EU 시장에 출시한다면 적용됩니다. 제3조 제1호는 별도로 시장에 출시되는 소프트웨어 또는 하드웨어 구성 요소를 포함합니다. OEM 제품 안에서만 시장에 나간다면 OEM이 제조자이며 구성 요소에 대해 실사를 수행해야 합니다(제13조 제5항). 형식 승인 차량의 구성 요소는 CRA 적용 대상이 아닙니다(제2조 제2항 (c)).

UN R155나 ISO/SAE 21434는 SBOM을 요구하나요?

아닙니다. R155는 SBOM을 전혀 언급하지 않으며, 차량 제조사가 공급업체 관련 위험을 관리하도록 요구합니다. ISO/SAE 21434는 인터페이스 합의서를 통해 공급업체와의 사이버보안 작업을 구성합니다. 자동차 분야에서 SBOM은 계약 요구 사항으로 들어옵니다.

OEM은 어떤 형식과 필드를 기대하나요?

대개 JSON 또는 XML 형식의 CycloneDX나 SPDX로, CISA 2026 Minimum Elements나 BSI TR-03183-2에 맞춘 것입니다. 작성자와 타임스탬프, 그리고 구성 요소별 이름, 버전, 제작자, package URL 또는 CPE, 라이선스, 해시를 전이적 종속성과 함께 담습니다.

업데이트된 SBOM은 얼마나 자주 보내야 하나요?

납품하는 모든 소프트웨어 버전마다, 오류를 수정할 때마다, 그리고 취약점을 평가했을 때 VEX 선언이나 보안 권고와 함께 보냅니다. 전달 시점은 계약에서 합의하세요.

SBOM을 공유하면 지식재산이 노출되나요?

아닙니다. SBOM은 구성 요소의 이름, 버전, 제작자, 라이선스, 해시, 관계를 나열할 뿐, 소스 코드, 알고리즘, 캘리브레이션 데이터는 담지 않습니다. NDA나 공급 계약에 따라, 취약점 관리와 컴플라이언스로 사용을 제한해 공유하세요. CRA는 SBOM 공개를 요구하지 않습니다.

VEX란 무엇이며, 고객이 요청할까요?

VEX는 제품이 취약점의 영향을 받는지를 not_affected, affected, fixed, under_investigation으로 밝히며, not_affected에는 근거를 붙입니다. 출하하는 구성 요소에서 널리 알려진 취약점이 다음에 나오면 요청받을 것으로 예상하세요.

ECU 펌웨어에 오픈소스가 없습니다. SBOM은 어떻게 되나요?

짧고 정직하게 작성합니다. 독점 애플리케이션, 부트로더, 실리콘 벤더 라이브러리나 캘리브레이션, 그리고 암호화 라이브러리 같은 오픈소스가 있다면 그것을 각각 자체 식별자와 함께 나열하고, 알려진 미지 항목을 더합니다. 부풀리지 마세요.

고객이 SBOM을 요구할 때: 구성 요소·소프트웨어 공급업체를 위한 가이드