[기고] 공급망 투명성의 핵심 인프라로서 ‘SBOM 제도화 대응 전략’

고려대 SW·AI융합대학원 최윤성 교수

1. 서론: 공급망 투명성의 제도적 전환점

최근 IT 시스템 침해 사고가 연이어 발생하면서 전 세계적으로 ‘디지털 자산의 가시성’이 보안의 핵심 이슈로 부상했다. 공격자는 이제 단일 시스템을 넘어, 소프트웨어(SW) 공급망 전체를 노리고 있다. 공급망 방어의 출발점은 “무엇이 내 시스템 안에 들어 있는가?”를 정확히 아는 것과 이를 알리는 것에서 시작한다.

이 문제에 대한 해법으로 주목받는 것이 SW 자재명세서(SBOM, Software Bill of Materials)이다. SBOM은 SW를 구성하는 모든 컴포넌트, 라이브러리, 의존성의 목록을 데이터 형태로 제공하여, 공급망의 투명성을 확보하는 공동의 기술적 토대이다.

미국 식품의약청(FDA), 유럽연합 사이버 복원력 법(EU CRA)과 같은 글로벌 규제 및 국제표준화기구(ISO/IEC, ETSI, CEN/CENELEC)들은 이미 SBOM을 필수 관리 항목으로 포함하고 시장 진입을 위한 인증의 기본 요건으로 삼고 있다. 이는 사실상 글로벌 공급망 신뢰 체계의 관문 역할을 하는 것이다.

2. SBOM의 정의와 가치

SBOM은 SW 내 구성 요소들의 재료 명세서이다. 제조업의 BOM(Bill of Materials)이 완제품을 구성하는 부품 정보를 제공하듯, SBOM은 SW의 ‘보안·법적 책임·기술 품질관리’를 위한 근거 자료를 제공한다.

• 공급망 투명성 확보 : 외부와 내부 구성요소의 위치와 출처를 명확히 하여, 취약점 전파의 경로를 가시화한다.

• 위험의 조기 감지 및 대응 : 보안 취약점, 라이선스 위반, 기술 부채를 조기에 탐지하여 선제적으로 조치하는 것이 가능하다.

• 공급망 신뢰성 강화 : SBOM은 협력사 간 데이터 공유의 표준 포맷으로, 신뢰 기반 협력 구조를 형성한다.

• 규제 준수와 고객 신뢰 확보 : 美 FDA, EU CRA 등에서 요구하는 투명성 준수를 입증할 수 있다.

3. SBOM 기반 보안 위험관리: 오해와 진실

SBOM 보안은 ‘파일’이 아니라 ‘프로세스’이다

많은 기업이 SBOM 제도를 단순히 생성 도구의 구매나 문서 파일 같은 산출물만 확보하는 것으로 오해한다. 그러나 SBOM 생성은 보안의 시작일 뿐이며, 그 목적은 ‘지속적인 위험관리의 체계화’이다. SBOM 파일 하나로 공급망 공격 대응이 가능하리라 믿는 것은 착각이다.

효과적인 SBOM 관리는 다음 3단계를 포함해야 한다.

1. 생성(Create) : 제품별, 버전별 구성요소를 정확히 식별하고 메타데이터를 수집

2. 활용(Operate) : 취약점 탐지·모니터링·패치 프로세스와 동적 연계

3. 공유(Share) : 협력사 및 고객과 신뢰 기반으로 자동화된 데이터 교환

SBOM 보안은 라이선스 관리와는 조금 다르다

SBOM 보안은 단순한 사용 허가 관리가 아닌 ‘공동의 위험관리’ 도구이다. 예컨대 Log4J 사건처럼, 모든 조직이 동일한 오픈소스 SW(OSS)를 사용하고 있을 때, 취약점 식별과 대응은 한 조직의 문제가 아니라 생태계 전체의 공동 과제가 된다. SBOM은 이러한 보안책임의 분산과 협력 기반 대응을 가능하게 한다.

SBOM이 기술 부채를 ‘공개’하는 수단이 되어서는 안 된다

