SBOM이란 — 소프트웨어 부품표, 로그4j 때 80곳 중 한 곳도 이걸로 찾지 못했다

2021년 12월, 전 세계 보안팀이 같은 질문 하나에 몇 주를 썼다. "우리 시스템 어디에 로그4j가 들어 있나?" 자바 로깅 라이브러리 로그4j(Log4j)에 원격 코드 실행 취약점(Log4Shell)이 공개됐을 때, 대부분의 기관은 자기 소프트웨어에 그 부품이 들어 있는지조차 바로 알지 못했다. 미국 사이버안전검토위원회가 첫 보고서에서 살핀 약 80개 기관 가운데 소프트웨어 목록으로 취약 지점을 찾은 곳은 한 곳도 없었다. 그 목록이 SBOM(Software Bill of Materials, 소프트웨어 부품표)이다. 앤트로픽이 오픈소스 프로젝트에 무료 AI 보안 스캔을 열고(「앤트로픽 사이버 미션」), 유럽연합이 제조사 신고 의무를 시작한 2026년 가을, 이 목록이 다시 보안의 출발점으로 불려 나온다.

1. SBOM에는 무엇이 들어가나

식품 포장의 성분표처럼, SBOM은 소프트웨어가 무엇으로 만들어졌는지를 적는다. 차이는 사람이 아니라 기계가 읽도록 만든다는 점이다. 그래야 새 취약점 목록과 자동으로 대조할 수 있다.

이 가운데 가장 중요한 것이 의존 관계다. 개발자가 직접 넣은 라이브러리는 수십 개여도, 그 라이브러리가 다시 끌어오는 '간접 의존' 부품은 수백 개가 된다. 로그4j가 찾기 어려웠던 이유도 대부분 이 간접 의존 깊숙이 들어 있었기 때문이다. 악성 패키지가 의존 관계를 타고 퍼지는 방식은 「npm 공급망 공격이란」에 정리했다.

2. SBOM이 있을 때와 없을 때

보안업체 테너블은 로그4j 당시 대부분의 납품업체가 SBOM을 주지 않아 대응팀이 업체마다 직접 물어야 했고, 그 과정이 "고되고 중복되며 시간이 많이 든다"고 정리했다. 오픈소스 보안 보고서(OSSRA 2022)도 쉴 새 없는 대응의 원인을 '로그4j가 어디 있는지, 있기는 한지 몰랐다는 것'으로 꼽았다.

다만 SBOM은 필요조건이지 충분조건이 아니다. 목록은 무엇이 들어 있는지 알려 줄 뿐, 그 부품이 이미 패치됐는지, 실제로 공격에 쓰일 수 있는 경로에 있는지는 알려 주지 않는다. 그래서 SBOM과 함께 '이 취약점이 우리 제품에서 실제로 악용 가능한가'를 적는 VEX(취약점 악용 가능성 정보) 문서를 붙이는 방식이 쓰인다. 취약점의 심각도를 매기는 기준은 「CVSS란」, 패치가 없는 취약점의 위험은 「제로데이란」에 있다.

3. 누가 요구하나 — 미국 조달에서 유럽 의무로

유럽연합 사이버복원력법은 유럽에서 팔리는 '디지털 요소가 있는 제품' 전반에 적용된다. 해설 자료들에 따르면 위반 시 최대 1,500만 유로 또는 전 세계 연 매출의 2.5% 가운데 큰 금액이 과징금으로 매겨질 수 있다. 한국 기업도 유럽에 제품을 팔면 대상이 된다. CISA 초안은 SPDX와 CycloneDX를 자동화에 적합한 표준 형식으로 꼽으면서, 서비스형 소프트웨어(SaaS)와 AI 소프트웨어는 전통적인 SBOM 모델로 다 담기 어렵다고 인정했다.

4. AI 시대의 SBOM — 남은 과제와 확인되지 않은 것

• AI 모델 부품표: AI 시스템에는 코드뿐 아니라 모델 가중치·학습 데이터·외부 API가 들어간다. 이를 담는 'AI-BOM' 논의가 있지만 정착된 표준은 아직 없다. CISA 초안도 AI 소프트웨어를 과제로 남겼다.
• AI가 찾는 취약점의 홍수: AI 스캐너가 찾아내는 후보 취약점은 사람이 검토하는 속도보다 빠르다. 어느 부품이 어디 쓰이는지 아는 SBOM이 있어야 우선순위를 정할 수 있다(「앤트로픽 사이버 미션」).
• CISA 최종본: 2025년 최소 요소 개정안이 최종 확정됐는지와 초안과의 차이는 확인하지 못했다.
• 세부 기한 해석: CRA 신고 의무의 최종 보고서 기한 등은 해설마다 표현이 조금씩 다르다. 법 원문으로 확인이 필요하다.
• 한국 제도: 국내 공공 조달·가이드라인의 SBOM 적용 범위는 이 글에서 다루지 않았다.