SBOM(소프트웨어 자재명세서)과 공급망 취약점 대응 사례 분석

이 글은 공개된 1차출처(미국 NTIA의 SBOM 최소요소 보고서, CISA SBOM 페이지, NIST의 행정명령 14028 안내)와 독립 분석 글 여러 건을 교차 읽고 우리 관점에서 다시 쓴 정보성 정리본입니다. 특정 문장·코드를 그대로 옮기지 않았으며, 자세한 내용은 하단 참고자료의 원문을 참고하세요.

Security · 공급망·소프트웨어 · 개념정리 [정보성]

요즘 소프트웨어는 처음부터 끝까지 한 팀이 짜는 경우가 드뭅니다. 외부 라이브러리와 오픈소스 조각을 쌓아 올려 조립하는 쪽에 가깝습니다. 그래서 새 취약점이 하나 터지면 “우리 제품 안에 그게 들어 있나?”라는 단순한 질문에 답하기가 의외로 어렵습니다. SBOM(Software Bill of Materials, 소프트웨어 자재명세서)은 바로 그 질문에 빠르게 답하기 위한 재료 목록입니다. 이 글은 SBOM이 무엇이고, 왜 공급망 취약점 대응의 기초 체력으로 꼽히는지, 그리고 혼자서는 무엇을 못 하는지를 정리합니다.

소프트웨어 공급망 사고의 상당수는 “무엇이 들어 있는지 몰라서” 대응이 늦어집니다. 취약점 자체보다 가시성 부족이 피해를 키우는 구조입니다. SBOM은 이 구조적 약점을 겨냥한 투명성 도구이고, 그래서 최근 몇 년간 정부·업계가 한목소리로 밀어 온 기본기입니다.

핵심 사실 요약

SBOM이란 무엇인가 (30초 개념)

SBOM은 하나의 소프트웨어가 어떤 컴포넌트로 이루어졌고 그들이 서로 어떤 공급망 관계를 맺는지를 담은 공식 기록입니다. 미국 상무부 산하 NTIA는 SBOM을 “소프트웨어를 만들고, 사고, 운영하는 쪽 모두에게 공급망에 대한 이해를 높여 주는 정보”라고 설명합니다. CISA는 더 직관적으로 “소프트웨어 컴포넌트를 이루는 재료의 목록, 곧 중첩된 인벤토리”에 비유합니다. 요리로 치면 완성된 음식 사진이 아니라 성분표에 가깝습니다.

왜 필요한가 — 투명성이 없으면 비용이 커진다

NTIA는 소프트웨어 구성에 대한 투명성이 없을 때 “기여자·구성·기능을 들여다볼 수 없어 사이버 위험이 커지고 개발·조달·유지보수 비용도 올라간다”고 짚습니다. 핵심은 취약점 관리입니다. NTIA는 SBOM이 의존성 전반의 투명성을 제공해 “새로 발견된 취약점의 위험을 더 빠르고 정확하게 평가하게” 해 주며, 취약점 식별과 대응 속도를 모두 끌어올린다고 설명합니다.

이 효용은 추상적인 주장이 아니라 실제 사건에서 드러났습니다. 2021년 말 Log4Shell 사태가 대표적입니다. 문제의 Log4j 라이브러리는 대개 전이(transitive) 의존성으로, 즉 내가 직접 가져온 게 아니라 내가 쓰는 라이브러리가 다시 끌어온 형태로 의존성 트리 깊숙이 묻혀 있었습니다. 인벤토리가 없는 팀은 코드베이스와 컨테이너 이미지를 손으로 뒤져야 했습니다. 반면 SBOM이 갖춰져 있으면 새 CVE가 뜰 때 쿼리 한 번으로 영향받는 애플리케이션과 버전을 드러낼 수 있습니다. Log4j 사태가 많은 조직이 자기 환경을 제대로 들여다보지 못한다는 사실을 드러냈다는 진단은 여러 독립 분석(InformationWeek·SC Media)이 공통적으로 내놓은 것입니다. CISA 자신은 SBOM을 소프트웨어 보안과 공급망 위험 관리의 핵심 구성요소로 규정합니다.

무엇이 들어가나 — 최소 요소와 표준 포맷

NTIA는 2021년 보고서에서 SBOM의 최소 요소를 세 범주로 제시합니다. 데이터 필드(Data Fields), 자동화 지원(Automation Support), 실무·프로세스(Practices and Processes)의 세 축입니다.

