axios가 3시간 동안 오작동을 일으켰지만, 주간 다운로드 1억 건을 기록하는 사용자들은 이를 눈치채지 못했다

주요 내용

• 악성 axios 버전은 약 3시간 동안만 유통되었기 때문에, 탐지되기 전에 설치된 경우 경고 기반 방어 체계의 도움을 받지 못했습니다.
• 다운로드 횟수는 채택 여부를 나타낼 뿐, 검토 여부를 나타내는 것은 아니며, axios는 팀이 한 번도 선택하지 않은 패키지를 통해서도 도입될 수 있습니다.
• 잠금 설치, 설치 스크립트 차단, 격리 창, 출처 확인, 레지스트리 검사 등 여러 가지 제어 수단을 통해 이 일련의 과정을 차단할 수 있었을 것입니다.
• 가장 강력한 예방적 통제 조치는 설치 시점이나 그 이전에 이루어지는데, 정작 많은 팀이 이 부분에 가장 적은 투자를 해왔습니다.

2026년 3월 31일, 두 가지 악성 버전의 axios가 공개되었으며, 누군가가 이를 제거하기 전까지 약 3시간 동안 온라인 상태를 유지했습니다. 이 기간 동안 해당 악성 버전은 JavaScript 생태계전역에 걸쳐 의존성 트리에 은밀하게 침투했으며, 이를 설치한 사용자 중 이를 알아챌 수 있는 사람은 거의 없었습니다.

이 프로젝트의 누구도 해당 릴리스를 공개하지 않았습니다. 이 릴리스들은 해킹당한 유지보수 담당자 계정에서, 프로젝트 자체 CI 파이프라인을 우회한 도난당한 장기 유효 토큰을 이용해 수동으로 게시된 것이었기 때문에, 레지스트리상에서는 평범한 axios 릴리스처럼 보였습니다. 버전 번호도 정상적으로 보였습니다. npm audit 은 해당 기간 초반에는 아무런 경고도 표시하지 않았는데, 이는 결국 이 사건을 설명하게 될 권고문이 아직 작성되지 않았기 때문입니다.

npm 공급망 공격의 내막: 3시간 동안의 기록

3시간은 그리 긴 시간이 아닙니다. 대부분의 팀이 새 버전이 출시된 사실조차 알아차리기에는 턱없이 짧은 시간이며, 평가할 여유는 더더욱 없습니다.

퍼블리시 측 보안 침해의 일반적인 양상은 이미 잘 알려져 있으며, axios는 이 개요를 따르면서도 일반 버전에는 없는 추가 계층을 하나 더 도입했습니다. 두 릴리스 모두 plain-crypto-js라는 완전히 새로운 종속성을 포함했는데, 이 패키지는 postinstall 훅에서 페이로드를 실행하기 위한 목적 외에는 존재 이유가 없었습니다. 약 18시간 전에 해당 패키지의 무해한 미끼 버전이 미리 올라와 있었기 때문에, 악성 후속 버전이 완전히 새로운 것처럼 보이지 않게 했으며, axios 소스 파일 자체는 전혀 수정되지 않았습니다. 사회공학 을 통해 공격자는 먼저 유지보수자의 컴퓨터에 침투했으며, 이를 통해 게시 권한을 획득했습니다.

흥미로운 단계는 전파 과정입니다. 게시와 검색 단계 사이에서, 기본 npm install 경로는 패키지에 대해 네트워크를 통해 전송되는 아티팩트가 해당 패키지가 주장하는 소스 코드와 워크플로우를 기반으로 빌드되었음을 증명하도록 요구하지 않습니다. 바로 그 간극이 공격의 온갖 기회가 되는 창구입니다.

