공급망 취약점: 위험, 영향 및 완화 방안

이 블로그 글의 AI 요약으로 바로 가기

주요 내용

공급망의 취약점은 여러분이 의존하는 패키지, 레지스트리 및 빌드 시스템에서 비롯됩니다.
ChainDrop은 2026년 8월, 어떤 npm 패키지의 취약점도 악용하지 않은 채 최소 444개의 npm 패키지를 공격했습니다.
OWASP는 Endor Labs의 연구 결과를 인용하여 전이적 종속성 내 취약점의 약 95%라고 밝혔다.

대부분의 팀은 자사 애플리케이션이 어떤 프레임워크와 주요 라이브러리를 기반으로 구축되었는지 줄줄이 읊을 수 있습니다. 하지만 그 라이브러리들이 뒤에서 조용히 불러오는 패키지들에 대해서도 똑같이 설명할 수 있는 팀은 훨씬 적으며, 이러한 격차는 소프트웨어 공급망 보안에서 가장 큰 사각지대 중 하나입니다. 이 가이드에서는 위험이 어디에 숨어 있는지, 그로 인한 비용이 얼마나 드는지, 그리고 다른 누군가보다 먼저 이를 포착하는 방법을 다룹니다.

공급망 취약점이란 무엇인가?

공급망 취약점이란, 귀사의 비즈니스가 의존하는 공급업체, 벤더, 소프트웨어 및 물류 네트워크 내의 모든 약점을 말하며, 이는 업무 중단, 손실 또는 보안 침해로 이어질 수 있습니다. 이러한 취약점은 벤더 측에 있을 수도 있고, 귀사가 한 번도 접촉해 본 적 없는 유지보수 담당자에게 있을 수도 있으며, 심지어 귀사의 자체 빌드 서버에 있을 수도 있습니다. 어느 쪽이든, 그 여파를 감당해야 하는 것은 바로 귀사입니다.

소프트웨어 분야에서 이러한 네트워크는 대부분의 의존성 그래프가 시사하는 것보다 훨씬 더 광범위합니다. 여기에는 타사 패키지, 빌드 도구, 소스 저장소, 패키지 레지스트리, CI/CD 파이프라인, 서명 인프라, 그리고 이 모든 것을 유지 관리하는 모든 사람이 포함됩니다.

서로 겹치는 두 가지 범주를 구분해 볼 필요가 있습니다. 운영상의 취약점은 단일 지점(예: 한 공장과 같은)이 고장 났을 때 이를 대체할 백업 수단이 없어 발생하는 문제입니다. 즉, 한 공장이든, 한 해운 노선이든, 한 클라우드 리전이든, 해당 인프라가 중단될 경우 의지할 대안이 전혀 없는 상황을 말합니다. 반면 보안상의 취약점은 전혀 다른 문제입니다. 여기서의 문제는 실제 취약점 그 자체이며, 이는 파트너사의 방어 체계에 존재하는 허점이든, 직접 작성하지는 않았지만 여전히 실행 중인 코드에 내재된 결함이든 상관없이 해당됩니다.

이 가이드의 나머지 부분에서는 두 번째 범주, 특히 오픈 소스 소프트웨어에 초점을 맞출 것입니다. 이 분야에서는 긴 의존성 체인, 공개 레지스트리, 자원봉사자 유지보수 등으로 인해 위험 노출 범위가 빠르게 변화합니다.

공급망 취약점의 일반적인 유형

오픈소스 공급망 사고의 상당 부분은 네 가지 반복되는 패턴에서 기인합니다.

1. 해킹당한 관리자 계정

도난당한 인증 정보나 해킹당한 계정을 이용하면, 해당 패키지의 원래 코드에 있는 결함을 악용하지 않고도 신뢰할 수 있는 패키지에 악성 코드를 삽입할 수 있습니다. axios npm 침해 사건 사건이 이를 잘 보여주는 사례입니다. 정식 관리자의 계정, 겉보기에는 정상적인 릴리스, 그리고 npm이 침해된 버전을 삭제하기 전까지 약 3시간 동안 숨어 있던 원격 접속 트로이목마가 바로 그것입니다.