이 가운데 데이터 필드는 컴포넌트마다 담아야 할 최소 항목 일곱 가지로 정해져 있습니다.

이 일곱 항목의 목표는 컴포넌트를 공급망 전반에서 추적할 수 있을 만큼 식별하고, 취약점 데이터베이스 같은 유용한 데이터와 연결(map)할 수 있게 하는 것입니다. 쓰임새로는 생산자·운영자의 인벤토리·취약점·라이선스 관리, 그리고 구매자의 위험 평가가 꼽힙니다.

포맷도 아무렇게나 적으면 안 됩니다. NTIA가 상호운용 가능한 데이터 포맷으로 인정한 것은 SPDX, CycloneDX, SWID 태그 세 가지입니다. SBOM은 이 중 하나의 상호운용 포맷으로 조직 경계를 넘어 전달돼야 합니다. 독립 분석에 따르면 SPDX는 Linux Foundation에서 나왔고 국제표준(ISO/IEC 5962:2021)으로 등재됐으며, CycloneDX는 OWASP에서 나와 보안·취약점 추적에 초점을 둔 포맷입니다. (⚠️미확인: SPDX의 ISO 번호는 특정 버전 기준 표기로, 이후 버전에서 표준이 갱신됐는지는 이번 정리에서 확인하지 못했습니다.)

중요한 점은 SBOM이 사람이 읽는 문서가 아니라 기계가 읽는 데이터여야 한다는 것입니다. NTIA는 취약점 식별·분석·완화가 “자동화와 도구 통합을 지원하고 애플리케이션이 질의·처리할 수 있는 기계가독 SBOM이라야” 실현된다고 못 박습니다. 종이 성분표로는 수천 개 의존성을 즉시 교차 검색할 수 없기 때문입니다.

제도적 배경과 VEX라는 짝꿍

SBOM 논의가 빠르게 제도화된 계기는 2021년 5월 12일 발효된 미국 행정명령 14028(EO 14028)입니다. 이 명령은 NTIA에 60일 안에 SBOM 최소 요소를 공표하도록 지시했고, 연방에 소프트웨어를 납품하는 벤더에게 SBOM 제공을 요구하는 방향을 세웠습니다. (⚠️미확인: 벤더의 SBOM 제공 의무 시점을 2023년 9월로 적은 2차 자료가 있으나 구속력 있는 날짜인지 1차 문서로 확증하지 못했습니다. 또한 EO 14028이 이후 폐지됐다는 2차 요약도 있으나 관보·행정명령 1차출처로 교차확인하지 못했습니다 — 둘 다 별도 1차 확인이 필요합니다.)

SBOM과 자주 함께 거론되는 짝이 VEX(Vulnerability Exploitability eXchange)입니다. SBOM이 “무엇이 들어 있나”를 말한다면, VEX는 “그 취약점이 이 제품에 실제로 영향을 주는가”를 단언하는 문서입니다. CISA는 VEX를 “특정 제품(들)이 알려진 취약점의 영향을 받는지 여부를 가리키는 증언(attestation)“으로 설명합니다. 컴포넌트에 취약점이 들어 있어도 실제로는 영향받지 않는(not_affected) 경우를 걸러 내, SBOM만으로는 판정하기 어려운 실제 악용 가능성을 보완합니다. CycloneDX가 VEX를 지원하는 포맷으로 꼽힙니다.

SBOM만으로는 부족하다 — 재료 목록이지 경호원이 아니다

SBOM은 강력한 출발점이지만 그 자체가 방어는 아닙니다. 독립 분석들은 SBOM 단독의 한계를 이렇게 정리합니다. 첫째, 취약한 컴포넌트가 실제로 인터넷에 노출돼 있는지는 알려 주지 않습니다. 둘째, 취약한 함수가 실제 호출 경로상에서 도달 가능한지(reachable), 즉 정말 쓰이는 코드인지는 말해 주지 않습니다. 셋째, CISA의 KEV(알려진 악용 취약점) 카탈로그나 EPSS(악용 예측 점수) 같은 위협 인텔과 자동으로 교차참조해 주지도 않습니다. 그래서 효과적인 대응에는 SBOM 위에 위협 인텔 보강, 우선순위화, 그리고 “이 컴포넌트는 누구 담당인가”를 잇는 소유권 매핑이 함께 필요합니다. 성분표를 손에 쥐는 것과 실제로 요리를 안전하게 내는 것은 다른 일입니다.

