소프트웨어 공급망 보안: 왜 지금 중요한가

1. 이 챕터에서 하는 일

이 챕터는 실습 없이 읽기만 하는 배경 지식 챕터입니다. 소프트웨어 공급망 보안의 현실을 실제 사고 사례를 통해 이해하고, SBOM(소프트웨어 부품 명세서, Software Bill of Materials)이 왜 필수 도구가 되었는지, 그리고 이를 요구하는 국제 규제의 흐름을 파악합니다.

이 챕터를 읽고 나면 "왜 이 키트가 필요한가"에 대한 명확한 답을 얻을 수 있습니다. 이후 챕터에서 수행하는 모든 작업 — 정책 수립, 프로세스 설계, SBOM 생성, 취약점 분석 — 이 챕터의 맥락 위에서 그 목적이 더욱 선명해집니다.

2. 소프트웨어 공급망이란

오픈소스가 제품 안으로 들어오는 경로

소프트웨어는 혼자 만들어지지 않습니다. 개발자는 npm, PyPI, Maven 같은 패키지 저장소에서 오픈소스 라이브러리를 가져다 쓰고, 그 라이브러리는 또 다른 라이브러리에 의존합니다. 이 연쇄 구조 전체가 소프트웨어 공급망입니다.

현대 소프트웨어는 70~80%가 오픈소스 컴포넌트로 구성됩니다. 자체 코드보다 외부에서 가져온 코드가 훨씬 많다는 뜻입니다. 이는 개발 속도를 높이는 강점이지만, 동시에 외부 위협이 내부로 유입되는 통로이기도 합니다.

공급망 보안이란 이 경로 전체에서 발생할 수 있는 위험 — 취약점, 악성코드, 라이선스 위반 — 을 식별하고 관리하는 체계를 말합니다.

3. 실제 공급망 공격 사례

다음 사례는 공급망 보안이 추상적 개념이 아님을 보여줍니다. 앞의 세 건은 코드와 메인테이너의 신뢰를 노린 초기 유형이고, 뒤의 두 건은 2025년 이후 자격증명과 빌드 파이프라인으로 옮겨 간 유형입니다.

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시간 내에 약 80만 건, 이후 수 주간 수백만 건의 익스플로잇 시도가 탐지되었습니다.

교훈 어디서 어떤 오픈소스를 사용하는지 파악하지 못하면 패치조차 불가능합니다. SBOM이 있었다면 Log4j를 사용하는 모든 시스템을 즉시 식별하고 대응할 수 있었을 것입니다.

XZ Utils (2024, CVE-2024-3094)

사건 개요 공격자는 "Jia Tan"이라는 가명으로 2년간 XZ Utils 오픈소스 프로젝트에 신뢰할 수 있는 기여자로 활동했습니다. 장기간 정상적인 기여를 통해 신뢰를 쌓은 뒤, sshd(SSH 데몬)에 백도어를 삽입하는 악성 코드를 커밋했습니다. 배포 직전 한 개발자의 이상 징후 발견으로 전면 확산은 막았습니다.

영향 범위 Fedora 베타, Debian testing, openSUSE Tumbleweed 등 주요 배포판의 개발·베타 버전에 취약한 버전이 포함됐고, 안정판 배포 직전에 발견되어 확산을 막았습니다. 발견이 수일만 늦었어도 수백만 대의 서버에 백도어가 심어졌을 것입니다.

교훈 오픈소스 프로젝트 기여자의 신원과 장기적 행동 패턴을 모니터링해야 합니다. 의존하는 오픈소스 프로젝트의 관리 상태(거버넌스, 메인테이너 활동)도 공급망 보안의 일부입니다.

tj-actions/changed-files (2025-03, CVE-2025-30066)

사건 개요 GitHub Actions 워크플로에서 널리 쓰이던 tj-actions/changed-files 액션의 여러 버전 태그가 악성 커밋 하나를 가리키도록 재지정됐습니다. v1.0.0, v35.7.7-sec, v44.5.1 을 포함한 태그가 모두 같은 커밋으로 바뀌었고, 그 커밋의 스크립트는 러너 워커 프로세스 메모리에서 시크릿을 추출해 워크플로 로그에 출력했습니다.

