들어가며
지난 1화에서 SBOM이 무엇인지, 왜 필요한지 살펴봤다면, 이제 본격적으로 실무에 적용해볼 차례입니다.
이번 2화에서는 실제 SBOM을 생성하기 위해 알아야 할 세 가지 핵심 주제를 다룹니다.
먼저 SPDX, CycloneDX, SWID Tags 등 주요 SBOM 표준 형식들을 비교하여 어떤 상황에서 무엇을 선택해야 하는지 알아보겠습니다.
다음으로 SCA(Software Composition Analysis) 도구가 어떻게 작동하며 SBOM과 어떤 시너지를 만들어내는지 살펴봅니다.
마지막으로 간단한 예시로 실제 SBOM 생성 과정을 단계별로 따라가며, 생성된 SBOM을 확인하고 품질을 평가할 수 있는 체크리스트를 확인해 보겠습니다.
이론에서 실전으로 넘어가는 중요한 단계이니, 차근차근 따라와 주세요!
SBOM 표준 형식 비교
SBOM 포맷은 소프트웨어 제품의 구성요소를 최종 사용자 또는 고객과 공유하기 위한 표준입니다.
소프트웨어의 구성을 다른 툴이 이해할 수 있도록 공통의 형식으로 설명하는 역할을 하죠.
SBOM을 생성할 때 사용할 수 있는 주요 표준 형식은 크게 세 가지가 있어요.
각각의 특징을 한번 살펴볼까요?
1. SPDX (Software Package Data Exchange)
Linux Foundation에서 운영하는 프로젝트인 SPDX는 소프트웨어 패키지와 관련된 정보에 대해 공통 데이터 교환 포맷을 만드는 것이 목적입니다.
장점:•
업계에서 가장 널리 채택된 표준
•
다양한 파일 형식 지원 (JSON, YAML, RDF/XML, Tag-Value)
•
강력한 라이선스 관리 기능
•
정부 및 대기업에서 선호
단점:•
상대적으로 복잡한 구조
•
파일 크기가 큰 편
•
보안 취약점 정보는 제한적
SPDX 예시 (JSON 형식):{
"spdxId": "SPDXRef-DOCUMENT",
"spdxVersion": "SPDX-3.0",
"creationInfo": {
"created": "2024-01-15T10:30:00Z",
"creators": ["Tool: company-sbom-generator-1.0.0"]
},
"name": "express-app-v1.2.3",
"dataLicense": "CC0-1.0",
"elements": [
{
"spdxId": "SPDXRef-Package-express-4.18.2",
"name": "express",
"versionInfo": "4.18.2",
"downloadLocation": "https://registry.npmjs.org/express/...",
"concludedLicense": "MIT",
"declaredLicense": "MIT",
"copyrightText": "Copyright (c) 2009-2014 TJ Holowaychuk...",
"originatedBy": ["Person: TJ Holowaychuk"]
},
"..."
],
"relationships": [
{
"spdxElementId": "SPDXRef-DOCUMENT",
"relationshipType": "describes",
"relatedSpdxElement": "SPDXRef-Package-express-4.18.2"
},
"..."
]
}
JSON
복사
2. CycloneDX
CycloneDX는 OWASP에서 개발한 보안 중심의 SBOM 표준입니다.
주요 특징:•
DevSecOps 워크플로우에 친화적
장점:•
보안 정보가 풍부함
•
간단하고 경량화된 구조
•
DevSecOps 워크플로우 친화적
•
취약점 스캔 도구들과 연동이 쉬움
단점:•
라이선스 정보는 SPDX보다 제한적
•
상대적으로 새로운 표준
•
채택 범위가 SPDX보다 좁음
CycloneDX 예시 (JSON 형식):{
"bomFormat": "CycloneDX",
"specVersion": "1.4",
"serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
"version": 1,
"metadata": {
"timestamp": "2024-01-15T10:30:00.000Z",
"tools": [
{
"vendor": "Company",
"name": "company-sbom-generator",
"version": "1.0.0"
}
],
"component": {
"type": "application",
"name": "express-app",
"version": "1.2.3"
}
},
"components": [
{
"type": "library",
"bom-ref": "pkg:npm/express@4.18.2",
"name": "express",
"version": "4.18.2",
"scope": "required",
"licenses": [{"license": {"id": "MIT"}}],
"purl": "pkg:npm/express@4.18.2"
},
"..."
],
"vulnerabilities": [
{
"bom-ref": "vuln-lodash-prototype-pollution",
"id": "CVE-2020-8203",
"source": {"name": "National Vulnerability Database"},
"ratings": [{"score": 7.4, "severity": "high", "method": "CVSSv3"}],
"affects": [{"ref": "pkg:npm/lodash@4.17.21"}]
},
"..."
]
}
JSON
복사
3. SWID Tags
SWID (Software Identification) Tags는 ISO/IEC 19770-2 표준을 기반으로 한 형식입니다.
장점:•
국제 표준의 신뢰성
•
자산 관리 시스템과 연동
•
정형화된 구조
단점:•
복잡한 XML 구조
•
SBOM 전용이 아닌 범용 자산 관리 목적 (소프트웨어 자산 관리에 중점)
•
개발자 친화적이지 않음
•
도구 지원이 제한적
SWID Tags 예시 (XML 형식):<?xml version="1.0" encoding="UTF-8"?>
<SoftwareIdentity
xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"
name="express-app"
tagId="company.com/express-app-1.2.3"
version="1.2.3">
<Entity
name="Company Inc."
regid="company.com"
role="softwareCreator tagCreator"/>
<Meta
product="express-app"
colloquialVersion="1.2.3"/>
<Payload>
<File
name="express"
version="4.18.2"
size="208179">
<FileSystemItem
key="true"
location="/node_modules/express/package.json"/>
</File>
<!-- ... additional components ... -->
</Payload>
</SoftwareIdentity>
XML
복사
어떤 형식을 선택해야 할까요?
SPDX를 선택하는 경우:
•
정부 납품이나 대기업 거래가 많은 경우
•
라이선스 컴플라이언스가 중요한 경우
•
장기적인 안정성을 원하는 경우
CycloneDX를 선택하는 경우:
•
보안 취약점 관리가 우선순위인 경우
•
DevSecOps 파이프라인에 통합하려는 경우
•
빠르고 가벼운 처리가 필요한 경우
결론: 대부분의 경우 SPDX 또는 CycloneDX 중에서 선택하게 될 텐데, 규제 대응이 중요하다면 SPDX, 보안 중심이라면 CycloneDX를 추천합니다!
SCA와 SBOM 생성
SBOM을 실제로 생성하고 관리하기 위해서는 SCA(Software Composition Analysis) 도구를 이해하는 것이 필수입니다.
SCA 도구가 무엇인지, 어떤 이점을 제공하는지 자세히 살펴보겠습니다.
SCA란 무엇인가?
Software Composition Analysis(소프트웨어 구성 분석)는 애플리케이션에서 사용되는 오픈소스 및 서드파티 컴포넌트를 식별, 분석, 관리하는 프로세스입니다.
SCA 도구가 제공하는 핵심 정보:
•
컴포넌트 인벤토리: 어떤 오픈소스 라이브러리와 의존성이 사용되고 있는지
•
보안 취약점: 알려진 CVE(Common Vulnerabilities and Exposures) 식별
•
라이선스 정보: 각 컴포넌트의 라이선스 유형과 컴플라이언스 위험도
•
의존성 관계: 직접/간접 의존성의 복잡한 연결 구조
SCA 도구 선택 가이드
분석 도구를 선택할 때는 여러 관점에서 평가해야 합니다.
기술적 호환성부터 비즈니스 요구사항까지 종합적으로 검토하는 것이 중요합니다.
우선 기술적 적합성을 확인해야 합니다.
현재 사용 중인 프로그래밍 언어와 패키지 매니저를 지원하는지, 컨테이너나 바이너리 분석이 필요한지, 대규모 조직이나 다수의 프로젝트에서 확장 가능한지 살펴봐야 합니다.
다음으로는 성능과 정확성을 평가해야 합니다.
False positive와 False negative 비율이 어느 정도인지, CI/CD 파이프라인에 미치는 영향은 얼마나 되는지, 전이 의존성을 어느 깊이까지 추적하는지 확인해야 합니다.
마지막으로 통합성과 운영 편의성도 중요한 요소입니다.
기존 개발 워크플로우와 잘 맞는지, API를 통한 자동화가 가능한지, 팀의 기술 수준에 맞는 습득 난이도를 가지고 있는지 고려해야 합니다.
SCA와 SBOM의 시너지
SCA 도구는 단순히 SBOM을 생성하는 것을 넘어서, SBOM을 활용한 지속적인 보안 관리를 가능하게 합니다:
1.
지속적 모니터링: SBOM 기반으로 새로운 취약점이 발견될 때 즉시 영향받는 프로젝트 식별
2.
위험도 기반 우선순위 결정: SBOM 데이터와 실제 사용 패턴을 결합하여 패치 우선순위 자동 결정
3.
트렌드 분석: 시간에 따른 컴포넌트 사용 패턴과 리스크 변화 추적
4.
협업 강화: 개발팀과 보안팀 간의 데이터 기반 소통 촉진
SCA 도구를 제대로 활용하면, SBOM은 단순한 문서가 아닌 살아있는 보안 자산이 됩니다!
SBOM 생성 과정과 결과 분석
이제 간단한 예시를 통해 SBOM이 어떻게 생성되는지 살펴보겠습니다.
실제 프로젝트에서는 선택한 도구에 따라 구체적인 방법이 달라지지만, 전체적인 과정과 결과물의 특성을 이해하는 것이 중요해요!
일반적인 SBOM 생성 과정
1단계: 프로젝트 분석
도구가 프로젝트의 구조와 의존성을 분석합니다:
도구가 프로젝트의 구조와 의존성을 분석합니다:•
패키지 매니저 파일 스캔 (package.json, pom.xml, requirements.txt 등)
•
설치된 패키지와 버전 정보 수집
•
전이 의존성(간접 의존성) 추적
2단계: 메타데이터 수집
각 컴포넌트에 대한 상세 정보를 수집합니다:
각 컴포넌트에 대한 상세 정보를 수집합니다:•
라이선스 정보
•
공급업체 정보
•
패키지 저장소 위치
•
파일 해시 값 (도구에 따라)
3단계: SBOM 문서 생성
수집된 정보를 선택한 표준 형식으로 구조화합니다.
수집된 정보를 선택한 표준 형식으로 구조화합니다. 예시: Node.js 프로젝트
간단한 Express.js 애플리케이션을 예로 들어보겠습니다:
// package.json
{
"name": "sbom-demo-app",
"version": "1.0.0",
"dependencies": {
"express": "^4.18.2",
"lodash": "^4.17.21",
"axios": "^1.3.4"
},
"devDependencies": {
"jest": "^29.5.0"
}
}
JSON
복사
이 간단한 package.json 파일을 SBOM 도구로 스캔하면 다음과 같은 정보들을 얻을 수 있습니다:
•
직접 의존성: 4개 (express, lodash, axios, jest)
•
전이 의존성: 실제로는 60개 이상의 패키지가 간접적으로 포함됨
•
라이선스: 각 패키지의 라이선스 정보 (MIT, Apache 등)
•
취약점: 알려진 CVE가 있는 패키지 식별
•
의존성 트리: 어떤 패키지가 어떤 패키지를 필요로 하는지 관계 정보
예를 들어, express 하나만 설치해도 실제로는 path-to-regexp, cookie, send, mime 등 수십 개의 다른 패키지들이 함께 설치되며, SBOM은 이 모든 것을 추적하여 완전한 소프트웨어 구성 목록을 제공합니다.
SBOM 품질 평가 기준
AI까지 겸비한 솔루션들이 SBOM을 만들어주고 있지만, 그래도 신뢰성 확인은 꼭!!! 해야 합니다.
이 부분이 더 어려운 작업일 수 있지만, 개발자/운영자라면 앞으로 점점 더 필요한 역량이 될 겁니다.
자동으로 추출한 SBOM에서 아래와 같은 요소들을 평가할 수 있어야겠죠?
완성도 (Completeness):•
모든 직접 의존성이 포함되었는가?
•
전이 의존성은 어느 깊이까지 추적되었는가?
•
개발 의존성도 적절히 구분되어 있는가?
정확성 (Accuracy):•
실제 사용되는 버전과 일치하는가?
•
라이선스 정보가 정확한가?
•
중복 항목이나 누락된 항목은 없는가?
유용성 (Usefulness):•
취약점 분석에 필요한 정보가 충분한가?
•
라이선스 컴플라이언스 체크가 가능한가?
•
공급망 리스크 분석에 활용할 수 있는가?
마무리
이번 2화에서는 SBOM을 실제로 생성하고 활용하기 위한 실무 지식을 익혔습니다.
SPDX와 CycloneDX라는 두 주요 표준의 특성을 파악했고, SCA 도구가 단순한 목록 생성을 넘어 지속적인 보안 관리 플랫폼 역할을 할 수 있음을 확인했습니다.
특히 Node.js 프로젝트 예시를 통해 4개의 직접 의존성이 실제로는 60개 이상의 컴포넌트로 확장되는 현실을 직접 목격했습니다.
이것이 바로 SBOM이 필요한 이유입니다.
package.json에 보이지 않는 수많은 전이 의존성들까지 완전히 추적하고 관리할 수 있게 해주니까요.
다만 SBOM을 제대로 활용하려면 도구뿐만 아니라 팀의 역량 개발도 함께 고려해야 합니다.
취약점 분석, 라이선스 관리, 의존성 모니터링까지 새로운 업무 영역이 생기니까요.
오늘 학습한 내용을 바탕으로 여러분의 프로젝트에서 첫 번째 SBOM을 생성/평가해보시길 바랍니다!
참고 자료
성소연 프로
기업에서 오픈소스를 안전하게 사용할 수 있도록 돕는 거버넌스 업무를 담당하고 있어요