본문으로 건너뛰기

SBOM 생성

우리 서비스에 어떤 라이브러리가 포함되어 있는지 정확히 알고 계신가요? SBOM(Software Bill of Materials)은 소프트웨어에 포함된 모든 구성요소의 목록입니다. 마치 식품의 "재료 목록"처럼, 소프트웨어가 어떤 부품들로 이루어져 있는지 투명하게 보여줍니다.

SBOM이 왜 중요한가요?

Log4Shell(CVE-2021-44228) 같은 보안 사고가 발생했을 때, SBOM이 있으면 "우리 서비스 중 어디에 Log4j가 사용되고 있지?"라는 질문에 즉시 답할 수 있습니다. SBOM 없이는 모든 서비스를 일일이 확인해야 하므로 대응이 늦어질 수밖에 없습니다.

SBOM 결과

개요​

  • SBOM이란: 소프트웨어에 포함된 모든 구성요소(라이브러리, 패키지 등)의 목록
  • 생성 시점: [보안 분석] 페이지의 SBOM / 라이선스 탭에서 독립 스캔으로 직접 실행 (SAST/SCA 스캔으로 자동 생성되지 않음)
  • 표준 형식: CycloneDX 1.6 및 SPDX 1.5 (JSON). 스캔 이력에 각 SBOM의 생성 형식이 표시됩니다.
  • 확인 위치: [보안 분석] 메뉴 > 서비스 선택 > SBOM / 라이선스 탭
SBOM/라이선스 스캔 실행 방식

KIOPS는 SBOM/라이선스 스캔을 SAST·SCA와 분리된 독립적인 스캔으로 제공합니다. 사용자는 [보안 분석] 페이지의 SBOM / 라이선스 탭에서 [스캔 시작] 버튼으로 직접 실행합니다 — SAST나 SCA 스캔을 실행해도 SBOM은 자동으로 생성되지 않습니다. SBOM은 Syft, 소스 라이선스는 ScanCode로 생성되며, SBOM / 라이선스 탭에서 결과 조회와 다운로드, 라이선스 검토를 수행합니다.

SBOM 결과 확인 방법​

  1. 사이드바의 "보안" 그룹 > [보안 분석] 메뉴를 클릭합니다.
  2. 페이지 상단의 카드 캐러셀에서 서비스를 선택합니다.
  3. SBOM / 라이선스 탭을 선택합니다.
  4. 탭 내부 토글로 SBOM 구성요소 보기와 라이선스 분석 보기를 전환합니다.
URL로 바로 진입하기

/security?id={서비스ID}&area=sbom URL로 진입하면 해당 서비스의 SBOM / 라이선스 탭이 바로 열립니다.

라이선스 분석 결과는 SBOM 컴포넌트 데이터에서 파생되는 한 개념이므로 별도 탭이 아닌 같은 탭의 토글로 통합되어 있습니다. [보안 분석] 페이지의 SBOM·라이선스 영역 상태는 license_analysis 테이블의 카테고리 합산으로 표시됩니다 — strong_copyleft는 위험도 High, weak_copyleft는 Medium으로 분류됩니다.

SBOM의 필요성​

규정 준수​

전 세계적으로 SBOM 제출을 의무화하는 규정이 늘어나고 있습니다.

  • EO 14028 (미국): 미국 연방정부와 거래하는 소프트웨어 공급업체는 SBOM을 제공해야 합니다.
  • EU CRA (유럽): 유럽 사이버 복원력법에 따라 디지털 제품에 SBOM이 필요합니다.

보안 관리​

  • 공급망 공격 대응: 어떤 구성요소가 포함되어 있는지 파악하여 공급망 공격에 빠르게 대응
  • 취약점 영향 범위 파악: 새로운 CVE가 발표되면 영향받는 서비스를 즉시 식별
  • 라이선스 컴플라이언스: 사용 중인 오픈소스 라이선스 파악 및 관리

SBOM 유형​

KIOPS는 분석 대상에 따라 두 가지 유형의 SBOM을 생성합니다. 두 유형 모두 SBOM / 라이선스 탭에서 출처 토글(소스 / 이미지)을 선택해 독립 스캔으로 실행합니다.

소스 SBOM (sbom_type: 'source')​

