공급망 보안

• 1: 개요
• 1.1: 규제 동향
• 1.2: SK텔레콤 공급망 보안 정책
• 2: SBOM 관리
• 2.1: SBOM이란?
• 2.2: SBOM 표준
• 3: 취약점 관리
• 3.1: 취약점 관리 프로세스
• 3.2: 지속적 모니터링
• 3.3: 취약점 대응
• 4: 공급사 가이드
• 4.1: SBOM 제출 요구사항
• 4.2: SBOM 생성 방법
• 4.2.1: 빠른 시작
• 4.2.2: 언어별 가이드
• 4.2.3: Docker 이미지
• 4.3: 검증 체크리스트
• 4.4: SK텔레콤 제공 도구
• 4.4.1: 언어별 세부 사용 가이드
• 4.5: 제출 절차

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 도입과 철저한 공급망 보안 정책을 수립하여 시행하고 있습니다.

1.1 - 규제 동향

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

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

핵심 내용

• SBOM 제출 의무화: 연방 정부에 소프트웨어를 납품하는 기업은 반드시 SBOM을 제출해야 합니다.
• NIST 가이드라인 준수: NIST(미국 국립표준기술연구소)가 정의한 ‘보안 소프트웨어 개발 프레임워크(SSDF)‘를 준수해야 합니다.
• 최소 기준 제시: 미 행정부는 SBOM의 최소 요소(데이터 필드, 자동화 지원 등)를 정의하여 표준화를 주도했습니다.

“연방 정부의 구매력을 활용하여 소프트웨어 시장 전체의 보안 수준을 상향 평준화하겠다.”

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

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

핵심 내용

• CE 마크 인증: 디지털 요소가 포함된 모든 제품은 사이버 보안 요구사항을 충족하고 CE 마크를 부착해야만 EU 내에서 판매할 수 있습니다.
• 보안 지원 기간 명시: 제조사는 제품 예상 사용 기간(최대 5년) 동안 보안 업데이트를 제공해야 합니다.
• 취약점 신고 의무: 치명적인 취약점 발견 시 24시간 이내에 ENISA(유럽 네트워크 정보보호원)에 보고해야 합니다.
• SBOM 관리: 제조사는 제품의 소프트웨어 구성요소를 식별하고 문서화(SBOM)해야 합니다.

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

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

주요 내용 (v1.0 기준)

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

SK텔레콤의 대응

SK텔레콤은 이러한 국내외 규제 흐름에 선제적으로 대응하기 위해 자체적인 공급망 보안 정책을 수립하였으며, 모든 협력사에 대해 글로벌 표준(SPDX, CycloneDX)에 부합하는 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 생성 방법과 기술적 가이드는 다음 문서를 참고하시기 바랍니다.

• 공급사 가이드 (For Suppliers)
• 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 생성

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

• 공급사 가이드 (For Suppliers)
• 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 표준은 아님 (사실상 표준)
• 파일 레벨 정보는 제한적
• 라이선스 표현이 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 생성 방법과 기술적 가이드는 다음 문서를 참고하시기 바랍니다.

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

참고 자료

• SPDX Specification
• CycloneDX Specification
• NTIA SBOM Formats Comparison

3 - 취약점 관리

개요

SBOM 생성은 끝이 아니라 시작입니다. 생성된 SBOM 데이터를 활용하여 우리 소프트웨어에 숨어있는 알려진 취약점(Known Vulnerabilities)을 찾아내고, 신속하게 조치하는 것이 공급망 보안의 핵심 목표입니다.

본 가이드는 SK텔레콤의 취약점 관리 프로세스와 도구 활용법을 다룹니다.

가이드 구성

1. 취약점 관리 프로세스: 취약점 식별부터 조치까지의 전체 프로세스 흐름을 이해합니다.
2. 지속적 모니터링: 일회성 점검이 아닌, 매일 새로운 위협을 감지하는 체계를 구축합니다.
3. 사고 대응 시나리오: Log4j와 같은 긴급 보안 사고 발생 시 대응 절차를 학습합니다.

