와이즈스톤 와이즈스톤

기술인사이트

기술리포트

보안 품질 관리의 첫걸음 SBOM
  • 작성자
    와이즈스톤 김홍기 이사
  • 작성일
    2026-04-02
SBOM
소프트웨어 공급망 보안의 새로운 표준


1. SBOM이란 무엇인가?
SBOM(Software Bill of Materials)은 우리말로 '소프트웨어 자재명세서'라고 부릅니다. 이 개념은 제조업에서 수십 년간 사용해 온 BOM(Bill of Materials), 즉 제품을 구성하는 모든 부품과 원자재를 체계적으로 나열한 문서에서 비롯됩니다. 자동차 한 대를 만들기 위해 어떤 강철, 어떤 전자부품, 어떤 플라스틱이 몇 개나 들어가는지를 기록하듯, SBOM은 하나의 소프트웨어 제품이 어떤 오픈소스 라이브러리, 어떤 서드파티 컴포넌트, 어떤 독자 코드 모듈로 구성되어 있는지를 계층적으로 기록한 공식 문서입니다.

현대 소프트웨어는 전체 코드의 70~90%가 외부에서 가져온 컴포넌트로 이루어져 있습니다. 개발자가 직접 작성하는 코드는 소수에 불과하며, 나머지는 수백 개의 오픈소스 패키지와 그 패키지들이 다시 의존하는 또 다른 패키지들로 채워집니다. 이 복잡한 의존성 그래프를 한눈에 파악할 수 있도록 정리한 것이 바로 SBOM입니다.


핵심 정의 -
SBOM이란 소프트웨어를 구성하는 모든 컴포넌트·라이브러리·의존성의 이름, 버전, 출처, 라이선스, 해시값 등을 기계가 읽을 수 있는 형태로 기록한 투명성 문서입니다. 쉽게 말해 '이 소프트웨어의 재료 목록'입니다.



NTIA가 정의한 SBOM 최소 구성 요소

미국 국가통신정보청(NTIA)은 SBOM이 최소한으로 갖춰야 할 7가지 데이터 필드를 정의했습니다. 공급자명, 컴포넌트명, 버전 문자열, 고유 식별자, 의존성 관계, 작성자, 타임스탬프가 그것입니다. 여기서 고유 식별자는 패키지 URL(PURL)이나 CPE 형식을 사용하며, 취약점 데이터베이스와의 자동 매핑을 가능하게 하는 핵심 필드입니다.




2. 왜 SBOM이 필요한가?

2021년 12월, 전 세계 보안 담당자들은 한 줄의 CVE 번호 때문에 잠을 설쳤습니다. CVE-2021-44228, 흔히 Log4Shell이라 불리는 Apache Log4j의 원격 코드 실행 취약점이 공개된 것입니다. CVSS 최고점인 10.0점을 기록한 이 취약점의 문제는 단순히 취약점 자체의 심각성에만 있지 않았습니다. 대부분의 기업이 자사 제품 어딘가에 Log4j가 포함되어 있다는 사실조차 즉각 파악하지 못했다는 것이 더 큰 문제였습니다. 어떤 서버에, 어떤 버전이, 몇 개나 있는지를 확인하는 데만 며칠이 걸렸습니다. SBOM이 갖춰져 있었다면 이 확인 작업은 수 분 안에 끝났을 것입니다.


Log4Shell이 가르쳐 준 교훈 —
취약점보다 더 위험한 것은 '내 소프트웨어에 무엇이 들어 있는지 모르는 것'입니다.
SBOM은 공급망 전체에 대한 가시성을 확보하여
사고 발생 시 영향 범위를 즉시 파악할 수 있게 해줍니다.


SBOM이 해결하는 네 가지 핵심 문제

첫째, 취약점 신속 탐지입니다.
새로운 CVE가 발표되면 SBOM에 기록된 컴포넌트 버전 정보와 자동으로 대조하여 영향 받는 시스템을 즉시 식별할 수 있습니다. 이 과정이 자동화되면 수작업으로 수일이 걸리던 취약점 영향 분석이 수 분 내로 단축됩니다.