Wiz는 텔레메트리 데이터에서 발견된 감염된 환경 중 약 3%에서 연구진은 텔레메트리 데이터를 분석한 결과, 감염된 환경 중 약 3%에서 악성코드가 실제로 실행되는 것을 확인했으며, 연구진은 별도로 노출 기간 동안 다운로드 횟수가 약 60만 건에 달한다고 추산했습니다로 추산했습니다. 이 두 수치는 서로 다른 표본 집단에서 도출된 것이므로, 이를 곱한다고 해서 실제 감염자 수를 산출할 수는 없습니다. 하지만 이 두 수치를 함께 살펴보면, 단순히 디스크에 파일이 존재하는 것이 아니라 매우 짧은 노출 기간 내에 페이로드 실행이 실제로 확인되었음을 보여줍니다.

현실 점검: 악성 버전의 게시를 중단하면 향후 설치만 막을 수 있습니다. 이미 해당 버전을 실행한 시스템, 이미 유출된 토큰, 또는 악성 코드가 포함된 상태로 이미 빌드 및 배포된 컨테이너 이미지에 대해서는 아무런 효과가 없습니다.

주간 다운로드 수 1억 건이 왜 보안 신호가 아닌지

인기 있는 의존성을 선택하는 데에는 ‘인기가 높다는 것은 철저한 검증을 거쳤다는 뜻이다’라는 암묵적인 전제가 깔려 있습니다. ‘많은 사람이 보면 버그가 빨리 발견된다’는 식의 사고방식이지요.

소스 코드에 관해서는 타당한 주장입니다. 하지만 릴리스 무결성 측면에서는 설득력이 떨어집니다. 공격이 레지스트리에서 발생하는 동안 모든 시선은 리포지토리에 쏠려 있기 때문입니다. 이 둘은 서로 다른 구성 요소이며, npm은 이 둘이 일치할 것을 요구하지 않습니다. 그날 밤 수많은 스캐너가 감시 중이었고, 그중 몇 개는 몇 분 만에 해당 릴리스에 문제를 제기했습니다. 기본 설치 경로에는 이를 기다리는 요소가 전혀 없습니다.

두 번째 문제가 있는데, 바로 이 문제 때문에 이런 종류의 사고에 대응하기가 정말 골치 아픈 것입니다. 일부 팀은 애초에 axios를 직접 설치한 적이 전혀 없습니다. 그들은 axios를 설치하는 또 다른 무언가를 설치하는 무언가를 설치했을 뿐입니다.

OWASP의 ‘오픈 소스 소프트웨어 Top 10’에 인용된Endor Labs의 연구에 따르면, 간접 의존성에 존재하는 취약점의 비중이 약 95% 라고 밝혔습니다. 이 수치는 악성코드가 아닌 알려진 취약점을 집계한 것이지만, 의존성 그래프의 상당 부분이 개발자가 의도적으로 선택한 패키지 외부에 위치해 있음을 보여주며, 이러한 그래프의 깊이는 줄어들 기미가 보이지 않습니다. 보안이 침해된 패키지가 아무도 실제로 읽어보지 않은 그래프의 네 단계 아래에 위치해 있다면, “우리가 axios를 사용하긴 하는가?”라는 질문에 빠르게 답하기는 의외로 어려운 일이 됩니다.

npm ls axios –all

npm ls plain-crypto-js –all

HTTP 클라이언트를 추가한 것으로 기억하는 리포지토리뿐만 아니라 모든 리포지토리에 대해 이 명령을 실행해 보세요. 만약 둘 중 하나라도 다음과 같은 결과가 반환된다면 axios 1.14.1이나 0.30.4, 혹은 plain-crypto-js 4.2.1을 반환하면, 해당 호스트를 침해된 것으로 간주하고 axios 1.14.0 또는 0.30.3으로 되돌리고, 해당 호스트가 접근할 수 있는 모든 인증 정보를 갱신하십시오.

국가 기관이 HTTP 클라이언트를 왜 필요로 했을까?