이 한계론은 우리가 다른 글에서 반복해 다룬 주제와 같은 뿌리입니다. 취약점의 “존재”와 “도달 가능성·악용 가능성”을 구분하는 사고입니다. 정적으로 취약한 코드가 있다는 사실과, 그 코드가 실제 입력 경로에서 닿아 악용된다는 사실은 전혀 다른 층위입니다. SBOM은 전자를 기계가독으로 만들어 주는 도구이고, VEX와 reachability 분석은 후자로 좁혀 주는 도구입니다. 둘을 같은 것으로 착각하면 “성분표가 곧 안전”이라는 잘못된 안도에 빠집니다.

대응방안

• 먼저 갖추기: 생산·조달하는 소프트웨어에 대해 기계가독 SBOM(SPDX·CycloneDX·SWID 중 하나)을 확보해 두면, 신규 CVE가 떴을 때 영향 범위 질의를 즉시 돌릴 수 있습니다.
• SBOM만으로 끝내지 않기: SBOM에 VEX, KEV·EPSS 같은 위협 인텔, 노출·도달 가능성 판단을 얹어 우선순위를 매깁니다. 재료 목록은 시작이지 결론이 아닙니다.
• 운영 관점: 컴포넌트별 소유권을 미리 매핑해 두면, 영향 범위가 드러난 다음 패치 책임자를 찾는 시간을 줄일 수 있습니다.

SBOM 한 장이 공급망 보안을 끝내 주지는 않습니다. 다만 “우리 안에 무엇이 있는지”를 기계가 읽을 수 있게 적어 두는 이 기초 작업이 없으면, 다음 Log4Shell이 왔을 때 또 코드베이스를 손으로 뒤지게 됩니다. 그래서 우리는 이것을 특별한 묘기가 아니라 기본기로 다룹니다.

References / 참고자료

1. NTIA (美 상무부), “The Minimum Elements for an SBOM” (2021, PDF, 1차) — 7개 데이터 필드·3개 범주·상호운용 포맷·취약점 대응 효용의 핵심 근거. https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf
2. NTIA Blog, “NTIA Releases Minimum Elements for a Software Bill of Materials” (1차 요약) — 정의와 사용처 공식 발표. https://www.ntia.gov/blog/ntia-releases-minimum-elements-software-bill-materials
3. CISA, “Software Bill of Materials (SBOM)” (1차) — SBOM 정의, 공급망 위험 관리에서의 역할, VEX 설명. https://www.cisa.gov/sbom
4. NIST, “Software Supply Chain Security Guidance under EO 14028” (1차) — 행정명령 14028의 맥락. https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance-20
5. Wiz, “What is an SBOM?” · “Guide to Standard SBOM Formats” (2차 분석) — Log4Shell·전이 의존성, SPDX/CycloneDX/VEX. https://www.wiz.io/academy/application-security/software-bill-of-material-sbom · https://www.wiz.io/academy/standard-sbom-formats
6. J.M. Porup, CSO Online, “SBOM formats SPDX and CycloneDX compared” (2차 분석) — 포맷 비교와 ISO 표준 등재. https://www.csoonline.com/article/573291/sbom-formats-spdx-and-cyclonedx-compared.html
7. ArmorCode, “Your SBOM Is a Grocery List, Not a Bodyguard” (2차 의견) — SBOM 단독의 한계(도달 가능성·KEV·EPSS). https://www.armorcode.com/blog/your-sbom-is-a-grocery-list-not-a-bodyguard
8. SC Media, “SBOM is an ingredient, not the whole recipe…” (2차 분석) — Log4j 맥락에서의 SBOM 한계론. (⚠️미확인: 이번 정리 시점에 이 URL이 접근 차단(HTTP 403)돼 본문을 직접 대조하지 못했습니다. 링크·제목은 실재하며 해당 한계론은 아래 7·9번으로 교차 보강됩니다.) https://www.scworld.com/analysis/asset-management/sbom-is-an-ingredient-not-the-whole-recipe-in-preventing-the-next-log4j-breakdown
9. InformationWeek, “Log4J Attacks Confirm Need for DevSecOps, Automation, SBOM” (2차 분석) — Log4j가 SBOM 필요성을 입증했다는 분석. https://www.informationweek.com/software-services/log4j-attacks-confirm-need-for-devsecops-automation-sbom

이 글은 위 공개 출처들을 우리 관점에서 다시 쓰고 정리한 정보성 글입니다. 특정 문장·코드를 그대로 옮기지 않았으며, 자세한 내용은 원문을 참고하세요.