2. 타이포스쿼팅 및 네임스페이스 유사 도메인

패키지 검토는 라벨에 표시된 좌표나 발행자보다는 패키지 내부의 코드에 초점을 맞추는 경향이 있기 때문에, 실제 이름과 한 글자만 다른 이름도 계속 작동하는 것입니다. Maven Central에 올라온 가짜 Jackson 라이브러리는 는 정식 패키지인 com.fasterxml.jackson.core 대신 org.fasterxml.jackson.core라는 이름으로 배포되었는데, 접두사 하나만 바뀐 이 이름은 언뜻 보기에는 정품처럼 보입니다. 저희가 분석한 npm install에서의 타이포스쿼팅 에 대한 분석에서는, 누구도 눈치채기 전에 얼마나 설득력 있는 유사 이름이 널리 퍼질 수 있는지를 다루고 있습니다.

3. 빌드 시 및 설치 시 실행

빌드를 손상시키기 위해 패키지가 애플리케이션 코드를 직접 건드릴 필요는 없습니다. 다음 두 가지 모두 애플리케이션이 실행되기 전에 실행됩니다. 인터프리터 시작 시 실행되는 악성 Python .pth 파일과, Cargo의 빌드 과정에서 실행되는 Rust build.rs 스크립트입니다. Hades 캠페인은 은 시작 후크를 통해 공격을 수행했습니다. 2026년 8월 arrayref 침해 사건사건에서는, 크레이트가 ‘proc-macro1’이라는 타이포스쿼팅된 종속성을 포함했는데, 이 종속성의 빌드 스크립트가 cargo build 실행 중에 페이로드를 가져와 실행했습니다.

4. 기본적으로 신뢰를 전제로 하는 유통 채널

레지스트리들은 속도를 위해 일부 검증 절차를 희생하는데, 공격자들은 그 타협점이 정확히 어디에 있는지 파악해 냈습니다. Go 모듈 프록시 는 버전이 한 번 확인되면 캐시된 사본을 보관하는데, 이것이 바로 백도어가 심어진 github.com/boltdb-go/bolt 모듈이 업스트림 저장소가 정리된 후에도 3년 넘게 재현 가능하게 이용 가능했던 이유입니다. Packagist는 과거에 안정 버전이 이동된 Git 태그를 따르도록 허용했는데, 바로 이 때문에 Laravel-Lang 공격자들이 700개 이상의 과거 버전을 재작성할 수 있게 했으며 할 수 있었습니다. 이후 Packagist는 공개된 안정 버전에 대해 버전과 커밋 간의 참조를 불변으로 변경했기 때문에, 태그를 다시 지정한다고 해도 릴리스가 가리키는 대상이 더 이상 은밀하게 변경될 수 없게 되었습니다.

모든 공급망 취약점이 반드시 공격자를 필요로 하는 것은 아닙니다. Log4Shell 은 수많은 의존성 트리에서 여러 계층 깊숙이 묻혀 있던 라이브러리의 결함이었으며, 바로 그 깊이 때문에 수많은 팀이 자신들이 영향을 받았는지조차 파악하는 데 며칠을 소비해야 했습니다.

알고 계셨나요? 그 ChainDrop으로 알려진 npm 웜는 Shai-Hulud 계열의 변종인데, 이 웜 역시 소프트웨어 결함을 이용할 필요가 없었습니다. 2026년 8월 4일, 한 공격자가 유지보수자의 GitHub 계정에 침입하여 keyv 및 cacheable 저장소에 악성 커밋을 푸시했습니다. 해당 프로젝트의 자체 릴리스 워크플로가 감염된 버전을 빌드하고 배포했기 때문에, 첫 번째 공격 물결은 정당한 출처 증명을 갖춘 상태로 npm에 유입되었습니다. 이후 웜은 도난당한 게시 토큰을 이용해 확산되었으며, 총 444개의 패키지 이름에 도달했고, 이들의 월간 다운로드 수는 합계 20억 건에 달했습니다. 게시자의 신원, 서명, 버전 번호만을 확인하는 제어 방식으로는 이를 차단할 방법이 없습니다.