출처 토글에서 소스코드를 선택해 실행합니다(Syft + ScanCode).

  • 분석 대상: Git 저장소의 소스 코드 및 의존성 매니페스트 파일
  • 포함 정보: package.json, requirements.txt, pom.xml, go.sum 등에 명시된 라이브러리

이미지 SBOM (sbom_type: 'image')​

출처 토글에서 컨테이너 이미지를 선택해 실행합니다(Syft).

  • 분석 대상: 빌드된 컨테이너 이미지
  • 포함 정보: OS 패키지(apt/apk) + 언어 패키지 + 베이스 이미지 구성요소
두 SBOM의 차이

소스 SBOM은 "선언된 의존성"을, 이미지 SBOM은 "실제 빌드 결과물에 포함된 모든 구성요소"를 보여줍니다. 보안 분석과 컴플라이언스 측면에서는 두 SBOM을 모두 보유하는 것이 권장됩니다.

VEX 정보 결합​

SBOM 생성 시 함께 실행되는 취약점 스캐너의 VEX 적용 여부는 SBOM 유형에 따라 비대칭으로 설정됩니다.

  • 이미지 SBOM: Syft는 컨테이너 이미지와 소스 코드 모두에서 CycloneDX/SPDX 형식의 SBOM을 생성합니다. VEX 필터링은 Syft가 아닌 별도의 Trivy 취약점 스캔에서만 수행되며, 이미지 SBOM 생성 시에는 적용되지 않습니다.
  • 소스 SBOM: ScanCode의 라이선스 분석은 취약점 필터링을 수행하지 않습니다. GitHub API 레이트 리미트 회피를 위해 VEX 조회는 생략됩니다. 이는 설계상 의도된 비대칭성으로, 소스 코드 라이선스 정확성을 우선시합니다.
"SBOM인데 왜 취약점도 함께 도는가?"

SBOM 생성 시 취약점 스캐너를 함께 호출하는 이유는, 스캐너가 의존성 트리를 구축하기 위해 필요하기 때문입니다. 이미지 SBOM은 VEX 결과까지 결합해 "어떤 구성요소가 실제로 영향을 받는지"를 더 풍부하게 보여줍니다.

SBOM 다운로드​

SBOM / 라이선스 탭에서 다운로드 버튼을 클릭하면 JSON 형식으로 다운로드됩니다.

  • 형식: SBOM 스캔 시 선택한 형식(CycloneDX 또는 SPDX)의 JSON으로 제공됩니다. CycloneDX는 최신 Syft 기준 1.6 버전으로 출력됩니다.
  • XML 미지원: XML 다운로드는 제공되지 않습니다.
  • 다운로드 버튼 라벨: 버튼에 JSON (CycloneDX) 라벨이 고정 표기될 수 있으나 이는 UI 라벨일 뿐이며, 실제 저장되는 파일은 스캔 시 생성된 형식(CycloneDX 또는 SPDX)의 JSON입니다.

배포된 이미지 기준 SBOM 선택​

SBOM 히스토리에서 초기 선택 우선순위는 다음과 같습니다:

  1. 배포된 이미지/커밋 매칭 (우선순위 1순위): 현재 배포된 이미지 URL 또는 커밋 SHA와 일치하는 SBOM이 자동 선택됩니다.
  2. 다중 이미지 배포 시 primary 이외의 실제 배포 이미지 매칭 (우선순위 2순위): primary 이미지에 해당하는 SBOM이 없으면, actual_image_urls에 포함된 다른 실제 배포 이미지와 일치하는 SBOM을 선택합니다.
  3. 최신 SBOM (우선순위 3순위): 매칭되는 SBOM이 없으면 가장 최근에 생성된 SBOM이 선택됩니다.

라이선스 정보가 있는 SBOM을 우선하는 이전 동작(2026-05-28 이전)은 제거되었습니다.

소스 SBOM 이력 테이블에서도 현재 배포 중인 커밋을 강조 표시합니다. 스캔 이력 테이블의 커밋 컬럼에 "현재 배포됨" 라벨이 표시되어 어느 소스 버전이 운영 중인지 한눈에 확인할 수 있습니다.

SBOM 내용 이해하기​