구글의 위협 인텔리전스 그룹은 액시오스 해킹 사건의 배후로 UNC1069를 지목했다라고 밝혔다. UNC1069는 암호화폐 거래소에서 자금을 탈취한 전력이 있는, 금전적 동기를 가진 북한 연계 해킹 집단이다. 마이크로소프트는 이와 중복되는 활동을 ‘Sapphire Sleet’로 추적하고 있는 반면, 다른 연구자들은 관련 활동을 ‘BlueNoroff’나 ‘Stardust Chollima’와 같은 명칭으로 지칭하고 있다. HTTP 클라이언트는 해당 분야의 해킹 집단에게는 다소 이례적인 표적처럼 보이지만, 이를 해킹함으로써 얻을 수 있는 이점을 고려해 보면 이야기가 달라진다.

대규모로 운영되는 개발자용 컴퓨터와 빌드 에이전트 — 이 시스템들에는 클라우드 역할 자격 증명, 레지스트리 토큰, 서명 키, 그리고 아직 출시되지 않은 프로젝트의 소스 코드가 저장되어 있습니다. 프로덕션 환경 대신 개발자 도구를 공략하는 것은 이전 npm 캠페인에서도 반복적으로 나타난 패턴이며, 개발자 워크스테이션과 빌드 에이전트가 유난히 광범위한 하위 시스템 접근 권한을 가진 자격 증명을 보유하고 있기 때문에 이 전략은 효과를 발휘합니다.

버라이즌의 ‘2026년 데이터 유출 조사 보고서’ 에 따르면, 취약점 악용이 도용된 인증 정보를 제치고 주요 초기 접근 경로로 부상했으며, 전체 침해 사고의 31%를 차지한 반면 인증 정보 악용은 13%에 그쳤습니다. 하지만 인증 정보가 여전히 중요하지 않은 것은 아닙니다. 침입이 시작된 후에는 여전히 가장 흔한 요소 중 하나로 남아 있으며, 수천 개의 빌드 환경에서 토큰을 추출해 가는 침해 사고는 바로 이러한 공급을 끊임없이 유지하는 유형의 사례입니다.

샤이-훌루드와 자가 확산형 악성코드로의 전환

axios는 단 한 번의 유포에 그쳤습니다. 웜 공격 캠페인은 완전히 다른 차원의 문제입니다.

Shai-Hulud는 2025년 9월, 개발(dev) 또는 CI 환경에서 실행되면 비밀 정보를 탐색하고 npm 게시 토큰을 찾아 이를 이용해 더 많은 패키지에 스스로를 배포하는 악성 코드를 통해 선례를 남겼습니다. 이와 관련된 캠페인으로 알려진 미니 샤이-훌루드 로 알려진 관련 캠페인은 2026년 4월 29일에 시작되어 5월에 걸쳐 두 차례 더 이어졌습니다. 캠페인 도중 TeamPCP가 GitHub에 이 웜의 소스 코드를 공개했는데, 이는 마치 병 속으로 다시 돌아가지 않는 지니와 같은 상황이었습니다.

브랜딩보다 메커니즘이 더 중요합니다. 자가 확산형 캠페인은 게시 권한을 가진 모든 피해자를 또 다른 배포 거점으로 전환시키므로, 공격자가 별다른 조치를 취하지 않아도 영향을 받는 패키지의 수는 계속 늘어납니다.

주의: 은밀한 스캔은 양날의 검과 같습니다. 여러 웜 공격 캠페인은 TruffleHog와 같은 상용 비밀 정보 스캐너를 묶어 감염된 호스트에서 인증 정보를 수집했는데, 이는 방어 측이 사용하는 도구와 동일하지만 방향만 반대일 뿐입니다.

이러한 성장 곡선은 어떤 패키지가 악성인지 미리 파악할 필요 없이 제어 지점을 설정해야 하는 근거가 됩니다. 패키지가 해결되기 전에 선별하고, 공개된 아티팩트를 검증된 소스 코드와 대조하여 확인하면, 보안 권고문이 발표되기를 기다리지 않고도 전체 범주의 침해 사례를 포착할 수 있습니다. 이것이 바로 npm용 SecureChain의 근거가 됩니다.

