2026년 소프트웨어 공급망이 붕괴되었으며, 통계 수치가 이를 입증하고 있다

주요 내용

• 2026년 3월부터 7월 사이에 npm, PyPI, Go 모듈 및 Packagist를 대상으로 한 6건의 확인된 공급망 공격이 발생했다.
• 그들 중 누구도 다른 사람의 애플리케이션 코드에 버그가 있을 필요는 없었고, 배포 과정 중 단 한 단계만 신뢰할 수 있으면 충분했다.
• 6건 중 3건은 불과 몇 시간 만에 처리되었는데, 이는 대부분의 스캔 일정보다 더 빠른 속도입니다.
• 설치 후 탐지 기능은 현재 팀들이 겪고 있는 공격보다 속도가 더 느린 공격을 대상으로 설계되었습니다.

올해 가장 신속하게 진행된 두 건의 공격 사례는 공격자가 얼마나 짧은 시간만으로도 공격을 감행할 수 있는지 보여줍니다. 3월 31일, 두 개의 악성 Axios 릴리스가 npm에 약 3시간 동안 방치된 채로 있다가 누군가에 의해 삭제되었습니다. Mastra 해킹 사건은 그보다 훨씬 더 빠르게 진행되어, 약 88분 만에 140개 이상의 패키지를 재게시했습니다 재게시했습니다. 마이크로소프트는 두 사건 모두 ‘Sapphire Sleet’의 소행으로 지목한 반면, 구글은 axios 침해 사건을 현재 ‘Midnight Neptune’이라 부르는 북한 해커 집단과 연관 지었으며, 이전 명칭은 UNC1069로 지칭하는 북한 해커 집단과 연관 지었습니다. 두 사건 모두 악성 버전이 사용자에게 도달하기 전에 차단되지 않았으며, 어느 경우에도 누구도 패키지의 소스 코드를 수정하지 않았습니다. 공격자는 package.json에 단 하나의 종속성을 추가한 뒤, 나머지는 npm install이 처리하도록 내버려 두었습니다.

기존의 CVE 중심 SCA 및 SBOM 워크플로 는 두 가지 모두를 차단하도록 설계된 적이 없습니다. 결정적인 순간에 대조할 대상이 없었기 때문입니다. 두 창이 열리고 닫히는 데 걸린 시간은 수많은 야간 빌드가 완료되는 데 걸리는 시간보다도 더 짧았습니다.

지금까지 2026년의 양상은 이렇습니다. 몇 달이 지나도 여전히 논란의 대상이 되는 거대한 침해 사고는 하나도 없었지만, 짧고 빠르며 능숙하게 수행된 공격 캠페인이 공공 등록부를 차례로 공략해 온 반면, 대부분의 방어 체계는 이미 발생한 사고를 보고하기 위해 처리 과정의 맨 끝에서 대기하고 있는 실정입니다.

2025년과 2026년 사이에 무엇이 달라졌는가

날짜를 나열해 보면 그 양상이 뚜렷하게 드러납니다. 2026년 3월부터 7월까지 5개월 동안 4개 생태계에서 총 6건의 공격 캠페인이 확인되었습니다. 이는 한 달에 약 한 건씩, 독립적으로 확인된 주요 공격 캠페인이 발생한 셈이며, 그중 몇 건은 특정 위협 행위자의 이름이 밝혀지기도 했습니다.

그리고 더 광범위한 위협 데이터를 보면, 이번 사건이 단순히 한두 차례의 이례적으로 심각한 사태에 그친 것이 아님을 알 수 있습니다. Wiz의 2026년 상반기 클라우드 위협 보고서 에 따르면, 고객에게 보고된 중대한 사고 건수가 2025년 하반기 대비 60% 증가해 추적 기간 중 최고치를 기록했으며, 이 중 공급망 공격이 차지하는 비중은 전체 사고의 약 10%에서 25%로 상승했습니다. Wiz는 레지스트리 상태 관리가 아닌 클라우드 사고 건수를 집계하므로, 이는 특정 벤더가 자체 가설을 입증하는 것이 아니라 해당 추세를 외부에서 검증한 결과로 볼 수 있습니다. 구글의 위협 인텔리전스 그룹(Threat Intelligence Group) 는 2025년과 2026년 초에 걸쳐 발생한 초대규모 오픈소스 공급망 캠페인의 증가가 탐지 능력의 향상보다는 해당 전술의 실질적인 확장을 반영한다고 높은 확신도로 평가하고 있으며, 인용된 OpenSSF 통계에 따르면 2024년부터 2025년 사이 식별된 악성 오픈소스 패키지의 증가율은 1,400%를 넘어선 것으로 나타났다.