둘째, 라이선스 컴플라이언스입니다.
오픈소스 라이브러리는 각기 다른 라이선스 조건을 가지고 있습니다. GPL, MIT, Apache 2.0 등 수십 가지 라이선스가 혼재하는 환경에서 상업적 배포 시 준수해야 할 의무 사항을 자동으로 검사하고 충돌을 사전에 방지하는 데 SBOM이 필수적입니다.

셋째, 공급망 투명성입니다.
소프트웨어를 구매하거나 도입하는 기관·기업 입장에서는 납품받은 제품이 어떤 구성 요소로 이루어져 있는지 검증할 권리가 있습니다. SBOM은 이 투명성의 근거 문서로서, 납품자와 수요자 사이의 신뢰를 기술적으로 뒷받침합니다.

넷째, 규제 대응입니다.
미국 행정명령, EU 사이버복원력법, 국내 디지털의료제품법 등 주요 규제들이 SBOM 제출을 의무화하거나 요건으로 포함하고 있습니다. 이제 SBOM은 선택이 아닌 시장 진입의 전제 조건이 되고 있습니다.


3. 국내외 SBOM 정책 동향
SBOM을 처음으로 국가 차원에서 제도화한 것은 미국입니다. 2021년 5월, 바이든 행정부는 행정명령(EO 14028)을 통해 연방기관에 소프트웨어를 납품하는 모든 기업에 SBOM 제공을 의무화했습니다. 같은 해 국가통신정보청(NTIA)은 SBOM의 최소 구성 요소와 운용 개념을 공식 정의했고, 사이버보안인프라국(CISA)은 2025년 이를 업데이트하여 출처, 무결성 인증 등 메타데이터 요건을 대폭 확대했습니다. 의료기기 분야에서는 2023년 FDA가 인터넷 연결 의료기기의 인허가 심사에 SBOM 제출을 의무화하면서 규제의 강도를 한층 높였습니다.

유럽연합은 미국보다 더 광범위한 규제를 준비하고 있습니다. EU 집행위원회가 2022년 제안한 사이버복원력법(Cyber Resilience Act, CRA)은 유럽 내에서 판매되는 모든 디지털 제품에 대해 SBOM을 포함한 사이버보안 기술문서 제출을 의무화합니다. 세부 요건은 현재 표준화 기구에서 논의 중이며, 2027년부터 본격 시행될 예정입니다. 위반 시 최대 1,500만 유로 또는 연간 전 세계 매출의 일정 비율에 달하는 과징금을 부과할 수 있어, 미국보다 제재 강도도 상당히 높습니다. 일본은 민관 협력으로 개념검증(PoC) 프로젝트를 완료하고 2025년부터 광범위한 도입을 추진하고 있습니다.


주요국 규제 비교


국내 추진 경과
국내에서 SBOM에 대한 관심이 본격적으로 높아진 것은 미국 EO 14028 발표 이후입니다. 미국 연방정부에 소프트웨어를 납품하는 국내 기업들이 직접 영향을 받게 되면서 정부와 산업계 모두 대응 필요성을 인식하기 시작했습니다. 이어 Log4Shell과 같은 대형 공급망 사고들이 잇따르면서 SBOM 도입 논의는 더욱 가속화 되었습니다.

국내 추진 타임라인
2023~2024년: 과기정통부·국정원이 공동으로 '소프트웨어 공급망 보안 강화 가이드라인'을 발표하고 판교 테스트베드를 운영하며 SBOM 실증 사업을 추진했습니다.

2025년 1월 24일: 디지털의료제품법이 시행되면서 디지털의료기기 전자적 침해행위 보안 지침 제16조에 SBOM 관리 활동이 명시되었습니다. 현재는 권고 수준이지만 향후 인허가 의무화가 예상됩니다.

2025년: KISA가 40억 원 규모의 'SBOM 기반 SW 공급망 보안 모델 구축 지원사업'을 본격 시작했습니다. 개발·공급 기업과 도입·운영 기업이 컨소시엄을 구성하여 전 주기 SBOM 활용 모델을 구축합니다.

2026년: 지원 범위가 기존 개발·공급 기업 중심에서 실제로 소프트웨어를 도입·운영하는 기업까지 확대되었습니다.

2027년(목표): 공공기관에 도입되는 IT시스템 및 소프트웨어 제품에 SBOM 제출이 의무화될 예정입니다.


4. SBOM 문서 작성 방법