마스트라와 jscrambler가 그 흐름을 이어갔다

2026년에 발생한 두 건의 후속 사건을 통해 3월의 사건이 일회성 사건이 아니라는 점이 분명해졌다. 6월 17일의 Mastra AI 패키지 탈취 사건 와 7월 11일의 jscrambler 침해 사건은 모두 사용자의 소비 코드에 존재하는 취약점이 아닌, 게시 측 접근을 통해 발생했습니다.

마이크로소프트는 Mastra 침해 사건을 ‘Sapphire Sleet’의 소행으로 지목했는데, 이는 구글이 UNC1069로 추적하는 활동을 마이크로소프트가 명명한 이름이다. axios 사건 발생 약 11주 후, 동일한 클러스터가 매우 유사한 공격 수법을 다시 사용했다. @mastra 범위 전반에 걸쳐 여전히 게시 권한을 보유한 전직 기여자 계정이 140개 이상의 패키지를 재게시하는 데 사용되었으며, 각 패키지의 유일한 변경 사항은 ‘easy-day-js’라는 단일 종속성이 추가된 것이었습니다. 이 라이브러리는 dayjs와 유사하게 생겼으나, 악성 postinstall 훅을 포함하고 있었습니다. 라이브러리 코드 자체는 전혀 수정되지 않았는데, 이는 axios 사건에서 발생한 상황과 정확히 일치합니다.

Sonatype은 2025년 한 해 동안만 npm, PyPI 및 기타 레지스트리에 등록된 새로운 악성 오픈소스 패키지가 발견되었다고 보고했는데, 이는 2025년 한 해 동안만 npm, PyPI 및 기타 레지스트리에서 확인된 수치이므로 그 규모 자체가 새로운 현상은 아닙니다. 최근의 이러한 현상이 보여주는 것은, 해킹당한 게시 권한이 그 방대한 양의 악성 코드를 얼마나 빠르게 빌드 단계까지 도달하게 만드는지입니다.

과연 무엇이 그 일을 막을 수 있었을까?

다음은 3시간 동안 지속된 게시 측 침해 사고를 바탕으로 정직하게 검증한 6가지 후보 통제 조치입니다.

–ignore-scripts 는 그 자리를 굳건히 다졌으며, 이후 생태계도 이에 발맞춰 발전해 왔습니다. 2026년 7월 8일에 출시된 npm 12에서는 암시적인 node-gyp rebuild도 포함됩니다. binding.gyp 가 트리거하던 암묵적인node-gyp재구축도 포함됩니다. 따라서 npm 12는 사용자가 별도의 플래그를 기억할 필요 없이 이 작업을 차단합니다. 설치 시점 스크립트나 네이티브 빌드 스크립트가 진정으로 필요한 의존성은 이제 명시적으로 승인받아야 하며, 업그레이드로 인해 파이프라인이 예기치 않게 중단되는 상황을 방지하기 위해 이 과정을 신중하게 검토할 가치가 있습니다.

아직은 근본적인 해결책은 아닙니다. 모듈 본문에 포함된 악성 코드는 스크립트 차단 여부와 상관없이 누군가 해당 패키지를 임포트하는 순간 실행됩니다. 지난 7월의 jscrambler 침해 사건 사건이 이를 가장 명확하게 보여주는 사례입니다. 최초의 악성 배포본은 사전 설치 후크에서 실행되었고, 이후 같은 3시간 동안의 게시 과정 중에 공격자는 동일한 드로퍼를 패키지 자체 코드 내로 이동시켜, 패키지가 임포트되거나 CLI가 실행될 때 작동하도록 했습니다. 설치 스크립트를 차단하는 것은 필수적이지만, 그것만으로는 충분하지 않습니다.

락파일 관리 방식에 대해서는 더 큰 주의사항이 필요합니다. 대부분의 팀이 이미 이 부분을 충분히 처리했다고 가정하는 통제 수단이기 때문입니다.