graph TD
    A["SBOM 수집"] --> B["관리 포털 업로드"]
    B --> C{"취약점 분석"}
    C -->|취약점 발견| D["티켓 생성 (Jira)"]
    D --> E["개발팀 할당"]
    E --> F["패치/완화 조치"]
    F --> G["재검증 및 완료"]
    C -->|정상| H["모니터링 유지"]

3.1 - 취약점 관리 프로세스

1. 식별 (Identification)

가장 먼저 해야 할 일은 ‘우리가 무엇을 쓰고 있는가’와 ‘그것이 위험한가’를 파악하는 것입니다.

• SBOM 활용: 모든 프로젝트의 구성요소를 식별합니다.
• 취약점 DB 매핑: NVD(National Vulnerability Database), GitHub Advisory 등 공신력 있는 데이터베이스와 SBOM의 컴포넌트를 매핑하여 CVE(Common Vulnerabilities and Exposures)를 찾아냅니다.

CVE 데이터베이스

알려진 취약점은 CVE(Common Vulnerabilities and Exposures) 번호로 식별됩니다.

예시: Log4Shell

• CVE-2021-44228
• Apache Log4j 2.0-beta9 ~ 2.14.1
• CVSS 점수: 10.0 (Critical)

NVD 연동

SBOM 관리 포털은 NVD(National Vulnerability Database)와 연동하여 자동으로 취약점을 탐지합니다.

2. 평가 (Assessment)

모든 취약점이 즉시 고쳐야 할 만큼 위험한 것은 아닙니다. 실제 영향도를 평가하여 우선순위를 정해야 합니다.

• CVSS 점수: 기본 점수(Base Score)를 참고하되, 맹신하지 않습니다.
• EPSS (Exploit Prediction Scoring System): 해당 취약점이 실제로 공격될 확률을 고려합니다.
• 도달 가능성 (Reachability): 취약한 라이브러리가 코드 내에서 실제로 호출되고 있는지 분석합니다. 호출되지 않는다면 우선순위를 낮출 수 있습니다.

CVSS (Common Vulnerability Scoring System)

추가 고려사항

CVSS 점수 외에 다음을 고려합니다.

• 악용 가능성 (Exploit Available)
• 영향 범위 (Public-facing vs Internal)
• 완화 조치 가능 여부

3. 조치 (Remediation)

평가 결과 위험하다고 판단된 취약점은 다음 중 하나의 방법으로 조치해야 합니다.

1. 업데이트 (Update): 취약점이 해결된 안전한 버전으로 라이브러리를 업그레이드합니다. (가장 권장)

<!-- Before -->
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.14.1</version>  <!-- Vulnerable -->
</dependency>

<!-- After -->
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.17.1</version>  <!-- Patched -->
</dependency>

2. 완화 (Mitigation): 패치가 불가능한 경우, 설정 변경이나 WAF(웹방화벽) 규칙 추가 등으로 공격 경로를 차단합니다.

예시: Log4Shell 완화

# JVM 옵션으로 JNDI lookup 비활성화
-Dlog4j2.formatMsgNoLookups=true

3. 수용 (Acceptance): 비즈니스 영향도가 낮거나 도달 불가능한 경우, 위험을 수용하고 모니터링합니다. (단, 승인 절차 필요)

4. 검증 (Verification)

조치가 완료된 후에는 반드시 재검증을 수행해야 합니다.

• 재빌드 및 스캔: 패치 후 다시 빌드하여 SBOM을 생성하고 스캔했을 때 취약점이 사라졌는지 확인합니다.

3.2 - 지속적 모니터링

왜 지속적 모니터링인가?

어제 안전했던 소프트웨어가 오늘은 위험할 수 있습니다. (Zero-day vulnerability) 소프트웨어 코드는 변하지 않았더라도, 그 코드가 사용하는 라이브러리에서 새로운 취약점이 발견될 수 있기 때문입니다. 따라서 빌드 시점에만 검사하는 것으로는 불충분합니다.

자동화된 모니터링 체계

SK텔레콤은 SBOM 관리 포털을 통해 중앙 집중화된 모니터링 환경을 제공합니다.

1. 일일 동기화 (Daily Sync)

SBOM 관리 포털은 NVD, OSS Index 등 글로벌 취약점 데이터베이스와 매일 동기화됩니다.

