공급사 SBOM 제출 가이드
SK텔레콤에 소프트웨어를 공급하는 파트너사를 위한 SBOM 생성 및 제출 가이드입니다.
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가이드 구성
본 섹션은 다음과 같이 구성되어 있습니다.
- 제출 요구사항: SK텔레콤이 요구하는 필수 포맷(CycloneDX, SPDX)과 데이터 필드를 정의합니다.
- SKT 제공 도구 활용 (Easy Mode): 복잡한 설정 없이 즉시 사용 가능한 표준 생성 도구 사용법을 안내합니다.
- 오픈소스 도구 활용: 범용 오픈소스 도구(cdxgen, Syft 등)를 활용한 생성 방법을 안내합니다.
- 검증 체크리스트: 제출 전 반드시 확인해야 할 필수 항목 점검표를 제공합니다.
- 제출 절차: 생성된 SBOM 파일의 명명 규칙과 제출 채널을 안내합니다.
관련 문서
1 - SBOM 제출 요구사항
SK텔레콤 정책에 따른 표준 SBOM 형식, 필수 포함 정보, PURL 식별자 규칙을 상세히 정의합니다.
1. 표준 데이터 형식
SK텔레콤은 글로벌 표준으로 자리 잡은 두 가지 형식을 모두 지원합니다. 공급사는 사용하는 도구가 지원하는 형식을 선택하여 제출할 수 있습니다.
| 형식 | 버전 | 권장 용도 | 파일 형식 |
|---|
| CycloneDX | v1.3, v1.4, v1.5 | 애플리케이션 보안, 취약점 관리 중심 | JSON (권장), XML |
| SPDX | v2.2, v2.3 | 라이선스 컴플라이언스 중심 | JSON, Tag-Value |
참고: 두 형식 모두 동등하게 인정되나, 내부 시스템 연동성을 위해 CycloneDX (JSON) 형식을 권장합니다.
2. 필수 포함 정보
제출되는 SBOM 문서는 다음의 정보들을 반드시 포함하고 있어야 합니다. 정보가 누락된 경우 반려될 수 있습니다.
문서 자체와 생성 도구에 대한 정보입니다.
- 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): [필수] 패키지 식별자
2.3 의존성 범위 (Dependency Scope)
중요: 전이적 의존성(Transitive Dependencies)을 반드시 포함해야 합니다.
SK텔레콤은 제출된 SBOM을 기반으로 취약점을 분석합니다. 직접 의존성만 포함된 SBOM은 숨겨진 취약점을 놓칠 수 있으므로 반려될 수 있습니다.
| 의존성 종류 | 설명 | 포함 여부 |
|---|
| 직접 의존성 (Direct) | 프로젝트가 직접 선언한 라이브러리 | 필수 |
| 전이적 의존성 (Transitive) | 직접 의존성이 다시 의존하는 라이브러리 | 필수 |
| 개발 전용 의존성 (Dev-only) | 테스트, 빌드 도구 등 런타임 미포함 라이브러리 | 권장 포함 |
전이적 의존성이란?
예를 들어 프로젝트가 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 예시
| 생태계 | PURL 형식 예시 |
|---|
| Java (Maven) | pkg:maven/org.springframework/spring-core@5.3.20 |
| JavaScript (NPM) | pkg:npm/express@4.18.2 |
| Python (PyPI) | pkg:pypi/django@4.1.0 |
| Go | pkg:golang/github.com/gin-gonic/gin@v1.8.1 |
| .NET (NuGet) | pkg:nuget/Newtonsoft.Json@13.0.1 |
| OS 패키지 (RPM) | pkg:rpm/centos/glibc@2.17-317.el7?arch=x86_64 |
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"
}
}]
}]
}
...
참고 자료
관련 문서
2 - 오픈소스 도구를 활용한 SBOM 생성
범용 오픈소스 도구를 활용하여 환경별로 SBOM을 생성하는 방법을 안내합니다.
SKT 제공 도구를 사용할 수 없거나, 이미 자체적인 빌드 파이프라인을 보유한 경우 오픈소스 도구를 직접 활용할 수 있습니다. 아래는 SK텔레콤이 검증한 주요 오픈소스 도구 목록과 공식 사용법 링크입니다.
도구 환경 구축에 익숙하지 않은 경우, Docker가 설치되어 있다면 SKT 제공 도구를 먼저 검토해 보시기 바랍니다.
도구 선택 가이드
graph TD
A[분석 대상 확인] --> B{소스코드인가?}
B -- Yes --> C[cdxgen 권장]
B -- No --> D{Docker 이미지인가?}
D -- Yes --> E[Syft 또는 Trivy 권장]
D -- No --> F[바이너리/펌웨어]
F --> G[Syft 권장]주요 도구 안내
cdxgen (소스코드 분석 권장)
Java, Python, Node.js, Go 등 다양한 언어 프로젝트를 자동 분석하여 CycloneDX 형식의 SBOM을 생성합니다.
Syft (컨테이너 이미지 및 바이너리 분석 권장)
Docker 이미지, 파일시스템, 바이너리 파일을 분석하여 OS 패키지와 애플리케이션 라이브러리를 모두 식별합니다. CycloneDX 및 SPDX 형식을 지원합니다.
Trivy (컨테이너 이미지 분석)
컨테이너 이미지 분석과 취약점 스캔을 함께 수행할 수 있는 올인원 도구입니다.
언어별 전용 플러그인
빌드 도구 플러그인을 사용하면 더 정확한 의존성 정보를 추출할 수 있습니다.
| 언어/빌드 도구 | 플러그인/도구 | 공식 문서 |
|---|
| Java (Maven) | cyclonedx-maven-plugin | 링크 |
| Java (Gradle) | cyclonedx-gradle-plugin | 링크 |
| Python | cyclonedx-bom | 링크 |
| Node.js | @cyclonedx/cyclonedx-npm | 링크 |
| Go | cyclonedx-gomod | 링크 |
전이적 의존성 포함 확인
SK텔레콤 제출 SBOM은 전이적 의존성(Transitive Dependencies)을 반드시 포함해야 합니다.
전이적 의존성이란 프로젝트가 직접 선언하지 않았지만, 사용하는 라이브러리가 내부적으로 의존하는 라이브러리를 말합니다. 이 항목이 누락되면 숨겨진 취약점을 탐지할 수 없어 SBOM이 반려될 수 있습니다.
핵심 원칙: 빌드(패키지 설치) 완료 후 SBOM을 생성해야 합니다.
소스코드만 있는 상태에서는 전이적 의존성이 누락될 수 있습니다. 아래 표를 참고하여 SBOM 생성 전에 선행 작업을 완료하십시오.
도구별 전이적 의존성 지원 현황
| 도구 / 방법 | 전이적 의존성 포함 | SBOM 생성 전 선행 작업 |
|---|
| cdxgen (소스코드) | 자동 포함 | 별도 빌드 불필요 (자동 감지) |
| cdxgen (Java/Maven) | 조건부 | mvn package 또는 mvn dependency:resolve 먼저 실행 |
| cdxgen (Java/Gradle) | 조건부 | ./gradlew dependencies 먼저 실행 |
| cdxgen (Python) | 조건부 | 가상환경 활성화 후 pip install -r requirements.txt 먼저 실행 |
| cdxgen (Node.js) | 조건부 | npm install 또는 yarn install 먼저 실행 |
| Syft (Docker 이미지) | 자동 포함 | 이미지 빌드 완료 후 스캔 (OS/앱 패키지 모두 포함) |
| Syft (파일시스템/RootFS) | 자동 포함 | 배포 아티팩트 기준으로 스캔 |
| Maven 플러그인 | 자동 포함 | mvn package 단계에서 자동 생성 |
| Gradle 플러그인 | 자동 포함 | ./gradlew cyclonedxBom 실행 |
권장: Docker 이미지로 납품하는 경우, 빌드된 이미지를 Syft로 스캔하면 소스코드 분석보다 더 완전한 전이적 의존성을 포함할 수 있습니다.
공통 주의사항
도구를 사용하기 전 아래 사항을 확인하십시오.
- 전이적 의존성 포함 여부: 위 표를 참고하여 SBOM 생성 전 선행 작업을 완료합니다. 의존성 누락은 반려 사유가 됩니다.
- PURL 포함 여부: 생성된 SBOM에 모든 컴포넌트의
purl 필드가 포함되어 있는지 확인합니다. SK텔레콤 시스템은 PURL을 기반으로 취약점을 매핑합니다. - 출력 포맷: CycloneDX JSON 형식을 권장합니다. (
-o cyclonedx-json 또는 동등한 옵션 사용) - 프로젝트 정보: 메타데이터에 납품 프로젝트의 이름과 버전이 정확히 기입되었는지 확인합니다.
관련 문서
3 - SBOM 제출 전 검증 체크리스트
SBOM 제출 전 필수 확인 사항을 점검하여 반려를 방지합니다.
필수 점검 항목
아래 체크리스트를 통과하지 못한 SBOM은 시스템에서 자동으로 반려될 수 있습니다.
1. 파일 무결성
2. 필수 데이터 필드
3. 의존성 완전성 확인
전이적 의존성 누락은 가장 흔한 반려 사유입니다. 아래 항목을 반드시 확인하십시오.
의존성 수 기준 가이드: 일반적인 웹 애플리케이션은 전이적 의존성까지 포함하면 수십~수백 개의 컴포넌트가 포함됩니다. SBOM의 컴포넌트 수가 예상보다 현저히 적다면 의심해보십시오.
4. 식별자 (PURL) 확인
SK텔레콤 시스템은 PURL을 통해 취약점을 매핑합니다. 가장 중요한 항목입니다.
온라인 검증 도구
관련 문서
4 - SKT 제공 도구 활용 (Easy Mode)
SK텔레콤 표준 스크립트를 활용하여 복잡한 설정 없이 SBOM을 생성하는 방법입니다.
도구 개요
SKT SBOM Scanner는 공급사가 별도의 도구 학습이나 환경 설정 없이도 즉시 표준 준수 SBOM을 생성할 수 있도록 제공되는 도구입니다.
SKT SBOM Scanner는 오픈소스로 개발·운영되고 있습니다.
소스 코드, 이슈 트래커, 기여 방법 등 자세한 내용은 GitHub 저장소를 참고하세요.
github.com/sktelecom/sbom-tools
버그 제보, 기능 제안, Pull Request를 통한 기여를 환영합니다.
주요 장점
- 환경 독립성: Docker 컨테이너 기반으로 동작하여 로컬에 Java, Python 등을 설치할 필요가 없습니다.
- 다중 언어 지원: 프로젝트 내의 여러 언어(Java, JS, Python 등)를 한 번에 분석합니다.
- 자동 표준 준수: SK텔레콤 정책에 맞는 CycloneDX JSON 파일을 자동으로 생성합니다.
지원 언어 상세
| 언어 | 패키지 매니저 | 필수 파일 | 비고 |
|---|
| Java | Maven, Gradle | pom.xml, build.gradle | Java 7-17 지원 (JDK 17) |
| Python | pip, Poetry | requirements.txt, pyproject.toml | Python 3.6+ 지원 |
| Node.js | npm, Yarn, pnpm | package.json, package-lock.json | - |
| Ruby | Bundler | Gemfile, Gemfile.lock | - |
| PHP | Composer | composer.json, composer.lock | - |
| Rust | Cargo | Cargo.toml, Cargo.lock | - |
| Go | Go modules | go.mod, go.sum | - |
| .NET | NuGet | *.csproj, packages.config | - |
| C/C++ | Conan, vcpkg | conanfile.txt, vcpkg.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
지원 파일 형식:
분석 한계:
- 컴파일된 바이너리는 기본 메타데이터만 추출 가능
- 내부 라이브러리나 의존성은 정적 링크 시 감지 불가능
- 정확한 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 파일 생성 완료 후:
- 검증 체크리스트로 파일 확인
- 제출 절차에 따라 SK텔레콤에 제출
- 문제 발생 시 담당자에게 문의
관련 문서
4.1 - 언어별 세부 사용 가이드
SKT SBOM Scanner는 다양한 프로그래밍 언어와 빌드 시스템을 지원합니다.
지원 언어 및 도구
- 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
언어별 사용 가이드
스크립트 다운로드
curl -O https://raw.githubusercontent.com/sktelecom/sbom-tools/main/scripts/scan-sbom.sh
chmod +x scan-sbom.sh
1. Java (Maven)
필수 파일
예시
# 스크립트 다운로드
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 (레거시)
필수 파일
주의사항
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.jsonpackage-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
필수 파일
예시
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.jsoncomposer.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.tomlCargo.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
필수 파일
예시
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 또는 *.slnpackages.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
참고
5 - SBOM 제출 절차
작성된 SBOM 파일의 제출 채널과 이메일 양식, 제출 후 프로세스를 안내합니다.
1. 제출 시기
- 소프트웨어 계약 체결 후 초기 납품 시
- 소프트웨어의 주요 버전(Major/Minor) 업데이트 시
- 계약서에 명시된 정기 제출 일정 도래 시
2. 제출 방법
SBOM 파일은 SK텔레콤 사업부서 및 보안부서 담당자에게 이메일 혹은 지정된 시스템을 통해 제출합니다.
제출 방법
- 사업부서 및 보안부서 담당자에게 이메일 또는 담당자가 지정한 채널로 SBOM 파일을 전달합니다.
- 이메일 제목:
[SBOM 제출] 공급사명_프로젝트명_버전 - 첨부파일: 생성된 SBOM 파일 (비밀번호 걸린 압축 파일 금지)
본문 필수 기재 사항:
- 납품 계약 번호
- 담당자 정보 (성명, 부서, 연락처)
- 프로젝트 정보 (시스템명, 상세 버전)
- 사용 도구 (예: SKT SBOM Scanner v1.0)
사업부서 담당자의 TOSCA 등록 의무
공급사로부터 SBOM을 접수한 SK텔레콤 사업부서 담당자는 사내 오픈소스 & SBOM 관리 시스템인 TOSCA에 해당 SBOM을 등록해야 합니다.
TOSCA (SK텔레콤 오픈소스 & SBOM 관리 시스템)
https://tosca.sktelecom.com
3. 제출 후 검증 및 조치
제출된 SBOM은 TOSCA에 등록된 후 아래 절차에 따라 검증됩니다.
| 단계 | 내용 | 처리 기한 |
|---|
| 형식 검증 | 필수 필드 누락 여부 확인. 미충족 시 반려 통보 | 접수 후 3일 이내 |
| 보안 취약점 분석 | Critical/High 등급 취약점 탐지 여부 자동 분석 | - |
| 조치 요청 | 심각한 취약점 발견 시 패치 계획 또는 소명서 요청 | Critical: 7일 / High: 30일 |
검증 결과 및 조치 요청 사항은 사업부서 담당자를 통해 공급사 및 보안부서 담당자에 통보됩니다.
관련 문서