각 캠페인의 지속 시간을 주목할 필요가 있습니다. Mastra는 약 88분 동안 활동했습니다. axios는 약 3시간 동안 지속되었습니다. 5가지 악성 jscrambler 변종은 대략 비슷한 기간 동안 유포되었습니다. 나머지 캠페인들은 이와는 정반대로, 몇 주 동안 조용히 활동했는데, 이는 오히려 더 심각한 문제라고 볼 수 있습니다. 매일 밤 정기적으로 위협을 탐지하도록 설계된 도구 입장에서는 이 범위의 양쪽 끝 모두 대응하기 까다로운 상황입니다.

현실 점검: 한 달에 한 번씩 캠페인이 진행된다고 해서 공격자 수가 그만큼 급증하는 것은 아닙니다. 자동화가 그 원인의 상당 부분을 설명해 주며, 2026년에는 이를 명확히 보여주는 사례가 있었습니다. TeamPCP는 5월 12일 GitHub에 Mini Shai-Hulud 웜의 전체 소스 코드를 공개했고, 그 도구 체인을 활용한 파생 캠페인이 몇 주 만에 등장했습니다. 패키지 공개는 스크립트로 자동화할 수 있고, 자격 증명 도용도 스크립트로 자동화할 수 있으며, 네임스페이스 사칭 역시 수년 전부터 스크립트로 자동화해 왔습니다.

또한 당사의 상세한 개요를 통해 슬롭스쿼팅과 AI 패키지의 환각 현상에 대해 더 자세히 알아보실 수 있습니다.

전형을 정립한 여섯 차례의 캠페인

아래에 소개된 6가지 사례는 패키지 수 기준으로 선정한 상위 6개가 아닙니다. 이는 도용된 인증 정보를 이용한 해킹(axios, jscrambler)부터 자가 전파형 웜, 휴면 계정의 재활성화, AI 검토자를 겨냥한 프롬프트 주입, 그리고 사회공학에 의한 계정 탈취에 이르기까지, 올해 발생한 다양한 사건들을 가장 잘 아우르는 6가지 사례입니다.

이 여섯 가지를 나열해 보면, 모두에 공통적으로 적용되는 한 가지 사실이 있습니다. 그 중 어느 하나도 피해자 자신의 코드에 존재하는 취약점을 필요로 하지 않았습니다. 모든 사례가 관리자의 키보드와 사용자의 설치 명령어 사이에서 발생하는 신뢰할 수 있는 단계를 악용했으며, 여섯 건 중 네 건에서는 그 단계가 정식 관리자 계정이었습니다.

axios와 Mastra 사이에 나타나는 공통된 출처 표기는 단순한 스타일상의 우연이 아닙니다. 마이크로소프트는 두 캠페인 모두에 동일한 제작진을 투입했기 때문에, 따라서 6개 중 적어도 2개는 서로 다른 두 팀이 우연히 같은 아이디어를 떠올린 것이 아니라, 한 그룹이 작품 간에 접근 방식을 다듬어 나간 결과입니다. ‘Hades’와 ‘Mini Shai-Hulud’ 역시 같은 계보를 공유합니다. 따라서 6개의 캠페인이라기보다는 4개의 뚜렷한 클러스터에 가깝다는 점을, 누군가 이를 6개의 독립적인 그룹으로 오해하기 전에 분명히 밝혀둘 필요가 있습니다.

