최근 금융권과 공공기관에서 소프트웨어 공급망 보안(Software Supply Chain Security)이 뜨거운 화두입니다. 2020년 SolarWinds 해킹 사건 이후, 전 세계적으로 소프트웨어 구성 요소의 투명성 확보가 얼마나 중요한지 실감하게 되었죠.

여러분이 사용하는 소프트웨어 안에는 수백, 수천 개의 오픈소스 라이브러리와 서드파티 컴포넌트가 숨어 있습니다. 그중 단 하나의 취약점이라도 악용되면, 전체 시스템이 위험에 빠질 수 있습니다. 바로 이런 문제를 해결하기 위해 등장한 개념이 SBOM, VDR, VEX입니다.

오늘은 이 세 가지 개념을 실무에 바로 적용할 수 있도록 상세히 풀어드리겠습니다.

 

 

01. 공급망 보안이 왜 이렇게 중요해졌을까?

소프트웨어 개발 환경이 급격히 변화하고 있습니다. 과거에는 모든 코드를 직접 작성했지만, 지금은 70~90%가 오픈소스나 서드파티 라이브러리로 구성됩니다.

실제로 2021년 발생한 Log4Shell 취약점(CVE-2021-44228)을 기억하시나요? 전 세계 수백만 개의 애플리케이션이 영향을 받았고, 많은 기업이 자사 소프트웨어에 해당 라이브러리가 포함되어 있는지조차 파악하지 못했습니다.

이처럼 “우리 시스템에 무엇이 들어있는지 모르는 상태”는 더 이상 용납되지 않습니다. 미국 바이든 행정부의 사이버보안 행정명령(Executive Order 14028)에서도 SBOM 제출을 의무화했고, 한국 역시 과기정통부와 KISA를 중심으로 소프트웨어 공급망 보안 가이드라인을 강화하고 있습니다.

 

 

 

02. SBOM이란? 소프트웨어의 성분표

SBOM의 정의와 역할

SBOM(Software Bill of Materials)은 말 그대로 ‘소프트웨어 자재 명세서’입니다. 식품의 영양성분표처럼, 소프트웨어를 구성하는 모든 컴포넌트, 라이브러리, 모듈의 목록을 상세히 기록한 문서입니다.

SBOM에는 다음과 같은 정보가 포함됩니다:

항목	설명	예시
컴포넌트 이름	라이브러리나 패키지명	Apache Log4j
버전	정확한 버전 번호	2.14.1
공급자	개발/배포 주체	Apache Software Foundation
라이선스	사용 조건	Apache License 2.0
의존성	다른 컴포넌트와의 관계	slf4j-api 1.7.25
해시값	무결성 검증용	SHA-256: a1b2c3…

SBOM의 실질적 활용

실무에서 SBOM은 어떻게 활용될까요?

취약점 신속 대응
Log4Shell 같은 긴급 취약점이 발표되면, SBOM이 있으면 5분 안에 영향 범위를 파악할 수 있습니다. SBOM이 없으면 며칠씩 걸릴 수도 있죠.

라이선스 컴플라이언스
GPL 라이선스를 가진 오픈소스를 상용 소프트웨어에 잘못 포함하면 법적 문제가 발생할 수 있습니다. SBOM으로 사전에 라이선스를 검토하면 이런 리스크를 예방할 수 있습니다.

공급망 투명성 확보
고객이나 감독기관에 “우리 소프트웨어는 안전합니다”라고 증명할 수 있는 객관적 근거가 됩니다.

 

 

03. SBOM 표준 형식은 어떤 게 있을까?

SBOM은 여러 형식으로 작성할 수 있는데, 현재 업계 표준으로 자리잡은 세 가지 형식이 있습니다.

SPDX (Software Package Data Exchange)

리눅스 재단(Linux Foundation)에서 개발한 ISO/IEC 5962 국제 표준입니다.

특징:

• 가장 역사가 오래되고 성숙한 표준 (2010년 시작)
• JSON, XML, YAML, RDF 등 다양한 포맷 지원
• 라이선스 정보에 특히 강점

예시 (JSON 형식):

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "MyApp-SBOM",
  "packages": [{
    "name": "log4j-core",
    "SPDXID": "SPDXRef-Package-log4j",
    "versionInfo": "2.17.1",
    "licenseConcluded": "Apache-2.0"
  }]
}

공식 사이트: https://spdx.dev/

CycloneDX

OWASP(Open Web Application Security Project)에서 관리하는 형식으로, 보안에 특화되어 있습니다.

특징:

• 취약점 정보(VEX 포함) 통합 지원
• 서비스 BOM(SaaSBOM), 하드웨어 BOM 확장 가능
• JSON, XML 형식 지원
• 보안 전문가들 사이에서 인기

예시 (JSON 형식):

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [{
    "type": "library",
    "name": "log4j-core",
    "version": "2.17.1",
    "purl": "pkg:maven/org.apache.logging.log4j/[email protected]"
  }]
}

공식 사이트: https://cyclonedx.org/

SWID (Software Identification Tag)

ISO/IEC 19770-2 표준으로, 소프트웨어 자산 관리에 초점을 맞춥니다.

특징:

• 기업 IT 자산 관리와 연계 용이
• XML 기반
• 설치된 소프트웨어 추적에 강점

실무에서는 CycloneDX와 SPDX가 양대 산맥을 이루고 있으며, 보안 중심이라면 CycloneDX, 라이선스 관리가 중요하다면 SPDX를 추천합니다.

 

 

04. VDR이란? 취약점 공개 보고서

VDR의 개념

VDR(Vulnerability Disclosure Report)은 소프트웨어에서 발견된 보안 취약점을 상세히 기술한 문서입니다. CVE(Common Vulnerabilities and Exposures) 정보와 연계되어 있으며, 다음 내용을 포함합니다:

구성 요소	내용
취약점 ID	CVE-2021-44228
심각도	CVSS 점수 (0~10)
영향받는 버전	Log4j 2.0-beta9 ~ 2.14.1
취약점 설명	JNDI Injection 원격 코드 실행
공개일	2021-12-09
패치 버전	2.15.0 이상

VDR의 실무 활용

취약점 우선순위 설정
CVSS 점수가 9.0 이상인 Critical 취약점은 즉시 패치해야 합니다. VDR을 통해 어떤 취약점부터 처리해야 할지 명확해집니다.

패치 계획 수립
취약점이 발견되면 즉시 패치할 수도 있지만, 시스템 안정성을 고려해 테스트 후 단계적으로 적용해야 하는 경우도 많습니다. VDR은 이런 의사결정의 기초 자료가 됩니다.

규제 대응
금융감독원이나 개인정보보호위원회 같은 규제 기관에서 취약점 관리 현황을 요청할 때, VDR 기록이 있으면 체계적으로 대응할 수 있습니다.

 

 

05. VEX란? 취약점 영향도 판단의 핵심

VEX의 정의

VEX(Vulnerability Exploitability Exchange)는 VDR에서 한 단계 더 나아간 개념입니다.

“취약점이 존재하긴 하지만, 우리 시스템에서는 실제로 악용될 수 없다”는 판단을 문서화하는 것이죠.

예를 들어봅시다. 여러분의 애플리케이션에 Log4j 2.14.1이 포함되어 있다고 가정해봅시다. 이 버전에는 Log4Shell 취약점이 있습니다. 하지만 여러분의 코드에서는 해당 기능을 전혀 사용하지 않거나, 방화벽 설정으로 외부 접근이 차단되어 있을 수 있습니다.

이럴 때 VEX를 통해 “취약점은 있지만 영향 없음(Not Affected)” 또는 “완화 조치 적용됨(Mitigated)”이라고 명시할 수 있습니다.

VEX 상태 분류

VEX는 취약점의 상태를 다음과 같이 분류합니다:

상태	영문	설명
영향 없음	Not Affected	취약한 코드 경로를 사용하지 않음
영향 받음	Affected	실제로 악용 가능하며 조치 필요
해결됨	Fixed	패치 적용 완료
조사 중	Under Investigation	영향 여부 분석 중

VEX 실무 예시

Log4Shell 취약점 발표 직후, 수많은 기업이 혼란에 빠졌습니다. “우리 시스템에 Log4j가 있긴 한데, 정말 위험한가?”

이때 VEX가 있었다면:

{
  "vulnerability": {
    "id": "CVE-2021-44228",
    "status": "not_affected",
    "justification": "vulnerable_code_not_in_execute_path",
    "statement": "Log4j는 포함되어 있으나, JNDI lookup 기능은 설정에서 비활성화되어 있으며 외부 입력을 받지 않습니다."
  }
}

이렇게 명확히 기록하고 관리할 수 있었겠죠.

 

 

06. SBOM-VDR-VEX의 연계 프로세스

세 가지 개념이 실제 업무에서 어떻게 연결되는지 단계별로 살펴보겠습니다.

Step 1: SBOM 생성