공급망의 취약점이 기업에 미치는 영향

공급망 취약점으로 인한 비용은 단순히 해당 사고 자체에 그치는 경우가 거의 없습니다. 수 주간 이어지는 조사, 운영 중단 기간 동안 발생한 매출 손실, 그리고 몇 달 뒤에 드러나는 감사 결과까지 모두 고려해야 합니다. 상호 의존 관계를 체계적으로 파악하고 대응 계획을 사전에 시뮬레이션해 두면, 위험 요소를 파악하고 확산을 차단하는 데 소요되는 시간을 단축할 수 있으며, 바로 이 과정에서 비용의 대부분이 눈에 띄지 않게 누적됩니다.

1. 직접적인 금전적 손실

명백한 비용 항목으로는 가동 중단 기간 동안의 매출 손실, 사고 대응 리테이너 비용, 영향을 받은 모든 빌드에 대한 긴급 복구 비용, 그리고 규제 당국의 과징금 등이 있습니다. 대략적인 규모를 살펴보면, 2026년 버라이즌 DBIR 보고서에 따르면 몸값 지불액의 중앙값을 139,875달러로로 제시했으나, 이는 버라이즌의 데이터셋에서 도출된 랜섬웨어 관련 수치일 뿐, 공급망 사고로 인한 비용을 측정하는 지표는 아닙니다. 실제 비용은 노출 기간, 재구축이 필요한 아티팩트의 수, 그리고 데이터가 외부로 유출되었는지 여부에 따라 달라집니다.

2. 운영 중단 시간

보안 문제가 있는 종속성이 프로덕션 환경에 유입된 경우, 해당 종속성을 안전한 버전으로 교체하는 것은 대개 시작에 불과합니다. 문제가 있는 패키지가 포함된 모든 아티팩트를 식별하고, 재빌드한 뒤 다시 배포해야 하는데, 그 목록은 팀이 예상하는 것보다 훨씬 긴 경우가 많습니다.

3. 데이터 유출 및 법적 위험

커뮤니티에서 관리하는 패키지의 경우, 문제가 발생했을 때 책임을 규정한 공급업체 계약이 없는 경우가 많습니다. 널리 사용되는 많은 오픈소스 라이선스는 보증을 부인하고 책임을 제한하기 때문에, 협상을 통해 체결된 상용 지원 계약에 비해 구제 수단이 더 적을 수 있습니다. 취약점이 있는 코드가 애초에 귀사의 것이 아니었다고 해서 귀사의 규제상 의무가 사라지는 것은 아닙니다.

4. 평판 훼손

고객과 언론인들은 문제가 누구의 코드에서 비롯되었는지에 대해서는 그다지 신경 쓰지 않고, 시스템이 침해당했다는 사실 자체에 더 큰 관심을 기울이는 경향이 있습니다. 특히 이 사건이 단순한 운의 문제가 아니라 보안 통제 체계의 문제로 비춰질 경우, 평판에 미치는 영향은 기술적 복구 작업이 끝난 후에도 훨씬 더 오랫동안 지속될 수 있습니다.

5. 규정 준수 및 감사 미비

프레임워크와 감사 범위에 따라, 패치가 적용되지 않은 구성 요소나 평가되지 않은 종속성은 실제로 악용된 사례가 없더라도 문제점으로 지적될 수 있습니다. 오래된 암호화 라이브러리가 대표적인 예이며, 각 문제점마다 수정 시간이 소요될 뿐만 아니라 관련 모든 요소에 대한 감사관의 면밀한 검토가 필요합니다. 다음 가이드를 참조하십시오. OpenSSL 보안가이드를 참조하십시오.