SBOM은 투명성 도구이지만, 내부 품질관리 정보(기술 부채, 개발 결함 등)를 노출해서는 안 된다. 공개용 SBOM에는 OSS 정보나 필수 보안 메타데이터만 포함하는 정책적 판단이 필요하다. 기업 내부에서는 실제 위험 관리를 위한 상세 버전의 리파지토리(Repository)를 별도로 운용해야 한다.

4. SBOM 제도화의 글로벌 흐름

이러한 SBOM 규제의 핵심은 ‘SBOM 파일 제출’이 아니라, 취약점 식별→모니터링→패치→검증의 관리체계 구축이다.

(2023년) 미국 FDA 의료기기 SBOM 요구

FDA는 모든 SW 기반 의료기기에 대해 SBOM 제출을 의무화해 구성 요소별 보안 취약점 모니터링과 위기 대응 체계를 구축하였다. SBOM 정확성, 적시 갱신, 패치 관리 절차 등이 심사와 인증의 핵심 요소이다.

(2024년) 미국 NIAP의 CC 인증 제도

NIAP(국가정보 보증 파트너십)의 Common Criteria (CC) 평가에서는 보안제품 심사 시 주요 SW 구성요소의 SBOM 제출을 요구하며, 해당 정보는 취약점 평가와 인증 자료로 활용된다. 제출된 SBOM은 제품 검증 단계별로 정밀 심사를 받게 된다.

(2025년) 미국 BIS의 자동차 SW 부품 규제

BIS(산업안보국)는 차량용 SW의 안전·보안 이슈 발생 시, 내장된 모든 SW 부품의 자재명세서(SBOM)를 제출하도록 규정하여 공급망의 취약점 관리와 신속한 리콜을 지원한다. 이 정책은 자율주행차, 커넥티드카에 중점 적용된다.

(2025년) PCI DSS 4.0.1 (글로벌 결제 보안 표준)

PCI DSS 4.0.1은 결제 시스템의 SW 구성요소 및 외부 라이브러리에 대해 인벤토리 작성·관리를 의무화하고 있다. 이를 통해 취약점이 있는 컴포넌트를 식별·대응하여 카드 정보 유출 위험을 줄인다.

(2027년) EU CRA (사이버 복원력법)

CRA는 디지털제품·SW에 대해 SBOM 제출 및 위험관리 체계를 법적으로 요구하며, 정보는 규제기관과 소비자에게 모두 제공된다. 주기적 갱신과 공급망 내 신속 통보를 통해 대규모 보안 사고를 예방한다.

5. SBOM과 IT 자산관리의 관계

SBOM은 IT 자산관리(ITAM)의 하위 또는 보완 개념으로 이해해야 한다.

일례로 IT 자산관리(ITAM)가 “무엇을 가지고 있는가”를 관리한다면, SBOM은 “그 안에 무엇이 들어 있는가”를 관리한다. 즉, ITAM이 건물의 외관이라면, SBOM은 세부 설계도다. 단순히 “서버 10대가 웹서비스를 운영 중”이라는 수준을 넘어 “그중 3대에 Log4j 2.14.1 버전이 포함되어 CVE-2021-44228에 취약하다”라는 구체적인 공격표면 관리가 가능해진다.

6. SBOM 관리의 절차적 구성

1. SW 자산 식별 : 제품·시스템별 구성요소(DB화)

2. 취약점 탐지 : NVD, KEV, GitHub Advisory 등과 연동하여 자동 탐지

3. 검증 및 예외 처리 : 정적분석 오탐(FP)을 필터링

4. 대응계획 수립 및 패치 : Time-sensitive 이슈이므로 제품 수명주기와 연계해 주기적 점검

5. 공유 및 보고 : 협력사 간 SBOM 교환 자동화, 고객을 위한 인증 보고

7. 국내 산업의 대응 방향

우리 산업계는 이미 오픈소스 관리를 통한 SBOM 활용의 기초를 쌓아왔다. 한화시스템, 삼성전자, LG CNS 등 대기업은 OSS 라이선스 관리부터 SBOM 기반의 취약점 관리로 점진적 확장을 진행 중이다.

중소기업도 SBOM 도입은 충분히 가능하다.

• SW 시스템의 규모가 작아 상대적으로 형상 관리가 쉽다.

• 오픈소스 도구(Syft+Grype, FOSS Light 등)를 활용하여 무상으로 시작할 수 있다.