하데스(Hades)는 잠시 주목해 볼 만한 사례입니다. 이 패키지는 LLM 기반 분석기가 이를 안전한 것으로 판정하도록 유도하기 위해 평문 프롬프트 주입을 포함하고 있었는데, 연구진은 이를 새로운 회피 기법이라고 설명했습니다. 이 전략은 공격자가 현재 패키지와 엔지니어 사이에 AI 도구가 존재한다고 가정할 때만 유효합니다. 2026년 중반쯤이면 이는 전혀 무리한 가정이 아닐 것입니다. 지난 12월 발생한 Maven Central 사례에서도 머신러닝 분석을 우회하기 위해 유사한 노이즈 기법이 사용된 바 있어, 이 기법은 수개월 동안 조용히 발전해 온 것으로 보입니다. 또한 하데스는 도난당한 GitHub 토큰이 취소될 경우 파괴적인 조치를 취하겠다고 위협하는 토큰 모니터를 실행했는데, 이는 문제를 해결하려는 사람의 작업 순서를 은밀하게 뒤바꾸는 역할을 합니다.

PolinRider는 또 다른 이유로 우려되는 대상입니다. 이는 버려진 도메인 이름을 기회주의적으로 가로챈 것이 아니었으며, 보고된 침입 경로는 자격 증명 유출보다 훨씬 더 기이합니다. 연구원들은 도난당한 GitHub 자격 증명이 침입 경로가 전혀 아니었다고 말합니다. 피해자들은 먼저 악성 VS Code 확장 프로그램이나 npm 패키지를 통해 침해당했으며, 이후 만료된 도메인이나 기타 계정 복구 경로를 통해 관리자 권한을 탈취당했는데, 이 모든 과정이 사회공학 기법으로 치밀하게 포장되어 있었습니다. 건전한 배포 관행만으로는 이러한 위험을 없앨 수 없습니다. 취약점은 릴리스 프로세스가 아니라 관리자의 도구 사용 및 계정 복구 절차에 있습니다.

이 글 뒷부분에서는 2026년과 관련된 두 건의 추가 공격 사례가 소개됩니다. TrapDoor는 npm, PyPI, Crates.io에 걸쳐 34개의 악성 패키지를 심었고, Laravel-Lang은 재작성된 Git 태그를 통해 700개 이상의 버전이 악성 코드로 변조되었습니다. TeamPCP는 사정이 다릅니다. ‘Mini Shai-Hulud’ 항목이 이미 TeamPCP로 분류되어 있기 때문에 별도의 항목이 없습니다. 구글이 UNC6780으로 추적하는 이 대규모 작전은 2월부터 5월까지 진행되었으며, 보안 도구 Trivy, Checkmarx 및 해당 KICS Docker 이미지, LiteLLM을 포함한 보안 도구에 대한 CI/CD 침해 공격을 연쇄적으로 연결하여, 장기간에 걸친 인증 정보 탈취 행각을 벌였습니다. 표의 한 행보다 더 큰 규모이지만, 작동 방식은 동일합니다.

공격 표면이 설치 시점으로 이동했다

2026년 한 해를 관통하는 핵심은 바로 ‘타이밍’입니다.

공격자들은 npm, PyPI, Cargo의 동일한 취약점을 세 가지 다른 방식으로 공략했으며, ‘TrapDoor’ 사례가 가장 대표적인 예시인데, 이는 한 캠페인이 이 세 가지를 모두 활용했기 때문입니다. npm의 설치 후 훅(postinstall hook), PyPI의 임포트 시 실행, 그리고 Crates.io에서 cargo build 실행 중에 작동하는 build.rs 스크립트가 바로 그것입니다. 트리거는 다르지만, 기본 원리는 동일합니다. 이 코드는 패키지를 사용하는 과정이 아니라, 패키지를 획득하는 과정에서 실행됩니다. PolinRider의 Go 측 구현은 방식이 또다시 다른데, 이는 페이로드가 설치 후크가 아닌 빌드 도구 설정 파일과 VS Code 작업에 포함되어 있기 때문입니다 에 포함되어 있어, `go get` 명령어가 실행될 때가 아니라 개발자의 툴이 프로젝트를 열 때 실행됩니다. 신뢰에 대한 악용 방식은 동일하지만, 파이프라인의 적용 시점은 다릅니다.

