공급망 보안

• 1: 소프트웨어 공급망 공격과 보안 필요성
• 1.1: 규제 동향
• 1.2: SK텔레콤 공급망 보안 정책
• 2: SBOM 이란?
• 2.1: SBOM 개념 및 필요성
• 2.2: SBOM 표준
• 3: 공급사 SBOM 제출 가이드
• 3.1: SBOM 제출 요구사항
• 3.2: BomLens
• 3.3: 오픈소스 도구를 활용한 SBOM 생성
• 3.4: 서버(OS + 애플리케이션) SBOM 생성
• 3.5: SBOM 제출 전 검증 체크리스트
• 3.6: SBOM 제출 절차

1 - 소프트웨어 공급망 공격과 보안 필요성

1. 소프트웨어 공급망 공격이란?

소프트웨어 공급망 공격(Software Supply Chain Attack)은 공격자가 소프트웨어 개발사나 공급업체의 시스템, 또는 개발 과정에 침투하여 악성 코드를 심거나 취약점을 악용하는 사이버 공격 기법입니다.

전통적인 공격이 최종 사용자를 직접 겨냥했다면, 공급망 공격은 신뢰받는 소프트웨어 업데이트나 개발 도구를 오염시켜 이를 사용하는 수많은 하류(Downstream) 기업과 사용자들을 동시에 감염시킵니다.

graph LR
    A[공격자] -->|침투| B[공급업체 빌드 서버]
    B -->|악성코드 주입| C[오염된 소프트웨어 업데이트]
    C -->|배포| D[고객사 A]
    C -->|배포| E[고객사 B]
    C -->|배포| F[고객사 C]
    style B fill:#f9f,stroke:#333,stroke-width:2px
    style C fill:#f96,stroke:#333,stroke-width:2px

2. 주요 공격 사례

최근 몇 년간 발생한 대형 보안 사고들은 공급망 보안의 중요성을 전 세계에 각인시켰습니다.

SolarWinds 사태 (2020)

• 개요: 네트워크 모니터링 솔루션인 SolarWinds Orion의 빌드 시스템이 해킹당해, 정상적인 업데이트 파일에 백도어가 심어졌습니다.
• 피해: 미국 정부 기관, 포춘 500대 기업 등 전 세계 18,000여 개 조직이 피해를 입었습니다.
• 시사점: 신뢰하는 벤더의 정식 서명된 소프트웨어조차 안전하지 않을 수 있음을 보여주었습니다.

Log4j 취약점 (2021)

• 개요: 자바 기반 로깅 라이브러리인 Log4j에서 원격 코드 실행(RCE)이 가능한 치명적인 취약점(Log4Shell)이 발견되었습니다.
• 피해: 이 라이브러리를 직간접적으로 사용하는 전 세계 수억 대의 디바이스와 서버가 위험에 노출되었습니다.
• 시사점: SBOM(Software Bill of Materials)을 통해 우리 시스템이 어떤 오픈소스를 사용하고 있는지 파악하는 것이 얼마나 중요한지 깨닫게 된 계기입니다.

3CX 공급망 공격 (2023)

• 개요: VoIP 소프트웨어 3CX의 데스크톱 앱이 트로이 목마에 감염된 상태로 배포되었습니다.
• 특징: 공격자는 3CX 직원의 PC를 먼저 해킹한 후 개발 환경으로 침투(Lateral Movement)하여 바이너리를 변조했습니다.

3. 왜 공급망 보안인가?

현대 소프트웨어 개발 환경은 복잡하게 얽힌 의존성(Dependency) 위에 구축되어 있습니다.

1. 오픈소스 의존성 증가: 현대 애플리케이션 코드의 70~90%는 오픈소스 컴포넌트로 구성됩니다.
2. 파급력: 하나의 공통 컴포넌트가 오염되면 전 세계적인 피해로 확산됩니다.
3. 탐지의 어려움: 개발 및 빌드 단계에서 오염된 코드는 전통적인 보안 검사(방화벽, 백신 등)를 우회하기 쉽습니다.

이에 따라 SK텔레콤은 공급망의 투명성을 확보하고 리스크를 관리하기 위해 SBOM 도입과 철저한 공급망 보안 정책을 수립하여 시행하고 있습니다.

관련 문서

• 글로벌 규제 동향: 미국 EO 14028, EU CRA 등 주요 규제 현황
• SK텔레콤 공급망 보안 정책: SK텔레콤의 구체적인 요구사항
• 공급사 가이드: 공급사를 위한 SBOM 생성 및 제출 안내

1.1 - 규제 동향

1. 미국: 행정명령 14028 (EO 14028)

2021년 5월, 바이든 행정부는 ‘국가의 사이버 보안 개선에 관한 행정명령(Executive Order 14028)‘을 발표했습니다. 이는 SolarWinds 사태 이후 공급망 보안을 국가 안보 차원에서 다루기 시작한 결정적 계기입니다.

핵심 내용

• SBOM 요구 추진: EO 14028은 SBOM의 최소 요소 정의와 안전한 소프트웨어 개발 관행을 지시했고, 연방 납품 기업의 SBOM 제출과 자기증명 의무는 후속 OMB 지침으로 구체화됐습니다.
• NIST 가이드라인 준수: NIST(미국 국립표준기술연구소)가 정의한 ‘보안 소프트웨어 개발 프레임워크(SSDF)‘를 준수해야 합니다.
• 최소 기준 제시: 미 행정부는 SBOM의 최소 요소(데이터 필드, 자동화 지원 등)를 정의하여 표준화를 주도했습니다.

2. 유럽연합(EU): 사이버 복원력 법안 (CRA)

EU는 Cyber Resilience Act (CRA)를 통해 디지털 제품의 전체 생명주기에 걸친 보안 요구사항을 법제화했습니다.

핵심 내용

• CE 마크 인증: 디지털 요소가 포함된 모든 제품은 사이버 보안 요구사항을 충족하고 CE 마크를 부착해야만 EU 내에서 판매할 수 있습니다.
• 보안 지원 기간 명시: 제조사는 제품의 예상 사용 기간 동안 보안 업데이트를 제공해야 하며, 그 기간은 원칙적으로 5년 이상입니다. 예상 사용 기간이 5년보다 짧으면 그 기간에 맞춥니다(Regulation (EU) 2024/2847 제13조, Recital 60). 즉 5년은 상한이 아니라 기준선입니다.
• 취약점 신고 의무: 적극적으로 악용되는(actively exploited) 취약점이나 심각한 보안 사고를 인지하면, 24시간 이내에 조정자로 지정된 CSIRT와 ENISA에 조기경보를 제출하고, 이후 72시간 이내 후속 신고와 최종 보고서를 제출해야 합니다(Regulation (EU) 2024/2847 제14조).
• SBOM 관리: 제조사는 제품의 소프트웨어 구성요소를 식별하고 문서화(SBOM)해야 합니다.