주의: 다음과 같은 캐럿 범위: ^1.7.0 와 같은 캐럿 범위가 package.json 와 같은 캐럿 범위는 이를 고정하는 항목이 없을 경우, 악의적인 패치 릴리스로 문제없이 해결될 수 있습니다. 커밋된 락파일은 이를 방지하며, npm ci 는 락파일과 package.json 이 서로 일치하지 않을 때 조용히 해결 방식을 변경하는 대신 실행을 거부하기 때문입니다. 이 보호 기능은 락파일이 재생성되거나, 보안 취약점이 포함된 버전으로 업데이트되는 순간 사라집니다. 많은 파이프라인이 이 중 적어도 하나를 놓치고 있습니다.

이 경우 출처 정보가 유용하며, 특히 이러한 특정 오류 유형에 대해서는 그 가치를 충분히 입증합니다.

알고 계셨나요? npm은 CI를 통해 배포된 패키지에 대해 Sigstore 기반의 출처 인증을 지원하며, 다음 명령어 하나로 현재 보유한 패키지의 상태를 확인할 수 있습니다: npm audit signatures.

그것이 무엇을 증명하는지 정확히 짚어볼 필요가 있습니다. 출처 추적(Provenance)은 아티팩트가 주장하는 소스 및 빌드 워크플로우에서 비롯되었음을 검증하는 것으로, 이는 아티팩트 내부의 코드가 악성인지 여부와는 별개이며 훨씬 더 명확히 답할 수 있는 문제입니다. axios의 경우, 이 점이 도움이 되었을 것입니다. 마지막으로 정상적으로 출시된 1.x 릴리스에는 출처 정보가 포함되어 있었지만, 악성 릴리스에는 포함되어 있지 않았기 때문입니다. 악성 릴리스는 프로젝트의 CI 워크플로우 대신 도난당한 토큰을 사용하여 수동으로 푸시된 것이었습니다. 하지만 이는 악성코드 방지 수단은 아닙니다. 2026년 미니 샤이-훌루드 공격에서는 유효한 출처 정보를 가진 악성 패키지가 배포되었는데, 이는 해당 패키지를 빌드한 파이프라인이 실제로 침해당했기 때문입니다.

다음 번을 앞두고 무엇을 바꿔야 할까?

이 중 어느 것도 플랫폼을 재구축할 필요가 없습니다. 현재 파이프라인이 어떤 단계에 있는지 고려하여 선택하십시오.

락파일이 일관성 없이 커밋된 경우, 먼저 이를 수정한 다음 CI를 npm ci로 전환하세요. 이는 목록에 있는 가장 간단한 조치 중 하나이며, 이 특정 사고를 아예 막을 수 있었을 것입니다.

이미 다음을 실행 중이라면 npm ci 를 모든 환경에서 실행 중이라면, 새 릴리스 시 격리 기간을 추가하세요. npm은 네이티브 min-release-age 설정을 제공해 왔으며, pnpm 11에서는 minimumReleaseAge 값을 기본적으로 1일로 설정하지만, 사용자가 직접 값을 설정하지 않는 한 설치에 실패하지는 않습니다. 또한 Unit 42는 지난 24~72시간 내에 게시된 모든 패키지의 배포를 보류할 것을 권장합니다. 이는 대부분의 악성 패키지가 해당 기간 내에 식별되어 제거되기 때문입니다. 최초의 Shai-Hulud 웜이 완전히 제거되는 데 며칠이 걸렸기 때문에 모든 사례를 포착할 수는 없겠지만, 일반적인 경우에는 적용됩니다.