표준 툴링은 종속성이 표시된 시점과 해당 종속성이 실행되는 시점 사이에, 스캔이 먼저 문제를 포착할 수 있을 만큼 충분한 시간이 존재한다고 가정합니다. 설치 시 실행 방식은 종속성 해결 후 아티팩트만 검사하는 모든 경우에 대해 이러한 시간 간격을 제거합니다.

상당히 성숙한 파이프라인을 갖춘 40명 규모의 엔지니어링 조직을 상상해 보세요. Dependabot이 PR을 생성하면, SCA 도구가 락파일을 스캔하고, CI는 심각도가 높은 항목이 있으면 빌드를 차단하며, 빌드 시점에 SBOM이 생성됩니다. 이러한 설정은 알려진 취약점이 있는 종속성을 잘 처리합니다. 하지만 1시간 전에 공개된, 평범한 패치 버전 업데이트처럼 보이다가 설치 중에 실행되고 점심 시간 전에 철회되는 버전에 대해서는 거의 대응하지 못합니다. 해당 체인에서 일치할 만한 보안 권고 사항은 없었으며, axios와 Mastra 사례의 경우 페이로드는 스캐너가 두 번 확인할 이유가 없었던 종속성 내부, 한 단계 아래에 위치해 있었습니다.

주의: 정확한 버전 고정(pinning)은 사람들이 생각하는 것보다 더 큰 효과를 내지만, 기대하는 것보다는 효과가 적습니다. 3시간 동안 새 설치(fresh install)를 수행하지 않은 채 깨끗한 axios에 버전을 고정한 사용자들은 아무 문제 없이 잘 작동했습니다. 버전 고정이 알려주지 못하는 점은, 의도적으로 업그레이드한 버전이 신뢰할 수 있는지 여부이며, 전이적 의존성의 느슨한 범위(loose range)가 자동으로 해결을 수행할 때는 아무런 역할을 하지 못합니다. Mastra 사건이 발생한 것도 바로 이러한 이유 때문입니다. 주입된 easy-day-js 의존성이 캐럿 범위로 선언되어 있었기 때문에, npm은 아무런 문제 없이 패치 릴리스 버전으로 업그레이드해 버렸습니다. 또한 버전 뒤에 있는 아티팩트가 변경될 수 없다고 가정하지만, Laravel-Lang은 기존 태그를 재작성하여 새로운 커밋을 가리키게 함으로써 이 가정을 반증했습니다.

패키지가 개발자의 컴퓨터나 빌드 에이전트에 도달하기 전에 검사하는 것은, 설치 시점에 발생하는 코드 문제를 사후에 보고하는 대신 차단할 수 있는 몇 안 되는 단계 중 하나입니다. 바로 그 부분이 취약점입니다 SecureChain for OSS 는 바로 이 취약점을 해소하기 위해 설계되었으며, 이것이 바로 이 솔루션이 파이프라인 끝에 스캐너를 하나 더 추가하는 대신 레지스트리 수준에서 작동하는 이유이기도 합니다.

스캐너가 왜 항상 늦는 걸까요?

기존의 CVE 중심 소프트웨어 구성 분석은 한 가지 질문에 대해 탁월한 성능을 발휘합니다. 바로 ‘이 빌드에 어떤 알려진 취약점이 있는 구성 요소가 포함되었는가’라는 질문입니다. 이 부분에서는 정말 뛰어나며, 계속 활용할 가치가 있습니다.

하지만 이것만으로는 또 다른 질문에 대한 답이 되지 않습니다. 바로 지금 이 아티팩트가 관리자가 공개한 것과 동일한 것일까요?

이는 제품 문제라기보다는 데이터 문제입니다. 취약점에 초점을 맞춘 SCA는 의존성 목록을 권고 사항 데이터와 대조하여 분석하는데, 권고 사항은 누군가가 악성 패키지를 발견하고 이를 신고한 뒤, 해당 권고 사항이 공개되어야만 생성됩니다. 탐지는 대개 신속하게 이루어집니다. Socket은 악성 jscrambler 릴리스가 공개된 지 6분 만에 이를 탐지했으며, TrapDoor 패키지의 경우 공개부터 탐지까지 평균 6분 미만이 소요되었습니다. 스캐너가 조회하는 권고 정보 확인 과정이 가장 시간이 오래 걸리는 부분이며, 이러한 사건 중 상당수는 CVE가 전혀 생성되지 않기도 합니다. 이것이 바로 이들 중 어느 것도 CISA 알려진 악용 취약점 카탈로그에 절대 나타나지 않는 이유이기도 합니다. 권고 피드는 본질적으로 이미 발견된 사항에 대한 기록일 뿐입니다.