2. 실시간 영향도 분석

새로운 CVE가 데이터베이스에 등록되는 즉시, 저장된 모든 프로젝트의 SBOM과 대조 분석을 수행합니다. 우리 프로젝트가 해당 취약점의 영향을 받는지 1시간 이내에 파악할 수 있습니다.

3. 알림 (Alerting)

위험도(Critical, High)가 높은 새로운 취약점이 탐지되면, 담당자에게 즉시 알림이 발송됩니다.

• Slack/Teams 연동: 팀 채널로 실시간 알림 전송
• 이메일: 보안 담당자 및 프로젝트 PL에게 리포트 발송
• Jira 티켓 생성: 자동으로 이슈를 생성하여 조치 프로세스 시작

모니터링 대상

• 운영 중인 서비스 (Production): 현재 고객에게 서비스되고 있는 버전
• 개발 중인 프로젝트 (Development): 릴리스 예정인 차기 버전
• 레거시 시스템: 더 이상 개발되지 않지만 운영 중인 시스템 (관리가 소홀하기 쉬움)

자동화 워크플로우

graph TD
    A[신규 CVE 발표] --> B[SBOM 관리 포털<br/>자동 수집]
    B --> C{영향 받는<br/>프로젝트?}
    C -->|Yes| D[Slack 알림]
    D --> E[담당자 확인]
    E --> F[Jira 티켓 생성]
    F --> G[패치 작업]
    G --> H[검증]

3.3 - 취약점 대응

긴급 대응 프로세스

초고위험(Critical) 취약점이 공개되었을 때, 신속한 대응이 기업의 생존을 결정합니다.

graph TD
    A["취약점 공개 (Zero-day)"] --> B["영향도 파악 (SBOM 검색)"]
    B --> C{영향 받는 시스템 식별}
    C -->|식별됨| D[비상 대응팀 소집]
    D --> E["완화 조치 (긴급 패치/WAF)"]
    E --> F["근본 조치 (라이브러리 업데이트)"]
    F --> G[재검증 및 모니터링]
    C -->|식별 안 됨| H[지속 모니터링]

시나리오: Log4j 사태 재연

가상의 상황을 통해 대응 절차를 익혀봅시다.

상황 발생 (D-Day 09:00)

• 뉴스: “Apache Log4j 2.x 버전에서 치명적인 원격 코드 실행 취약점(Log4Shell) 발견”
• 보안팀: 즉시 SBOM 관리 포털 검색 시작

1. 영향도 파악 (09:10)

SBOM 관리 포털의 Global Search 기능을 활용하여 전사적으로 log4j-core 컴포넌트를 검색합니다.

• 검색어: pkg:maven/org.apache.logging.log4j/log4j-core
• 결과: 총 150개 프로젝트 중 12개 프로젝트에서 취약한 버전(2.0-beta9 ~ 2.14.1) 사용 중임이 식별됨.

2. 비상 전파 (09:30)

식별된 12개 프로젝트의 담당자에게 긴급 알림(Slack/SMS) 발송.

“귀하의 프로젝트(OOO시스템)가 Log4j 취약점(CVE-2021-44228)에 노출되었습니다. 즉시 조치 바랍니다.”

3. 긴급 완화 조치 (10:00)

라이브러리 업데이트에는 시간이 걸리므로, 즉시 적용 가능한 완화 조치를 먼저 수행합니다.

• 조치: JVM 시작 옵션에 -Dlog4j2.formatMsgNoLookups=true 추가 후 재기동.

4. 근본 조치 (D+1일)

개발팀은 안전한 버전(2.17.1 이상)으로 의존성을 업데이트하고 테스트를 거쳐 정식 배포를 진행합니다.

5. 검증 및 종료 (D+3일)

모든 대상 시스템의 SBOM이 갱신되었으며, SBOM 관리 포털에서 해당 취약점이 더 이상 탐지되지 않음을 확인하고 비상 상황을 종료합니다.

4 - 공급사 가이드

개요

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

적용 대상

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