직접 패키지를 배포하는 경우, 프로비넌스 기능을 활성화하고, 장기 유효한 배포 토큰 대신 OIDC를 활용한 신뢰할 수 있는 배포 방식으로 전환하십시오. axios 공격자는 도난당한 클래식 토큰을 사용하여 프로젝트의 일반적인 OIDC 배포 워크플로를 우회했는데, 이는 해당 토큰을 완전히 폐지해야 한다는 타당한 근거가 됩니다. 여러분이 그렇게 생각하든 그렇지 않든, 여러분은 이미 다른 누군가의 공급망의 일부입니다.

또한 빌드 에이전트에 클라우드 역할 자격 증명이 저장되어 있다면, 이를 최우선으로 유효 기간을 단축하십시오. 이것이 바로 설치 오류와 사고 보고의 실질적인 차이입니다.

문제는 가장 강력한 예방적 통제 수단 중 상당수가 문제 해결 전이나 해결 단계에 적용되는 반면, 팀들이 이미 투자한 자원의 대부분은 사후에 문제를 발견하는 데 초점을 맞추고 있다는 점입니다. 이는 소프트웨어 구성 분석이 본래의 역할을 제대로 수행하지 못한다는 비판이 아닙니다. 이는 시기의 문제이며, 시기의 문제는 단순히 스캔 단계를 하나 더 추가한다고 해서 해결되는 것이 아닙니다.

실제 상황은 조직이 새로운 종속성 버전을 얼마나 빨리 필요로 하는지에 따라 달라집니다. 빠르게 변화하는 업스트림 패키지를 기반으로 AI 툴을 출시하는 팀들은 격리 기간으로 인해 실질적인 비용을 치르게 됩니다. 반면, 변화 속도가 느린 내부 플랫폼을 사용하는 팀들은 이러한 비용을 훨씬 덜 부담하며, 종종 마이너 버전에서 이미 3주나 뒤처져 있었음에도 아무도 눈치채지 못했다는 사실을 알게 되기도 합니다.

다음 작품은 이미 어딘가에서 공개 중입니다

그 시간 동안 발생한 설치 건수를 세어보기 전까지는 3시간이 그리 긴 시간처럼 느껴지지 않습니다. 바로 이것이 여기서 얻을 수 있는 진정한 교훈이며, 북한 소행 여부나 웜의 명칭 문제는 아닙니다. 핵심은 공개와 발견 사이의 간극, 그리고 그 간극 안에 기본적으로 들어 있는 정보가 얼마나 적은가 하는 점입니다.

axios는 주목을 받았습니다. 규모가 작은 보안 침해 사례는 대개 훨씬 덜 주목받기 마련입니다. 이러한 사례들은 별다른 소란 없이 레지스트리에서 제거되며, 이미 해당 라이브러리를 설치한 사용자들은 스스로 노출 위험을 파악해야만 합니다. 누군가의 의존성 트리에서 네 단계나 깊숙이 자리 잡고 있는 다음 사례 역시 스스로 드러나지 않을 것입니다.

권고 사항 기반 스캔은 위협이 이미 알려진 상황에서 가장 효과적입니다. npm 공급망 공격이 진행 중인 시점에 이를 포착하려면, 권고 사항 데이터를 통해 해당 패키지의 이름이 먼저 밝혀지기를 기다리기보다는 설치 시점에 바로 검사를 수행해야 합니다. 바로 이것이 SecureChain for npm 이 바로 그 격차를 해소하기 위해 설계되었습니다.

자주 묻는 질문

npm 공급망 공격이란 무엇인가요?

npm 공급망 공격이란, 사용자의 시스템에 도달하기도 전에 레지스트리에 등록된 패키지가 침해되는 것을 말하며, 이는 대개 사용자의 코드 결함 때문이 아니라, 도난당한 게시 자격 증명, 관리자 계정의 탈취, 또는 네임스페이스 사칭을 통해 발생합니다.

Axios 보안 침해 사건은 어떻게 된 건가요?