알아두면 좋은 정보: 2026년 캠페인의 여러 사례에서, 일반적인 패치 버전 업데이트처럼 보이지만 실제로는 해당 커밋, 풀 리퀘스트 또는 태그가 전혀 없는 악성 버전이 공개된 바 있습니다. jscrambler 8.14.0이 가장 대표적인 사례인데, 연구진이 해당 프로젝트의 GitHub 저장소에서 이에 대한 커밋, 태그 또는 풀 리퀘스트를 전혀 찾지 못했으며, 최신 태그는 여전히 8.13.0으로 남아 있었기 때문입니다. 일반적인 업데이트 도구는 아티팩트가 소스 변경 사항과 일치하는지 확인하지 않습니다. 새로운 버전 번호를 확인하면 풀 리퀘스트를 생성하고, 일부 팀은 이를 자동으로 병합하기도 합니다. 버전 번호를 올리는 것과 검증된 변경 사항은 같은 것이 아닙니다.

생태계 지표가 가리키는 향후 전망

2024년 내내 그리고 2025년 대부분 동안, npm은 도입 규모와 설치 시 자동으로 실행되는 라이프사이클 스크립트 덕분에 모든 이목의 중심이 되었습니다. 하지만 이제 그 집중은 끝났습니다.

TrapDoor는 5월 한 주 동안 세 개의 생태계를 공격했으며, 34개의 악성 패키지와 384개 이상의 버전 npm, PyPI, Crates.io에 배포되었습니다. 이들은 해킹당한 도구가 아닌 가짜 도구로, 암호화폐나 AI 개발자가 별다른 의심 없이 설치할 법한 유틸리티처럼 이름이 지어졌으며, 각 레지스트리마다 고유한 실행 경로가 마련되어 있었습니다. 또한 AI 코딩 어시스턴트를 조종하기 위해 .cursorrules 및 CLAUDE.md 파일을 심어두었는데, 이는 향후 공격 양상을 엿볼 수 있는 좋은 예시입니다.

Packagist 역시 5월에 힘든 시기를 겪었습니다. 5월 22일과 23일, 약 90분 동안 공격자들이 4개의 Laravel-Lang 현지화 저장소에 있는 모든 Git 태그를 재작성했으며, 700개가 넘는 과거 버전들이 이 결국 악성 커밋을 가리키게 되었고, Composer의 오토로더는 이후 모든 요청 시 해당 커밋을 실행했습니다. 침입 경로는 유출된 GitHub 토큰이었으며, 프로젝트 소스 코드는 전혀 손대지 않았습니다. 이와 별개로, 8개 패키지를 대상으로 한 공격 캠페인은 페이로드를 `composer.json` 대신 `package.json`에 숨겨두었으며 에 페이로드를 숨겼는데, 이는 PHP 중심의 검토 과정에서 가장 확인하기 어려운 위치였습니다.

또한 Laravel 보안에 대한 당사의 종합 가이드에서 PHP 생태계를 보호하기 위한 모범 사례를 살펴보실 수 있습니다.

그리고 이 기사가 다루는 기간 직전인 2025년 12월, 잭슨(Jackson)과 닮은 타이포스쿼팅 라이브러리가 가 코발트 스트라이크(Cobalt Strike) 비콘을 탑재한 채 Maven Central에 등장했습니다. 이 공격의 핵심은 접두사 교체였는데, 실제 라이브러리가 com.fasterxml을 사용하는 반면 org.fasterxml로 변경된 것이었습니다. 자바의 역도메인 규칙으로는 이를 탐지할 수 없었습니다. 이를 발견한 아이키도(Aikido) 팀은 이를 Maven Central에서 탐지한 최초의 정교한 악성코드라고 밝혔으므로, 이는 전체 생태계가 아닌 해당 연구진에게 있어 첫 사례로 이해해야 합니다. 적어도 제거는 신속하게 이루어졌으며, 신고 접수 후 약 90분 만에.

