소프트웨어 공급망 보안: 왜 지금 중요한가
1. 이 챕터에서 하는 일
이 챕터는 실습 없이 읽기만 하는 배경 지식 챕터다. 소프트웨어 공급망 보안의 현실을 실제 사고 사례를 통해 이해하고, SBOM(Software Bill of Materials)이 왜 필수 도구가 되었는지, 그리고 이를 요구하는 국제 규제의 흐름을 파악합니다.
이 챕터를 읽고 나면 "왜 이 키트가 필요한가"에 대한 명확한 답을 얻을 수 있습니다. 이후 챕터에서 수행하는 모든 작업 — 정책 수립, 프로세스 설계, SBOM 생성, 취약점 분석 — 이 챕터의 맥락 위에서 그 목적이 더욱 선명해진다.
2. 소프트웨어 공급망이란
오픈소스가 제품 안으로 들어오는 경로
소프트웨어는 혼자 만들어지지 않는다. 개발자는 npm, PyPI, Maven 같은 패키지 저장소에서 오픈소스 라이브러리를 가져다 쓰고, 그 라이브러리는 또 다른 라이브러리에 의존합니다. 이 연쇄 구조 전체가 소프트웨어 공급망입니다.
현대 소프트웨어는 70~90%가 오픈소스 컴포넌트로 구성됩니다. 자체 코드보다 외부에서 가져온 코드가 훨씬 많다는 뜻입니다. 이는 개발 속도를 높이는 강점이지만, 동시에 외부 위협이 내부로 유입되는 통로이기도 하다.
공급망 보안이란 이 경로 전체에서 발생할 수 있는 위험 — 취약점, 악성코드, 라이선스 위반 — 을 식별하고 관리하는 체계를 말합니다.
3. 실제 공급망 공격 사례 3가지
다음 세 사례는 공급망 보안이 추상적 개념이 아님을 보여준다.
SolarWinds (2020)
사건 개요 공격자는 SolarWinds의 내부 빌드 파이프라인에 악성코드(Sunburst)를 삽입했다. 정상적인 소프트웨어 업데이트 패키지(Orion 플랫폼)에 포함되어 배포되었기 때문에, 기존 보안 도구로는 탐지가 극히 어려웠다.
영향 범위 미국 재무부, 국무부 등 연방정부 기관을 포함해 전 세계 18,000개 이상의 조직이 악성 업데이트를 설치했다. 수개월간 탐지되지 않은 채 내부 네트워크에 접근이 허용되었다.
교훈 소프트웨어를 만드는 빌드 파이프라인 자체가 공격 대상이 될 수 있습니다. 제품에 포함된 모든 컴포넌트가 어디서 왔는지, 빌드 과정이 안전한지 검증하는 체계가 필요하다.
Log4Shell (2021, CVE-2021-44228)
사건 개요 Java 애플리케이션에서 거의 보편적으로 사용되는 로깅 라이브러리 Apache Log4j 2에서 JNDI(Java Naming and Directory Interface) 인젝션 취약점이 발견되었다. 공격자는 특수하게 조작된 문자열 하나로 원격 코드 실행(RCE)이 가능했다.
영향 범위 전 세계 수억 개 시스템이 영향을 받았으며, Apple, Amazon, Tesla, 트위터 등 사실상 모든 대형 기술기업의 서비스가 해당되었다. 발견 직후 72시간 내에 수백만 건의 익스플로잇 시도가 탐지되었다.
교훈 어디서 어떤 오픈소스를 사용하는지 파악하지 못하면 패치조차 불가능하다. SBOM이 있었다면 Log4j를 사용하는 모든 시스템을 즉시 식별하고 대응할 수 있었을 것입니다.
XZ Utils (2024, CVE-2024-3094)
사건 개요 공격자는 "Jia Tan"이라는 가명으로 2년간 XZ Utils 오픈소스 프로젝트에 신뢰할 수 있는 기여자로 활동했다. 장기간 정상적인 기여를 통해 신뢰를 쌓은 뒤, sshd(SSH 데몬)에 백도어를 삽입하는 악성 코드를 커밋했다. 배포 직전 한 개발자의 이상 징후 발견으로 전면 확산은 막았다.
영향 범위 Fedora, Debian, Ubuntu 등 다수의 주요 Linux 배포판에 이미 취약한 버전이 포함되어 있었다. 발견이 수일만 늦었어도 수백만 대의 서버에 백도어가 심어졌을 것입니다.
교훈 오픈소스 프로젝트 기여자의 신원과 장기적 행동 패턴을 모니터링해야 합니다. 의존하는 오픈소스 프로젝트의 관리 상태(거버넌스, 메인테이너 활동)도 공급망 보안의 일부다.
4. 국제 규제 동향
공급망 보안은 이제 자율적 모범 사례를 넘어 법적 요구사항이 되고 있습니다.
미국 행정명령 EO 14028 (2021)
배경 SolarWinds, Microsoft Exchange 등 잇따른 대형 공급망 공격에 대응하여 바이든 행정부가 2021년 5월 서명한 사이버보안 강화 행정명령입니다.
핵심 요구사항
- 연방정부에 납품하는 소프트웨어에 대해 SBOM 제출 의무화
- NTIA(미국 통신정보청)가 정의한 SBOM 최소 요소 기준 준수
- 소프트웨어 개발 보안 관행(Secure Software Development Practices) 준수 확인
한국 기업 영향 미국 연방정부에 직접 납품하는 기업은 즉시 영향권에 있습니다. 간접 공급망(납품 기업의 하청)도 동일한 요구사항을 전달받는 추세이므로, 미국 시장에서 활동하는 기업은 대부분 영향을 받는다고 봐야 합니다.
EU Cyber Resilience Act - CRA (2024)
배경 EU 디지털 단일 시장에 출시되는 디지털 제품의 사이버보안을 강화하기 위해 2024년 채택된 EU 전체 적용 규정입니다.
핵심 요구사항
- EU 시장에 출시하는 디지털 제품(소프트웨어 포함)에 보안 요구사항 적용
- 오픈소스 컴포넌트 목록 관리 및 취약점 대응 의무화
- 2027년 전면 시행 예정
제재 불이행 시 최대 1,500만 유로 또는 전 세계 연간 매출의 2.5% 중 큰 금액 적용.
한국 기업 영향 EU에 소프트웨어 제품이나 서비스를 판매하는 모든 기업이 해당됩니다. 클라우드 서비스, 모바일 앱, IoT 기기 등 디지털 요소가 있는 제품은 모두 적용 대상입니다.
국내 동향
국내에서도 공급망 보안 의무화 논의가 빠르게 진행되고 있습니다.
- 과기부/KISA 소프트웨어 공급망 보안 가이드라인 (2023): SBOM 도입을 권고하는 국내 최초 공식 가이드라인
- 공공 SW 사업 SBOM 도입 검토: 공공기관 발주 소프트웨어 사업에 SBOM 제출 요구 방안 검토 중
- 국내 SBOM 의무화 논의: EU CRA 시행 이후 국내 유사 규제 도입 가능성 높음
5. 두 표준이 공급망 보안에 기여하는 방식
ISO/IEC 5230과 ISO/IEC 18974는 공급망 보안의 두 가지 핵심 위험을 각각 담당합니다.
- ISO/IEC 5230: 오픈소스 사용의 투명성을 확보하여 라이선스 위반 위험을 제거한다
- ISO/IEC 18974: 알려진 취약점을 식별하고 대응하여 보안 위험을 제거한다
두 표준을 함께 준수하면 공급망 보안의 라이선스와 보안 양면을 모두 커버합니다.
| 위험 유형 | 담당 표준 | 주요 도구 |
|---|---|---|
| 라이선스 위반 | ISO/IEC 5230 | SBOM + 라이선스 스캔 |
| 보안 취약점 | ISO/IEC 18974 | SBOM + CVE 스캔 |
두 표준의 공통 핵심 도구는 SBOM입니다. SBOM이 있어야 라이선스도 스캔할 수 있고, CVE도 조회할 수 있습니다. Log4Shell 사례에서 보았듯이, SBOM 없이는 어디에 무엇이 있는지조차 알 수 없습니다.
6. 셀프스터디 경로
이 챕터는 읽기만 해도 됩니다. 개념 이해에 집중하세요.
- 이 문서 읽기 — 공급망 보안 전체 맥락 파악
- 사고 사례 3가지 핵심 교훈 자신의 언어로 정리
- 국제 규제 중 자사에 해당하는 항목 확인
sbom-101.md읽기 → SBOM 기술 개념 상세 이해
7. 완료 확인 체크리스트
- 공급망 보안 사고 3가지(SolarWinds, Log4Shell, XZ Utils)를 설명할 수 있다
- SBOM이 왜 필요한지 이해했다
- EO 14028 / EU CRA 가 자사에 미치는 영향을 파악했다
- 두 표준이 공급망 보안에서 담당하는 역할을 이해했다
8. 다음 단계
- SBOM 기술 개념 학습:
sbom-101.md로 이동하여 CycloneDX, SPDX 포맷과 SBOM 최소 요소를 학습한다 - 환경 준비로 바로 이동:
docs/01-setup/으로 이동하여 툴체인 설치를 시작한다
개념 이해를 충분히 했다면 docs/01-setup/ 부터 실습을 시작해도 좋다.
이 챕터는 언제든지 다시 돌아와서 참고할 수 있습니다.