SBOM과 오픈소스 취약점 관리 – 정보보호 전문가 실전 가이드
SBOM은 개발자, 보안 담당자, 법무팀 등 다양한 이해관계자에게 구성 요소의 가시성과 신뢰성 제공
목차
ㄴ SBOM 개요
ㄴ SBOM 표 예시 (CSV 또는 표 기반 시각화)
ㄴ 실제 SBOM 예시 형태 (SPDX JSON 일부 예)
ㄴ SBOM과 정보보호의 연관성
ㄴ 오픈소스 취약점 이슈와 대응
ㄴ SBOM을 활용한 오픈소스 보안 관리 전략
ㄴ SBOM 도입 시 고려사항
ㄴ 국내외 정책 및 규제 동향
ㄴ SBOM 운영 프로세스 및 실제 적용 사례
■ SBOM 개요
**SBOM(Software Bill of Materials)**은 소프트웨어를 구성하는 오픈소스 및 서드파티 라이브러리의 목록을 명세한 문서입니다. 즉, “이 소프트웨어 안에 어떤 부품이 들어있느냐”를 투명하게 보여주는 소프트웨어 구성 명세서입니다.
※ SBOM은 개발자, 보안 담당자, 법무팀 등 다양한 이해관계자에게 구성 요소의 가시성과 신뢰성을 제공합니다.
- 주요항목
- 컴포넌트명 (name)
- 버전 (version)
- 해시값 (Hash/SHA256)
- 라이선스 정보
- 의존성 관계 (dependency tree)
■ SBOM 표 예시 (CSV 또는 표 기반 시각화)
| 항목 (Field) | 설명 (Description) | 예시 값 (Sample) |
| Component Name | 오픈소스 구성요소 또는 라이브러리 이름 | log4j-core |
| Version | 사용된 구성요소의 버전 | 2.17.1 |
| Type | 소프트웨어 구성 요소 유형 (library, application, framework 등) | library |
| Supplier | 구성 요소를 제공한 공급자 또는 제작자 | Apache Software Foundation |
| Package URL (purl) | 구성 요소를 고유하게 식별하기 위한 표준 URL | pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1 |
| License | 해당 구성 요소의 라이선스 정보 | Apache-2.0 |
| Copyright | 저작권 정보 | Copyright 2021 Apache Software Foundation |
| Vulnerability Info | 알려진 취약점 정보 (CVE 등) | CVE-2021-44228 |
| Checksum (SHA-256) | 파일 무결성 확인을 위한 해시 | 1a2b3c... (SHA-256 값) |
| Dependency Relationship | 다른 구성요소와의 의존 관계 (optional) | direct / transitive |
■ 실제 SBOM 예시 형태 (SPDX JSON 일부 예)
{
"name": "log4j-core",
"versionInfo": "2.17.1",
"supplier": "Organization: Apache Software Foundation",
"downloadLocation": "https://repo.maven.apache.org/maven2/...",
"licenseConcluded": "Apache-2.0",
"copyrightText": "Copyright 2021 Apache Software Foundation",
"externalRefs": [
{
"referenceCategory": "PACKAGE-MANAGER",
"referenceType": "purl",
"referenceLocator": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1"
}
],
"checksums": [
{
"algorithm": "SHA256",
"checksumValue": "e6b1...cc9a"
}
]
}
■ SBOM과 정보보호의 연관성
SBOM은 단순한 리스트 이상의 역할을 합니다. 특히 공급망 보안 측면에서 다음과 같은 기능을 수행합니다.
- 신뢰할 수 없는 코드 탐지 : 외부에서 유입된 의심스러운 오픈소스 식별
- 취약한 컴포넌트 선제 대응 : CVE와 매칭하여 위험 요소 조기 대응
- DevSecOps 연계 : 개발과 동시에 보안을 자동화하는 기반 요소
SBOM은 Zero Trust 아키텍처에서도 핵심 요소로 자리 잡고 있으며, 클라우드·컨테이너 환경에서도 사용 범위가 확대되고 있습니다.
■ 오픈소스 취약점 이슈와 대응
대다수의 소프트웨어는 수십~수백 개의 오픈소스 라이브러리를 포함합니다. 이들 중 일부는 다음과 같은 이유로 심각한 보안 위협이 될 수 있습니다
- CVE 미등록 상태로 은폐된 취약점 존재
- 유지보수 종료로 패치 불가능한 컴포넌트
- 의도적으로 악성 코드가 삽입된 오픈소스 백도어 사례 (예: xz 백도어 사건)
※ 대표 사례
- Log4j 취약점 (CVE-2021-44228) : 전 세계 수백만 개 시스템에 영향
- Spring4Shell (CVE-2022-22965) : 스프링 프레임워크 기반 서비스 전체 노출
- XZ 백도어 : 주요 리눅스 배포판에 사전 삽입된 공급망 공격 사례
오픈소스는 보안 취약점이 발견되더라도 자동으로 알림이 오지 않기 때문에, SBOM은 이를 추적하고 관리하는 핵심 도구입니다
■ SBOM을 활용한 오픈소스 보안 관리 전략
보안 담당자는 SBOM을 통해 다음과 같은 보안 전략을 수립할 수 있습니다
- 취약한 라이브러리 자동 식별 : CVE/CWE와 연동하여 위험도 파악
- 패치 우선순위 결정 : 활용 범위와 외부 노출 여부에 따라 대응 속도 차등화
- 신뢰 출처 확인 : 공식 저장소 여부 및 hash값 검증으로 무결성 확보
- 자동화된 SCA 도구 연계 : Snyk, Anchore, Trivy 등과 연동하여 실시간 관리
※ TIP : SBOM 단독으로는 exploitability까지 확인 불가 → VEX와 함께 사용하면, 실제로 공격 가능한지 여부까지 파악 가능
■ SBOM 도입 시 고려사항
SBOM 생성 및 활용 시 다음과 같은 사항을 고려해야 합니다
1. SBOM 생성 도구
- Syft (Anchore)
- Trivy (Aqua)
- CycloneDX (OWASP)
- SPDX (Linux Foundation)
2. 포맷 선택 기준
| 포맷 | 특징 |
| SPDX | ISO/IEC 표준 채택, 법적 라이선스 명시 용이 |
| CycloneDX | 보안 위협 대응 중심, VEX와의 통합 지원 |
| SWID | 에이전트 기반 상용 SW에 적합 |
3. CI/CD 통합
- GitHub Actions, GitLab CI, Jenkins 등에 자동화 플러그인 존재
- 빌드시 SBOM 자동 생성 → 저장소에 등록 방식으로 연동
■ 국내외 정책 및 규제 동향
SBOM 도입은 선택이 아닌 필수로 바뀌고 있습니다
- 미국 : EO 14028 이후 연방정부 납품 SW는 SBOM 필수
- NIST : SP 800-218 (SSDF)에서 SBOM 요구사항 명시
- EU : CRA(Cyber Resilience Act)에서 제조사 SBOM 제출 의무화
- 대한민국
- KISA : 오픈소스 보안 가이드 권고 강화
- ISMS-P : 오픈소스 컴포넌트 관리 항목 포함될 가능성
- 금융권 : 전자금융감독규정 해석상 취약점 선제 대응 요구 증가
■ SBOM 운영 프로세스 및 실제 적용 사례
※ 운영 프로세스 예시
- 소스코드 분석 → SBOM 생성 → 저장소 등록 → 취약점 연동(CVE) → 패치 또는 교체
※ 사례
- 미국 금융권 : 내부 레거시 시스템부터 SBOM 도입, 취약점 트래킹 자동화
- 국내 IT기업 : SCA 도구 + VEX 연계, SBOM 자동화 운영
- 정부기관 : 공개 소프트웨어 등록 시 SBOM 제출 권고 시행 중
감사합니다.