• 소스코드: Java, Python, JavaScript, Go, C/C++ 등으로 작성된 애플리케이션
• 컨테이너 이미지: Docker 이미지 또는 OCI 호환 컨테이너
• 실행 파일: 컴파일된 바이너리(.jar, .dll, .so) 및 라이브러리
• 임베디드 시스템: 펌웨어 이미지, RootFS, 디바이스 드라이버

SBOM 제출 프로세스

공급사는 계약 시점부터 최종 납품까지 아래의 절차를 준수해야 합니다.

flowchart TD
    A[계약 검토] --> B["소프트웨어 개발/빌드"]
    B --> C{SBOM 생성}
    C -->|SKT 제공 도구 활용| D[SKT SBOM Scanner 활용]
    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. SK텔레콤 제공 도구 (Easy Mode): 복잡한 설정 없이 즉시 사용 가능한 표준 생성 도구 사용법을 안내합니다.
3. 오픈소스 도구 활용: 범용 오픈소스 도구(cdxgen 등)를 활용한 생성 방법을 안내합니다.
4. 검증 체크리스트: 제출 전 반드시 확인해야 할 필수 항목 점검표를 제공합니다.
5. 제출 절차: 생성된 SBOM 파일의 명명 규칙과 제출 채널을 안내합니다.

4.1 - SBOM 제출 요구사항

1. 표준 데이터 형식

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

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

2. 필수 포함 정보

제출되는 SBOM 문서는 다음의 정보들을 반드시 포함하고 있어야 합니다. 정보가 누락된 경우 반려될 수 있습니다.

2.1 메타데이터 (Metadata)

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

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

2.2 컴포넌트 정보 (Components)

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

• Name: 컴포넌트 이름 (예: commons-lang3)
• Version: 컴포넌트 버전 (예: 3.12.0)
• PURL (Package URL): [필수] 패키지 식별자

3. Package URL (PURL) 준수

PURL(Package URL)은 소프트웨어 패키지를 고유하게 식별하기 위한 표준 URL 형식입니다. SK텔레콤의 취약점 분석 시스템은 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

4.2 - SBOM 생성 방법

개요

SK텔레콤 제공 도구를 사용할 수 없거나, 이미 자체적인 빌드 파이프라인을 보유한 경우 오픈소스 도구를 활용할 수 있습니다. 본 가이드에서는 SK텔레콤이 검증한 오픈소스 도구들의 사용법을 안내합니다.

도구 환경 구축에 익숙하지 않은 경우, Docker가 설치되어 있다면 SK텔레콤 제공 도구를 참고하시기 바랍니다.

도구 선택 가이드

graph TD
    A[분석 대상 확인] --> B{소스코드인가?}
    B -- Yes --> C[cdxgen 권장]
    B -- No --> D{Docker 이미지인가?}
    D -- Yes --> E[Syft 또는 Trivy 권장]
    D -- No --> F[바이너리/펌웨어]
    F --> G[Syft 권장]

상세 가이드

하위 메뉴에서 각 도구별 상세 사용법을 확인하실 수 있습니다.

1. 빠른 시작 (cdxgen): 가장 범용적으로 사용되는 cdxgen 도구 사용법
2. 언어별 가이드: Java, Python, Node.js 등 언어별 전용 도구 설정법
3. Docker 이미지: 컨테이너 이미지 및 파일시스템 분석 방법

4.2.1 - 빠른 시작

cdxgen 소개

cdxgen은 CycloneDX 형식을 기본 지원하며, 별도의 복잡한 설정 없이 프로젝트 구조를 자동 분석하여 SBOM을 생성해주는 강력한 도구입니다.

추천 대상

• 소스코드 형태로 납품하는 경우
• 여러 언어가 섞인 프로젝트 (예: Java 백엔드 + React 프론트엔드)
• 빠르게 SBOM을 생성하고 싶은 경우

설치 및 실행

1. 설치 (Node.js 필요)

npm install -g @cyclonedx/cdxgen

2. 기본 실행

프로젝트 루트 디렉토리에서 아래 명령어를 실행합니다.

# 기본 생성 (bom.json 생성)
cdxgen -o bom.json

3. 프로젝트 정보 포함 (권장)

SK텔레콤 제출 규격을 준수하기 위해 프로젝트 이름과 버전을 명시합니다.

cdxgen -o bom.json --project-name "MyPaymentApp" --project-version "1.0.0"