먼저 소프트웨어를 빌드할 때 자동으로 SBOM을 생성합니다.

방법:

• Java/Maven: CycloneDX Maven Plugin 사용
• JavaScript/npm: SPDX-SBOM-Generator 사용
• Python/pip: cyclonedx-python 사용
• Container: Syft, Trivy 같은 도구 사용

예를 들어 Maven 프로젝트라면 pom.xml에 플러그인을 추가하면 됩니다:

<plugin>
  <groupId>org.cyclonedx</groupId>
  <artifactId>cyclonedx-maven-plugin</artifactId>
  <version>2.7.10</version>
  <executions>
    <execution>
      <goals>
        <goal>makeAggregateBom</goal>
      </goals>
    </execution>
  </executions>
</plugin>

빌드 시 자동으로 target/bom.json 파일이 생성됩니다.

Step 2: 취약점 스캔 및 VDR 생성

SBOM을 기반으로 취약점 데이터베이스(NVD, OSV 등)와 대조하여 VDR을 생성합니다.

도구:

• Dependency-Check: OWASP에서 제공하는 무료 도구
• Grype: Anchore에서 개발한 오픈소스 스캐너
• Trivy: Aqua Security의 컨테이너/SBOM 스캐너

명령어 예시:

# Grype로 SBOM 스캔
grype sbom:./bom.json -o json > vdr.json

Step 3: VEX 작성 및 배포

보안팀이나 개발팀에서 VDR을 검토하고, 각 취약점의 실제 영향도를 판단하여 VEX를 작성합니다.

작성 도구:

• CycloneDX CLI 도구
• 수동 작성 (JSON/XML)
• 자동화 스크립트 (Python, Go 등)

전체 프로세스 흐름도

[소스코드] 
    ↓
[빌드 시스템]
    ↓ (SBOM 생성)
[SBOM 파일]
    ↓ (취약점 DB 조회)
[취약점 스캐너]
    ↓ (VDR 생성)
[VDR 파일]
    ↓ (보안팀 분석)
[VEX 문서]
    ↓ (배포)
[고객/감독기관]

 

 

 

07. 실전 도구 추천: 오늘 당장 시작하기

무료 오픈소스 도구

1. Syft + Grype (Anchore)

가장 인기 있는 조합입니다.

설치 (Linux/Mac):

# Syft 설치 (SBOM 생성)
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Grype 설치 (취약점 스캔)
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

사용법:

# Docker 이미지의 SBOM 생성
syft nginx:latest -o cyclonedx-json > nginx-sbom.json

# SBOM 기반 취약점 스캔
grype sbom:./nginx-sbom.json

공식 문서: https://github.com/anchore/syft

2. OWASP Dependency-Check

Java, .NET, Python 등 다양한 언어 지원.

설치:

# Homebrew (Mac)
brew install dependency-check

# 또는 직접 다운로드
wget https://github.com/jeremylong/DependencyCheck/releases/download/v8.4.3/dependency-check-8.4.3-release.zip

실행:

dependency-check.sh --scan ./my-project --format JSON --out ./reports

공식 사이트: https://owasp.org/www-project-dependency-check/

3. Trivy (Aqua Security)

컨테이너 이미지, 파일시스템, Git 저장소 모두 스캔 가능.

설치:

# Linux
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo "deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install trivy

사용:

# SBOM 생성
trivy image --format cyclonedx nginx:latest > sbom.json

# 취약점 스캔
trivy sbom sbom.json

공식 문서: https://trivy.dev/

상용 플랫폼

규모가 큰 조직이라면 상용 솔루션도 고려할 만합니다:

• Snyk: 개발자 친화적 UI, CI/CD 통합 용이
• JFrog Xray: Artifactory와 연계된 강력한 스캔
• Sonatype Nexus Lifecycle: 엔터프라이즈급 정책 관리
• Black Duck (Synopsys): 오픈소스 거버넌스에 특화

 

 

08. 금융권 실무 적용 사례

제가 근무하는 은행에서는 2023년부터 SBOM 관리 체계를 구축했습니다. 실제 경험을 바탕으로 적용 과정을 공유합니다.

도입 전 문제점

• 오픈소스 라이브러리가 500개 이상인데 관리는 Excel로만
• 취약점 발표되면 며칠간 수작업으로 확인
• Log4Shell 때는 주말 비상 근무까지

도입 과정

1단계: 파일럿 프로젝트 (2개월)

• 주요 애플리케이션 10개 선정
• Syft + Grype 조합으로 테스트
• SBOM 자동 생성 파이프라인 구축