2026년 3월 31일, axios의 악성 버전인 1.14.1과 0.30.4가 배포되었다가 약 3시간 후에 회수되었습니다. 두 버전 모두 plain-crypto-js 라는 의존성을 삽입하여, 설치 후 훅을 통해 크로스 플랫폼 원격 액세스 트로이목마를 심었습니다. 구글의 위협 인텔리전스 그룹(Threat Intelligence Group)은 이번 침해 사고의 배후로 UNC1069를 지목했으며, 마이크로소프트는 이와 중복되는 활동을 ‘Sapphire Sleet’로 추적하고 있습니다. 대신 사용할 수 있는 정상 버전은 1.14.0과 0.30.3입니다.

npm audit는 악성 패키지를 탐지하나요?

이 취약점 검사는 레지스트리의 권고 사항 데이터에 의존하기 때문에, 새로 침해된 릴리스가 식별되고 기록되기 전까지는 이에 대한 경고를 제공할 수 없습니다. axios의 경우, 3시간 이내에 권고 사항이 등록되었지만, 이미 완료된 설치를 되돌릴 수는 없었습니다. npm audit 서명 는 별도의 검사 기능으로, 레지스트리의 서명과 출처 인증을 검증하므로 이 경우 더 유용합니다.

락파일(lockfile)은 npm 릴리스가 탈취되는 것을 방지해 주나요?

고정된 잠금 파일은 예상치 못한 버전이 해결되는 것을 막아주며, npm ci 은 락파일과 package.json 가 일치하지 않을 경우 진행을 거부하기 때문입니다. 이 보호 기능은 락파일이 재생성되거나 해당 문제가 포함된 버전으로 업데이트되면 사라지며, npm install 은 해결 방식을 변경하고 락 파일을 재작성할 수 있기 때문에 더 느슨한 방식입니다.

샤이-훌루드 웜이란 무엇인가요?

감염된 환경에서 기밀 정보를 탈취하고, npm 게시 토큰을 찾아내어 이를 이용해 더 많은 패키지에 스스로를 주입함으로써, 공격자가 별도의 조치를 취하지 않아도 감염 범위를 확대해 나가는 자가 확산형 npm 악성코드 캠페인입니다. 이 악성코드의 소스 코드는 2026년 5월에 공개되었기 때문에, 현재는 모방 공격이 잇따르고 있는 상황입니다.

패키지가 실제 관리자에 의해 빌드되었는지 어떻게 확인할 수 있나요?

실행 npm audit signatures 명령어를 실행하여 레지스트리 서명과, 존재하는 경우 출처 증명서를 확인하십시오. 출처 증명은 아티팩트가 주장하는 소스 및 CI 워크플로우에 의해 생성되었음을 확인해 줍니다. 이는 코드가 안전한지 여부와는 별개의 문제입니다. 왜냐하면 보안이 침해된 파이프라인에서도 적절하게 인증된 빌드를 생성할 수 있기 때문입니다.

문제가 해결되기 전에 무단 배포를 차단하세요

단순히 보안 권고 피드에만 의존할 경우, 악성 릴리스가 이미 빌드에 포함된 후에야 그 사실을 알게 될 수 있습니다. SecureChain for npm은 패키지 해결 단계에서 패키지를 검사하고, 검증된 소스 코드로부터 패키지를 재빌드하여, 보안이 침해되었거나 정책을 위반한 아티팩트가 그 단계까지 도달하기 전에 차단합니다. 다음을 확인해 보세요. SecureChain for npm를 확인해 보시고, TuxCare 뉴스레터를 구독하여 매주 제공되는 오픈소스 공급망 업데이트 소식을 받아보세요.

요약

기사 이름

axios npm 공급망 공격과 이를 통해 드러난 사실들

설명

Axios의 악성 버전 두 개가 3시간 동안 활성화된 상태로 남아 있었습니다. 이번 npm 공급망 공격을 통해 어떤 취약점이 드러났는지, 그리고 어떤 보안 조치가 실제로 이를 막을 수 있는지 확인해 보세요.

작성자

팀 워커

게시자 이름

TuxCare

게시자 로고