3. 한국: SW 공급망 보안 가이드라인

대한민국 정부(과학기술정보통신부, KISA, 국가정보원)도 글로벌 흐름에 발맞춰 ‘SW 공급망 보안 가이드라인’을 발표하고 실증 사업을 추진하고 있습니다.

주요 내용 (v1.0 기준)

• SBOM 도입 권고: 공공 및 민간 분야에서 SW 개발 및 납품 시 SBOM을 생성하고 활용할 것을 권고합니다.
• 역할별 보안 활동 정의:
  • 공급사(개발사): 안전한 개발 환경 구축, SBOM 생성 및 제공, 보안 취약점 점검.
  • 수요사(운영사): 납품받은 SW의 SBOM 요구 및 검증, 지속적인 취약점 모니터링.

SK텔레콤의 대응

SK텔레콤은 이러한 국내외 규제 흐름에 선제적으로 대응하기 위해 자체적인 공급망 보안 정책을 수립하였으며, 모든 협력사에 대해 글로벌 표준(SPDX, CycloneDX)에 부합하는 SBOM 제출을 의무화하고 있습니다.

관련 문서

• 공급망 보안 개요 : 소프트웨어 공급망 공격의 개념과 주요 사례
• SK텔레콤 공급망 보안 정책: SK텔레콤이 공급사에 요구하는 구체적인 정책
• 공급사 가이드: 공급사를 위한 SBOM 생성 및 제출 안내

1.2 - SK텔레콤 공급망 보안 정책

---

NOTICE.

본 문서는 사내 보안 및 문서 관리 정책에 따라 대외비 내용을 제외한 요약본입니다. 전체 내용이 아닌 개략적인 핵심 사항 위주로 작성되었음을 참고해 주시기 바랍니다.

---

1. 정책 목적

본 정책은 SK텔레콤이 도입하는 모든 소프트웨어의 투명성을 확보하고, 알려진 취약점(Known Vulnerabilities) 및 라이선스 위반 리스크를 사전에 식별하여 제거하는 것을 목적으로 합니다.

2. 적용 대상

SK텔레콤과 소프트웨어 공급 계약을 체결하는 모든 공급사는 본 정책의 적용을 받습니다.

3. 주요 요구사항

공급사는 다음 3가지 원칙을 준수해야 합니다.

원칙 1: SBOM 제출 의무화

• 모든 소프트웨어 납품 시, 해당 버전에 부합하는 SBOM(Software Bill of Materials)을 제출해야 합니다.
• 허용 포맷: CycloneDX (v1.3 이상) 또는 SPDX (v2.2 이상)
• 필수 포함 정보: 공급사명, 컴포넌트명, 버전, 의존성 관계, Package URL (PURL)

원칙 2: 취약점 점검 및 조치

• 공급사는 납품 전 자체적으로 최신 보안 취약점(CVE)을 점검해야 합니다.
• Critical/High 등급의 취약점이 발견된 경우, 이를 패치하거나 완화 조치를 적용한 후 납품해야 합니다.
• 패치가 불가능한 경우, ‘취약점 소명서’를 통해 해당 취약점이 실제 서비스에 영향을 주지 않음을 증명해야 합니다.

원칙 3: 투명한 변경 관리

• 계약 기간 중 소프트웨어의 구성 요소가 변경(업데이트, 패치 등)되는 경우, 갱신된 SBOM을 즉시 제출해야 합니다.
• 오픈소스 라이선스 의무 사항(고지 의무, 소스코드 공개 의무 등)을 준수했음을 보증해야 합니다.

관련 문서

• 공급망 보안 개요 : 소프트웨어 공급망 공격의 개념과 주요 사례
• 글로벌 규제 동향: SBOM 관련 국내외 규제 현황
• 공급사 가이드: SBOM 생성 및 제출 방법 상세 안내
• 제출 요구사항: SBOM 포맷 및 필수 데이터 필드 정의

2 - SBOM 이란?

개요

이 섹션은 기업 구성원을 위한 SBOM(Software Bill of Materials) 실무 가이드입니다. 단순히 정책을 준수하는 것을 넘어, SBOM을 활용하여 프로젝트의 보안성을 높이고 의존성 관리의 효율성을 높이는 방법을 다룹니다.

가이드 구성

본 가이드는 SBOM의 도입부터 운영까지 단계별로 구성되어 있습니다.

1. 개념 및 필요성: SBOM이 무엇이며, 왜 지금 우리에게 필요한지 근본적인 이유를 설명합니다.
2. 표준 비교 (SPDX vs CycloneDX): 업계 표준 포맷의 차이점을 이해하고, 프로젝트 성격에 맞는 포맷을 선택할 수 있습니다.
3. 프로젝트 SBOM 생성: 개발 중인 프로젝트에서 직접 SBOM을 추출하는 실무적인 방법을 안내합니다.
4. CI/CD 통합: Jenkins, GitHub Actions 등 CI/CD 파이프라인에 SBOM 생성을 자동화하는 방법을 다룹니다.
5. SBOM 관리: 생성된 SBOM을 중앙 저장소에 저장하고 버전별로 관리하는 전략을 소개합니다.

graph TD
    A[개발 시작] --> B[의존성 추가]
    B --> C{빌드/배포}
    C -->|자동화| D[SBOM 생성]
    D --> E[저장소 업로드]
    E --> F[취약점 분석]
    F --> G[보안 조치]

SBOM 생성

상세한 SBOM 생성 방법과 기술적 가이드는 다음 문서를 참고하시기 바랍니다.

• 공급사 가이드 (For Suppliers)
• SBOM 생성 방법

2.1 - SBOM 개념 및 필요성

SBOM의 정의

SBOM (Software Bill of Materials)은 소프트웨어를 구성하는 모든 컴포넌트, 라이브러리, 모듈 등의 목록과 그들 간의 의존성 관계를 기술한 정형화된 명세서입니다. 제조업에서 제품의 부품 목록을 관리하는 BOM(Bill of Materials) 개념을 소프트웨어 공학에 적용한 것입니다.

graph TD
    A[소프트웨어 제품] --> B[직접 의존성]
    B --> C[라이브러리 A v1.2.3]
    B --> D[라이브러리 B v2.0.1]
    B --> E[라이브러리 C v3.1.0]
    C --> F[전이적 의존성]
    F --> G[라이브러리 D v1.0.0]
    F --> H[라이브러리 E v2.5.0]
    D --> F