4. 언어 타입 명시 (정확도 향상)

특정 언어만 분석하거나 정확도를 높이려면 -t 옵션을 사용합니다.

# Java 프로젝트 명시
cdxgen -t java -o bom.json

# Python 프로젝트 명시
cdxgen -t python -o bom.json

4.2.2 - 언어별 가이드

1. Java (Maven / Gradle)

Java 프로젝트는 빌드 도구의 플러그인을 사용하는 것이 가장 정확합니다.

Maven

pom.xml에 플러그인을 추가하여 빌드 시 생성합니다.

<plugin>
    <groupId>org.cyclonedx</groupId>
    <artifactId>cyclonedx-maven-plugin</artifactId>
    <version>2.7.9</version>
</plugin>

• 실행: mvn cyclonedx:makeAggregateBom

Gradle

build.gradle에 플러그인을 적용합니다.

plugins {
    id 'org.cyclonedx.bom' version '1.7.4'
}

• 실행: ./gradlew cyclonedxBom

2. Python (pip / Poetry)

pip (requirements.txt)

가상환경이 활성화된 상태에서 실행하는 것이 좋습니다.

pip install cyclonedx-bom
cyclonedx-py requirements -o bom.json

Poetry

poetry run cyclonedx-py poetry -o bom.json

3. Node.js (npm / Yarn)

package.json과 package-lock.json(또는 yarn.lock)이 있는 위치에서 실행합니다.

npm install -g @cyclonedx/cyclonedx-npm
cyclonedx-npm --output-file bom.json

4. Go (Go Modules)

go.mod 파일이 있는 위치에서 실행합니다.

go install github.com/CycloneDX/cyclonedx-gomod/cmd/cyclonedx-gomod@latest
cyclonedx-gomod app -json -output bom.json

4.2.3 - Docker 이미지

Syft 소개

Syft는 컨테이너 이미지 분석에 특화된 도구로, 이미지 레이어 내의 OS 패키지(APK, DEB, RPM)와 애플리케이션 라이브러리를 모두 식별합니다.

설치

# Linux / macOS
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

사용 방법

1. Docker 이미지 스캔

로컬 Docker 데몬에 있는 이미지나 원격 레지스트리의 이미지를 분석합니다.

# CycloneDX JSON 형식으로 출력
syft "myapp:latest" -o cyclonedx-json=bom.json

2. 이미지 파일(.tar) 스캔

docker save로 저장된 타르볼 파일도 분석 가능합니다.

syft "docker-archive:myapp.tar" -o cyclonedx-json=bom.json

3. 디렉토리 스캔 (RootFS)

이미지 내부 파일시스템이나 특정 디렉토리를 스캔할 때 사용합니다.

syft "dir:./rootfs" -o cyclonedx-json=bom.json

4.3 - 검증 체크리스트

필수 점검 항목

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

1. 파일 무결성

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

2. 필수 데이터 필드

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

3. 식별자 (PURL) 확인

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

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

온라인 검증 도구

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

4.4 - SK텔레콤 제공 도구

도구 개요

SKT SBOM Scanner는 공급사가 별도의 도구 학습이나 환경 설정 없이도 즉시 표준 준수 SBOM을 생성할 수 있도록 제공되는 도구입니다.

주요 장점

• 환경 독립성: Docker 컨테이너 기반으로 동작하여 로컬에 Java, Python 등을 설치할 필요가 없습니다.
• 다중 언어 지원: 프로젝트 내의 여러 언어(Java, JS, Python 등)를 한 번에 분석합니다.
• 자동 표준 준수: SK텔레콤 정책에 맞는 CycloneDX JSON 파일을 자동으로 생성합니다.

지원 언어 상세

• Java 21: 대부분 JDK 17에서 분석 가능하나, Java 21 전용 기능 사용 시 제한이 있을 수 있습니다.
• Python 2: 2020년 공식 지원 종료로 더 이상 지원하지 않습니다. Python 3로 마이그레이션을 권장합니다.

참고사항:

