SBOM(Software Bill of Materials)은 소프트웨어에 들어간 구성요소의 목록이다. 오픈소스와 상용 라이브러리, 외주 코드 등의 이름·버전·출처를 기록해 무엇에 의존하는지 보여 준다.
지금 중요한 이유는 연결이 코드 밖으로도 넓어졌기 때문이다. 클라우드와 SaaS, 외주 업체가 내부 시스템이나 민감한 데이터에 접근한다. 우리가 무엇에 의존하는지 모르면 어디가 약한 고리인지도 알 수 없다(KCBCA Signals p.20–21).
그래서 만들고 끝내면 안 된다.
검토할 때 사실이었다고 지금도 사실이라는 보장은 없기 때문이다(p.21). 배포에 맞춰 목록을 갱신하고 출처와 검토 증거를 계속 확인해야 한다. 10월 1일 보도된 CPS 보안 워크숍 발표도 생성 자체보다 구성요소를 계속 식별·관리·공유하는 체계를 강조했다(데일리시큐).
SBOM 뜻, 목록에는 무엇을 적는가?
하나의 소프트웨어에는 직접 작성한 코드뿐 아니라 AI가 만든 코드, 외주 협력사의 코드, 오픈소스와 상용 라이브러리도 들어간다(데일리시큐 10/1). 이 목록에는 구성요소를 다음과 같이 기록한다.
| 항목 | 담는 내용 |
|---|---|
| 구성요소 이름 | 어떤 라이브러리·패키지가 들어 있는지 |
| 버전 | 정확히 어느 버전을 쓰는지 |
| 공급자·출처 | 누가 만들었고 어디서 받아 왔는지 |
| 의존 관계 | 어떤 구성요소가 무엇에 기대는지 |
| 라이선스 | 어떤 조건으로 쓸 수 있는지 |
| 식별자·해시 | 같은 파일인지 확인할 고유값 |
목록이 있으면 취약점이 새로 공개됐을 때 영향받는 서비스를 바로 찾을 수 있다(데일리시큐 10/1). 소프트웨어 공급망 보안과 의존성 관리의 출발점이다.
의존 지도는 코드 밖까지 그려야 한다
회사가 기대는 것은 패키지만이 아니다. 클라우드, SaaS, 결제대행, 외주 업체, API, 오픈소스, AI 도구가 내부 시스템이나 민감한 데이터에 접근하기도 한다(p.20). 내부 통제가 튼튼해도 이런 연결을 통해 제3자 위험을 떠안을 수 있다.
의존 지도에 적을 네 가지 (p.21) ① 무엇에 접근할 수 있는가? ② 어떤 데이터를 다루는가? ③ 어떤 소프트웨어·서비스를 들여오는가? ④ 어떤 업무가 여기에 기대는가?
공격자는 가장 튼튼한 회사를 정면으로 뚫을 필요가 없다. 이미 신뢰받는 통로를 가진 작은 협력사나 의존성을 거쳐 들어올 수 있다(p.20).
외부 패키지가 들어오는 길목을 확인한다
한 연구기관에서 AI 코딩 에이전트가 존재하지 않는 패키지 이름을 반복해서 지어냈고, 공격자는 그 이름으로 악성 패키지를 공개 저장소에 올렸다. 이후 빌드가 이를 가져오며 연구 자료가 몰래 유출됐다(p.16–17).
제시된 조치는 AI 코딩 에이전트와 빌드 파이프라인이 공개 패키지 저장소에 제한 없이 접근하지 못하게 하는 것이다. 외부 의존성은 선별된 사설 미러를 거치게 하고, 사용 전에 출처를 암호학적으로 검증하며 패키지 등록 경과 기간과 행위를 확인한다(p.17).
이런 공격 방식은 10월 13일 '공급망 공격' 글에서 자세히 다뤘다.
검토한 증거도 시간이 지나면 낡다
위험한 가정은 '검토할 때 사실이었으니 지금도 사실일 것'이라는 생각이다(p.21). 점검 보고서는 새 보고서로 대체되고, 인증은 만료되고, 고친 취약점이 다시 열릴 수 있다. 그동안 예전 PDF만 믿고 있을 수 있다(p.21).
SBOM도 배포·업데이트에 맞춰 다시 만들고 버전을 남겨야 한다. 증거는 누가 제공했고 언제 승인했는지, 어느 버전을 검토했으며 이후 파일이 바뀌었는지 추적할 수 있어야 한다(p.21).
여러 곳이 같은 서비스를 쓸 때의 집중 위험
의존 지도를 그리면 여러 회사가 같은 서비스에 기대고 있는지도 보인다. 거래 확인 정보를 주는 공용 서비스가 침해되면, 각자 지갑을 지킨 회사들도 해로운 거래를 동시에 승인할 수 있다. 그 서비스가 복구까지 맡는다면 대응도 함께 어려워질 수 있다(p.33).
2026년 9월, 클라우드 학습관리시스템(LMS) 제공 업체가 침해된 뒤 이 서비스를 쓰던 웹사이트 22곳에서 개인정보가 유출된 것이 확인됐다(보안뉴스 9/30).
함께 쓰는 도구와 공급사를 찾고, 그 서비스가 없어도 복구할 수 있는지 시험해 두어야 한다(p.33).
SBOM 의무화, 어디까지 확인됐나?
유럽연합 사이버복원력법(CRA)은 2024년 12월 10일 발효됐다. 신고 의무는 2026년 9월 11일부터, 주요 의무는 2027년 12월 11일부터 적용된다(유럽연합 집행위원회). 규정 전문(前文) 제77항은 디지털 요소가 있는 제품의 제조사가 SBOM 작성 등을 통해 구성요소를 식별·문서화해야 한다고 설명한다(EUR-Lex, 규정 2024/2847).
국내 'SW 공급망 보안 가이드라인'은 구성요소 명세서 검증, 소프트웨어 구성요소 관리, 명세서에 기반한 공급망 보안 관리 방법을 안내한다 (한국인터넷진흥원, 공공데이터포털).
SBOM 도입 체크표
| 점검 항목 | 이렇게 확인한다 | 근거 |
|---|---|---|
| 코드 밖 의존 | 클라우드·SaaS·외주·API·AI 도구도 지도에 넣는다 | p.20 |
| 패키지 유입 경로 | 공개 저장소 직행 대신 출처를 검사하는 사설 미러를 거친다 | p.17 |
| 배포 시 갱신 | 배포 때마다 목록을 다시 만들고 버전을 남긴다 | 데일리시큐 |
| 증거 상태 | 보고서 대체·인증 만료·취약점 재발을 확인한다 | p.21 |
| 새 취약점 대응 | 공개된 취약점을 목록과 바로 대조한다 | 데일리시큐 |
| 공통 의존 | 함께 쓰는 서비스 없이도 복구되는지 시험한다 | p.33 |
| 책임자 | 갱신·확인 책임과 모니터링 담당을 정한다 | p.16 |
자주 묻는 질문
Q. 작은 회사도 SBOM이 필요한가?
규모가 작아도 오픈소스와 SaaS를 쓰고, 다른 회사의 공급망에 연결돼 있다(p.20). 우선 핵심 제품 하나의 구성요소부터 기록하고 배포할 때마다 갱신해 본다.
Q. SBOM만 있으면 안전한가?
아니다.
구성요소 목록은 무엇이 들어 있는지 보여 주지만 안전을 증명하지는 않는다. 증거 이력을 남겨도 내용이 참이라는 보장은 아니다(p.21). 새 취약점과 대조하고 조치하며 갱신해야 한다.
Q. 누가 관리해야 하는가?
만드는 사람과 별도로 갱신·확인 책임자를 정해야 한다. KCBCA Signals는 의존성 경계의 책임과 모니터링을 이사회 감독 아래 지정하도록 제안한다(p.16).
한눈에 정리
- SBOM은 소프트웨어 구성요소의 목록이자 의존성 관리의 출발점이다
- 의존 지도에는 클라우드·SaaS·외주·API·AI 도구도 넣는다(p.20–21)
- 배포에 맞춰 목록을 갱신하고 증거의 만료·변경을 추적한다(p.21)
- 함께 쓰는 서비스 없이도 복구되는지 시험한다(p.33)
소프트웨어 공급망 보안과 AI 시대의 신뢰를 더 살펴보고 싶다면 KCBCA Signals 보고서를 읽어 본다.
KCBCA Signals Vol.1 Issue 1 원문 읽기
참고: KCBCA Signals Vol.1 Issue 1 Rob Goehring(Wisr.ai CEO) p.20–21 Jack Wong(Scryer CEO, KCBCA GLOBAL 이사) p.16–17 Marc Krisjanous(Zanarc 창업자·수석 컨설턴트) p.33 보도: 데일리시큐 10/1(CPS 보안 워크숍, 스패로우 여구용 본부장), 보안뉴스 9/30 공식 자료: 유럽연합 집행위원회, EUR-Lex 2024/2847, 한국인터넷진흥원