SBOM의 주요 구성 요소

컴포넌트 정보

각 소프트웨어 컴포넌트에 대한 기본 정보를 포함합니다.

• 이름(Name): 컴포넌트의 공식 명칭
• 버전(Version): 정확한 버전 번호
• 공급자(Supplier): 컴포넌트를 제공한 조직 또는 개인
• 라이선스(License): 적용되는 오픈소스 라이선스

고유 식별자

컴포넌트를 명확히 식별하기 위한 표준화된 식별자를 사용합니다.

Package URL (purl)

가장 일반적으로 사용되는 식별자 형식입니다.

pkg:maven/org.springframework/spring-core@5.3.20
pkg:npm/express@4.18.2
pkg:pypi/django@4.1.0

CPE (Common Platform Enumeration)

보안 취약점 데이터베이스와 연동하기 위해 사용됩니다.

cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*

의존성 관계

컴포넌트 간의 의존성 관계를 명시합니다.

• 직접 의존성(Direct Dependencies): 프로젝트가 직접 사용하는 라이브러리
• 전이적 의존성(Transitive Dependencies): 직접 의존성이 다시 의존하는 라이브러리

메타데이터

SBOM 자체에 대한 정보를 포함합니다.

• 생성 도구: SBOM을 생성한 도구의 이름과 버전
• 생성 시각: SBOM이 생성된 날짜와 시간
• 생성자: SBOM을 생성한 조직 또는 개인

왜 필요한가?

SBOM은 단순한 문서가 아니라 소프트웨어 투명성을 위한 핵심 데이터입니다.

1. 보안 취약점의 신속한 식별

새로운 취약점(예: Log4j 사태)이 발표되었을 때, 우리 서비스 중 어디에 해당 라이브러리가 쓰이고 있는지 즉시 파악할 수 있습니다. SBOM이 없다면 모든 서버와 코드를 일일이 전수 조사해야 하며, 대응 골든타임을 놓치게 됩니다.

2. 라이선스 리스크 관리

오픈소스 라이선스 위반은 법적 분쟁으로 이어질 수 있습니다. SBOM을 통해 프로젝트에 포함된 모든 라이선스를 식별하고, 호환되지 않는 라이선스(예: GPL과 상용 코드의 결합) 사용을 사전에 차단할 수 있습니다.

3. 소프트웨어 품질 및 노후화 관리

오래되고 지원이 중단된(EOL, End-of-Life) 컴포넌트를 식별하여 기술 부채를 관리하고 소프트웨어의 건전성을 유지할 수 있습니다.

4. 규제 준수

미국 연방 정부를 비롯한 다양한 조직에서 SBOM 제출을 의무화하고 있습니다.

• 미국 행정명령 14028 (연방 정부 공급사)
• EU Cyber Resilience Act
• 의료기기 FDA 승인

관련 문서

• SBOM 표준 비교 (SPDX vs CycloneDX)
• 공급사 가이드: SBOM 생성 및 제출 방법

참고 자료

• NTIA SBOM Minimum Elements
• CISA SBOM Sharing Lifecycle
• Linux Foundation: SBOM Guide

2.2 - SBOM 표준

주요 SBOM 표준

현재 시장을 양분하고 있는 두 가지 주요 표준 형식이 있습니다. 두 형식 모두 널리 사용되지만, 탄생 배경과 주력 분야에 차이가 있습니다.

• SPDX: Software Package Data Exchange
• CycloneDX: OWASP 주관의 보안 중심 SBOM 표준

SPDX (Software Package Data Exchange)

개요

SPDX는 Linux Foundation이 주관하는 오픈소스 프로젝트로, 소프트웨어 패키지의 라이선스 및 저작권 정보를 표준화된 방식으로 표현하기 위해 개발되었습니다. (ISO/IEC 5962:2021)

주요 특징

1. SPDX는 원래 오픈소스 라이선스 정보 교환을 위해 개발되어, 라이선스 관련 정보를 상세하게 표현합니다.

• 표준화된 라이선스 식별자 (SPDX License List)
• 라이선스 표현식 (예: Apache-2.0 OR MIT)
• 저작권 정보 및 파일별 라이선스

2. 패키지뿐만 아니라 개별 파일 레벨의 정보도 포함할 수 있습니다.

• 파일별 해시값
• 파일별 라이선스
• 파일별 저작권 정보

SPDX 문서 구조

{
  "SPDXID": "SPDXRef-DOCUMENT",
  "spdxVersion": "SPDX-2.3",
  "name": "Example-SBOM",
  "documentNamespace": "https://example.com/sbom-2023-001",
  "creationInfo": {
    "created": "2023-01-15T10:30:00Z",
    "creators": ["Tool: SPDX-Tools-2.3"]
  },
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-1",
      "name": "spring-core",
      "versionInfo": "5.3.20",
      "licenseDeclared": "Apache-2.0",
      "externalRefs": [
        {
          "referenceType": "purl",
          "referenceLocator": "pkg:maven/org.springframework/spring-core@5.3.20"
        }
      ]
    }
  ]
}

장점

• ISO 국제 표준으로 공식 인정
• 라이선스 정보가 상세함
• 파일 레벨까지 추적 가능
• 성숙한 도구 생태계

단점

• 보안 취약점 정보가 선택사항
• 구조가 다소 복잡
• 보안 중심 프로젝트에는 부족할 수 있음

CycloneDX

개요

CycloneDX는 OWASP(Open Web Application Security Project)에서 개발한 SBOM 표준으로, 애플리케이션 보안에 중점을 둡니다.

주요 특징

1. 처음부터 보안 취약점 관리를 위해 설계되었습니다.

• 취약점 정보 (Vulnerabilities)
• 보안 분석 결과 (Security Analysis)
• 위협 정보 (Threats)

2. SPDX에 비해 구조가 간결하고 이해하기 쉽습니다.

• 필수 정보에 집중
• JSON, XML 형식 지원
• 작은 파일 크기

3. 다양한 사용 사례를 지원하는 확장 기능을 제공합니다.

• SaaS BOM
• Hardware BOM
• AI/ML BOM
• Cryptography BOM

CycloneDX 문서 구조

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2023-01-15T10:30:00Z",
    "tools": [
      {
        "name": "cyclonedx-maven-plugin",
        "version": "2.7.9"
      }
    ],
    "component": {
      "type": "application",
      "name": "MyApp",
      "version": "1.0.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "spring-core",
      "version": "5.3.20",
      "purl": "pkg:maven/org.springframework/spring-core@5.3.20",
      "licenses": [
        {
          "license": {
            "id": "Apache-2.0"
          }
        }
      ]
    }
  ]
}