현실 점검: 공급업체 계약서에 SOC 2를 명시한다고 해서 그 자체로 큰 의미가 있는 것은 아닙니다. A SOC 2 보고서 은 타입 I의 경우 특정 시점의 통제 설계, 타입 II의 경우 명시된 기간 동안의 운영 효과성을 다루므로, 실제 보고서와 그 범위, 기간, 예외 사항을 꼼꼼히 살펴봐야 합니다. 하지만 그런 검토만으로는 공급업체가 지난주 발견된 중대한 CVE에 대한 패치를 적용했는지 여부를 알 수 없습니다.

공급망 취약점을 파악하는 방법

공급망 취약점 탐지는 화려하지는 않지만, 바로 그 과정에서 진정한 성과가 나타납니다. Log4Shell 사태가 이를 잘 보여줬습니다. 최신 의존성 목록을 보유하고 있던 팀들은 다른 팀들이 사고 발생 중에야 겨우 목록을 재구성하고 있을 때 이미 노출 여부를 파악할 수 있었습니다. 사고 발생 시가 아니라 평범한 화요일에 이 작업을 수행하십시오.

1. 종속성 목록을 구축하고 계층화하기

누군가가 의도적으로 추가한 패키지뿐만 아니라, 애플리케이션이 직접적으로나 간접적으로 불러오는 모든 오픈소스 패키지를 나열하십시오. 그런 다음, 내일 어느 하나가 악의적인 행위를 할 경우 어떤 문제가 발생하는지에 따라 중요도 순으로 분류하십시오. package.json이나 requirements.txt에 명시된 내용만 확인하는 목록은 해당 파일 아래에 숨겨진 모든 패키지를 놓치게 되며, 바로 그 패키지들이 절대 간과해서는 안 될 것들입니다.

2. 소프트웨어 BOM 생성

빌드하는 모든 애플리케이션에 대해 SBOM 을 생성하고 아티팩트와 함께 저장하십시오. 단순히 실행만 하는 타사 소프트웨어의 경우, 공급업체로부터 이에 상응하는 구성 요소 목록을 확보하십시오. 의존성 가시성 측면에서 이는 이 목록에서 가장 가치가 높은 통제 수단 중 하나입니다. 최신의 정확한 SBOM이 있다면 “이 구성 요소가 어디에서 실행되고 있는가?”라는 질문을 수동으로 일일이 찾아보는 작업에서 검색 가능한 쿼리로 바꿔줍니다. 물론 최종 답변을 얻기 위해서는 여전히 배포 데이터와 취약점 정보가 필요하지만요. SBOM이 없다면, 팀은 압박 속에서 락파일, 빌드 기록, 실제 시스템을 일일이 대조해야 하는 상황에 처하게 됩니다.

3. 단일 고장 지점 파악

중요한 종속성 하나하나에 대해 직설적인 질문을 던져보세요. 만약 오늘 이 패키지가 사라지거나 악성 코드로 변한다면, 대안은 무엇이며 전환하는 데 얼마나 걸릴까요? 이에 대한 답을 찾을 수 없는 것은, 공식적으로 ‘단일 고장 지점(single point of failure)’으로 지정되었는지 여부와 상관없이 사실상 단일 고장 지점입니다. 라이브러리 자체는 물론, 이를 관리하는 유지보수자 계정, 그리고 패키지를 가져오는 레지스트리에 대해서도 이 과정을 반복해 보세요.

4. 패키지 및 관리자의 상태 평가

