SBOM
SBOM(Software Bill of Materials, 소프트웨어 자재 명세서 또는 소프트웨어 구성요소 명세서)은 특정 소프트웨어를 구성하는 컴포넌트, 버전, 공급자, 식별자, 의존관계, 라이선스, 생성 시점 등을 기계가 처리할 수 있는 형식으로 기록한 소프트웨어 공급망 투명성 문서이다.[1]
SBOM은 제조업의 자재명세서(BOM, Bill of Materials) 개념을 소프트웨어 분야에 적용한 것이다. 하나의 애플리케이션은 직접 작성한 코드뿐 아니라 오픈소스 라이브러리, 상용 컴포넌트, 프레임워크, 컨테이너 이미지, 운영체제 패키지, 빌드 도구, 런타임 의존성 등으로 구성된다. SBOM은 이러한 구성요소와 관계를 명확히 기록하여 취약점 대응, 라이선스 준수, 공급망 위험관리, 감사 대응에 활용한다.
미국 행정명령 14028의 정의를 인용한 NIST 자료는 SBOM을 “소프트웨어를 만드는 데 사용된 여러 컴포넌트의 세부사항과 공급망 관계를 담은 공식 기록”으로 설명한다. 같은 자료는 SBOM이 투명성, 출처 확인, 취약점 식별·조치 속도 향상에 도움을 줄 수 있다고 설명한다.[1]
현대 소프트웨어는 대부분 외부 패키지와 오픈소스에 의존한다. 이 때문에 특정 라이브러리에서 취약점이 발견되면 조직은 자사 제품이나 운영 시스템이 해당 컴포넌트를 포함하는지 빠르게 파악해야 한다. SBOM이 없으면 저장소, 빌드 스크립트, 컨테이너 이미지, 배포 산출물을 수작업으로 추적해야 하므로 대응 시간이 길어진다.
SBOM의 주요 필요성은 다음과 같다.
- 취약점 대응: CVE, NVD, OSV 등 취약점 데이터베이스와 구성요소 목록을 대조하여 영향 여부를 확인한다.
- 공급망 투명성: 제품에 포함된 직접·간접 의존성을 파악하여 공급망 위험을 관리한다.
- 라이선스 관리: 오픈소스 라이선스 의무사항, 충돌, 고지 필요 여부를 확인한다.
- 구매·조달 보안: 발주자가 납품 소프트웨어의 구성요소와 보안 상태를 검토할 수 있다.
- 사고 대응: Log4j와 같은 광범위한 취약점 발생 시 영향을 받는 제품과 서비스를 빠르게 식별한다.
- 규제 대응: 미국, 유럽, 의료기기, 공공조달 등에서 요구되는 소프트웨어 공급망 보안 요구사항을 충족하는 데 활용된다.
NTIA의 2021년 최소 요소 보고서는 SBOM의 기본 요소를 데이터 필드, 자동화 지원, 운영 관행이라는 세 영역으로 정리하였다.[2]
| 영역 | 내용 |
|---|---|
| 데이터 필드 | 공급자, 컴포넌트명, 컴포넌트 버전, 기타 고유 식별자, 의존관계, SBOM 작성자, 타임스탬프 등 |
| 자동화 지원 | 자동 생성, 기계 판독 가능 형식, 도구 간 교환 가능성 |
| 운영 관행 | 생성 빈도, 제공 방식, 접근 통제, 오류 수정, 알려진 미확인 사항, SBOM 범위 관리 |
실무적으로는 다음 정보가 함께 포함되는 경우가 많다.
| 항목 | 설명 |
|---|---|
| 컴포넌트명 | 라이브러리, 패키지, 모듈, 이미지, 바이너리 등의 이름 |
| 버전 | 컴포넌트의 정확한 버전, 릴리스, 빌드 번호 |
| 공급자·작성자 | 컴포넌트를 만든 조직, 프로젝트, 벤더, 유지보수자 |
| 식별자 | PURL, CPE, SWID, SPDX ID, 해시 등 기계적으로 대조 가능한 식별자 |
| 의존관계 | 직접 의존성과 전이 의존성의 관계 |
| 라이선스 | 컴포넌트에 적용되는 오픈소스 또는 상용 라이선스 |
| 해시 | 컴포넌트 무결성 확인을 위한 암호학적 해시 |
| 생성 정보 | SBOM 생성 도구, 생성 시점, 생성 주체, 대상 소프트웨어 버전 |
| 취약점 정보 | 알려진 취약점, 영향 여부, 패치 상태, VEX 정보 등 |
CISA는 SBOM 문서가 생성되는 시점과 방식에 따라 여러 유형을 구분한다.[3]
| 유형 | 설명 |
|---|---|
| Design SBOM | 설계 단계에서 예상되는 컴포넌트와 의존성을 기록한 SBOM |
| Source SBOM | 소스코드와 패키지 매니페스트를 기준으로 생성한 SBOM |
| Build SBOM | 빌드 과정에서 실제 포함된 컴포넌트를 기준으로 생성한 SBOM |
| Analyzed SBOM | 바이너리, 컨테이너 이미지, 펌웨어 등 산출물을 분석하여 생성한 SBOM |
| Deployed SBOM | 운영 환경에 배포된 소프트웨어와 설정을 기준으로 생성한 SBOM |
| Runtime SBOM | 실행 중 로딩된 라이브러리, 플러그인, 서비스 호출 등 런타임 상태를 반영한 SBOM |
일반적으로 보안 활용성은 빌드 또는 배포 산출물에 가까울수록 높아지지만, 설계·소스 단계 SBOM도 조기 위험 식별과 라이선스 검토에 유용하다.
SBOM은 사람이 읽는 문서보다 기계가 처리할 수 있는 표준 형식으로 생성·교환되는 것이 중요하다.
| 형식 | 설명 |
|---|---|
| SPDX | System Package Data Exchange. 리눅스 재단 계열 프로젝트로 시작된 개방형 표준이며, ISO/IEC 5962:2021 국제표준으로도 채택되었다. SPDX 3.0 계열은 소프트웨어뿐 아니라 AI, 데이터, 보안 참조 등으로 표현 범위를 확장하였다.[4] |
| CycloneDX | OWASP 기반의 BOM 표준으로, SBOM뿐 아니라 SaaSBOM, HBOM, CBOM, AI/ML-BOM, VEX 등 공급망 위험관리를 위한 여러 BOM 유형을 지원한다.[5] |
| SWID 태그 | Software Identification Tag. 소프트웨어 식별과 설치 자산 관리를 위해 사용되는 태그 기반 형식이다. |
SPDX와 CycloneDX는 모두 널리 사용되는 SBOM 형식이다. SPDX는 라이선스, 저작권, 패키지 식별, 규정 준수 정보 표현에 강점이 있고, CycloneDX는 보안, 취약점, 서비스, 의존관계, VEX, 운영 환경 정보 표현에 중점을 둔다. 실제 조직에서는 규제 요구, 도구 호환성, 고객 요구사항에 따라 하나 또는 둘 모두를 지원하는 경우가 많다.
SBOM은 개발·빌드·배포·운영 단계에서 자동 생성되는 것이 바람직하다.
| 방식 | 설명 | 장점 | 한계 |
|---|---|---|---|
| 매니페스트 기반 생성 | package-lock.json, pom.xml, requirements.txt, go.mod 등 의존성 파일을 분석 | 빠르고 개발 단계에 통합하기 쉬움 | 실제 빌드 산출물과 차이가 날 수 있음 |
| 빌드 기반 생성 | CI/CD 또는 빌드 시스템에서 실제 포함된 컴포넌트를 기록 | 실제 산출물과의 일치도가 높음 | 빌드 환경 통합이 필요함 |
| 컨테이너·이미지 분석 | 컨테이너 이미지, OS 패키지, 애플리케이션 패키지를 스캔 | 배포 대상 기준 분석 가능 | 숨겨진 바이너리나 동적 다운로드 컴포넌트 탐지가 어려울 수 있음 |
| 바이너리 분석 | 실행 파일, 펌웨어, 라이브러리 바이너리에서 구성요소를 추정 | 소스코드가 없을 때 유용 | 정확도와 식별 가능성이 도구에 크게 의존함 |
| 런타임 관찰 | 실행 중 로딩되는 라이브러리와 서비스 호출을 관찰 | 실제 사용 컴포넌트 파악 가능 | 운영 부하와 관찰 범위 제한이 있을 수 있음 |
SBOM 기반 보안 관리는 단순히 파일을 생성하는 것에서 끝나지 않는다. 생성, 검증, 저장, 분석, 공유, 갱신, 폐기의 전 과정이 운영 프로세스에 포함되어야 한다.
- 대상 정의: 애플리케이션, 컨테이너 이미지, 펌웨어, SaaS, 라이브러리 등 SBOM 생성 대상을 정한다.
- 생성 시점 결정: 소스, 빌드, 배포, 런타임 중 어떤 단계에서 생성할지 정한다.
- 형식 선택: SPDX, CycloneDX 등 고객·규제·도구가 요구하는 표준 형식을 선택한다.
- 자동 생성: CI/CD 파이프라인, 패키지 관리자, 컨테이너 스캐너와 연계해 자동 생성한다.
- 품질 검증: 필수 필드, 식별자, 의존관계, 라이선스, 해시, 생성 정보 누락 여부를 검증한다.
- 취약점 매핑: CVE, NVD, OSV, 벤더 보안 권고와 대조하여 영향을 받는 컴포넌트를 식별한다.
- VEX 연계: 취약점이 실제 제품에서 악용 가능한지, 패치됐는지, 영향을 받지 않는지 등의 상태를 기록한다.
- 위험 평가: 취약점 심각도, 실제 사용 여부, 노출 경로, 패치 가능성, 업무 중요도를 기준으로 우선순위를 정한다.
- 공유·보관: 고객, 감사자, 보안팀, 조달팀, 운영팀이 필요한 범위에서 접근하도록 통제한다.
- 갱신: 새 릴리스, 패치, 의존성 변경, 취약점 발견 시 SBOM을 갱신한다.
VEX(Vulnerability Exploitability eXchange)는 특정 제품 또는 컴포넌트가 특정 취약점의 영향을 받는지, 실제로 악용 가능한지, 조치 상태가 어떤지를 기계 판독 가능한 방식으로 전달하는 보안 권고 형식이다. OASIS CSAF 2.0은 VEX를 특정 취약점에 대해 제품이 영향을 받는지 여부를 공급자 등이 주장할 수 있게 하는 방식으로 설명한다.[6]
SBOM은 “무엇이 들어 있는가”를 보여주고, VEX는 “그 취약점이 이 제품에서 실제로 문제가 되는가”를 설명한다. 예를 들어 SBOM 분석 결과 취약한 라이브러리가 포함되어 있더라도, 해당 취약 코드 경로가 사용되지 않거나 취약 기능이 비활성화되어 있으면 VEX를 통해 “영향 없음” 또는 “악용 불가” 상태를 전달할 수 있다. 따라서 SBOM과 VEX를 함께 사용하면 취약점 알림의 오탐과 과잉 대응을 줄일 수 있다.
SBOM은 권고 수준의 보안 관행에서 점차 조달, 제품 보안, 의료기기, 디지털 제품 규제의 핵심 문서로 확대되고 있다.
| 구분 | 주요 내용 |
|---|---|
| 미국 행정명령 14028 | 연방정부 소프트웨어 공급망 보안 강화의 일환으로 SBOM을 핵심 요소로 제시하였다. NIST는 연방기관이 조달 시 기계 판독 가능한 SBOM 제공을 요구할 수 있다고 설명한다.[1] |
| NTIA 최소 요소 | 2021년 SBOM의 기본 데이터 필드, 자동화 지원, 운영 관행을 제시하였다.[2] |
| CISA 2025 최소 요소 초안 | CISA는 2025년 SBOM 도구와 구현 성숙도 향상을 반영한 갱신 지침 초안을 공개하고 의견수렴을 진행하였다.[7] |
| EU Cyber Resilience Act | 디지털 요소가 포함된 제품에 대해 설계, 개발, 유지보수 전 과정의 사이버보안 요구사항을 부과한다. 법은 2024년 12월 10일 발효되었고, 주요 의무는 2027년 12월 11일부터 적용된다.[8] |
| FDA 의료기기 사이버보안 지침 | 의료기기 사전 제출 문서에서 사이버보안 설계, 라벨링, 문서화, 사이버 기기 관련 요구사항을 다루며, 의료기기 소프트웨어 공급망 관리에서 SBOM이 중요한 문서로 활용된다.[9] |
| 한국 SW 공급망 보안 가이드라인 | 과학기술정보통신부, 한국인터넷진흥원, 국가정보원, 디지털플랫폼정부위원회가 2024년 「SW 공급망 보안 가이드라인 1.0」을 마련하였다. 해당 안내는 해외 주요국의 SBOM 제출 의무화 등에 대응하여 정부·공공기관·기업의 SW 공급망 보안 관리역량 강화를 목적으로 한다.[10] |
한국에서는 “SBOM” 외에도 “SW 구성요소 명세서”, “소프트웨어 자재명세서”, “SW명세서” 등의 용어가 함께 사용된다. KISA 보호나라의 SW 공급망 보안 체계 진단 서비스는 SW 개발보안 진단, SW명세서 생성 및 분석, SW 개발환경 진단을 컨설팅 대상으로 제시한다. 해당 서비스 설명은 SW명세서를 SW 분야 공급망 위험관리를 위해 투명한 SW 구성요소를 제공하는 명세서로 설명하며, SBOM이라고도 쓰인다고 안내한다.[11]
국내 조직에서 SBOM을 도입할 때는 해외 규제 대응뿐 아니라 공공 조달, 대기업 협력사 보안 요구, 오픈소스 라이선스 컴플라이언스, ISMS-P 운영 통제, 침해사고 대응 체계와의 연계를 함께 고려해야 한다.
SBOM은 다음 보안 운영 영역과 연계된다.
| 영역 | 활용 방법 |
|---|---|
| 취약점 관리 | SBOM 컴포넌트를 CVE, NVD, OSV, 벤더 권고와 매핑하여 영향 여부를 확인 |
| 패치 관리 | 취약 컴포넌트의 사용 위치, 영향 서비스, 패치 우선순위를 식별 |
| 자산 관리 | CMDB, ITAM, 클라우드 자산 목록과 연결하여 소프트웨어 인벤토리 보강 |
| DevSecOps | CI/CD 단계에서 SBOM 생성, 취약점 스캔, 정책 위반 차단 자동화 |
| 조달 보안 | 납품 소프트웨어의 구성요소, 라이선스, 보안 상태를 계약·검수 항목에 포함 |
| 사고 대응 | 신규 취약점 공개 시 영향 시스템을 빠르게 검색 |
| 라이선스 준수 | GPL, LGPL, Apache, MIT 등 오픈소스 라이선스 의무사항 점검 |
| 공급업체 관리 | 외부 개발사, SaaS 제공자, 장비 제조사로부터 SBOM 제출과 갱신을 요구 |
SBOM의 가치는 정확성과 최신성에 크게 좌우된다. 형식만 맞는 SBOM이라도 누락, 잘못된 버전, 모호한 식별자, 불완전한 의존관계가 있으면 취약점 대응에 실패할 수 있다.
| 품질 기준 | 설명 |
|---|---|
| 완전성 | 직접 의존성뿐 아니라 가능한 범위의 전이 의존성까지 포함하는지 |
| 정확성 | 실제 빌드·배포 산출물과 SBOM 내용이 일치하는지 |
| 최신성 | 릴리스, 패치, 의존성 변경 시 SBOM이 갱신되는지 |
| 식별 가능성 | PURL, CPE, 해시 등 자동 대조 가능한 식별자가 포함되는지 |
| 기계 판독성 | SPDX, CycloneDX 등 표준 형식으로 자동 처리 가능한지 |
| 재현성 | 동일한 빌드에서 일관된 SBOM을 생성할 수 있는지 |
| 무결성 | SBOM 자체가 변조되지 않았음을 서명, 해시, 증명으로 확인할 수 있는지 |
| 범위 명확성 | 소스, 빌드, 배포, 런타임 중 어떤 범위를 나타내는지 명확한지 |
SBOM은 소프트웨어 공급망 보안의 기반 데이터이지만, 그 자체만으로 보안을 보장하지는 않는다. NTIA 보고서도 SBOM이 모든 소프트웨어 보안 문제를 해결하는 만능 수단은 아니며, 추가 보안 도구와 관행의 기반 데이터 계층으로 작동한다고 설명한다.[2]
주요 한계는 다음과 같다.
- 정확도 문제: 생성 도구가 모든 컴포넌트를 정확히 식별하지 못할 수 있다.
- 전이 의존성 누락: 간접 의존성이나 동적 로딩 컴포넌트가 빠질 수 있다.
- 바이너리 식별 어려움: 소스코드 없이 바이너리만 분석하는 경우 식별 정확도가 낮아질 수 있다.
- 취약점 오탐: 취약한 버전이 포함되어도 실제 코드 경로가 사용되지 않을 수 있다.
- 정보 노출 위험: 내부 아키텍처, 상용 컴포넌트, 미패치 취약점 정보가 외부에 노출될 수 있다.
- 갱신 부담: 릴리스와 패치가 잦은 조직에서는 SBOM 생성·검증·공유 자동화가 필수적이다.
- 표준 해석 차이: 같은 소프트웨어라도 도구와 형식에 따라 서로 다른 SBOM이 생성될 수 있다.
- 책임 범위: 공급자, 통합자, 운영자 중 누가 어떤 수준의 SBOM을 제공하고 유지할지 계약상 정의가 필요하다.
SBOM을 실무에 도입할 때는 전체 시스템을 한 번에 대상으로 삼기보다 위험도가 높은 제품과 고객 요구가 있는 영역부터 단계적으로 확대하는 것이 적절하다.
- 정책 수립: SBOM 생성 대상, 형식, 필수 필드, 보관 기간, 외부 제공 기준을 정의한다.
- 도구 선정: 개발 언어, 패키지 관리자, 컨테이너, 펌웨어, 클라우드 환경을 지원하는 도구를 선정한다.
- CI/CD 통합: 빌드 시점 SBOM 생성과 검증을 자동화한다.
- 취약점 DB 연계: NVD, OSV, 벤더 권고, 내부 취약점 관리 시스템과 연결한다.
- 정책 게이트 설정: 심각 취약점, 금지 라이선스, 미확인 컴포넌트가 있을 때 릴리스 차단 또는 승인 절차를 둔다.
- VEX 운영: 실제 영향 여부와 조치 상태를 구조화하여 취약점 노이즈를 줄인다.
- 공급업체 요구사항 반영: 계약서, 제안요청서, 검수 기준에 SBOM 제출과 갱신 의무를 포함한다.
- 보안 저장소 운영: SBOM을 중앙 저장소에 보관하고 접근권한, 변경이력, 무결성을 관리한다.
- 정기 점검: SBOM 품질, 도구 정확도, 취약점 대응 시간, 라이선스 위반 여부를 주기적으로 점검한다.
- SCA(Software Composition Analysis): 소프트웨어 구성요소를 분석하여 오픈소스 사용 현황, 취약점, 라이선스 위험을 식별하는 기술이다.
- SLSA(Supply-chain Levels for Software Artifacts): 소프트웨어 빌드와 산출물의 무결성을 보증하기 위한 공급망 보안 프레임워크이다.
- in-toto: 소프트웨어 공급망 단계별 증명과 무결성 검증을 위한 프레임워크이다.
- PURL(Package URL): 패키지 생태계, 이름, 버전 등을 표준화해 표현하는 식별자이다.
- CPE(Common Platform Enumeration): 소프트웨어와 하드웨어 플랫폼을 식별하기 위한 표준화된 명명 체계이다.
- VEX: SBOM에 포함된 컴포넌트의 취약점이 실제 제품에 영향을 주는지 전달하는 취약점 악용 가능성 정보 형식이다.
- AIBOM 또는 AI/ML-BOM: AI 시스템의 모델, 데이터셋, 프레임워크, 학습 환경, 의존성을 포함하도록 SBOM 개념을 확장한 명세서이다. 2026년 CISA와 G7 파트너들은 AI 시스템의 구성요소와 의존성 투명성을 높이기 위한 AI용 SBOM 최소 요소 지침을 발표하였다.[12]
- ↑ 1.0 1.1 1.2 「Software Security in Supply Chains: Software Bill of Materials (SBOM)」, NIST, URL: https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance-20, 확인일: 2026-06-05.
- ↑ 2.0 2.1 2.2 「The Minimum Elements For a Software Bill of Materials (SBOM)」, NTIA, URL: https://www.ntia.gov/sites/default/files/publications/sbom_minimum_elements_report_0.pdf, 확인일: 2026-06-05.
- ↑ 「Types of Software Bill of Materials (SBOM)」, CISA, URL: https://www.cisa.gov/resources-tools/resources/types-software-bill-materials-sbom, 확인일: 2026-06-05.
- ↑ 「The System Package Data Exchange™ (SPDX®)」, SPDX, URL: https://spdx.dev/, 확인일: 2026-06-05.
- ↑ 「CycloneDX: The International Standard for Bill of Materials」, CycloneDX, URL: https://cyclonedx.org/, 확인일: 2026-06-05.
- ↑ 「Common Security Advisory Framework Version 2.0」, OASIS, URL: https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html, 확인일: 2026-06-05.
- ↑ 「Request for Comment on 2025 Minimum Elements for a Software Bill of Materials」, Federal Register, URL: https://www.federalregister.gov/documents/2025/08/22/2025-16147/request-for-comment-on-2025-minimum-elements-for-a-software-bill-of-materials, 확인일: 2026-06-05.
- ↑ 「Cyber Resilience Act」, European Commission, URL: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act, 확인일: 2026-06-05.
- ↑ 「Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions」, FDA, URL: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-management-system-considerations-and-content-premarket, 확인일: 2026-06-05.
- ↑ 「SW 공급망 보안 가이드라인 1.0」, 한국인터넷진흥원, URL: https://www.kisa.or.kr/2060204/form?page=1&postSeq=15, 확인일: 2026-06-05.
- ↑ 「SW 공급망 보안 체계 진단」, KISA 보호나라&KrCERT/CC, URL: https://www.boho.or.kr/kr/subPage.do?menuNo=205010, 확인일: 2026-06-05.
- ↑ 「Software Bill of Materials for AI - Minimum Elements」, BSI, URL: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/SBOM-for-AI_minimum-elements.pdf?__blob=publicationFile&v=4, 확인일: 2026-06-05.