이는 명확한 ‘이전’과 ‘이후’의 구분이라기보다는 주요 캠페인의 표적이 어디로 이동했는지를 보여주는 변화로 해석해야 합니다. 왜냐하면 악성 패키지가 이미 그 레지스트리 대부분에서 발견된 바 있기 때문입니다. 다중 언어를 사용하는 개발 환경의 경우, 생태계별로 방어 체계를 구축하는 것만으로는 실질적인 보호 범위를 확보할 수 없다는 점이 실질적인 교훈입니다. npm에 대한 철저한 통제, PyPI에 대한 느슨한 관리, 그리고 Go나 Rust에 대한 대책 부재는 마치 정문은 잠가 놓았지만 여러 측면 출입구가 열려 있는 것과 같으며, 올해의 데이터에 따르면 공격자들은 이미 이러한 취약점을 노리고 있습니다.

이에 대해 어떻게 해야 할까

이 중 어느 것도 아키텍처 재구성을 필요로 하지 않습니다. 이 모든 작업은 이번 분기 내에 완료할 수 있습니다.

주요 생태계가 하나뿐이라면

우선 설치 시점의 보안 취약점을 해결하십시오. 빌드 과정에서 허용되는 곳이라면 어디에서든 .npmrc 파일에 `ignore-scripts=true`를 설정하고, 패키지가 해결되기 전에 이를 검사하는 레지스트리 계층을 통해 설치 과정을 진행하십시오. 하지만 스크립트 차단을 유일한 해결책으로 여겨서는 안 됩니다. 악성 jscrambler 버전 5개 중 2개는 드로퍼를 preinstall 훅에서 제거하고 패키지의 메인 코드와 CLI로 옮겼는데, 이 경우 `–ignore-scripts`는 전혀 효과가 없습니다.

여러 언어를 구사하신다면

이미 일부 통제 수단이 마련된 생태계에 대해 심층적으로 분석하기 전에, 통제 수단이 전혀 없는 생태계가 어디인지 먼저 파악하십시오. 이 위협 모델에서는 ‘범위상의 공백’이 ‘심도상의 공백’보다 더 치명적입니다. TrapDoor와 PolinRider 사례 모두, 단 하나의 통제되지 않은 생태계만으로도 다른 모든 곳에서 이루어진 노력을 무효화하기에 충분하다는 점을 보여주었습니다.

자동 종속성 업데이트에 의존하는 경우

신규 출시 시 지연 기간을 적용합니다. Unit 42의 대응 지침 는 대부분의 악성 패키지가 해당 기간 내에 식별되어 제거된다는 점을 근거로, 지난 24~72시간 내에 공개된 모든 버전을 차단할 것을 권장하며, Wiz 역시 24시간의 대기 기간을 적용함으로써 이와 유사한 접근 방식을 취합니다. 짧은 격리 기간을 두면 패치 적용이 약간 늦어지는 대가를 치르더라도 이러한 공격의 상당 부분을 무해한 것으로 만들 수 있습니다.

컨트롤을 앞쪽으로 옮기는 것이 뒤쪽에 또 다른 컨트롤을 덧붙이는 것보다 낫습니다. 여기서 무엇보다 중요한 두 가지가 있습니다. 패키지가 해결되기 전에 이를 포착하는 것과, 수신한 아티팩트가 표기된 소스 및 빌드와 일치하는지 확인하는 것입니다.

프로비넌스 기능을 활성화할 가치가 있지만, 한 가지 주의할 점이 있습니다. Mastra는 CI 게시 시 프로비넌스를 생성했지만 이를 필수로 요구하지는 않았기 때문에, 도난당한 토큰을 사용해도 인증 없이 게시할 수 있었습니다. 반면, TanStack의 Mini Shai-Hulud 사태에서는 파이프라인 자체가 악용되었기 때문에 유효한 SLSA 프로비넌스를 가진 패키지가 생성되었습니다. 인증을 필수로 요구했다면 첫 번째 사례는 막을 수 있었겠지만, 두 번째 사례는 막지 못했을 것입니다.