대부분의 오픈소스 종속성에는 설문지를 보낼 공급업체가 없기 때문에, 증거는 해당 패키지와 이를 둘러싼 프로젝트에서 찾아야 합니다. 즉, 공개 이력, 유지보수자 수, 과거 CVE에 대한 패치 속도, 릴리스에 출처 정보가 포함되어 있는지 여부 등을 살펴봐야 합니다. 눈에 띄는 활동이 없는 단일 유지보수자에게만 의존하고 있는 중요한 패키지는 면밀히 살펴볼 필요가 있지만, 활동이 없는 것이 단순히 코드가 완성되었음을 의미할 수도 있다는 점을 염두에 두어야 합니다.

5. 실패를 미리 연습해 보세요

두 가지 일반적인 시나리오, 즉 유지보수 담당자 계정이 해킹당하는 경우와 널리 사용되는 라이브러리에서 현재 활발히 악용되고 있는 CVE가 공개되는 경우에 대해 탁상 시뮬레이션을 진행해 보세요. 기본적인 질문에 답하는 데 걸리는 시간을 측정해 보세요. 대개 드러나는 문제는 자산 목록, 소유권, 의사결정 권한에 대한 공백이며, 아무리 새로운 도구를 도입한다고 해도 이러한 문제들은 그 자체만으로는 해결되지 않습니다.

전문가 팁: 오픈 소스 구성 요소에 대해 유료 상업적 지원을 받는 경우, 계약서에 패치 SLA와 침해 사고 통지 기간을 구체적으로 명시하십시오. “최선의 노력(Best effort)”은 수치로 측정할 수 있는 것이 아니며, 무보수 유지보수자가 있는 경우 계약상 패치 SLA가 전혀 보장되지 않습니다.

공급망 취약성 완화 전략

유전적으로 물려받은 위험은 없앨 수 없으므로, 실제로 통제할 수 있는 부분, 즉 보안 침해 발생 가능성, 침해로 인해 발생할 수 있는 피해 규모, 그리고 대응 속도 등에 초점을 맞추어야 합니다. 아래의 다섯 가지 사항은 시작하기에 합리적인 지침이 될 것입니다.

1. 패치 적용 시간 단축

의존성에서 공개된 취약점의 경우, 수정 조치를 미룰수록 노출 위험이 커지므로 가능한 한 패치 작업을 자동화해야 합니다. 악의적인 배포나 계정 탈취는 대응해야 할 공개 정보가 없다는 점에서 다른 유형의 문제이지만, 추가 설치가 발생할 때마다 피해 범위가 확대되므로 신속한 대응이 여전히 중요합니다. EOL(지원 종료) 구성 요소, 고정된 의존성 버전, 변경 관리가 적용되는 시스템 등 즉시 패치를 적용할 수 없는 경우에는, 가상 패치 은 제어 체계가 실제로 차단할 수 있는 공격 경로가 존재할 때 시간을 벌어줍니다. 지원이 중단된 패키지의 경우, 자체 환경에서 패치를 검증하는 전제 하에 공급업체가 지원하는 패치를 통해 지속 가능한 해결 방안을 마련할 수 있습니다.

2. 대체 도서관을 사전에 선정한다

빌드 과정에서 실제로 한 번도 실행해 본 적이 없는 대체 의존성은 진정한 대체 수단이 아닙니다. 압박을 받으며 어쩔 수 없이 알아내야 하는 상황이 오기 전에, 어떤 핵심 라이브러리에 생산 환경에 바로 적용할 수 있는 대안이 있는지, 또 어떤 라이브러리에는 대안이 없는지 미리 파악해 두십시오.

3. 보안이 침해된 패키지가 접근할 수 있는 범위를 제한하기

모든 종속성이 언젠가는 침해될 수 있다는 전제 하에 설계하십시오. 즉, CI에서는 최소 권한 원칙을 적용하고, 샌드박스화된 빌드 환경을 구축하며, 설치 스크립트는 기본적으로 제한을 두고, 필요하지 않은 파이프라인에는 장기 유효한 게시 토큰을 남겨두지 말아야 합니다. 특히 마지막 항목은 반드시 지켜야 합니다.

