SBOM[Software Bill of Materials]란?

현대 소프트웨어 개발에서 우리는 수많은 오픈소스 라이브러리와 서드파이 컴포넌트에 의존하고 있습니다.

하나의 애플리케이션이 수백 개의 외부 의존성을 가지는 것은 이제 일반적인 일이 되었습니다.

이러한 복잡한 소프트웨어 공급망 속에서 SBOM [ Software Bill of Materials ] 이 왜 중요한 보안 도구로 주목받고 있는지 살펴보겠습니다.

 

SBOM이란?

SBOM을 가장 쉽게 이해하려면 도시락을 생각해보면 됩니다.

 

누군가 도시락을 싸왔습니다.

안에는 닭가슴살, 고구마, 브로콜리, 삶은 달걀, 김치가 들어있습니다.

이 도시락은 깨끗하고 건강한 식단처럼 보여도

 

만약 누군가 김치에 이상한 첨가물이 있었다고 발표를 한다면

그 김치가 어떤 도시락에 들어갔는지 기록이 없다면? 

모든 도시락을 전부 폐기해야 합니다.

 

SBOM은 바로 이 도시락의 "식재료 구성표" 입니다.

어떤 소프트웨어에 어떤 재료 (라이브러리)가 들어갔는지 기록해 두는 문서입니다.

 

우리가 만든 웹사이트
├── React (프론트엔드 프레임워크)
│   ├── lodash (유틸리티 라이브러리)
│   ├── moment.js (날짜 처리)
│   └── axios (HTTP 클라이언트)
├── Express.js (백엔드 프레임워크)
│   ├── bcrypt (암호화)
│   ├── jsonwebtoken (인증)
│   └── mongoose (데이터베이스 연결)
└── 수백 개의 다른 라이브러리들...

 

SBOM은 바로 이 "소프트웨어 재로 목록" 입니다.

우리가 만든 프로그램에 정확히 어떤 라이브라리의 어떤 버전이 들어갔는지를 상세하게 기록한 문서입니다.

 

이게 왜 중요할까?

만약 `lodash 4.17.20` 버전에 심각한 보안 취약점이 발견되었다고 가정을 하겠습니다.

SBOM이 있다면:

• "우리 프로젝트는 lodash 4.17.21을 사용하므로 안전합니다"
• "A 프로젝트는 4.17.20을 사용하므로 즉시 업데이트가 필요합니다"

근데 만일 SBOM이 없다면:

• "우리가 lodash를 쓰고 있나? 어떤 버전인지 확인해봐야겠네..."
• "간접적으로 사용하는 라이브러리까지는 모르겠는데..."

하나하나 찾아봐야하는 상황에 맞닥드리게 됩니다.

 

SBOM의 핵심 구성 요소

SBOM에는 다음과 같은 정보가 포함됩니다.

• 컴포넌트 이름: 사용된 라이브러리나 모듈의 정확한 이름
• 버전 정보: 각 컴포넌트의 구체적인 버전
• 라이선스 정보: 각 컴포넌트의 라이선스 유형
• 공급업체 정보: 컴포넌트 제공자 또는 개발자
• 의존성 관계: 컴포넌트 간의 종속성 구조
• 해시값: 컴포넌트의 무결성 검증을 위한 체크섬

SBOM의 필요성

1. 복잡해진 소프트웨어 공급망

현대 애플리케이션은 평균적으로 다음과 같은 특징을 보입니다

• Node.js 프로젝트: 평균 1,000개 이상의 의존성
• Python 프로젝트: 평균 500개 이상의 의존성
• Java 프로젝트: 평균 300개 이상의 의존성

이러한 복잡성 속에서 개발자들은 실제로 자신이 사용하는 모든 컴포넌트를 완전히 파악하기 어려운 상황입니다.

 

2. 증가하는 공급망 공격

최근 몇 년간 소프트웨어 공급망을 노린 공격이 급증했습니다.

• SolarWinds 해킹 (2020): 정부기관과 대기업 18,000곳 피해
• Log4Shell 취약점 (2021): 전 세계 수백만 애플리케이션 영향
• ua-parser-js 공격 (2021): NPM 패키지를 통한 악성코드 유포

3. 규제 오규사항 강화

• 미국 행정명령 14028 (2021): 연방정부 소프트웨어 공급업체에 SBOM 제출 의무화
• EU 사이버 복원력 법안: SBOM 제공을 법적 요구사항으로 검토
• 국내 정보보호 정책: 공공기관 대상 소프트웨어 투명성 강화 추진

 

실제 공격 사례 1: 어떻게 해킹이 일어나는가?

1단계: 신뢰할 수 있는 패키지 장악