장점

• 보안 취약점 정보 기본 포함
• 구조가 간결하고 이해하기 쉬움
• 보안 도구와의 통합이 우수
• 활발한 커뮤니티 및 도구 개발

단점

• ISO 표준은 아니지만 ECMA International의 ECMA-424로 표준화됨
• 파일 레벨 정보는 제한적
• 라이선스 표현이 SPDX보다 단순

SPDX vs CycloneDX 비교

선택 가이드

CycloneDX 선택이 적합한 경우

다음과 같은 경우 CycloneDX를 권장합니다.

• 보안이 최우선: 취약점 관리가 주요 목적
• 빠른 시작: 간결한 구조로 빠르게 도입
• DevSecOps: CI/CD에 통합하여 자동화
• 현대적인 애플리케이션: 클라우드, 컨테이너 환경

SPDX 선택이 적합한 경우

다음과 같은 경우 SPDX를 권장합니다.

• 라이선스 컴플라이언스 중시: 상세한 라이선스 정보 필요
• 파일 레벨 추적: 소스코드 파일별 정보 필요
• ISO 표준 준수: 공식 표준 인증 필요
• 레거시 시스템: 기존 SPDX 도구 사용 중

SK텔레콤 권장사항

SK텔레콤의 내부 프로젝트는 CycloneDX (JSON) 형식을 기본 권장합니다. 이는 내부 취약점 관리 시스템과의 연동성이 CycloneDX가 더 우수하기 때문입니다. 단, 외부 파트너사가 SPDX를 제출하는 경우에도 호환성을 지원합니다.

상호 변환

SPDX와 CycloneDX 간 변환 도구가 제공됩니다.

SPDX에서 CycloneDX로 변환

# cyclonedx-cli 사용
cyclonedx convert --input-file sbom.spdx.json \
  --output-file sbom.cdx.json --input-format spdx \
  --output-format json

CycloneDX에서 SPDX로 변환

# spdx-tools 사용
java -jar tools-java-1.1.0-jar-with-dependencies.jar \
  Convert bom.cdx.json bom.spdx.json

관련 문서

• SBOM이란?: SBOM의 개념과 필요성
• 공급사 제출 요구사항: SK텔레콤이 허용하는 포맷 및 버전

참고 자료

• SPDX Specification
• CycloneDX Specification
• NTIA SBOM Formats Comparison

3 - 공급사 SBOM 제출 가이드

SK텔레콤은 소프트웨어 공급망의 투명성과 보안성을 강화하기 위해, 공급사로부터 납품받는 모든 소프트웨어 구성 요소 및 의존성에 대한 SBOM(Software Bill of Materials) 제출을 요청드리고 있습니다. 본 가이드는 공급사가 SK텔레콤의 보안 정책에 맞는 형식으로 SBOM을 생성하고 제출하는 방법을 안내합니다.

적용 대상

다음 형태의 소프트웨어를 납품하는 모든 공급사(개발사, 리셀러 포함)는 본 가이드라인의 적용을 받습니다.

• 소스코드: Java, Python, JavaScript, Go, C/C++ 등으로 작성된 애플리케이션
• 컨테이너 이미지: Docker 이미지 또는 OCI 호환 컨테이너
• 실행 파일: 컴파일된 바이너리(.jar, .dll, .so) 및 라이브러리
• 임베디드 시스템: 펌웨어 이미지, RootFS, 디바이스 드라이버
• 서버: OS(rootfs와 설치 패키지) 위에 애플리케이션과 정적 링크 라이브러리가 결합된 시스템

SBOM 제출 프로세스

공급사는 계약 시점부터 최종 납품까지 아래의 절차에 따라 진행하시기 바랍니다.

flowchart TD
    A[계약 검토] --> B["소프트웨어 개발/빌드"]
    B --> C{SBOM 생성}
    C -->|SKT 제공 도구 활용| D[BomLens 활용]
    C -->|자체 도구 활용| E["오픈소스 도구 활용<br>(cdxgen, Syft 등)"]
    D --> F["데이터 검증 (PURL 확인)"]
    E --> F
    F --> G["SBOM 제출 (이메일/포털)"]
    G --> H[SKT 보안성 검토]
    H -->|승인| I[납품 완료]
    H -->|반려| J[보완 및 재제출]
    J --> F

가이드 구성

본 섹션은 다음과 같이 구성되어 있습니다.

1. 제출 요구사항: SK텔레콤이 요구하는 필수 포맷(CycloneDX, SPDX)과 데이터 필드를 정의합니다.
2. BomLens: SK텔레콤이 제공하는 SBOM 생성 도구 사용법을 안내합니다.
3. 오픈소스 도구 활용: 범용 오픈소스 도구(cdxgen, Syft 등)를 활용한 생성 방법을 안내합니다.
4. 서버 SBOM 생성: OS·애플리케이션·정적 링크 세 층으로 나눠 생성하고 하나로 합치는 방법을 안내합니다.
5. 검증 체크리스트: 제출 전 반드시 확인해야 할 필수 항목 점검표를 제공합니다.
6. 제출 절차: 생성된 SBOM 파일의 명명 규칙과 제출 채널을 안내합니다.

관련 문서

• SK텔레콤 공급망 보안 정책: SBOM 제출 의무화 정책 배경 및 원칙
• 글로벌 규제 동향: SBOM 관련 국내외 규제 현황

3.1 - SBOM 제출 요구사항

1. 표준 데이터 형식

SK텔레콤은 글로벌 표준으로 자리 잡은 두 가지 형식을 모두 지원합니다. 공급사는 사용하는 도구가 지원하는 형식을 선택하여 제출할 수 있습니다.

참고: 두 형식 모두 동등하게 인정되나, 내부 시스템 연동성을 위해 CycloneDX (JSON) 형식을 권장합니다.

2. 필수 포함 정보

제출하는 SBOM 문서에는 다음 정보가 반드시 포함되어야 합니다. 정보가 누락되면 반려될 수 있습니다.

2.1 메타데이터 (Metadata)

문서 자체와 생성 도구에 대한 정보입니다.

• Timestamp: 생성 일시 (ISO 8601 형식)
• Tool Info: 생성 도구의 벤더, 이름, 버전 (예: CycloneDX-Maven-Plugin v2.7.9)
• Component Info: 납품하는 최상위 소프트웨어의 명칭 및 버전

생성 도구 명시 형식

