가. 소프트웨어 공급망 보안의 개념과 주요 위협 유형
나. SBOM(Software Bill of Materials)의 개념과 표준 포맷
다. SLSA(Supply chain Levels for Software Artifacts) 프레임워크
라. 국내외 규제 동향과 기업 대응 방안
I. 개요 — 왜 공급망 보안인가
현대 소프트웨어의 70~90%는 오픈소스와 서드파티 컴포넌트로 구성된다. 공격자들은 이 점을 노려 신뢰받는 공급망을 침투 경로로 활용한다. 2020년 SolarWinds 사태에서는 빌드 파이프라인에 악성코드를 삽입하여 18,000개 이상의 조직에 백도어가 배포되었고, 2021년 Log4Shell은 전 세계 수억 개 Java 애플리케이션이 영향을 받았다.
가. 소프트웨어 공급망 보안 개념과 위협 유형
소프트웨어 공급망 보안이란 소프트웨어가 설계·개발·빌드·배포·운영되는 전 과정에서 외부 컴포넌트·도구·프로세스를 통해 유입되는 보안 위협을 식별하고 관리하는 체계이다.
| 위협 유형 | 공격 방법 | 대표 사례 |
|---|---|---|
| 빌드 파이프라인 오염 | CI/CD 서버 침투 → 배포 아티팩트에 악성코드 삽입 | SolarWinds SUNBURST (2020) |
| 오픈소스 취약점 | 널리 사용되는 라이브러리의 알려진 CVE 악용 | Log4Shell (CVE-2021-44228) |
| 의존성 혼동(Dependency Confusion) | 내부 패키지명과 동일한 악성 공개 패키지 업로드 | Microsoft·Apple 등 35개사 피해 (2021) |
| 타이포스쿼팅(Typosquatting) | 유명 패키지와 유사한 이름의 악성 패키지 배포 | npm 악성 패키지 (colouurs, lodahs 등) |
| 계정 탈취 | 패키지 유지관리자 계정 해킹 → 악성 버전 배포 | event-stream npm 패키지 (2018) |
나. SBOM 개념과 표준 포맷
SBOM(Software Bill of Materials, 소프트웨어 구성요소 명세서)이란 소프트웨어에 포함된 모든 컴포넌트·라이브러리·의존성의 목록과 버전·라이선스·출처 정보를 기록한 공식 문서다. 식품의 성분표처럼, 소프트웨어의 구성 성분을 투명하게 공개하여 취약점 발생 시 영향 범위를 즉시 파악하게 한다.
| 구분 | SPDX | CycloneDX |
|---|---|---|
| 주관 | Linux Foundation (ISO/IEC 5962 표준) | OWASP |
| 포맷 | JSON, YAML, RDF, Tag-Value | JSON, XML |
| 강점 | 라이선스 컴플라이언스 관리에 강함 | 보안 취약점 연계(VEX) 기능 풍부 |
| VEX 지원 | 별도 확장 필요 | 기본 내장 (CVE 영향 여부 명시) |
| 도구 연계 | FOSSology, REUSE | Syft, Grype, Trivy |
Log4Shell 발생 시 SBOM이 있는 조직은 영향을 받는 시스템을 평균 수 시간 내에 파악했지만, 없는 조직은 수 주가 걸렸다. SBOM의 실질적 가치를 보여주는 대표적 사례다.
다. SLSA 프레임워크
SLSA(Supply chain Levels for Software Artifacts, “살사”)는 Google이 제안하고 OpenSSF에서 관리하는 빌드 파이프라인 보안 성숙도 프레임워크다. 소프트웨어 아티팩트(빌드 결과물)의 무결성을 보장하기 위한 4단계 체계를 정의한다.
| SLSA 레벨 | 요구사항 | 방어하는 위협 |
|---|---|---|
| Level 1 | 빌드 프로세스 문서화, SBOM 생성 | 실수에 의한 아티팩트 오염 방지 |
| Level 2 | 버전관리 사용, 빌드 서비스에서 생성한 Provenance(출처증명) 제공 | 소스 수정 후 재빌드 공격 |
| Level 3 | 소스·빌드 무결성 검증, 격리된 빌드 환경 | 빌드 서버 침투를 통한 아티팩트 오염 |
| Level 4 | 2인 이상 리뷰, 재현 가능 빌드(Reproducible Build) | 내부자 위협, 지속적인 탈취 공격 |
라. 국내외 규제 동향과 기업 대응 방안
규제 동향
- 미국 행정명령 EO 14028 (2021): 연방정부 납품 소프트웨어에 SBOM 제출 의무화. NIST SSDF(Secure Software Development Framework) 준수 요구
- EU CRA (Cyber Resilience Act, 2024): EU 시장 출시 디지털 제품에 SBOM 제공 및 취약점 보고 의무화
- 국내: 과기정통부 「소프트웨어 공급망 보안 가이드라인」 발표 (2023), 공공부문 SBOM 도입 권고
기업 대응 방안
- SBOM 자동 생성 파이프라인: Syft·Trivy·FOSSA 도구를 CI/CD에 통합하여 빌드마다 SBOM 자동 생성·저장
- 취약점 연속 모니터링: 생성된 SBOM을 CVE DB(NVD, OSV)와 지속 비교, 신규 취약점 발견 시 자동 알림
- SLSA 레벨 목표 수립: 단기 Level 2, 중기 Level 3 달성을 위한 빌드 파이프라인 강화 계획 수립
- 공급업체 보안 계약: 납품 소프트웨어에 SBOM 제공 요구 조항을 계약에 명문화
- 사내 오픈소스 거버넌스: 허용·금지 라이선스 정책 수립, 고위험 오픈소스 사용 심의 프로세스
SBOM = 소프트웨어 성분표 | 포맷: SPDX(라이선스 강점) vs CycloneDX(보안 강점)
SLSA = 빌드 파이프라인 무결성 4단계 (Level 1 문서화 → Level 4 재현가능 빌드)
주요 위협: SolarWinds(빌드 오염) · Log4Shell(오픈소스 취약점) · Dependency Confusion