영향 범위 이 액션을 사용하던 저장소가 2만 3천 개를 넘었습니다. 로그가 공개된 저장소에서는 API 키, 클라우드 자격증명, SSH 키가 그대로 노출됐습니다. 애플리케이션 코드는 한 줄도 바뀌지 않았습니다. 활동 기간은 2025-03-14부터 15까지이고, 46.0.1에서 수정됐습니다(CVSS 8.6).

교훈 의존성 목록에는 라이브러리뿐 아니라 빌드에 쓰는 액션과 도구도 들어갑니다. @v45 같은 이동 가능한 태그는 언제든 다른 커밋을 가리킬 수 있으므로, 40자리 커밋 SHA로 고정해야 실제로 실행되는 코드가 고정됩니다.

Shai-Hulud 계보와 ChainDrop (2025-2026)

사건 개요 2025-09 npm에서 처음 확인된 Shai-Hulud 웜은 훔친 npm 토큰으로 피해자가 관리하는 패키지를 다시 감염시키는 방식으로 500개가 넘는 패키지에 퍼졌습니다. 이후 2025-11 Shai-Hulud 2.0과 2026년 상반기의 여러 변종을 거쳐 2026-08-04 ChainDrop으로 이어졌습니다. ChainDrop은 npm 토큰이 아니라 메인테이너의 GitHub 계정을 침해해 정상 릴리스 워크플로를 실행시켰습니다. 그래서 악성 버전이 유효한 SLSA 출처 증명을 달고 게시됐습니다.

영향 범위 주간 다운로드가 1억 회를 넘는 keyv, flat-cache, file-entry-cache 를 시작점으로 네 시간이 채 안 되는 사이에 444개 패키지, 2,212개 버전이 오염됐습니다. 탈취 대상은 CI 러너 메모리의 시크릿과 AWS, Kubernetes, Vault 자격증명이었습니다.

교훈 이 사례에서 특히 볼 부분은 지속성 확보 방식입니다. ChainDrop의 페이로드는 침해한 저장소에 Claude Code 설정 파일(.claude/settings.json)의 SessionStart 훅과 VS Code .vscode/tasks.json 의 폴더 열기 작업을 심었습니다. 개발자가 그 저장소를 열기만 해도 다시 실행됩니다. AI 코딩 도구의 설정 파일이 곧 실행 경로라는 뜻이므로, 저장소에서 받은 설정 파일은 소스 코드와 같은 수준으로 검토해야 합니다. 또한 출처 증명이 붙어 있다는 사실만으로는 안전을 보장하지 못합니다. 침해된 파이프라인은 정상 절차로 증명을 발급하고, 받는 쪽에서는 구분되지 않습니다.

공격 축이 어디로 옮겨 갔는가

앞의 세 사례에서 공격자는 소스 코드나 메인테이너의 신뢰를 노렸습니다. 2025년 이후 사례에서는 배포 권한을 쥔 계정과 빌드 파이프라인을 노립니다. 라이브러리 소스를 고치지 않아도 게시 워크플로 하나를 장악하면 정상 배포와 구분되지 않는 악성 버전을 내보낼 수 있기 때문입니다. 따라서 오픈소스 컴포넌트 목록을 관리하는 것만으로는 부족하고, 그 컴포넌트를 가져와 빌드하는 파이프라인 자체를 통제 대상에 넣어야 합니다. 구체적인 방법은 파이프라인 자체 보안과 빌드 출처에서 다룹니다.

4. 국제 규제 동향

공급망 보안은 이제 자율적 모범 사례를 넘어 법적 요구사항이 되고 있습니다.

미국 행정명령 EO 14028 (2021)

배경 SolarWinds, Microsoft Exchange 등 잇따른 대형 공급망 공격에 대응하여 바이든 행정부가 2021년 5월 서명한 사이버보안 강화 행정명령입니다.

핵심 내용과 이후 변화