2단계: 전사 확대 (6개월)

• CI/CD에 SBOM 생성 단계 추가
• 개발자 교육 실시
• SBOM 저장소 구축 (Nexus Repository)

3단계: 운영 정착 (현재 진행형)

• 월 1회 전체 SBOM 재스캔
• 취약점 발견 시 자동 알림
• VEX 작성 프로세스 정립

도입 효과

지표	도입 전	도입 후
취약점 파악 시간	3~5일	30분 이내
패치 적용 주기	1~2개월	2주 이내
감사 대응 시간	2주	2일
라이선스 위반	연 3~4건	0건

특히 2024년 3월 XZ Utils 백도어 사건 때, SBOM 덕분에 영향 범위를 즉시 파악하고 선제적으로 대응할 수 있었습니다.

 

 

09. 자주 묻는 질문 (FAQ)

Q1. SBOM은 누가 만들어야 하나요?
A. 소프트웨어 개발자나 공급자가 만들어야 합니다. 빌드 시스템에 자동 생성 도구를 통합하면 수작업 없이 자동으로 생성됩니다.

Q2. SBOM에 기밀 정보가 포함되지 않나요?
A. SBOM은 공개 컴포넌트 목록만 포함하며, 소스코드나 설정 정보는 들어가지 않습니다. 다만 사용하는 라이브러리 버전이 노출되므로, 배포 시 주의가 필요합니다.

Q3. 레거시 시스템도 SBOM을 만들 수 있나요?
A. 가능합니다. 소스코드가 없어도 바이너리나 실행 파일을 분석하는 도구(Black Duck Binary Analysis, Revenera Flexera 등)가 있습니다.

Q4. SBOM 표준은 어떤 걸 선택해야 하나요?
A. 보안이 중요하면 CycloneDX, 라이선스 관리가 중요하면SPDX를 추천합니다. 두 형식 간 변환도 가능하니, 일단 하나를 선택해서 시작하세요.

Q5. VEX 작성이 꼭 필요한가요?
A. 모든 취약점에 VEX를 작성할 필요는 없습니다. Critical/High 등급 취약점이나 규제 대응이 필요한 경우에 작성하면 됩니다.

 

 

10. 2026년 전망과 준비 방향

규제 강화 추세

미국, EU에 이어 한국에서도 소프트웨어 공급망 보안 규제가 본격화될 전망입니다.

미국:

• NIST SP 800-218: Secure Software Development Framework
• CISA의 SBOM 의무화 로드맵

EU:

• Cyber Resilience Act (CRA): 2024년 통과, 2027년 본격 시행
• 취약점 발견 시 24시간 내 ENISA 보고 의무

한국:

• 과기정통부 SW 공급망 보안 가이드라인 (2023)
• 금융보안원의 취약점 관리 강화 방침

지금 준비해야 할 것들

1. SBOM 자동 생성 체계 구축: CI/CD 파이프라인에 통합
2. 취약점 모니터링 프로세스: 일일/주간 스캔 체계 수립
3. 담당자 역량 강화: DevSecOps 교육, 보안 도구 활용법
4. 공급업체 관리: 외부 개발사나 SI업체에도 SBOM 요구

앞으로의 트렌드

AI 기반 자동화
취약점 영향도 분석이나 VEX 작성을 AI가 지원하는 도구들이 나오고 있습니다.

SaaSBOM, HardwareBOM 확장
소프트웨어뿐 아니라 SaaS 서비스, 하드웨어 컴포넌트까지 BOM 개념이 확대됩니다.

블록체인 기반 검증
SBOM의 무결성을 블록체인으로 검증하는 시도도 진행 중입니다.

 

 

소프트웨어 공급망 보안은 더 이상 선택이 아닌 필수입니다. SBOM, VDR, VEX라는 세 가지 핵심 개념만 제대로 이해하고 적용해도, 여러분의 조직은 한 단계 성숙한 보안 체계를 갖출 수 있습니다. 처음에는 복잡하고 어렵게 느껴질 수 있지만, 오픈소스 도구들을 활용하면 생각보다 쉽게 시작할 수 있습니다. 오늘 당장 Syft나 Trivy를 설치해서 여러분의 프로젝트 하나에 적용해보세요.

 

 

---

참고 자료:

• CISA SBOM 가이드: https://www.cisa.gov/sbom
• NIST 소프트웨어 공급망 보안: https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security
• OWASP CycloneDX: https://cyclonedx.org/
• Linux Foundation SPDX: https://spdx.dev/
• Anchore Syft: https://github.com/anchore/syft