• C/C++ 프로젝트: 패키지 매니저(Conan, vcpkg) 사용 시에만 의존성 분석 가능. 헤더 파일 직접 관리 방식은 분석 제한적.
• 바이너리/펌웨어 파일: 기본 메타데이터만 추출 가능. 컴파일된 바이너리의 내부 의존성 분석에는 한계가 있음.
• RootFS 분석: 파일 시스템 구조 분석은 가능하나, 정적 링크된 라이브러리는 감지 불가능.

자세한 언어별 가이드는 언어별 세부 사용 가이드를 참조하세요.

사전 준비사항

• 운영체제:
  • Linux (권장)
  • macOS
  • Windows 10/11 (scan-sbom.bat 사용)
• Docker: v20.10 이상 설치 및 실행 중일 것
• 디스크 공간: 약 4-5 GB (Docker 이미지)

첫 실행 시 주의: Docker 이미지 다운로드로 5-10분 소요될 수 있습니다. 이후 실행부터는 캐시된 이미지를 사용하여 빠르게 실행됩니다.

도구 설치

Linux / macOS

# 스크립트 다운로드
curl -O https://raw.githubusercontent.com/sktelecom/sbom-tools/main/scripts/scan-sbom.sh
chmod +x scan-sbom.sh

# 설치 확인
./scan-sbom.sh --help

Windows

# 스크립트 다운로드
curl -O https://raw.githubusercontent.com/sktelecom/sbom-tools/main/scripts/scan-sbom.bat

# 설치 확인
scan-sbom.bat --help

사용 방법

1. 스크립트 실행

다운받은 scan-sbom.sh 파일을 프로젝트 루트 디렉토리에 위치시키고 실행합니다.

./scan-sbom.sh --project "프로젝트명" --version "버전" --generate-only

2. 주요 옵션 설명

• --project: (필수) 납품하는 프로젝트(애플리케이션)의 이름
• --version: (필수) 납품하는 프로젝트의 버전
• --target: (선택) 분석 대상 경로 또는 Docker 이미지명. (기본값: 현재 디렉토리 ./)
• --generate-only: (필수) 포털 자동 업로드 없이 로컬에 파일만 생성

사용 예시

1. 소스코드 분석 (Java/Python/Node.js 등)

소스코드가 있는 디렉토리에서 실행하면 pom.xml, package.json, requirements.txt 등을 자동 감지합니다.

cd /path/to/my-project
/path/to/scan-sbom.sh --project "MyWebApp" --version "1.0.0" --generate-only

• 결과: MySpringApp_1.0.0_bom.json 생성

2. Docker 이미지 분석

# 로컬 또는 레지스트리의 Docker 이미지 분석
./scan-sbom.sh --target "myapp:v1.0" --project "MyApp" --version "1.0" --generate-only

3. 바이너리 파일 분석 (펌웨어 등)

# 펌웨어 또는 실행 파일 분석
./scan-sbom.sh --target firmware.bin --project "RouterOS" --version "2.0" --generate-only

지원 파일 형식:

• ELF 바이너리
• 펌웨어 이미지

분석 한계:

• 컴파일된 바이너리는 기본 메타데이터만 추출 가능
• 내부 라이브러리나 의존성은 정적 링크 시 감지 불가능
• 정확한 SBOM 생성을 위해서는 소스 코드 레벨 분석을 권장
• 바이너리 분석 결과는 참고용으로만 활용

4. RootFS 디렉토리 분석

# 파일 시스템 전체 분석
./scan-sbom.sh --target ./rootfs/ --project "DeviceOS" --version "1.0" --generate-only

사용 사례:

• 임베디드 시스템 파일 시스템
• 언팩한 펌웨어 디렉토리
• 컨테이너 파일 시스템

SKT SBOM 관리 포털 업로드 (향후 지원 예정)

자동 업로드 (권장)

--generate-only 옵션을 제거하면 SBOM이 자동으로 SBOM 관리 포털 업로드에 업로드됩니다.

./scan-sbom.sh --project "MyApp" --version "1.0.0"

업로드 설정

스크립트 내부의 다음 변수를 수정하세요:

SERVER_URL="http://your-sbom-server:8081"
DEFAULT_API_KEY="YOUR_API_KEY_HERE"

또는 환경변수로 설정:

