SBOM(Software Bill of Materials)
1. 개요
가. 정의
소프트웨어를 구성하는 모든 컴포넌트·라이브러리·의존성과 그 버전·라이선스·공급자 정보를 기계 판독 가능하게 목록화한 명세서. 제조업의 자재명세서(BOM)에서 개념을 빌려온 것으로, 소프트웨어 공급망 보안(SSC, Software Supply Chain)의 핵심 산출물이다.
SBOM의 근본 취지는 "보이지 않으면 관리할 수 없다(You can't secure what you can't see)"는 명제에 있다. 현대 애플리케이션은 코드의 70~90%가 개발자가 직접 작성한 것이 아니라 외부 오픈소스·서드파티 컴포넌트로 채워지는데, 정작 그 안에 무엇이 얼마나 들어 있는지 목록조차 갖추지 못한 조직이 대부분이다. SBOM은 이 "소프트웨어의 성분표(食品 영양성분표에 비유되곤 한다)"를 명시화해, 그동안 관리 사각지대에 있던 취약점·라이선스 리스크를 관리 가능한 대상으로 끌어올린다.
SBOM은 단순한 문서가 아니라 자동화 가능한 데이터 구조라는 점이 핵심이다. 사람이 읽는 목록에 그친다면 수백 개 컴포넌트를 매일 갱신되는 취약점 데이터베이스와 대조하는 일은 불가능하다. 따라서 SBOM은 도구가 해석·대조·검증할 수 있는 표준 포맷으로 작성되어야 비로소 실효성을 갖는다.
나. 등장 배경 및 필요성
오픈소스 의존성이 폭증하면서 하나의 앱이 직간접적으로 수백~수천 개 컴포넌트에 의존하게 되었고, 그 깊숙한 곳에 숨은 결함 하나가 전체 공급망으로 번지는 대형 사고가 잇따랐다. 빌드 시스템 자체를 오염시켜 정상 서명된 업데이트에 악성코드를 실어 배포한 SolarWinds(2020) 사건과, 널리 쓰이는 자바 로깅 라이브러리의 원격코드실행 취약점인 Log4Shell(Log4j, 2021, CVE-2021-44228) 이 대표적이다.
특히 Log4Shell 당시 수많은 조직이 "우리 시스템이 Log4j를 쓰는지, 쓴다면 어느 버전을 어디에 쓰는지조차 파악하지 못해" 초기 대응이 며칠씩 지연되었다. 만약 SBOM이 구비되어 있었다면 한 번의 조회로 영향 범위를 즉시 식별하고 우선순위대로 패치할 수 있었을 것이다. 이 사건은 SBOM의 가치를 전 산업에 각인시킨 결정적 계기였다. 이런 배경에서 미국은 행정명령 EO 14028(2021) 을 통해 연방정부에 납품되는 소프트웨어에 SBOM 제출을 의무화했고, 이후 각국 규제와 산업 표준으로 빠르게 확산되었다.
2. SBOM 구성요소·표준 포맷과 생성 계층
가. 구성요소와 표준 포맷
SBOM이 실효성을 가지려면 사람이 아니라 도구가 자동으로 해석할 수 있어야 하므로, 기계 판독이 가능한 표준 포맷으로 작성하는 것이 중요하다. 포맷이 표준화되어야 서로 다른 조직·도구 사이에서 SBOM을 주고받고, 취약점 데이터베이스와 자동 대조하며, 공급망을 거슬러 올라가는 검증이 가능해진다.
| 구분 | 내용 |
|---|---|
| 구성요소 | 컴포넌트명·버전, 공급자, 의존관계, 라이선스, 해시(무결성 검증) |
| 표준 포맷 | SPDX(Linux재단, ISO 표준), CycloneDX(OWASP, 보안 특화), SWID |
미국 상무부 산하 NTIA는 SBOM이 갖춰야 할 최소 요소(minimum elements) 로 공급자명·컴포넌트명·버전·고유 식별자·의존관계·SBOM 작성자·타임스탬프를 규정했다. 이 최소 요소는 서로 다른 SBOM을 상호 대조·병합하기 위한 공통 기반이 된다. 각 컴포넌트의 고유 식별자로는 PURL(Package URL) 이나 CPE(Common Platform Enumeration) 가 쓰이는데, 표기가 표준화되어야 "이 컴포넌트가 그 CVE의 대상과 같은 것인가"를 오탐 없이 판단할 수 있기 때문이다.
포맷별 성격도 다르다. SPDX는 라이선스·규정 준수 관리에 강점이 있고 국제표준(ISO/IEC 5962:2021)으로 채택되었으며, CycloneDX는 OWASP가 주도해 취약점·공급망 보안 활용에 초점을 두고 VEX·서비스·의존성 그래프 표현이 풍부하다. 해시(체크섬)를 포함하는 이유는, 명세된 컴포넌트가 실제 배포물과 비트 단위로 동일한지(변조·오염 여부)를 검증하기 위함이다. 해시가 없으면 "목록은 맞지만 실물이 바꿔치기된" 공급망 공격을 걸러 낼 수 없다.
나. 생성 시점에 따른 계층
SBOM은 언제 만드느냐에 따라 정확성과 완전성이 달라진다. 이를 이해하면 왜 빌드 시점 자동 생성이 권장되는지가 분명해진다.
| SBOM 유형 | 생성 시점 | 특징 |
|---|---|---|
| Source SBOM | 소스·의존성 선언 시점 | 선언된 의존성 기준, 실제 포함물과 다를 수 있음 |
| Build SBOM | 빌드/컴파일 시점 | 실제 산출물 기준, 정확·최신(권장) |
| Deployed/Runtime SBOM | 배포·운영 시점 | 실행 환경·구성까지 반영 |
소스 단계에서 선언한 의존성과 실제 빌드 산출물에 포함된 컴포넌트는 종종 어긋난다(전이 의존성 해석, 조건부 포함, 번들링 등의 이유로). 그래서 신뢰할 수 있는 SBOM은 빌드 파이프라인이 실제로 만들어 낸 산출물에서 추출한 Build SBOM이어야 한다는 것이 정설이다.
3. 관리 대상: 오픈소스 리스크
SBOM으로 가시화하려는 리스크는 크게 네 가지이며, 그중 전이(transitive) 의존성이 가장 까다롭다. 내가 직접 가져온 라이브러리가 또 다른 라이브러리를 부르고, 그것이 다시 세 번째를 부르는 다단계 구조라, 정작 문제가 되는 컴포넌트는 눈에 보이지 않는 깊은 곳에 잠복하기 때문이다. 실제로 앱이 명시적으로 선언한 직접 의존성은 수십 개라도, 그로부터 딸려 오는 전이 의존성은 수백~수천 개에 이르는 경우가 흔하다.
| 취약점 | 내용 |
|---|---|
| 알려진 취약점(CVE) | Log4j 등 공개된 결함이 전이 의존성에 잠복 |
| 의존성 리스크 | 다단계 전이 의존성으로 무엇을 쓰는지 파악 곤란 |
| 라이선스 위반 | GPL 등 카피레프트 라이선스 미준수 시 법적 리스크 |
| 유지보수 중단·악성 | EOL(지원 종료) 패키지, 악성 주입(Typosquatting) |
라이선스 위반이 보안 못지않게 중요한 이유는, GPL 같은 강한 카피레프트 라이선스를 인지하지 못한 채 포함하면 자사 소스코드 공개 의무가 발생하거나 배포가 제한되는 등 법적·사업적 리스크로 직결되기 때문이다. 실제 오픈소스 라이선스 위반으로 제품 출하가 중단되거나 소송으로 번진 사례가 적지 않다.
마지막 유형인 유지보수 중단·악성 주입도 최근 급증하는 위협이다. 인기 패키지 이름과 한 글자만 다른 가짜 패키지를 등록해 오타를 노리는 타이포스쿼팅(Typosquatting), 정상 패키지의 유지보수 권한을 탈취해 악성 버전을 배포하는 의존성 하이재킹, 오랫동안 방치된 EOL 패키지의 미패치 취약점 등은 모두 SBOM이 없으면 존재 자체를 인지하기 어렵다.
이 네 가지 리스크는 서로 얽혀 증폭된다. 예컨대 EOL로 유지보수가 끊긴 전이 의존성에 새 CVE가 공개되면, 패치가 나오지 않으므로 대안 컴포넌트로 교체하거나 우회해야 하는데, 전이 의존성이라 어느 직접 의존성을 손봐야 할지조차 SBOM 없이는 추적하기 어렵다. 이처럼 리스크는 개별적으로가 아니라 의존성 그래프 전체의 맥락에서 판단해야 하며, SBOM은 바로 그 그래프를 제공하는 지도 역할을 한다.
4. SBOM 기반 관리 방안
SBOM은 한 번 만들고 끝나는 정적 문서가 아니라 생성→공유→매핑→대응→재생성이 순환하는 지속 프로세스여야 한다. 새로운 CVE는 매일 수십~수백 건씩 공개되므로, 어제까지 안전하던 컴포넌트가 오늘 취약해질 수 있기 때문이다.
flowchart LR
G["SBOM 생성(SPDX·CycloneDX)"] --> S["공유·공개"]
S --> M["취약점 매핑(CVE·NVD 대조)"]
M --> R["대응·패치·모니터링"]
R -. 지속 관리 .-> G
위 순환의 각 단계는 CI/CD 파이프라인과 운영 단계에 걸쳐 다음과 같이 구체화된다. 아래 그림은 개발-빌드-운영 축에서 SBOM이 어떻게 자동 통합되는지를 나타낸다.
flowchart TB
DEV["개발(의존성 선언)"] --> BUILD["빌드(SBOM 자동 생성)"]
BUILD --> SCA["SCA 스캔(구성·취약점·라이선스)"]
SCA --> VEX["VEX로 악용 가능성 판정"]
VEX --> GATE{"릴리스 게이트 통과?"}
GATE -->|No| DEV
GATE -->|Yes| OPS["배포·운영 모니터링"]
OPS -. 신규 CVE 감시 .-> SCA
| 단계 | 방안 |
|---|---|
| 생성 | CI/CD 빌드 시점에 SBOM 자동 생성(정확성·최신성 확보) |
| 분석(SCA) | SCA 도구로 구성요소·취약점·라이선스 스캔 |
| 매핑 | CVE/NVD 데이터베이스와 대조해 취약 컴포넌트 식별 |
| 대응·모니터링 | 패치·업그레이드, 신규 CVE 공개를 지속 감시 |
핵심은 SBOM 생성을 사람 손이 아니라 빌드 파이프라인에 자동 통합하는 것이다. 수작업으로 작성한 명세는 금세 실제 코드와 어긋나 신뢰할 수 없게 되므로, 빌드가 돌 때마다 실제 산출물에서 SBOM을 기계적으로 뽑아내야 한다. 대표 도구로는 SBOM 생성기인 Syft, 취약점 스캐너인 Grype·Trivy, 그리고 상용 SCA 플랫폼(예: Snyk, Sonatype 등)이 있으며, 이들을 CI에 연결해 생성-스캔-차단을 자동화한다.
또 하나 중요한 실무 포인트는 SBOM 자체의 신뢰성 확보다. SBOM이 위·변조되면 오히려 잘못된 안전감을 줄 수 있으므로, 생성된 SBOM에 디지털 서명을 붙이고(예: Sigstore/Cosign) 무결성을 검증하는 절차를 함께 갖춰야 공급망 신뢰 사슬이 완성된다.
5. 심화: VEX 결합과 국내외 규제 동향
취약점 목록만으로는 실제 위험을 과대평가하기 쉽다는 것이 SBOM 운영의 최대 함정이다. 어떤 컴포넌트에 CVE가 존재해도 해당 취약 코드 경로가 우리 제품에서 실제로 호출·실행되지 않으면 악용 위험이 없거나 매우 낮을 수 있다. 이 간극을 메우는 것이 VEX(Vulnerability Exploitability eXchange) 다. VEX는 각 취약점에 대해 "영향 없음(not_affected)·조사 중·영향 있음·조치 완료" 같은 악용 가능성 상태를 공급자가 명시적으로 선언하는 문서로, 대응 우선순위를 정하고 불필요한 패치 소동을 줄이는 데 결정적이다. SBOM이 "무엇이 들어 있는가"라면 VEX는 "그중 무엇이 실제로 위험한가"를 알려 주며, 둘은 짝을 이뤄야 실효성이 완성된다.
규제 동향도 빠르게 강화되고 있다. 미국은 EO 14028에 이어 의료기기(FDA)·연방조달 전반으로 SBOM 요구를 확대하고 있고, 유럽연합은 CRA(Cyber Resilience Act) 를 통해 시장에 출시되는 디지털 제품에 SBOM 구비와 취약점 처리 의무를 부과하는 방향으로 나아가고 있다. 국내(한국)에서도 과학기술정보통신부·KISA를 중심으로 SW 공급망 보안 가이드가 마련되고 공공·금융 부문을 시작으로 SBOM 적용이 논의·확산되는 흐름이다. 다만 세부 의무화 범위와 시점은 정책에 따라 달라질 수 있어, 조직은 규제를 뒤쫓기보다 선제적으로 SBOM 관리 체계를 갖추는 편이 유리하다.
기술사 관점의 예상 출제 방향은 (1) SBOM의 정의·최소요소·표준포맷(SPDX vs CycloneDX) 비교, (2) 전이 의존성·라이선스 리스크의 관리 필요성, (3) SBOM 생성-SCA-CVE 매핑-VEX-모니터링의 지속 프로세스, (4) DevSecOps 통합과 서명 기반 무결성 확보 방안으로 정리할 수 있다.
6. 고려사항 및 시사점
첫째, 자동화와 최신성 확보다. SBOM은 빌드 파이프라인에 통합해 매 빌드마다 자동 생성해야 하며, 수작업 명세는 금세 낡아 신뢰를 잃는다. 생성뿐 아니라 신규 CVE 공개에 맞춘 지속적 재매핑이 함께 돌아가야 SBOM이 살아 있는 자산이 된다.
둘째, VEX 결합을 통한 우선순위화다. 취약점 수 자체가 아니라 악용 가능성 기준으로 대응 순서를 정해야 한정된 인력을 실제 위험에 집중할 수 있다. VEX 없이 CVE만 나열하면 "패치 피로"로 정작 위험한 취약점 대응이 늦어지는 역설이 생긴다.
셋째, SBOM 무결성·신뢰 사슬 확보다. SBOM 자체를 서명·검증하고, 컴포넌트 해시로 배포물 변조를 탐지하며, 공급자로부터 받은 SBOM의 진위를 확인하는 절차가 있어야 공급망 신뢰가 성립한다. 신뢰할 수 없는 SBOM은 없느니만 못한 잘못된 안전감을 준다.
넷째, 라이선스·규정 준수의 상시 관리다. 보안 취약점뿐 아니라 카피레프트·상충 라이선스 여부를 지속 점검해 법적·사업적 리스크를 선제적으로 통제해야 하며, 이를 위해 SPDX 기반 라이선스 메타데이터를 정확히 관리할 필요가 있다.
다섯째, 조직 차원의 DevSecOps 내재화와 규제 대응이다. SBOM·SCA·VEX를 파이프라인에 상시 통합하고, EU CRA·국내 SW 공급망 보안 정책 등 규제 변화를 선제적으로 반영해 조직 전반의 공급망 보안 성숙도를 높여야 한다. SBOM은 그 자체가 목적이 아니라 공급망 전반의 가시성·신뢰·대응력을 떠받치는 기반 인프라라는 관점이 필요하다.
참고자료
- CISA, "Software Bill of Materials (SBOM)": https://www.cisa.gov/sbom
- NTIA, "The Minimum Elements For a Software Bill of Materials (SBOM)", 2021
- OWASP CycloneDX: https://cyclonedx.org/ · SPDX: https://spdx.dev/
한 줄 요약: SBOM은 소프트웨어 구성요소를 SPDX·CycloneDX 표준으로 목록화해 오픈소스 취약점·라이선스 리스크를 가시화 하고, 빌드 시 자동 생성→SCA 스캔→CVE 매핑→VEX 우선순위화→서명·모니터링 의 지속 프로세스로 공급망 보안을 관리하는 기반 인프라다.