생성 도구 정보는 형식에 따라 다음 필드에 기재해야 합니다.

• SPDX: creationInfo.creators 필드에 Tool: 접두어로 도구명과 버전 기재
• CycloneDX: metadata.tools 배열에 vendor, name, version 기재

// SPDX creationInfo 예시
"creationInfo": {
  "created": "2026-04-06T03:22:00Z",
  "creators": ["Tool: Syft-0.98.0", "Organization: VendorName"]
}

2.2 컴포넌트 정보 (Components)

소프트웨어를 구성하는 개별 라이브러리 정보입니다.

• Name: 컴포넌트 이름 (예: commons-lang3)
• Version: 컴포넌트 버전 (예: 3.12.0) — 필수: 버전 없이는 취약점 매핑 불가
• PURL (Package URL): [필수] 패키지 식별자

버전 정보는 반드시 포함해야 합니다. 각 패키지(package/component)는 SPDX의 versionInfo 또는 CycloneDX의 version 필드에 정확한 버전을 기재해야 합니다. 버전이 없으면 취약점 데이터베이스와의 매핑이 불가능하여 보안 분석을 수행할 수 없습니다.

2.3 의존성 범위 (Dependency Scope)

중요: 전이적 의존성(Transitive Dependencies)을 반드시 포함해야 합니다.

SK텔레콤은 제출된 SBOM을 기반으로 취약점을 분석합니다. 직접 의존성만 포함된 SBOM은 숨겨진 취약점을 놓칠 수 있으므로 반려될 수 있습니다.

전이적 의존성이란?

예를 들어 프로젝트가 library-A를 직접 사용하고, library-A가 내부적으로 library-B를 사용하는 경우, library-B가 전이적 의존성입니다. library-B에 취약점이 있어도 SBOM에 포함되지 않으면 탐지할 수 없습니다.

MyApp
  └─ library-A v1.0 (직접 의존성)  ← 공급사가 명시적으로 선언
       └─ library-B v2.3 (전이적 의존성)  ← SBOM에 반드시 포함되어야 함
            └─ library-C v0.9 (전이적 의존성)  ← SBOM에 반드시 포함되어야 함

올바른 SBOM 생성을 위한 전제 조건

전이적 의존성이 정확하게 포함되려면 빌드(또는 패키지 설치)가 완료된 상태에서 SBOM을 생성해야 합니다. 소스코드만 있는 상태에서는 전이적 의존성이 누락될 수 있습니다.

• Java (Maven): mvn package 또는 mvn dependency:resolve 실행 후 생성
• Java (Gradle): ./gradlew dependencies 실행 후 생성
• Python: pip install -r requirements.txt (가상환경 활성화) 후 생성
• Node.js: npm install 또는 yarn install 실행 후 생성
• Go: go mod download 실행 후 생성

각 도구별 전이적 의존성 포함 방법은 오픈소스 도구 활용 가이드를 참고하시기 바랍니다.

3. Package URL (PURL) 준수

PURL(Package URL)은 소프트웨어 패키지를 고유하게 식별하기 위한 표준 URL 형식입니다. SK텔레콤의 취약점 분석 시스템은 PURL을 기준으로 동작하므로, 모든 컴포넌트에 유효한 PURL이 포함되어야 합니다.

PURL은 반드시 pkg: 접두어로 시작하는 표준 형식이어야 합니다. name:version, org/repo:tag 등 자유 텍스트는 허용되지 않으며, 이 경우 취약점 매핑이 불가능해 반려됩니다.

언어별 PURL 예시

purl 타입 제한

purl은 생태계를 특정할 수 있는 타입이어야 합니다.

올바른 / 잘못된 PURL 예시

PURL에 대한 자세한 사양은 Package URL 공식 스펙을 참고하시기 바랍니다.

4. 샘플 문서

CycloneDX 샘플

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "metadata": {
    "timestamp": "2023-10-15T10:30:00Z",
    "tools": [{
      "vendor": "Example Corp",
      "name": "cyclonedx-maven-plugin",
      "version": "2.7.9"
    }],
    "component": {
      "type": "application",
      "name": "PaymentModule",
      "version": "2.1.0",
      "purl": "pkg:maven/com.example/payment-module@2.1.0"
    }
  },
  "components": [{
    "type": "library",
    "name": "spring-core",
    "version": "5.3.20",
    "purl": "pkg:maven/org.springframework/spring-core@5.3.20",
    "licenses": [{
      "license": {
        "id": "Apache-2.0"
      }
    }]
  }]
}
...

참고 자료

• CycloneDX Specification
• SPDX Specification
• Package URL Specification

관련 문서

• 공급사 가이드 홈
• BomLens: SK텔레콤이 제공하는 SBOM 생성 도구
• 오픈소스 도구 활용: cdxgen, Syft 등 오픈소스 도구 안내
• 검증 체크리스트: 제출 전 확인 사항
• 제출 절차: 제출 방법 및 이메일 양식

3.2 - BomLens

BomLens

BomLens는 공급사가 Docker 환경에서 SK텔레콤 정책에 맞는 산출물을 생성할 수 있는 오픈소스 도구입니다. 로컬에 언어별 도구를 따로 설치하지 않아도 여러 언어를 분석해 CycloneDX(JSON) 산출물을 만듭니다.

이 페이지는 빠른 시작만 다룹니다. 설치, 전체 옵션, 언어별 가이드, 입력 시나리오, 웹 UI 등 자세한 내용은 공식 저장소 문서를 참고하세요.

github.com/sktelecom/sbom-tools

버그 제보, 기능 제안, Pull Request 기여를 환영합니다.

생성되는 산출물

한 번의 실행으로 다음 세 가지가 함께 생성됩니다(--all 옵션).

사전 준비

BomLens는 Docker 위에서 동작합니다. Docker 엔진 20.10 이상을 설치하고 실행해 두세요. Docker가 없는 Windows에서는 무료인 Rancher Desktop을 권장합니다. 첫 실행 때 스캐너 이미지(약 3–4GB)를 내려받느라 5–15분쯤 걸립니다.

Windows에서 명령줄 없이 시작

명령줄이 익숙하지 않다면 두 가지 방법 중 하나로 SBOM을 생성할 수 있습니다. 자세한 절차는 명령줄 없이 시작하기를 참고하세요.

• 실행 파일: 최신 릴리스에서 SBOM-Generator-*.exe(BomLens 실행 파일)를 내려받아 더블클릭합니다. 이 파일은 아직 코드 서명이 되어 있지 않아 Windows SmartScreen 경고가 나타나면 “추가 정보"를 누른 뒤 “실행"을 선택합니다.
• 저장소 ZIP: 저장소의 Code 버튼에서 Download ZIP을 받아 압축을 풀고 scripts\sbom-ui.bat를 더블클릭하면 브라우저에서 http://localhost:8080이 열립니다.