• `event-stream`은 Node.js에서 매우 인기 있는 스트림 처리 라이브러리였습니다
• 주당 200만 회 다운로드, 1,600개 이상의 다른 패키지가 의존
• 원래 개발자는 더 이상 관리할 시간이 없어 새로운 관리자를 찾고 있었습니다

2단계: 사회공학적 접근

해커 -> 원래 개발자에게 이메일
"안녕하세요, event-stream을 사용하고 있는데 버그를 발견했습니다. 
수정 사항을 PR로 보내드릴게요. 그리고 이 패키지 관리를 도와드릴 수 있습니다."

 

 

 

 

 

 

• 해커는 몇 달간 정상적인 기여를 하며 신뢰를 쌓았습니다.
• 원래 개발자는 결국 프로젝트 관리 권한을 해커에게 넘겼습니다.

3단계: 악성 의존성 주입 

해커는 `event-stream` 3.3.6 버전에 새로운 의존성을 추가했습니다.

{
  "dependencies": {
    "flatmap-stream": "^0.1.1"  // <- 이 패키지가 악성 코드
  }
}

 

4단계: 표적 공격 실행

`flatmap-stream` 패키지 내부에는 다음과 같은 코드가 숨어있었습니다.

// 겉보기에는 정상적인 암호화된 문자열
var a = "Ly8gZGVjcnlwdCBhbmQgZXhlY3V0ZSBwYXlsb2Fk...";

// 특정 조건에서만 실행 (BitPay Copay 지갑 앱을 대상으로)
if (process.env.npm_package_description && 
    process.env.npm_package_description.indexOf('copay') >= 0) {
    
    // Base64 디코딩 후 악성 코드 실행
    eval(Buffer.from(a, 'base64').toString());
}

 

5단계: 실제 피해

• BitPay의 Copay 지갑 앱이 빌드될 때만 악성 코드가 활성화
• 사용자의 비트코인 개인키를 해커 서버로 전송
• 약 $100,000 상당의 비트코인이 도난당함

근데 만일 여기서 SBOM이 있었다면?

// SBOM에 이런 정보가 기록되어 문제를 빠르게 발견 가능
{
  "component": "event-stream",
  "version": "3.3.6",
  "dependencies": [
    {
      "name": "flatmap-stream",
      "version": "0.1.1",
      "addedDate": "2018-09-xx",  // <- 새로 추가된 의존성이 명확히 보임
      "author": "unknown"         // <- 출처 불명의 패키지 경고
    }
  ]
}

 

 

 

실제 공격 사례 2: SolarWinds 공급망 공격 (2020) - 가장 대규모 공격

1단계: 개발 환경 침투

• 해커들은 SolarWinds의 소프트웨어 개발 인프라에 침투
• 빌드 서버와 소스 코드 저장소에 접근 권한 획득
• 무려 18개월간 탐지되지 않고 잠복

2단계: 정상 소프트웨어 백도어 삽입

SolarWinds Orion 플랫폼의 정상적인 업데이트 과정에 악성 코드를 주입

// 정상 코드 사이에 교묘하게 삽입된 악성 코드
public class OrionImprovementBusinessLayer
{
    // 겉보기에는 정상적인 비즈니스 로직처럼 보임
    private static bool IsValidDomain(string domain)
    {
        // 실제로는 해커의 명령제어 서버와 통신
        if (domain.Contains("avsvmcloud.com")) // 해커의 도메인
        {
            // 시스템 정보 수집 및 추가 악성코드 다운로드
            return ExecuteRemoteCommand();
        }
        return true;
    }
}

 

 

3단계: 합법적 배포 채널 악용

 

• 악성 코드가 포함된 Orion 소프트웨어가 정상적인 업데이트로 배포
• SolarWinds의 디지털 서명이 그대로 적용되어 신뢰성 확보
• 자동 업데이트 시스템을 통해 전 세계로 확산

4단계: 대규모 피해 발생

 

• 미국 정부기관: 국무부, 재무부, 국토안보부, 국방부
• 대기업: Microsoft, FireEye, Cisco, Intel
• 총 피해 규모: 18,000개 이상의 조직

5단계: 실제 공격 시나리오

1. 피해 조직이 정상적인 SolarWinds 업데이트 설치
2. 악성 코드가 시스템에서 활성화 (최대 2주간 대기)
3. 해커 서버와 연결하여 시스템 정보 수집
4. Active Directory, 이메일 시스템 등에 추가 침투
5. 민감한 정보 장기간 탈취

 

 

 

SBOM의 표준 형식

1. SPDX [ Software Package Data Exchange ]

Linux Foundation에서 개발한 오픈 표준으로, ISO/IEC 5962:2021로 국제 표준화 되었습니다.