세분화와 유효 기간이 짧은 인증 정보는 침해된 패키지가 확산될 수 있는 범위를 제한하고, 전체 빌드 인프라 전반에 걸쳐 인증 정보가 유출될 가능성을 줄여줍니다.

4. 빌드에 포함되는 내용을 확인하세요

락파일(lockfile)을 사용하고, 중요한 종속성 버전을 고정하며, 생태계에서 지원하는 경우 아티팩트 해시를 확인하십시오. 보안 패치 버전이 출시되면 해당 고정 버전을 신속하게 갱신할 수 있는 절차를 마련해 두십시오. 오래된 고정 버전은 그 자체로 문제가 되기 때문입니다. CI 및 리포지토리 자동화 구성을 실행 가능한 코드로 취급하십시오. 실제로 그렇게 작동하기 때문입니다.

하지만 한계를 알아두는 것도 좋습니다. 2026년 5월 발생한 TanStack npm 침해 사건은 사건으로 인해, 연구진들은 프로젝트 자체 릴리스 워크플로우를 통해 직접 배포된, 암호학적으로 유효한 출처 증명서를 포함하는 최초의 악성 npm 패키지가 확인되었다고 밝혔습니다. 8월에 발생한 ChainDrop의 첫 번째 공격도 동일한 방식을 사용했습니다. 출처 증명서는 아티팩트가 어디서, 어떻게 빌드되었는지를 증명할 뿐, 해당 아티팩트가 무해한지 여부는 알려주지 않습니다. 이를 빌드 파이프라인 모니터링 및 기타 보안 개발 관행과 함께 활용해야 합니다.

5. 업스트림 중단 후 패치 계획 수립

유지보수자가 손을 뗀다고 해서 버려진 패키지가 빌드에 계속 포함되는 것을 막을 수는 없습니다. 어떤 종속성이 이미 유지보수가 중단되었는지 파악하고, 포크, 대체 패키지, 소스 패치 등 어떤 방식이든 미리 계획을 세워 두어야 합니다. 그렇지 않으면 해당 종속성 중 하나에 패치되지 않은 CVE가 발생하여 어쩔 수 없이 결정을 내려야 하는 상황에 처할 수 있습니다.

TuxCare로 공급망 취약점을 보완하세요

오픈 소스 위험은 취약한 코드, 보안이 침해된 배포자, 빌드 무결성, 전이적 의존성, 그리고 이러한 문제들에 대한 패치 적용 속도 등 매우 광범위한 영역을 포괄합니다. 출처와 무결성을 검증하는 것은 여러 통제 수단 중 하나이며, 패치 관리, 빌드 보안, 최소 권한 원칙, 그리고 실제로 시뮬레이션해 본 대응 계획과 함께 시행할 때 가장 효과적입니다. 만약 팀에서 더 이상 업스트림에서 적시에 수정 패치를 제공받지 못하는 의존성을 사용 중이거나, 패키지가 검증된 소스 코드로부터 재빌드되었는지 확인할 방법이 없다면, 오픈 소스 소프트웨어용 SecureChain 는 설치 시 패키지를 검사하고, 소스 코드로부터 재빌드하며, 업스트림 지원이 중단된 후에도 JavaScript, Python, Java, Go, Rust, PHP 전반에 걸쳐 지속적으로 패치를 적용합니다. 배포는 생태계별로 순차적으로 진행되므로, 특정 생태계의 현재 상태를 정확히 알고 싶으시면 [email protected]으로 이메일을 보내주십시오.

이러한 위험의 상당 부분은 팀이 의도적으로 설치한 것들 아래에 숨어 있습니다. 전이적 의존성에 묻혀 있는 CVE가 어떻게 프로덕션 환경에 도달하는지 자세히 알아보려면 “프로덕션을 침몰시킬 수 있는 의존성 빙산을 피하는 방법”를 시청해 보세요.

요약