공급망 보안(Supply Chain Security)과 SBOM 관리 전략

공급망 공격이 위험한 이유

2020년 SolarWinds 사태는 정상 소프트웨어 업데이트에 악성코드를 심어 18,000개 이상의 기업을 동시 감염시켰습니다. 2022년 Log4Shell도 공급망 보안의 심각성을 보여줬습니다.

SBOM(Software Bill of Materials)이란

SBOM은 소프트웨어를 구성하는 모든 컴포넌트 목록입니다. 미국 행정명령(EO 14028)으로 연방 납품 시 SBOM 제공이 의무화됐습니다.

SBOM 표준 형식

SBOM 생성 도구

# JavaScript/Node.js
npx @cyclonedx/cyclonedx-npm --output-format JSON > sbom.json

# Python
pip install cyclonedx-bom && cyclonedx-py environment > sbom.json

# Java (Maven)
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

# 컨테이너 이미지
syft my-image:latest -o cyclonedx-json > sbom.json

# Trivy로 SBOM 생성 및 취약점 연동
trivy image --format cyclonedx --output sbom.json my-app:latest
trivy sbom sbom.json

아티팩트 서명 (Cosign)

# 컨테이너 이미지 서명
cosign sign --key cosign.key my-registry/my-app:v1.0

# 서명 검증
cosign verify --key cosign.pub my-registry/my-app:v1.0

공급망 보안 체크리스트

개발 단계:
□ 오픈소스 라이선스 확인 (GPL 오염 방지)
□ 의존성 고정 (package-lock.json, poetry.lock)
□ 신뢰할 수 있는 레지스트리만 사용

CI/CD 단계:
□ 빌드마다 SBOM 자동 생성
□ CVE 데이터베이스와 자동 대조
□ 새 취약점 발견 시 즉시 알림

운영 단계:
□ SBOM 아카이브 관리 (버전별 보존)
□ 신규 CVE 발표 시 기존 배포본 소급 점검
□ 취약 컴포넌트 패치 SLA 정의

라이선스 정책

• 허용: MIT, Apache 2.0, BSD
• 검토 필요: LGPL, MPL
• 금지: GPL, AGPL (소스 공개 의무)

공급망 보안은 한 번의 조치로 끝나지 않습니다. Log4Shell처럼 수백 개 제품에 동시 영향을 미치는 취약점이 언제든 등장할 수 있습니다.

의존성 혼동(Dependency Confusion) 공격

사내 비공개 패키지명과 동일한 이름을 공개 레지스트리(npm/PyPI)에 더 높은 버전으로 올려두면, 빌드 도구가 공개본을 당겨가며 악성코드가 주입됩니다.

방어:
- 사내 스코프(@company/...) 강제, 스코프 외 설치 차단
- 비공개 레지스트리 우선순위 고정 + 공개 폴백 비활성화
- 설치 무결성 검증(npm: --ignore-scripts, lockfile 검증)

빌드 파이프라인 자체를 지키기 (SLSA)

SBOM이 "무엇이 들어갔나"라면, SLSA는 "그 빌드를 신뢰할 수 있나"를 다룹니다.

# GitHub Actions — 공급망 강화 핵심 3가지
- uses: actions/checkout@<full-40-char-SHA>   # 태그 대신 SHA로 고정
permissions:
  contents: read          # 최소 권한(default read)
  id-token: write         # OIDC 단기 토큰(장기 시크릿 제거)

• 서드파티 액션은 태그(v4)가 아니라 커밋 SHA로 고정해야 태그 변조 공격을 막습니다.
• 장기 비밀키 대신 OIDC 기반 단기 토큰으로 클라우드에 인증하세요.

VEX — "취약하지만 영향 없음"을 증명

SBOM에 CVE가 100개 붙어도 실제 악용 가능한 것은 일부입니다. VEX(Vulnerability Exploitability eXchange) 문서로 "이 CVE는 해당 함수를 호출하지 않아 영향 없음" 같은 판단을 기록하면, 무의미한 패치 압박과 고객 문의를 줄일 수 있습니다.

국내 맥락

• 과학기술정보통신부·KISA의 소프트웨어 공급망 보안 가이드라인이 SBOM 도입 기준을 제시합니다.
• 공공·금융 납품 시 SBOM 요구가 확대되는 추세이므로, CI 단계의 SBOM 자동 생성을 미리 표준화해 두는 것이 유리합니다.

자주 묻는 질문 (FAQ)

Q. SBOM만 만들면 공급망 보안이 끝나나요? 아니요. SBOM은 "재고 목록"일 뿐입니다. 신규 CVE 발표 시 기존 배포본을 소급 점검(continuous monitoring)하고 패치 SLA를 지키는 운영이 핵심입니다.

Q. SPDX와 CycloneDX 중 무엇을 쓰나요? 라이선스·컴플라이언스 중심이면 SPDX, 취약점 연동·보안 중심이면 CycloneDX가 편합니다. 도구가 둘 다 출력하는 경우가 많으니 소비처 요구에 맞추면 됩니다.