마일리지 역시 생태계에 따라 다릅니다. 계정 탈취와 PyPI 스타트업 후크는 서로 다른 문제이므로 각기 다른 해결책이 필요하며, 따라서 비용을 지불할 가치가 있는 어떤 제어 수단이라도 각 생태계가 실제로 코드를 실행하는 방식을 고려해야 합니다.

이 상황이 여러분에게 어떤 영향을 미치는지

여기에는 특별한 점이 전혀 없습니다. 2026은 새로운 유형의 취약점을 만들어낸 것이 아닙니다. 단지 대부분의 팀이 주시하지 않던 곳, 즉 누군가가 마침내 패키지를 스캔하는 시점이 아니라 패키지가 해결되어 실행되는 순간으로 공격의 무대를 옮겼을 뿐입니다. 3시간 동안 지속된 npm 탈취 사건부터 탈취된 유지보수자 계정을 통해 접근한 Go 모듈에 이르기까지, 이 목록에 포함된 모든 공격 캠페인이 성공한 이유는 해결, 설치, 빌드 과정 중이든, 편집기가 프로젝트를 여는 순간이든, 어떤 제어 메커니즘도 이를 확인할 기회를 얻기도 전에 이미 신뢰가 부여되었기 때문입니다.

따라서 진짜 문제는 설치 후 탐지 기능을 유지할지 여부가 아닙니다. 유지해야 합니다. 문제는 예방 조치가 더 이른 단계로 앞당겨져, 페이로드가 이미 CI 비밀 정보를 탈취한 후에 실행되는 스캔이 이를 알려주는 첫 번째 수단이 되지 않도록 할 수 있느냐는 것입니다. OSS용 SecureChain 는 이를 직접 구축하지 않고도 이러한 기능을 원하는 팀을 위해 존재합니다.

SecureChain 다운로드 → 

자주 묻는 질문

소프트웨어 공급망 공격이란 무엇인가요?

애플리케이션을 직접 공격하는 대신, 신뢰할 수 있는 종속성, 빌드 시스템, 저장소 또는 배포 채널을 통해 소프트웨어를 침해하는 공격입니다. 2026년 공격 캠페인의 압도적 다수는 공개 패키지 레지스트리와 해당 레지스트리에 패키지를 게시하는 계정을 표적으로 삼았습니다.

2026년에는 소프트웨어 공급망 공격이 몇 건 발생했나요?

확실한 총계는 없습니다. 이 글에서는 2026년 3월부터 7월 사이에 확인된 6건의 주요 캠페인을 다루고 있으며, TrapDoor, Laravel-Lang 및 더 광범위한 TeamPCP 작전을 포함하여 그 범위를 약간 벗어난 몇 건의 사례가 더 있습니다.

SBOM이 공급망 공격을 방지할 수 있을까요?

아닙니다. SBOM은 빌드에 포함된 구성 요소를 목록으로 정리한 것으로, 사고 대응 및 감사에 유용합니다. 그러나 SBOM은 목록에 포함된 아티팩트가 해당 유지보수자가 공개한 것과 동일하다는 것을 보장하지 않으며, 종속성 확보 과정에서 코드가 실행되는 것을 막아주지도 않습니다.

어떤 패키지 생태계가 가장 큰 타격을 입었나요?

2026년에 발생한 주요 보안 사고의 대부분은 npm에서 발생했으며, PyPI, Go 모듈, Crates.io, Packagist에서는 모두 연중반 무렵에 여러 패키지를 대상으로 한 표적 공격이 발생했습니다. Maven Central은 연초 직전에 한 차례 보안 사고가 발생했습니다.

SecureChain 다운로드 → 

요약

기사 이름

2026년의 소프트웨어 공급망 공격

설명

npm, PyPI, Go, Packagist를 대상으로 한 6건의 주요 공급망 캠페인이 발생했습니다. 이 캠페인들의 공통점은 무엇이며, 설치 후 스캔이 왜 계속해서 이를 놓치고 있는 것일까요?

작성자

팀 워커

게시자 이름

TuxCare

게시자 로고