웹 UI에서는 오른쪽에 진행 로그가 실시간으로 표시되고, 완료되면 산출물을 내려받을 수 있습니다.

빠른 시작 (CLI)

macOS와 Linux에서는 셸에서 스크립트를 내려받아 실행합니다.

curl -O https://raw.githubusercontent.com/sktelecom/sbom-tools/main/scripts/scan-sbom.sh
chmod +x scan-sbom.sh
cd /path/to/my-project
/path/to/scan-sbom.sh --project "MyApp" --version "1.0.0" --all --generate-only

• --generate-only는 포털 업로드 없이 로컬에 파일만 생성합니다(제출 전까지 권장).
• 웹 UI로 쓰려면 ./scan-sbom.sh --ui를 실행합니다(브라우저에서 http://localhost:8080).
• Windows에서 명령줄을 쓸 때는 같은 명령을 scripts\scan-sbom.bat로 실행합니다(Git Bash를 거치므로 Git for Windows 필요).
• GitHub URL, 소스 ZIP, Docker 이미지, 펌웨어, 바이너리 등 다른 입력 형태와 전체 옵션은 CLI 레퍼런스를 참고하세요.

더 알아보기

도구 사용법의 정본은 저장소 문서입니다.

다음 단계

SBOM을 생성한 뒤 검증 체크리스트로 파일을 확인하고 제출 절차에 따라 제출합니다. 필수 데이터 필드는 제출 요구사항, SKT 도구 대신 cdxgen, Syft 등을 직접 쓰는 방법은 오픈소스 도구 활용을 참고하세요.

3.3 - 오픈소스 도구를 활용한 SBOM 생성

SKT 제공 도구를 사용할 수 없거나, 이미 자체적인 빌드 파이프라인을 보유한 경우 오픈소스 도구를 직접 활용할 수 있습니다. 아래는 SK텔레콤이 검증한 주요 오픈소스 도구 목록과 공식 사용법 링크입니다.

도구 환경 구축에 익숙하지 않은 경우, Docker가 설치되어 있다면 BomLens를 먼저 검토해 보시기 바랍니다.

도구 선택 가이드

graph TD
    A[분석 대상 확인] --> S{OS와 앱이 결합된 서버인가?}
    S -- Yes --> T[층별로 나눠 생성<br>서버 SBOM 생성 가이드 참고]
    S -- No --> B{소스코드인가?}
    B -- Yes --> C[cdxgen 권장]
    B -- No --> D{Docker 이미지인가?}
    D -- Yes --> E[Syft 또는 Trivy 권장]
    D -- No --> F[바이너리/펌웨어]
    F --> G[Syft 권장]

서버처럼 OS와 애플리케이션이 결합된 경우는 한 번의 스캔으로 끝나지 않습니다. 층별로 나눠 생성하는 전체 절차는 서버 SBOM 생성을 참고하세요.

주요 도구 안내

cdxgen (소스코드 분석 권장)

Java, Python, Node.js, Go 등 다양한 언어 프로젝트를 자동 분석하여 CycloneDX 형식의 SBOM을 생성합니다.

• 공식 문서: https://cdxgen.github.io/cdxgen
• GitHub: https://github.com/CycloneDX/cdxgen
• 지원 언어: Java (Maven/Gradle), Python, Node.js, Go, Ruby, PHP, Rust, .NET, C/C++ 등

cdxgen은 lockfile이나 매니페스트를 정적으로 해석합니다. 정확한 결과를 얻으려면 의존성이 설치되거나 해결된 상태(lockfile이 있거나 빌드한 뒤)에서 실행하시기 바랍니다. 의존성이 해결되지 않은 순수 소스만 스캔하면 일부 컴포넌트나 purl이 누락될 수 있습니다.

Syft (컨테이너 이미지 및 바이너리 분석 권장)

빌드된 컨테이너 이미지나 패키지 매니저 메타데이터가 포함된 빌드 산출물을 분석하여 OS 패키지와 애플리케이션 라이브러리를 모두 식별합니다. CycloneDX 및 SPDX 형식을 지원합니다.

• 공식 문서: https://github.com/anchore/syft
• 권장 분석 대상: 빌드된 Docker 이미지, OCI 이미지, tar 파일

# 권장: 빌드된 이미지 스캔 (purl과 생태계를 자동 식별)
syft <이미지명>:<태그> -o cyclonedx-json=sbom.json

# 비권장: 설치 디렉터리나 원시 파일 스캔 (purl 누락으로 반려)
syft dir:/root/nag_pkg   # 패키지 매니저 메타데이터가 없으면 purl이 0개가 됩니다

CentOS 등 OS 위에 애플리케이션을 올려 납품하는 서버는 OS(rootfs/이미지)와 애플리케이션 두 층으로 나눠 생성하고, 정적 링크 라이브러리는 별도로 보강한 뒤 하나로 합칩니다. OS 층은 위 경고대로 패키지 데이터베이스가 있는 rootfs나 이미지를 대상으로 해야 합니다. 전체 절차는 서버 SBOM 생성을 참고하세요.

Trivy (컨테이너 이미지 분석)

컨테이너 이미지 분석과 취약점 스캔을 함께 수행할 수 있는 올인원 도구입니다.

• 공식 문서: https://aquasecurity.github.io/trivy/
• GitHub: https://github.com/aquasecurity/trivy

언어별 전용 플러그인

빌드 도구 플러그인을 사용하면 더 정확한 의존성 정보를 추출할 수 있습니다.

전이적 의존성 포함 확인

SK텔레콤 제출 SBOM은 전이적 의존성(Transitive Dependencies)을 반드시 포함해야 합니다.

전이적 의존성이란 프로젝트가 직접 선언하지 않았지만, 사용하는 라이브러리가 내부적으로 의존하는 라이브러리를 말합니다. 이 항목이 누락되면 숨겨진 취약점을 탐지할 수 없어 SBOM이 반려될 수 있습니다.

핵심 원칙: 빌드(패키지 설치) 완료 후 SBOM을 생성해야 합니다.

소스코드만 있는 상태에서는 전이적 의존성이 누락될 수 있습니다. 아래 표를 참고하여 SBOM 생성 전에 선행 작업을 완료하시기 바랍니다.

도구별 전이적 의존성 지원 현황

권장: Docker 이미지로 납품하는 경우, 빌드된 이미지를 Syft로 스캔하면 소스코드 분석보다 더 완전한 전이적 의존성을 포함할 수 있습니다.

공통 주의사항

도구를 사용하기 전 아래 사항을 확인하시기 바랍니다.

• 전이적 의존성 포함 여부: 위 표를 참고하여 SBOM 생성 전 선행 작업을 완료합니다. 의존성 누락은 반려 사유가 됩니다.
• PURL 포함 여부: 생성된 SBOM에 모든 컴포넌트의 purl 필드가 포함되어 있는지 확인합니다. SK텔레콤 시스템은 PURL을 기반으로 취약점을 매핑합니다. 제출 전 jq '[.components[] | select(.purl)] | length' sbom.json으로 purl 보유 컴포넌트 수를 세어 전체 컴포넌트 수와 일치하는지 확인하고, 0이거나 현저히 적으면 검증 체크리스트의 절차에 따라 재생성하시기 바랍니다.
• 출력 포맷: CycloneDX JSON 형식을 권장합니다. (-o cyclonedx-json 또는 동등한 옵션 사용)
• 프로젝트 정보: 메타데이터에 납품 프로젝트의 이름과 버전이 정확히 기입되었는지 확인합니다.

관련 문서

• 서버 SBOM 생성: OS·애플리케이션·정적 링크가 결합된 서버를 층별로 생성하고 합치는 방법
• 제출 요구사항: SBOM에 포함되어야 할 필수 데이터 필드
• 검증 체크리스트: 제출 전 확인 사항
• BomLens: SK텔레콤이 제공하는 SBOM 생성 도구

3.4 - 서버(OS + 애플리케이션) SBOM 생성

납품 서버는 단일 소스 트리가 아닙니다. 운영체제가 있고, 그 위에 설치된 애플리케이션이 있으며, 빌드 과정에서 바이너리에 정적 링크된 라이브러리가 있습니다. 이 중 하나만 스캔하면 나머지가 빠지고, 이것이 서버 SBOM이 반려되는 흔한 원인입니다.

서버는 두 층(OS와 애플리케이션)으로 보고 각 층을 따로 생성한 뒤 하나로 합칩니다. 두 층 모두 BomLens로 만들 수 있고, 층마다 입력만 바꾸면 됩니다. 여기에 더해, 정적 링크된 라이브러리는 두 층의 스캔이 모두 놓치는 사각지대라 별도로 다룹니다.

서버를 이루는 두 층

여기에 더해, 정적 링크된 라이브러리(빌드 시 바이너리에 포함된 openssl·liblfds 등)는 패키지 매니저가 선언하지 않고 OS 패키지 데이터베이스에도 올라 있지 않아 두 층의 스캔이 모두 놓치는 사각지대입니다. 별도로 탐지·기재해야 하며, 이를 빠뜨리는 것이 가장 흔한 반려 원인입니다.

층별 생성

아래 명령은 BomLens의 실행 스크립트 scan-sbom.sh를 사용합니다. BomLens 설치와 기본 사용법(스크립트 내려받기, 옵션, 웹 UI 등)은 BomLens를 먼저 참고하세요. cdxgen·Syft를 직접 쓰려면 오픈소스 도구 활용을 참고합니다.

OS 층

서버의 rootfs(추출한 루트 파일시스템)나 그 컨테이너 이미지를 스캔합니다. 패키지 데이터베이스(rpm/dpkg/apk)를 읽어 설치된 패키지를 모두 실제 purl(pkg:rpm/...)로 식별합니다.

# rootfs 디렉터리를 대상으로
scan-sbom.sh --project myserver-os --version 7 --target /path/to/server-rootfs --all --generate-only

# 서버가 컨테이너 이미지로 패키징돼 있다면
scan-sbom.sh --project myserver-os --version 7 --target myserver:7 --all --generate-only

대상에는 패키지 데이터베이스가 있어야 합니다. 설치 파일만 풀어 놓고 rpm 데이터베이스가 없는 폴더를 스캔하면 purl이 비어 반려됩니다.

애플리케이션 층

빌드를 마친 뒤 애플리케이션 소스를 스캔합니다. 패키지 매니저(Maven·npm·pip·Go modules·Conan 등)를 쓰면 전이 의존성까지 자동으로 해석됩니다.

cd /path/to/app-source
scan-sbom.sh --project myserver-app --version 2.0.0 --all --generate-only

매니페스트가 없는 순수 CMake/Make 애플리케이션은 컴포넌트 목록이 희소해지므로 --deep-license로 자체 소스의 라이선스를 보강합니다.

정적 링크 라이브러리 (사각지대)

소스 스캐너는 바이너리에 정적 링크된 라이브러리를 보지 못하고, OS 패키지 데이터베이스에도 올라 있지 않습니다. 이것이 두 층이 남기는 사각지대입니다. 완전 자동 경로가 없으므로 두 가지를 함께 씁니다. 도구가 찾을 수 있는 만큼은 납품 바이너리를 분석하고, 그래도 빠지는 부분은 빌드 스크립트에서 소스와 버전(예: openssl 1.1.1za)을 직접 기재합니다.

scan-sbom.sh --project myserver-bin --version 2.0.0 --target /path/to/delivered-binary --all --generate-only

정적 링크 구성요소의 정밀 식별은 바이너리 구성 분석(BDBA)의 몫이며, SK텔레콤이 보완 검증으로 수행합니다.

하나로 합쳐 제출

SK텔레콤 제출 시스템은 제품당 SBOM 하나를 등록합니다. 따라서 층별 SBOM을 --merge로 합쳐 단일 BOM으로 제출하고, 최상위 컴포넌트를 납품 제품명·버전으로 기재합니다. --merge는 purl 기준으로 중복을 제거하므로 둘 이상의 층에 나타나는 라이브러리는 한 번만 집계됩니다.

scan-sbom.sh --project myserver --version 1.0.0 \
  --merge myserver-os_7_bom.json myserver-app_2.0.0_bom.json myserver-bin_2.0.0_bom.json \
  --generate-only

서버 전체를 하나의 컨테이너 이미지로 납품한다면, 그 이미지를 --target으로 한 번에 스캔해 OS와 애플리케이션 층을 동시에 담을 수도 있습니다.

제출 전 검증

층별 SBOM과 병합본 모두에 대해 컴포넌트가 실제 purl을 갖는지 확인합니다. 전체 컴포넌트 수와 purl 보유 수가 비슷해야 합니다.

jq '.components | length' myserver_1.0.0_bom.json
jq '[.components[] | select(.purl)] | length' myserver_1.0.0_bom.json

차이가 크면 purl 없는 컴포넌트가 많다는 뜻이고, 보통 원시 디렉터리 스캔이 원인입니다. 자세한 점검은 검증 체크리스트를 따르십시오.

더 알아보기

서버 납품 SBOM의 상세 절차와 예시는 BomLens 저장소의 정본 문서에 있습니다.

서버 납품 가이드

관련 문서

• BomLens: SK텔레콤이 제공하는 SBOM 생성 도구
• 오픈소스 도구 활용: cdxgen·Syft 직접 사용
• 제출 요구사항: 필수 데이터 필드
• 검증 체크리스트: 제출 전 확인 사항

3.5 - SBOM 제출 전 검증 체크리스트

필수 점검 항목

아래 체크리스트를 통과하지 못한 SBOM은 시스템에서 자동으로 반려될 수 있습니다.

1. 파일 무결성

• 파일 확장자가 .json 또는 .xml 인가? (압축 파일 아님)
• 파일 크기가 1KB 이상이며, 내용이 비어있지 않은가?
• JSON 문법 오류가 없는가? (jq 등으로 확인 권장)

2. 필수 데이터 필드

• bomFormat: CycloneDX 또는 SPDX가 명시되었는가?
• Metadata: 최상위 컴포넌트(납품 프로젝트)의 이름과 버전이 정확한가?
• Components: 포함된 라이브러리 목록이 실제와 일치하는가?

3. 의존성 완전성 확인

전이적 의존성 누락은 가장 흔한 반려 사유입니다. 아래 항목을 반드시 확인하시기 바랍니다.

• 직접 의존성(프로젝트가 직접 선언한 라이브러리)이 모두 포함되어 있는가?
• 전이적 의존성(직접 의존성이 내부적으로 사용하는 라이브러리)이 포함되어 있는가?
• SBOM 생성 전 빌드(또는 패키지 설치)를 완료하였는가? (예: npm install, mvn package, pip install)
• 컴포넌트 수가 합리적인가? (직접 의존성만 몇 개인 프로젝트에서 총 컴포넌트 수가 10개 미만이라면 전이적 의존성이 누락되었을 가능성이 높음)

의존성 수 기준 가이드: 일반적인 웹 애플리케이션은 전이적 의존성까지 포함하면 수십~수백 개의 컴포넌트가 포함됩니다. SBOM의 컴포넌트 수가 예상보다 현저히 적다면 누락을 의심해 보시기 바랍니다.

4. 식별자 (PURL) 확인

SK텔레콤 시스템은 PURL로 취약점을 매핑합니다. 가장 중요한 항목입니다.

• 모든 컴포넌트(components) 객체 안에 purl 필드가 존재하는가?
• purl 보유 컴포넌트 수가 전체 컴포넌트 수와 일치(또는 근접)하는가?
• PURL 형식이 표준(pkg:type/namespace/name@version)을 따르는가?
• PURL 내에 특수문자 등이 올바르게 인코딩되었는가?

아래 명령으로 purl 개수를 직접 확인하시기 바랍니다. 전체 컴포넌트 수와 purl 보유 수가 같아야 합니다.

# CycloneDX — 두 값이 같아야 한다
jq '.components | length' sbom.json                      # 전체 컴포넌트 수
jq '[.components[] | select(.purl)] | length' sbom.json  # purl 보유 수

# SPDX — purl(externalRef) 보유 패키지 수
jq '[.packages[] | select(.externalRefs[]?.referenceType == "purl")] | length' sbom.json

purl 보유 수가 0이거나 전체 컴포넌트 수보다 현저히 적으면 제출하지 마십시오. 이는 패키지 매니저 메타데이터가 없는 설치 디렉터리나 원시 파일을 스캔했을 때 주로 발생합니다. 스캔 대상을 빌드된 이미지나 패키지 매니저 컨텍스트가 있는 위치로 바꾸거나 도구를 바꿔 재생성하시기 바랍니다. 자세한 내용은 SBOM 생성 방법을 참고하십시오.

온라인 검증 도구

• CycloneDX Validator: https://cyclonedx.github.io/cyclonedx-web-tool/validate

관련 문서

• 제출 요구사항: 필수 데이터 필드 및 PURL 형식 상세 안내
• 제출 절차: 체크리스트 통과 후 제출 방법
• BomLens: 체크리스트 항목을 충족하는 SBOM을 생성하는 도구

3.6 - SBOM 제출 절차

1. 제출 시기

• 소프트웨어 계약 체결 후 초기 납품 시
• 소프트웨어의 주요 버전(Major/Minor) 업데이트 시
• 계약서에 명시된 정기 제출 일정 도래 시

2. 제출 방법

SBOM 파일은 SK텔레콤 사업부서 및 보안부서 담당자에게 이메일 혹은 지정된 시스템을 통해 제출합니다.

제출 방법

• 사업부서 및 보안부서 담당자에게 이메일 또는 담당자가 지정한 채널로 SBOM 파일을 전달합니다.
• 이메일 제목: [SBOM 제출] 공급사명_프로젝트명_버전
• 첨부파일: 생성된 SBOM 파일 (비밀번호 걸린 압축 파일 금지)

본문 필수 기재 사항:

1. 납품 계약 번호
2. 담당자 정보 (성명, 부서, 연락처)
3. 프로젝트 정보 (시스템명, 상세 버전)
4. 사용 도구 (예: BomLens v1.0)

사업부서 담당자의 TOSCA 등록 의무

공급사로부터 SBOM을 접수한 SK텔레콤 사업부서 담당자는 사내 오픈소스 & SBOM 관리 시스템인 TOSCA에 해당 SBOM을 등록해야 합니다.

TOSCA (SK텔레콤 오픈소스 & SBOM 관리 시스템) https://tosca.sktelecom.com

• TOSCA는 SK텔레콤 내부 시스템으로, 사내 임직원만 접근 가능합니다.
• [SKT 구성원용] 공급사 SBOM 등록 및 리포트 출력 가이드: https://confluence.tde.sktelecom.com/x/bYNULw

3. 제출 후 검증 및 조치

제출된 SBOM은 TOSCA에 등록된 후 아래 절차에 따라 검증됩니다.

검증 결과와 조치 요청 사항은 사업부서 담당자를 통해 공급사 및 보안부서 담당자에게 통보됩니다.

관련 문서

• 검증 체크리스트: 제출 전 반드시 확인할 필수 항목
• 제출 요구사항: SBOM 포맷 및 필수 데이터 필드
• 공급사 가이드 홈: 전체 프로세스 흐름도 확인