CycloneDX 예시​

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.18.2",
      "purl": "pkg:npm/express@4.18.2",
      "licenses": [{"id": "MIT"}]
    }
  ]
}

포함되는 정보​

SBOM에는 각 구성요소에 대해 이름, 정확한 설치 버전, PURL(Package URL), 라이선스 정보가 포함됩니다. 각 컴포넌트에 대해 license_analysis 테이블에 별도 행이 생성되며, SPDX 라이선스 ID, 카테고리(permissive/weak_copyleft/strong_copyleft/proprietary/unknown), 위험도(low/medium/high/critical) 정보가 저장됩니다.

PURL이란?

Package URL(PURL)은 패키지를 전 세계적으로 고유하게 식별하는 표준입니다. pkg:npm/express@4.18.2처럼 표기되며, 패키지 타입, 이름, 버전을 하나의 문자열로 표현합니다.

SBOM 유형별 컴포넌트 컬럼​

참조(Reference) 컬럼은 이미지 SBOM에서만 표시됩니다. 소스 SBOM에서는 Syft이 externalReferences를 채우지 않아 의미있는 데이터가 없으므로 조건부로 숨깁니다.

라이선스 카테고리 및 위험도​

SBOM과 함께 생성된 라이선스 정보는 SBOM / 라이선스 탭의 라이선스 분석 보기에서 확인합니다.

라이선스 카테고리 (license_analysis.license_category)​

  • permissive: 허용적 라이선스 (MIT, Apache-2.0, BSD, ISC, Zlib 등) — risk_level: low
  • weak_copyleft: 약한 Copyleft (LGPL, MPL, EPL 등) — risk_level: medium
  • strong_copyleft: 강한 Copyleft (GPL, AGPL, EUPL 등) — risk_level: high
  • proprietary: 독점 라이선스 (Commercial, BUSL-1.1 등) — risk_level: critical
  • unknown: 식별 불가 — risk_level: medium

라이선스 위험도 (license_analysis.risk_level)​

  • low: 일반적인 사용에 제약 없음 (permissive)
  • medium: 주의 필요 (weak_copyleft, unknown)
  • high: 강한 Copyleft (GPL, AGPL 등)
  • critical: 상용 라이선스 또는 미식별 라이선스 (proprietary)
GPL 라이선스 주의

GPL 라이선스 라이브러리를 사용하면 파생 작업물의 소스 코드도 공개해야 할 수 있습니다. 상용 소프트웨어에서는 GPL 라이선스 사용에 주의가 필요합니다. SBOM에서 strong_copyleft 또는 critical 위험도 라이선스가 발견되면 법무팀과 상의하세요.

SBOM 활용 사례​

취약점 분석 연동​

새로운 CVE가 발표되었을 때 SBOM을 활용하면 영향받는 서비스를 빠르게 찾을 수 있습니다. SBOM과 CVE를 대조하여 해당 패키지를 사용하는 서비스를 자동으로 식별하고 대응할 수 있습니다.

라이선스 분석​

오픈소스 라이선스 위반은 법적 문제로 이어질 수 있습니다. SBOM의 라이선스 카테고리/위험도를 통해 사용 중인 라이선스를 파악하세요.

공급망 검증​

버전 간 SBOM을 비교하여 의존성 변경 사항을 추적하고, 알려지지 않은 공급자의 패키지가 포함되어 있지 않은지 확인할 수 있습니다.

문제 해결​

생성 실패​

  • 이미지/저장소 접근 불가: 컨테이너 레지스트리 또는 Git 토큰 인증 정보를 확인하세요. 토큰이 만료되었거나 권한이 부족할 수 있습니다.

불완전한 SBOM​

  • Lock 파일 없음: package-lock.json, yarn.lock 등의 lock 파일이 없으면 정확한 버전 정보를 추출할 수 없습니다.
  • 멀티스테이지 빌드: 멀티스테이지 빌드에서 최종 이미지에 복사되지 않은 패키지는 SBOM에 포함되지 않습니다. 이는 정상적인 동작입니다.

관련 가이드​

  • SCA 스캔 - 취약점 분석 (SBOM과 별개의 독립 스캔)
  • SAST 스캔 - 소스 코드 분석 (SBOM과 별개의 독립 스캔)