연방정부 납품 소프트웨어에 대한 SBOM 제공 지침 수립을 지시했고, NTIA(미국 통신정보관리청)의 SBOM 최소 요소 기준이 이때 정의됐습니다.
다만 이후 행정부 방침이 바뀌었습니다. EO 14306(2025-06)이 SBOM 산출물 요구 조항을 삭제했고, OMB M-26-05(2026-02)로 일괄 증명 의무가 폐지되어 현재는 기관별 위험 기반 판단으로 운영됩니다.
최소 요소 기준 자체는 2026-07 에 갱신됐습니다. CISA·NSA·FBI 와 한국을 포함한 국제 파트너 기관이 발표한 2026 Minimum Elements for a SBOM 이 NTIA 2021 기준을 대체했고, 컴포넌트 해시와 라이선스가 필수 필드가 됐습니다.

한국 기업 영향 미국 연방 조달의 일괄 SBOM 의무는 완화됐지만, 최소 요소 기준은 CISA 2026 판으로 이어지며 사실상 표준 역할을 계속합니다. 실질적인 SBOM 제출 요구는 EU CRA와 고객사 조달 계약에서 옵니다. 미국 시장에서 활동하는 기업은 계약 단위 요구에 대비하는 것이 현실적입니다.

EU Cyber Resilience Act - CRA (2024)

배경 EU 디지털 단일 시장에 출시되는 디지털 제품의 사이버보안을 강화하기 위해 2024년 채택된 EU 전체 적용 규정입니다.

핵심 요구사항

EU 시장에 출시하는 디지털 제품(소프트웨어 포함)에 보안 요구사항 적용
오픈소스 컴포넌트 목록 관리 및 취약점 대응 의무화
적극 악용 취약점과 중대 인시던트 보고 의무는 2026-09-11부터 먼저 적용되고, 본질적 요구사항의 전면 적용은 2027-12-11 입니다.

제재 불이행 시 최대 1,500만 유로 또는 전 세계 연간 매출의 2.5% 중 큰 금액 적용.

한국 기업 영향 EU에 소프트웨어 제품이나 서비스를 판매하는 모든 기업이 해당됩니다. 클라우드 서비스, 모바일 앱, IoT 기기 등 디지털 요소가 있는 제품은 모두 적용 대상입니다.

국내 동향

국내 정책은 권고 성격의 가이드라인에서 시작해 시행 일정을 갖춘 로드맵 단계로 넘어왔습니다.

SW 공급망 보안 가이드라인 1.0 (2024-05-13) 과학기술정보통신부, 국가정보원, 디지털플랫폼정부위원회가 함께 발표하고 KISA가 배포한 문서입니다. 정부기관, 공공기관, 기업이 각자 SW 공급망 보안 관리 역량을 갖추도록 돕는 것을 목적으로 하며, 미국과 유럽의 SBOM 제출 요구 흐름을 배경으로 제시합니다. 전체본과 요약본이 있고, 2024-09-12에 영문과 스페인어 요약본이 추가됐습니다.

SW 공급망 보안 단계별 이행안 (2026-06-24) 과학기술정보통신부가 "정부, 소프트웨어(SW) 공급망 보안 단계별 이행안(로드맵) 발표"라는 제목으로 공개했고, 국가정보원과 KISA가 함께 참여했습니다. "안전하고 책임 있는 공급망 보안 체계의 전환을 통한 사이버 복원력 확보"를 목표로 내걸고 아래 세 가지 추진 전략을 둡니다.

추진 전략	내용
공급망 위협 예방 역량 강화	공급망에 위협이 들어오기 전 단계의 관리 역량 확보
신속한 탐지 대응 체계 마련	침해가 발생했을 때의 탐지와 대응 절차 정비
정책 제도적 기반 조성	제도와 지원 체계 마련

세부 과제는 원문 확인이 필요합니다

세 전략 아래의 세부 과제와 연도별 시행 일정은 첨부 문서에 들어 있습니다. 공공 조달에서 SBOM 제출이 언제부터 어떤 범위로 요구되는지는 원문을 직접 확인하세요. KISA 가이드라인 자료실에서 두 문서를 모두 내려받을 수 있습니다.

