1️⃣ 배경
최근 몇 년 사이 보안 사고는 단순한 해킹을 넘어, 소프트웨어 공급망 전체를 겨냥한 대규모 공격으로 확산되고 있습니다.
Log4j (CVE-2021-44228, 일명 Log4Shell / 2021.11): 전 세계 수억 대 시스템에 탑재된 로그 라이브러리 하나의 취약점이 전 세계 인터넷 인프라를 위협
SolarWinds (2020.12): 백도어가 삽입된 빌드 툴을 통해 수천 개 기업 내부망이 은밀히 침해
이들 사건의 공통점은 무엇일까요?
바로 직접 작성한 코드가 아니라, 외부 라이브러리나 서드파티 컴포넌트 — 즉, 소프트웨어 구성요소 속에 취약점이 숨어 있었다는 것입니다.
이러한 사건들을 계기로 미국 정부는 2021년 행정명령 EO 14028을 통해 소프트웨어 공급망 보안을 강화했고, 그 중심에 SBOM을 명시했습니다.
이후 EU RED 인증, 미국 FDA 의료기기 보안 가이드라인에도 SBOM이 포함되며, 글로벌 표준으로 자리 잡고 있습니다.
2️⃣ SBOM이란?
SBOM (Software Bill of Materials) 은 말 그대로 소프트웨어의 자재명세서로, 어떤 라이브러리, 모듈, 외부 컴포넌트가 사용되었는지를 시스템이 읽을 수 있는 구조로 나열한 목록입니다.
SBOM이 포함하는 정보
구성요소 이름 및 버전 (예: log4j-core 2.14.1)
라이선스 (예: Apache-2.0)
공급처 (예: Maven 저장소 URL)
식별자 (PURL, CPE 등)
예시: CycloneDX 포맷으로 작성된 SBOM
{ "bomFormat": "CycloneDX", "specVersion": "1.4", "version": 1, "components": [ { "type": "library", "name": "log4j-core", "version": "2.14.1", "group": "org.apache.logging.log4j", "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1", "licenses": [ { "license": { "id": "Apache-2.0" } } ] } ] }
💡 참고: CycloneDX 외에도 SPDX, SWID 등 포맷이 있으며, SBOM 표준은 계속 발전 중입니다.
위 JSON SBOM 문서를 통해 다음과 같은 분석이 가능합니다:
SBOM의 핵심 기능
이처럼 SBOM은 단순한 목록을 넘어, 소프트웨어 보안과 신뢰를 위한 핵심 도구로 자리 잡고 있습니다.
3️⃣ SBOM 보안 취약점 분석 방법
SBOM이 유의미해지려면 단순히 구성요소 리스트만 나열하는 것을 넘어, 자동 보안 분석이 가능해야 합니다.
이때 핵심이 되는 개념이 바로 CPE, CVE, 그리고 VEX입니다.
핵심 용어 정리
예시로 이해하기: Log4j 2.14.1 취약점 분석 흐름
1. SBOM에서 구성요소 확인
우선 SBOM 파일 안에 다음과 같은 항목이 포함되어 있다고 가정합니다:
SW명: log4j-core
SW 버전: 2.14.1
Vendor: apache
이 정보는 SBOM 생성 도구나 빌드 시스템에서 자동으로 추출하거나 직접 식별합니다.
2. CPE 식별
다음으로는 해당 소프트웨어 구성요소에 대응하는 CPE 값을 찾아야 합니다.
CPE를 찾기 위해 NVD(National Vulnerability Database) 공식 CPE 검색 사이트에 접속합니다.
검색창에 log4j 혹은 log4j-core, apache 등을 입력하여 관련된 항목을 찾습니다.
예를 들어, log4j-core 2.14.1의 경우 아래와 같은 CPE가 해당됩니다:
# CPE 식별 결과
cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*
💡 참고: SBOM에 나타난 이름이나 버전 정보가 정확히 NVD에 등록된 CPE와 일치하지 않을 수 있습니다. 이 경우에는 최대한 유사한 항목을 찾는 과정이 필요합니다.
예를 들어 log4j-core라는 이름은 CPE에서는 단순히 log4j로 나타날 수 있으므로, 표기 방식의 차이를 감안해 유사도 기반 검색이 중요합니다.
3. CVE 조회
CPE가 식별되면, 해당 CPE에 연결된 보안 취약점(CVE)을 확인할 수 있습니다.
CVE는 전 세계적으로 공개된 보안 취약점 목록이며, 각 항목에는 고유한 식별자(ID)가 부여되어 있습니다.
위에서 식별한 log4j 2.14.1 CPE는 CVE-2021-44228 취약점과 연결되어 있습니다.
리모트 코드 실행(RCE)이 가능한 치명적인 이슈로, 전 세계적으로 큰 파장을 일으킨 바 있는 일명 Log4Shell 취약점입니다.
취약점 상세 정보를 통해 CVE-2021-44228은 CVSS 10점 만점(Critical) 으로 평가된 치명적인 취약점으로, 즉시 조치가 필요한 대상임을 확인할 수 있습니다.
💡 참고: CVSS(Common Vulnerability Scoring System)는 보안 취약점의 심각도를 0에서 10까지 점수로 평가해, 대응 우선순위를 정하는 국제 표준 지표입니다.
4. VEX 문서
마지막 단계에서는 식별된 취약점이 실제로 우리 시스템에 영향을 미치는지를 확인해야 합니다. 이때 활용되는 것이 VEX(Vulnerability Exploitability eXchange) 문서입니다.
아래 VEX JSON 문서는 CVE-2021-44228 취약점과 관련하여, 해당 소프트웨어 기능 중 ‘JNDI’ 부분이 우리 시스템에서는 사용되지 않는다는 점을 확인하였습니다.
따라서, 이 취약점에 대해서는 실제 공격 위험이 없으므로 not_affected(영향 없음)로 분류된 내용입니다.
{ "vulnerabilities": [ { "id": "CVE-2021-44228", "analysis": { "state": "not_affected", "justification": "component_not_present" }, "affects": [ { "ref": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1" } ] } ] }
VEX 문서에서 주로 사용하는 analysis.state 값들은 다음과 같은 표준 상태들이 있습니다:
affected : 해당 취약점이 컴포넌트에 영향을 미침
not_affected : 해당 취약점이 컴포넌트에 영향을 미치지 않음
under_investigation : 영향 여부를 조사 중
requires_configuration : 특정 설정에 따라 영향 여부가 달라짐
deprecated : 더 이상 사용되지 않는 상태
이 상태 값들은 VEX 표준 문서나 관련 스펙에서 정의되어 있습니다.
4️⃣ SBOM 기반 취약점 분석의 기대효과
체계적인 CPE → CVE → VEX 분석 흐름이 구축되면, SBOM은 단순한 구성요소 목록을 넘어 실제 보안 위협을 빠르게 식별하고 대응하는 강력한 도구가 됩니다.
이를 통해 조직은 다음과 같은 보안 관리 역량을 갖추게 됩니다:
취약한 컴포넌트를 신속하고 정확하게 파악
실제로 대응이 필요한 취약점만 선별해 효율적인 리소스 운영 가능
개발팀, 보안팀, 인증팀 간 불필요한 소통 비용과 혼선을 최소화
또한, SBOM 관리 프로세스를 자동화 도구나 CI/CD 파이프라인에 연동하면, 취약점 대응의 실시간성 및 정확도를 더욱 높일 수 있습니다.
5️⃣ 결론
소프트웨어 공급망 보안 위협이 점차 고도화되는 상황에서, SBOM은 단순한 문서가 아닌 보안과 신뢰를 확보하기 위한 필수 기반 체계로 자리 잡았습니다.
모든 조직과 개발팀은 SBOM을 반드시 생성하고 관리하는 체계를 구축해야 하며, 이는 앞으로 각종 보안 규제와 산업 표준의 기본 요건이 될 것입니다.
따라서 SBOM 도입은 더 이상 선택이 아니라, 안전하고 신뢰할 수 있는 소프트웨어 운영을 위한 필수 조건임을 명확히 인식해야 합니다.