① 표준 포맷 선택: SPDX vs CycloneDX
SBOM 문서를 작성할 때 가장 먼저 결정해야 할 사항은 어떤 표준 포맷을 사용할 것인가입니다. 현재 업계에서 가장 널리 쓰이는 두 가지 포맷은 SPDX와 CycloneDX입니다. 두 포맷 모두 JSON, XML 등 기계 판독 가능한 형식을 지원하며, 변환 도구를 통해 상호 전환도 가능합니다.

SPDX(Software Package Data Exchange)는 Linux Foundation이 주도하고 ISO/IEC 5962:2021로 표준화된 포맷으로, 라이선스 컴플라이언스에 특화되어 있습니다. 유일하게 ISO 인증을 받은 SBOM 표준이라는 점에서 정부 조달이나 글로벌 기업 납품 시 선호됩니다. 반면 CycloneDX는 OWASP Foundation이 만든 포맷으로, 보안 취약점 추적과 사이버보안 컨텍스트에 강점을 가집니다. 의료기기, 금융, 제조 등 보안이 핵심인 산업 분야에서 빠르게 채택되고 있으며, AI/ML 모델이나 SaaS까지 확장한 BOM 유형도 지원합니다.



② SBOM 생성 4단계 프로세스
SBOM은 반드시 자동화된 도구로 생성해야 합니다. 수작업으로 작성하면 누락과 오류가 불가피하며, 소프트웨어가 업데이트될 때마다 최신성을 유지하기도 어렵습니다. 이상적인 SBOM 생성 워크플로는 다음 네 단계로 구성됩니다.

STEP 1 — 컴포넌트 탐색
소스 코드를 분석하고 패키지 매니페스트(package.json, pom.xml, requirements.txt 등)를 파싱하여 직접 의존성과 전이적(transitive) 의존성을 모두 추출합니다. 이 단계에서 depth를 제한 하지 말고 전체 의존성 그래프를 빠짐없이 탐색해야 합니다.

STEP 2 — 메타데이터 수집
탐색된 각 컴포넌트에 대해 버전, SHA-256 해시, 라이선스 식별자, PURL(Package URL)을 수집하고 NVD(국가취약점데이터베이스)와 매핑하여 알려진 CVE 정보를 연결합니다.

STEP 3 — 포맷 변환·검증
수집된 정보를 선택한 표준(SPDX 또는 CycloneDX)의 스키마에 따라 변환하고, 도구를 이용해 유효성을 검사합니다. 이 단계에서 디지털 서명을 적용하면 SBOM의 무결성을 보장할 수 있습니다.

STEP 4 — CI/CD 통합·배포
생성된 SBOM을 빌드 파이프라인에 통합하여 새로운 릴리스마다 자동으로 갱신되도록 설정합니다. 생성된 SBOM은 버전 관리 시스템에 함께 저장하고, 취약점 자동 알림 시스템과 연동합니다.


③ CycloneDX JSON 실제 예시
다음은 CycloneDX 1.6 포맷의 SBOM 예시입니다. bomFormat, specVersion, metadata(작성 도구 및 대상 컴포넌트 정보), components(구성 라이브러리 목록), vulnerabilities(알려진 취약점) 섹션으로 구성됩니다.




④ SBOM 작성 핵심 원칙
SBOM 작성에서 가장 중요한 원칙은 다섯 가지입니다. 자동화, 완전성, 일관성, 최신성, 검증이 그것입니다. 각 원칙의 내용과 실무 체크포인트를 아래 표에 정리했습니다.



5. 주요 SBOM 도구 및 결론

오픈소스 SBOM 생성·분석 도구
현재 생태계에는 다양한 오픈소스 및 상용 SBOM 도구가 존재합니다.
대표적인 오픈소스 생성 도구로는 Anchore의 Syft와 OWASP의 cdxgen이 있습니다. Syft는 컨테이너 이미지, 파일시스템, 아카이브 등에서 SBOM을 생성하며 SPDX와 CycloneDX를 모두 지원합니다. cdxgen은 20개 이상의 언어 생태계를 지원하고 CI/CD 통합에 최적화되어 있습니다. 포맷 변환과 검증에는 CycloneDX CLI가 유용하며, 라이선스 컴플라이언스와 취약점 스캔을 통합한 상용 플랫폼으로는 FOSSA, Snyk, Black Duck 등이 있습니다.






6.결론