한국 기업 영향 아직 EU CRA 같은 처벌 조항이 있는 법적 의무는 아닙니다. 다만 공공 사업 발주 요구사항과 대기업 협력사 요구사항이 로드맵을 따라 움직이므로, SBOM 생성과 취약점 대응 체계를 미리 갖춰 두는 편이 유리합니다.

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. 내 조직의 공급망 위험 평가하기

사례와 규제를 알았다면, 다음 질문은 "그래서 우리 조직은 얼마나 위험한가"입니다. 아래는 도구가 없어도 시작할 수 있는 간단한 평가 틀입니다.

4가지 평가 축

각 오픈소스 컴포넌트(또는 제품 전체)를 아래 4가지로 가늠합니다. 높을수록 위험이 큽니다.

평가 축	핵심 질문	위험이 큰 경우
의존성 깊이	직접 가져다 썼나, 그 라이브러리가 또 끌어온 것(전이 의존)인가	보이지 않는 전이 의존 비중이 높을 때
노출면	외부 입력을 직접 처리하나(파서·네트워크·역직렬화)	외부 입력을 처리할 때
프로젝트 건강성	메인테이너가 활동 중인가, 최근 릴리스·기여자가 있나	방치된 프로젝트일 때(XZ Utils 교훈)
영향 범위	뚫리면 어디까지 닿나(인증·결제·고객 데이터)	핵심 자산에 접근할 때

의존성 깊이 — 가장 자주 놓치는 위험

직접 가져다 쓴 라이브러리(직접 의존)는 눈에 띄지만, 그 라이브러리가 다시 끌어오는 전이 의존(transitive dependency — 의존의 의존) 은 보이지 않습니다. Log4Shell·XZ Utils 모두 많은 조직에서 "내가 직접 쓴 적 없는데?"였습니다. SBOM은 이 전이 의존까지 모두 펼쳐 보여주므로, 위험 평가의 출발점입니다.

3단계 평가 절차

목록 확보 — SBOM으로 전이 의존까지 포함한 컴포넌트 목록을 만듭니다(SBOM 생성).
고위험 식별 — 위 4축으로 각 컴포넌트를 상·중·하로 나눠 고위험을 추립니다.
우선 적용 — 고위험부터 정책(허용 라이선스와 승인), 취약점 대응, 지속 모니터링을 먼저 적용합니다.

정기 점검

이 평가는 한 번으로 끝나지 않습니다. 의존성과 위협은 계속 바뀌므로, 정기적으로 다시 점검합니다.

7. 셀프 스터디

셀프스터디 모드 (약 1시간)

이 챕터는 읽기만 해도 됩니다. 개념 이해에 집중하세요.

이 문서 읽기 — 공급망 보안 전체 맥락 파악
사고 사례의 핵심 교훈을 자신의 언어로 정리
국제 규제 중 자사에 해당하는 항목 확인
sbom-101.md 읽기 → SBOM 기술 개념 상세 이해

8. 완료 확인 체크리스트

공급망 보안 사고(SolarWinds, Log4Shell, XZ Utils, tj-actions, ChainDrop)를 설명할 수 있다
공격 축이 메인테이너 신뢰에서 자격증명과 빌드 파이프라인으로 옮겨 간 이유를 설명할 수 있다
SBOM이 왜 필요한지 이해했다
EO 14028 / EU CRA / 국내 SW 공급망 보안 단계별 이행안이 자사에 미치는 영향을 파악했다
두 표준이 공급망 보안에서 담당하는 역할을 이해했다
4가지 평가 축으로 우리 조직의 고위험 컴포넌트를 가늠할 수 있다

9. 다음 단계

SBOM 기술 개념 학습: sbom-101.md 로 이동하여 CycloneDX, SPDX 포맷과 SBOM 최소 요소를 학습합니다
환경 준비로 바로 이동: docs/01-setup/ 으로 이동하여 툴체인 설치를 시작합니다

개념 이해를 충분히 했다면 docs/01-setup/ 부터 실습을 시작해도 좋습니다. 이 챕터는 언제든지 다시 돌아와서 참고할 수 있습니다.