• SBOM 표준(SPDX, CycloneDX)과 연계해 신속하게 구축할 수 있다.

• 오픈소스 보안 재단(OpenSSF) 같은 커뮤니티가 상호운용성 자동화를 위한 도구를 제공한다.

다만 SBOM 도입 후에는 ‘잔존 취약점의 폭발적 증가’ 현상을 경험하게 된다. 이는 시스템이 문제가 많아서가 아니라 기존에 없던 ‘가시성’이 생겼기 때문이다. 이 단계에서 실질적인 보안 역량 강화로 전환할 수 있도록 보안 인식 제고와 취약점 대응 교육이 병행되어야 한다.

8. 새로운 확장: SBOM에서 AI·SaaS·IoT로

SBOM 기술은 이제 AI, SaaS, IoT 영역으로 확장되고 있다.

• AIBOM (AI Bill of Materials) : AI 모델의 데이터 세트, 알고리즘, 파라미터 투명성 확보

• SaaSBOM : 클라우드 서비스 형태의 애플리케이션 구성요소 관리

• IoT SBOM : 의료기기, 자동차, 스마트홈 등 내장형 시스템의 보안 인증 기반으로 요구 증가

이러한 확장은 공급망 보안을 ‘단일 기관의 책임’이 아닌 ‘분산형 팀플레이 시스템’으로 전환한다. 각 생태계 참여자가 자신의 위치에서 주도적으로 위험을 관리하고, 정보 공유 분석센터(ISAC) 같은 분야별 거점(Hub)이 조직의 사일로(Silo) 현상을 해소해 주어야 한다.

9. 성공적인 SBOM 운영을 위한 조건

1. 정책적 지원 : 정부 차원의 가이드라인 2.0과 산업별 적용 범위 제시

2. 교육과 인식 개선 : 투명성은 실패의 용인을 전제로 한다. SBOM 도입 초기에 드러나는 문제를 ‘조직의 취약함’이 아닌 ‘학습 자산’으로 이해해야 한다.

4. 실증 중심 도입 : Pilot 프로젝트로 시작하여 프로세스와 위기 대응 체계를 경험적으로 확립

5. 자동화 기반 데이터 교류 : SBOM 공유 및 갱신을 수동 관리가 아닌 API 기반 자동화로 운영

6. 신뢰 중심의 생태계 조성 : 규제가 아닌 협력과 검증 체계로 SBOM을 운영해야 한다.

10. 결론: SBOM, 규제가 아닌 혁신의 언어

SBOM 보안의 궁극적 목표는 단순한 문서 제출이 아니다. 공급망을 구성하는 모든 참여자가 “투명성과 신뢰”를 공유하기 위한 데이터 기반 협력체계를 마련하는 것이다. 디지털 제품의 70~80%가 오픈소스로 구성된 현실에서, SBOM 없이 보안을 논하는 것은 “부품 목록 없는 공장의 품질 관리”와 같다. SBOM은 각 조직의 보안 수준을 판단하는 기준일 뿐 아니라, 미래 국가 사이버보안 역량의 한 축을 담당한다.

SBOM이 ‘규제’로 끝날 것인지, 아니면 ‘공유 기술’로 발전할지는 산업과 정책이 어떻게 상호작용을 하느냐에 달려 있다. 진정한 신뢰는 제도나 도구가 아니라, 실행되는 절차의 투명성과 지속적인 인식 확대에서 얻어진다. 공급망 보안은 혼자의 일이 아니다. 이제는 모든 조직이 서로의 ‘컴포넌트’로 연결된 거대한 네트워크 안에서, 각자의 역할을 다해야 한다. SBOM은 그 협력의 언어이자, 디지털 신뢰의 지도이다.

최윤성 교수 現 고려대학교 SW·AI융합대학원 SW보안학과 교수(강사) 現 경기대학교 AI컴퓨터학부 SW안전보안전공 교수(겸임) 現 대통령 직속 국가인공지능(AI) 전략위원회 민간위원 (보안TF) 現 과기정통부 ‘SW 공급망 보안 포럼’ 정책·산업 분과장 現 리눅스재단, Member of OpenSSF Program Committee   ※ SW공급망보안 가이드라인 1.0 저자 (과기정통부, 국정원, 디플정위)