{
  "spdxVersion": "SPDX-2.3",
  "creationInfo": {
    "created": "2024-01-15T10:00:00Z",
    "creators": ["Tool: example-sbom-tool"]
  },
  "packages": [
    {
      "name": "express",
      "versionInfo": "4.18.2",
      "downloadLocation": "https://registry.npmjs.org/express/-/express-4.18.2.tgz",
      "licenseConcluded": "MIT",
      "checksums": [
        {
          "algorithm": "SHA256",
          "checksumValue": "5de93b..."
        }
      ]
    }
  ]
}

 

2. CycloneDX

OWASP에서 개발한 경량화된 SBOM 형식으로, 보안 중심의 메타데이터에 특화되어 있습니다.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21",
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ],
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "f6dd13..."
        }
      ]
    }
  ]
}

 

 

SBOM 구현 전략

1. 개발 단계별 SBOM 생성

빌드 타임 생성

# Node.js 프로젝트 예시
npm install -g @cyclonedx/bom
cyclonedx-bom -o sbom.json

# Maven 프로젝트 예시
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

 

CI/CD 파이프라인 통과

# GitHub Actions 예시
name: Generate SBOM
on: [push, pull_request]
jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Generate SBOM
        run: |
          npm install -g @cyclonedx/cyclonedx-bom
          cyclonedx-bom -o sbom.json
      - name: Upload SBOM
        uses: actions/upload-artifact@v3
        with:
          name: sbom
          path: sbom.json

 

2. SBOM 관리 도구 도입

오픈소스 도구

• Syft: Anchore에서 개발한 SBOM 생성 도구
• Tern: VMware에서 개발한 컨테이너 분석 도구
• FOSSA: 라이선스 컴플라이언스와 취약점 관리

상용 솔루션

• Black Duck: Synopsys의 소프트웨어 구성 분석 플랫폼
• WhiteSource: 현재 Mend로 브랜딩된 SCA 솔루션
• Sonatype Nexus: 의존성 관리와 보안 분석

3. 취약점 모니터링 자동화

# Python 예시: SBOM 기반 취약점 체크
import json
import requests

def check_vulnerabilities(sbom_path):
    with open(sbom_path, 'r') as f:
        sbom = json.load(f)
    
    vulnerabilities = []
    for component in sbom['components']:
        # CVE 데이터베이스 조회
        response = requests.get(
            f"https://api.osv.dev/v1/query",
            json={
                "package": {
                    "name": component['name'],
                    "ecosystem": "npm"
                },
                "version": component['version']
            }
        )
        
        if response.json().get('vulns'):
            vulnerabilities.extend(response.json()['vulns'])
    
    return vulnerabilities

 

 

SBOM 도입 시 고려사항

1. 기술적 도전과제

성능 오버헤드

• SBOM 생성과 검증 과정에서 빌드 시간 증가
• 대규모 프로젝트에서 SBOM 파일 크기 문제

정확성 보장

• 동적 로딩 라이브러리 탐지의 어려움
• 런타임에 다운로드되는 의존성 추적 한계

2. 조직적 도전과제

개발 프로세스 변화

• 개발자들의 새로운 도구 학습 필요
• 기존 CI/CD 파이프라인 수정 작업

책임 소재 명확화

• SBOM 생성과 관리 담당자 지정
• 취약점 발견 시 대응 프로세스 정립

SBOM의 미래 전망

1. 자동화 기술 발전

• AI 기반 의존성 분석과 위험도 평가
• 실시간 취약점 모니터링과 자동 패치 적용

2. 표준화 가속화

• 업계 표준 형식의 통합과 발전
• 클라우드 네이티브 환경에 특화된 SBOM 형식 등장

3. 규제 환경 변화

• 더 많은 국가와 산업에서 SBOM 의무화 도입
• 소프트웨어 책임에 대한 법적 프레임워크 강화

 

SBOM은 단순한 문서가 아닌, 현대 소프트웨어 개발의 복잡성을 관리하고 보안을 강화하는 핵심 도구입니다. 초기 도입 비용과 복잡성이 있지만, 소프트웨어 공급망 공격이 증가하는 현실에서 SBOM은 선택이 아닌 필수가 되어가고 있습니다.

 

조직에서 SBOM을 성공적으로 도입하려면 기술적 구현뿐만 아니라 프로세스 개선과 팀 교육이 함께 이루어져야 합니다. 작은 프로젝트부터 시작하여 점진적으로 확대하는 접근 방식을 권장하며, 오픈소스 도구들을 활용해 초기 비용을 낮추면서 경험을 쌓아가는 것이 중요합니다.

 

소프트웨어의 투명성과 신뢰성이 더욱 중요해지는 시대에서, SBOM은 개발자와 사용자 모두에게 안전한 소프트웨어 생태계를 만들어가는 첫걸음이 될 것입니다.