SBOM은 더 이상 보안 전문가들만의 관심사가 아닙니다. 소프트웨어를 개발하거나 도입하는 모든 조직이 직면해야 할 현실입니다. 미국과 EU는 이미 법적 의무화를 시행했거나 임박했으며, 국내에서도 2027년을 기점으로 공공 분야 전반에 확산될 전망입니다. 특히 미국·EU 시장에 소프트웨어를 수출하는 국내 기업에게 SBOM은 시장 진입의 전제 조건이 되었습니다.

도입을 준비하는 조직이라면 먼저 포맷(SPDX 또는 CycloneDX)과 도구를 결정하고, 핵심 제품 하나에 대해 파일럿을 진행하는 것이 좋습니다. 이후 CI/CD 파이프라인에 통합하여 전 제품군으로 확대하고, 마지막으로 조달·계약 요건에 반영하고 공급망 파트너와 공유 체계를 구축하는 순서로 나아갈 수 있습니다. 2027년 국내 제도화 이전에 체계를 갖춘 조직이 경쟁 우위를 가질 것입니다.




[참고문헌]
1. 국제 규제 및 정책 문서
[1] U.S.Executive Order 14028 — Improving the Nation's Cybersecurity (2021.05.12) https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
[2] NTIA — The Minimum Elements For a Software Bill of Materials (SBOM) (2021.07) https://www.ntia.doc.gov/report/2021/minimum-elements-software-bill-materials-sbom
[3] NTIA — Survey of Existing SBOM Formats and Standards (2021) https://www.ntia.gov/files/ntia/publications/sbom_formats_survey-version-2021.pdf
[4] CISA — Software Bill of Materials (SBOM) Resources https://www.cisa.gov/sbom
[5] U.S. FDA — Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (2023) https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
[6] European Commission — Cyber Resilience Act (CRA) Proposal (2022) https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act

2. 표준 포맷 공식 문서
[7] Linux Foundation — SPDX Specification v3.0 (2024) https://spdx.github.io/spdx-spec/
[8] SPDX — How To Use SPDX in Different Scenarios (v2.3) https://spdx.github.io/spdx-spec/v2.3/how-to-use/
[9] OWASP CycloneDX — CycloneDX Specification v1.6 https://cyclonedx.org/specification/overview/
[10] ISO/IEC 5962:2021 — Information technology — SPDX® Specification V2.2.1 https://www.iso.org/standard/81870.html
[11]ECMA-424 — CycloneDX Bill of Materials (BOM) Standard (2023) https://ecma-international.org/publications-and-standards/standards/ecma-424/

3. 국내 정책 및 가이드라인
[12] 과학기술정보통신부·국가정보원 — 소프트웨어 공급망 보안 강화 가이드라인 (2024) https://www.ncsc.go.kr/
[13] 한국인터넷진흥원(KISA) — SBOM 기반 SW 공급망 보안 모델 구축 지원사업 공고 (2025) https://www.kisa.or.kr/
[14] 식품의약품안전처 — 디지털의료기기 전자적 침해행위 보안 지침 (2025.01.24) https://www.mfds.go.kr/
[15] 한국정보화진흥원 — SBOM 가이드 (globalict.kr) https://www.globalict.kr/sbom/sbom.do?menuCode=040600

4. 기술 분석 및 연구 자료
[16]NTIA—Framing Software Component Transparency: Establishing a Common SBOM (2019) https://www.ntia.gov/files/ntia/publications/ntia_sbom_formats_and_standards_whitepaper_-_version_20191025.pdf
[17] NIST — Secure Software Development Framework (SSDF) v1.1 (2022) https://csrc.nist.gov/Projects/ssdf
[18] HeroDevs — SPDX vs CycloneDX: Choosing the Right SBOM Format (2024) https://www.herodevs.com/blog-posts/spdx-vs-cyclonedx-choosing-the-right-sbom-format-for-your-software-supply-chain
[19] Scribe Security — SPDX vs. CycloneDX: SBOM Formats Compared (2023) https://scribesecurity.com/blog/spdx-vs-cyclonedx-sbom-formats-compared/
[20] Anchore — Syft: Generating an SBOM from container images and filesystems https://github.com/anchore/syft
[21] OWASP — cdxgen: CycloneDX Generator https://github.com/CycloneDX/cdxgen