export API_KEY="YOUR_API_KEY_HERE"
./scan-sbom.sh --project "MyApp" --version "1.0.0"

다음 단계

SBOM 파일 생성 완료 후:

1. 검증 체크리스트로 파일 확인
2. 제출 절차에 따라 SK텔레콤에 제출
3. 문제 발생 시 담당자에게 문의

관련 문서

• SBOM 제출 요구사항
• 언어별 세부 가이드
• 검증 체크리스트

4.4.1 - 언어별 세부 사용 가이드

지원 언어 및 도구

• Java: Maven, Gradle (Java 7, 8, 11, 17, 21)
• Python: pip, Poetry (Python 2.7, 3.x)
• Node.js: npm, Yarn, pnpm
• Ruby: Bundler, Gemfile
• PHP: Composer
• Rust: Cargo
• C/C++: Conan, vcpkg (제한적)
• Go: go.mod
• .NET: NuGet, project files

언어별 사용 가이드

1. Java (Maven)

필수 파일

• pom.xml

예시

cd /path/to/maven-project
./scan-sbom.sh --project "MyJavaApp" --version "1.0.0" --generate-only

레거시 Java 7 프로젝트

<!-- pom.xml에서 Java 버전 명시 -->
<properties>
    <maven.compiler.source>1.7</maven.compiler.source>
    <maven.compiler.target>1.7</maven.compiler.target>
</properties>

스캔 시 Docker 컨테이너 내부에서 적절한 JDK를 자동 선택합니다.

2. Java (Gradle)

필수 파일

• build.gradle 또는 build.gradle.kts

예시

cd /path/to/gradle-project
./scan-sbom.sh --project "MyGradleApp" --version "1.0.0" --generate-only

Gradle Wrapper 사용

# gradlew가 있으면 자동으로 사용됨
./gradlew dependencies # 로컬에서 미리 확인 (선택)
./scan-sbom.sh --project "MyApp" --version "1.0.0" --generate-only

3. Python 3.x

필수 파일

• requirements.txt (권장)
• pyproject.toml (Poetry)
• Pipfile (Pipenv)

예시

cd /path/to/python-project
./scan-sbom.sh --project "MyPythonApp" --version "1.0.0" --generate-only

requirements.txt 생성

pip freeze > requirements.txt
./scan-sbom.sh --project "MyApp" --version "1.0.0" --generate-only

Poetry 프로젝트

# pyproject.toml이 있으면 자동 감지
./scan-sbom.sh --project "MyPoetryApp" --version "1.0.0" --generate-only

4. Python 2.x (레거시)

필수 파일

• requirements.txt

주의사항

Python 2.x는 2020년 지원 종료되었으므로, 가능한 Python 3.x로 마이그레이션을 권장합니다.

예시

# requirements.txt 생성 (Python 2 환경)
python2 -m pip freeze > requirements.txt

# SBOM 생성
./scan-sbom.sh --project "LegacyPython2App" --version "1.0.0" --generate-only

Python 2 명시

# requirements.txt 상단에 추가
# python_version < "3"
Django==1.11.29
requests==2.27.1

5. Node.js

필수 파일

• package.json
• package-lock.json (npm) 또는 yarn.lock (Yarn)

예시

cd /path/to/nodejs-project

# package-lock.json 생성 (없는 경우)
npm install

# SBOM 생성
./scan-sbom.sh --project "MyNodeApp" --version "1.0.0" --generate-only

Yarn 프로젝트

# yarn.lock이 있으면 자동 감지
./scan-sbom.sh --project "MyYarnApp" --version "1.0.0" --generate-only

pnpm 프로젝트

# pnpm-lock.yaml이 있으면 자동 감지
./scan-sbom.sh --project "MyPnpmApp" --version "1.0.0" --generate-only

6. Ruby

필수 파일

• Gemfile
• Gemfile.lock (권장)

예시

cd /path/to/ruby-project

# Gemfile.lock 생성 (없는 경우)
bundle install

# SBOM 생성
./scan-sbom.sh --project "MyRailsApp" --version "1.0.0" --generate-only

Rails 프로젝트

cd /path/to/rails-app
bundle install
./scan-sbom.sh --project "MyRailsAPI" --version "1.0.0" --generate-only

7. PHP

필수 파일

• composer.json
• composer.lock (권장)

예시

cd /path/to/php-project

# composer.lock 생성 (없는 경우)
composer install

# SBOM 생성
./scan-sbom.sh --project "MyLaravelApp" --version "1.0.0" --generate-only

Laravel 프로젝트

cd /path/to/laravel-app
composer install --no-dev # 프로덕션 의존성만
./scan-sbom.sh --project "MyLaravelAPI" --version "1.0.0" --generate-only

8. Rust

필수 파일

• Cargo.toml
• Cargo.lock (권장)

예시

cd /path/to/rust-project

# Cargo.lock 생성 (없는 경우)
cargo generate-lockfile

# SBOM 생성
./scan-sbom.sh --project "MyRustApp" --version "1.0.0" --generate-only

Workspace 프로젝트

# 루트 디렉토리에서 실행
cd /path/to/rust-workspace
./scan-sbom.sh --project "MyRustWorkspace" --version "1.0.0" --generate-only

9. Go

필수 파일

• go.mod
• go.sum (권장)

예시

cd /path/to/go-project

# go.sum 생성 (없는 경우)
go mod download

# SBOM 생성
./scan-sbom.sh --project "MyGoApp" --version "1.0.0" --generate-only

10. .NET (C#)

필수 파일

• *.csproj 또는 *.sln
• packages.config (레거시) 또는 PackageReference

예시

cd /path/to/dotnet-project

# 의존성 복원 (선택)
dotnet restore

# SBOM 생성
./scan-sbom.sh --project "MyDotNetApp" --version "1.0.0" --generate-only

11. C/C++ (제한적 지원)

지원 패키지 매니저

• Conan (conanfile.txt, conanfile.py)
• vcpkg (제한적)

예시 (Conan)

cd /path/to/cpp-project

# conanfile.txt 예시
cat > conanfile.txt <<EOF
[requires]
boost/1.80.0
openssl/3.0.0

[generators]
cmake
EOF

# SBOM 생성
./scan-sbom.sh --project "MyCppApp" --version "1.0.0" --generate-only

주의: C/C++ 프로젝트는 패키지 매니저 없이 직접 의존성을 관리하는 경우가 많아, SBOM 생성이 제한적일 수 있습니다.

멀티 언어 프로젝트

모노레포 (Monorepo)

여러 언어가 혼합된 프로젝트의 경우:

# 루트 디렉토리에서 실행하면 모든 언어 자동 감지
cd /path/to/monorepo
./scan-sbom.sh --project "MyMonorepo" --version "1.0.0" --generate-only

마이크로서비스

각 서비스별로 개별 실행:

# 서비스 1 (Node.js)
cd services/api
../../scan-sbom.sh --project "MyAPI" --version "1.0.0" --generate-only

# 서비스 2 (Python)
cd ../worker
../../scan-sbom.sh --project "MyWorker" --version "1.0.0" --generate-only

참고

• cdxgen 공식 문서: https://github.com/CycloneDX/cdxgen
• CycloneDX 스펙: https://cyclonedx.org/
• 언어별 패키지 매니저: 각 언어의 공식 문서 참조

4.5 - 제출 절차

1. 제출 시기

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

2. 제출 방법

현재 SK텔레콤은 이메일 제출을 원칙으로 하고 있습니다. (추후 공급사 포털 오픈 예정)

이메일 양식

• 수신처: opensource@sk.com 및 계약 담당자(PL)
• 제목: [SBOM 제출] 공급사명_프로젝트명_버전
• 첨부파일: 생성된 SBOM 파일 (비밀번호 걸린 압축 파일 금지)

본문 필수 기재 사항:

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

3. 제출 후 검증 및 조치

제출된 SBOM은 SK텔레콤 내부 SBOM 관리 시스템에 등록되어 분석됩니다.

1. 형식 검증: 필수 필드 누락 시 3일 이내 반려 통보
2. 보안 취약점 분석: Critical/High 등급 취약점 탐지 여부 확인
3. 조치 요청: 심각한 취약점 발견 시, 공급사는 7일(Critical) / 30일(High) 이내에 패치 계획이나 소명서를 제출해야 합니다.