아티팩트 저장소에는 방화벽이 필요합니다.

 

아티팩트 저장소에는 방화벽이 필요합니다.

안녕하세요,

그로메트릭 입니다. 🐸

 

npm 등 공개 패키지 저장소에 의존해 개발하는 팀이라면 패키지가 개발 환경에 들어오는 지점을 반드시 점검해야 합니다.

공격자는 악성 패키지를 직접 배포하거나 정상 프로젝트를 탈취해, 평범한 의존성 다운로드를 자격 증명 탈취와 빌드 침해의 통로로 바꾸고 있습니다.

 

악성 패키지는 설치 과정에서 코드를 실행되며, 이 시점의 개발자 PC와 빌드 시스템은 소스 코드, 토큰, 클라우드 계정, 배포 자격 증명에 접근할 수 있는 상태입니다. 여기에 CI 파이프라인과 AI 에이전트가 사람의 검토 없이 패키지를 자동으로 내려받으면서 요청량 자체가 늘고 있습니다.

 

소프트웨어 공급망 보안 관점에서 패키지 유입 시점의 통제 여부가 실질적인 비즈니스 리스크를 좌우하는 상황입니다.

이번 소나타입 아티클에서는 끊임없는 보안 위협에 노출된 아티팩트 저장소(Repository)를 악성 패키지 유입으로부터 원천 차단하는 가장 확실한 방어선, 'Sonatype Repository Firewall'을 집중 조명합니다

*아래 글은 소나타입(Sonatype)의 공식 블로그 글을 번역하여 작성되었습니다.

---

악성 패키지는 설치 단계에서 실행됩니다: 리포지토리 방화벽이 필요한 이유

요약

• Sonatype은 2026년 1분기에 21,764개의 오픈 소스 악성코드 패키지를 식별했으며, 이로써 2017년 이후 기록된 총 악성코드 수는 1,346,867개에 달합니다.
• 이번 분기 악성 패키지 중 npm이 75%를 차지했습니다. 트로이 목마가 주를 이루었으며, 대부분의 활동은 자격 증명 탈취, 호스트 정찰 및 단계별 페이로드 전달에 집중되었습니다.
• 이번 분기의 주요 패턴은 신뢰 악용이었습니다. 공격자들은 신뢰할 수 있는 패키지, 신뢰할 수 있는 릴리스 경로 및 신뢰할 수 있는 워크플로 뒤에 숨어 공격에 성공했습니다.
• 특히 SANDWORM_MODE, LiteLLM 침해, axios 침해라는 세 가지 사건이 두드러졌습니다.

개발이 시작되기 전에 유입되는 악성 패키지는 어떤 위험을 만들까? 😈

대부분의 조직은 자신들이 만든 소프트웨어의 취약점을 찾는 데 많은 시간을 할애합니다. 하지만 개발이 시작되기도 전에 들어오는 악성 패키지들은 어떻게 해야 할까요?

공격자들은 악성 패키지를 게시하고, 원래 정상적으로 운영되던 프로젝트를 탈취하며, 반복되는 의존성 다운로드를 자격 증명 도용이나 빌드 침해의 기회로 만듭니다. 악성 패키지는 설치 중에 코드를 실행할 수 있습니다. 이때 개발자나 빌드 시스템은 소스 코드, 토큰, 클라우드 계정, 게시 자격 증명에 이미 접근할 수 있는 상태일 수 있습니다.

CI 파이프라인과 AI 에이전트는 패키지 요청량을 증가시킵니다. 이들은 의존성을 자동으로 해석하고 설치할 수 있으며, 사람이 각 요청을 검토하지 않은 채로 처리되는 경우가 많습니다. 이로 인해 패키지가 개발 워크플로우에 들어가는 지점이 위험을 평가하는 중요한 지점이 됩니다.

저장소 또는 패키지 방화벽은 구성 요소가 개발자, 에이전트 또는 빌드에 도달하기 전에 의존성 요청을 위협 인텔리전스 및 정책과 비교해 검증합니다. 보호 수준은 인텔리전스의 품질과 방화벽이 요청을 평가할 수 있는 위치에 달려 있습니다.

최근 공격 사례에서 패키지 안에는 무엇이 숨어 있었을까? 🎭

2026년 10월, TensorLake TypeScript SDK의 탈취된 릴리스가 설치 훅을 사용해 자격 증명을 검색하고 원격 명령을 수락했습니다.

Sonatype의 분석 결과, 침해된 계정의 접근 권한을 사용해 저장소를 수정할 수 있는 코드가 발견되었고, GitHub 폴백을 통해 수집된 데이터를 노출할 수 있었습니다. 조사 결과 데이터가 공개되었는지, 저장소가 수정되었는지, 다운스트림 시스템이 영향을 받았는지는 확인되지 않았습니다.

다른 캠페인들은 동일한 워크플로우로 다른 경로를 사용했습니다.

• 탈취된 패키지와 새로운 악성 패키지: 6개의 npm 패키지가 동일한 악성코드를 전달했습니다. 3개는 탈취된 정상 패키지로 보였고, 3개는 이미 악성 페이로드가 포함된 상태로 게시되었습니다. 악성코드는 이더리움 트랜잭션을 이용해 추가 페이로드를 호스팅하는 인프라를 찾아냈습니다.
• 대규모 패키지 플러딩: Sonatype은 Flooding Dropper 캠페인에서 약 850개의 컴포넌트를 확인했습니다. 이 패키지들은 Windows, Linux, macOS에서 추가 페이로드를 다운로드하고 실행했습니다.
• 자격 증명 도용 및 전파: Mini Shai-Hulud 웨이브는 2,200개 이상의 컴포넌트 버전에 영향을 미쳤습니다. 정상 패키지의 악성 릴리스는 설치 훅을 이용해 자격 증명을 훔쳤고, 게시 권한이 있는 경우 추가 패키지를 침해했습니다.
• 설치 시 실행: Miasma 웨이브는 익숙한 라이프사이클 스크립트에만 의존하지 않고, binding.gyp와 node-gyp를 악용해 설치 시 실행되도록 했습니다. Leo Platform 침해 보고서는 23개의 악성 패키지 버전을 추적했습니다.

이러한 사건들은 패키지 위험이 의심스러운 이름이나 새로 생성된 프로젝트에만 국한되지 않는 이유를 보여줍니다. 악성 코드는 친숙한 패키지로 도착하여 설치 과정에서 실행되며, 요청한 개발자, 빌드 또는 에이전트가 가진 접근 권한으로 작동할 수 있습니다.

저장소(패키지) 방화벽은 정확히 무엇을 할까? 🚥

저장소 또는 패키지 방화벽은 개발 환경에서 패키지 소스로 전달되는 의존성 요청을 검사합니다. 요청된 구성 요소를 보안 인텔리전스와 비교하여 평가하며, 제품의 기능과 구성에 따라 악의적이거나 정책을 위반하는 것으로 보이는 구성 요소를 차단하거나 격리할 수 있습니다.

패키지가 설치되면, 팀은 영향을 받은 기기를 조사하고, 노출된 자격 증명을 식별하며, 지속성 여부를 확인하고, 패키지가 다른 시스템에 도달했는지 확인해야 할 수 있습니다. 알려진 악성 패키지를 진입 지점에서 차단하면 그 정리가 시작되는 것을 막을 수 있습니다.

방화벽은 소프트웨어 공급망 보호의 한 단계입니다. 엔드포인트 보안, 코드 검토 또는 기타 통제를 대체하지 않습니다. 이는 패키지 요청을 통해 들어오는 악성 또는 정책 위반 구성 요소를 다룹니다. 그리고 모든 통제와 마찬가지로, 그 범위는 어떤 개발자, 파이프라인, 에이전트, 패키지 소스가 이를 통해 경로를 통과하느냐에 달려 있습니다.

패키지 방화벽을 고를 때 확인해야 할 5가지 기준은? 📋

저장소나 패키지 방화벽은 저장소와 레지스트리 사이에 위치하는 것 이상을 해야 합니다. 옵션을 평가할 때 다음과 같은 것들이 가능한지 고려해 보세요.

1. 패키지가 요청되는 시점에, 다운로드 전에 악성 컴포넌트를 차단할 수 있는가
2. 알려진 취약점이나 의심스러운 패키지 이름 이상의 것을 식별하는 데 도움을 줄 수 있는 최신의 심층 위협 인텔리전스를 사용하는가
3. 공개 패키지 소스에 접근할 수 있는 개발자, CI 파이프라인, AI 에이전트의 요청을 보호하는가
4. 기존 워크플로우를 변경하지 않고도 저장소 도구와 패키지 소스에 맞게 적용할 수 있는가
5. 팀이 사용하는 패키지 생태계를 다루며, 어떤 레지스트리, 미러, 프라이빗 소스가 포함되는지 명확한가

강력한 방화벽 보호는 악성 컴포넌트가 개발 과정에 들어가기 전에 식별하고 차단함으로써 팀이 위협에 앞서 나갈 수 있도록 돕습니다. 패키지 요청을 접수 시점에 평가함으로써 침해된 빌드의 위험과 그에 따른 조사 및 재작업을 줄이고, 팀이 개발을 계속 진행할 수 있도록 돕습니다.

Sonatype의 인텔리전스는 방화벽 판단에 어떻게 반영될까? 🪄

방화벽의 결정은 그 근거만큼만 유용합니다. Sonatype Firewall은 머신러닝 신호와 AI 기반 분석을 Sonatype 보안 연구팀의 전문성과 결합하여 의심스러운 패키지를 식별하고 악성 코드 포함 여부를 조사합니다.

릴리스 동작을 분석하고, 패키지 내용을 검토하며, 여러 출처에 걸친 결과를 연관시켜 Sonatype은 위협을 조기에 탐지하고, 추가로 영향을 받은 패키지를 발견하며, 새로운 발견을 실행 가능한 인텔리전스로 전환하여 Firewall의 차단 및 격리 결정에 반영할 수 있습니다.

이 작업에는 여러 종류의 분석이 포함될 수 있습니다.

분석 방식	내용
활동 및 릴리스 패턴	프로젝트 이력이나 일반적인 생태계 활동과 다르게 동작하는 패키지를 드러내는 데 도움을 줄 수 있습니다.
행동 분석	패키지나 릴리스 주변의 비정상적인 신호를 표시할 수 있습니다. 연구자들은 이러한 발견을 조사하여 해당 컴포넌트가 악성인지 확인할 수 있습니다.
페이로드 분석	자격 증명 도용, 코드 주입, 다른 페이로드 다운로드 등 코드가 실제로 무엇을 하는지 살펴봅니다.
2차 확장	원래 패키지를 넘어 코드를 추적합니다. Advanced Binary Fingerprinting은 패키지의 선언된 의존성에 나타나지 않을 수 있는 내장되거나 이름이 변경된 코드를 식별하는 데 도움을 줍니다. 한 조사에서 Sonatype 연구진은 flatmap-stream 사건과 관련된 코드를 추가로 12개의 npm 컴포넌트에서 발견했습니다.

이 방법들은 패키지 이름이나 매니페스트만으로는 제공할 수 없는 맥락을 함께 제공합니다. 이러한 맥락은 방화벽이 요청을 허용할지, 차단할지, 또는 검토를 위해 보류할지 더 충분한 정보를 바탕으로 결정할 수 있도록 도와줍니다.

결론: 모든 패키지 요청에는 더 안전한 경로가 필요합니다 👷‍♂️

모든 의존성은 요청으로 시작됩니다. 개발자가 패키지를 추가하거나, 파이프라인이 빌드에 끌어들이거나, AI 에이전트가 생성 코드를 위해 선택합니다. 그 요청은 컴포넌트가 소프트웨어의 일부가 되기 전에 평가할 수 있는 기회입니다.

 

Sonatype Firewall은 오픈소스가 소프트웨어 공급망에 진입하는 바로 그 시점에서 팀이 보안과 개발을 하나로 결합할 수 있도록 돕습니다. Sonatype의 연구를 기반으로 하며 지원되는 저장소 환경과 함께 작동하도록 설계되어, 조직이 악성 컴포넌트가 개발자나 워크플로우에 도달하기 전에 미리 차단할 수 있도록 돕습니다. 이를 통해 팀은 진입 시점에서 알려진 위협을 차단하고, 피할 수 있는 혼란을 줄이며, 개발을 더 자신 있게 진행할 수 있습니다.

 

기존 저장소가 안전한 구성 요소 선택을 지원하더라도, 악성 패키지가 개발에 침투할 수 있습니다. 차이는 위협이 어떻게 식별되는지, 새로운 악성 활동이 얼마나 빨리 감지되는지, 그리고 그 정보로 패키지가 다운로드되기 전에 차단할 수 있는지에 달려 있습니다. Sonatype Firewall이 바로 그 차이입니다. 다양한 저장소 관리자와 함께 작동하도록 설계되었기 때문에, 알려진 위험을 차단하고 후속 작업을 피할 수 있는 추가 보호 계층을 더할 수 있습니다.

 

Sonatype Firewall이 어떻게 악성 패키지로부터 저장소를 안전하게 보호할 수 있는지 확인해 보세요.

---

출처

소나타입 블로그 : Your Artifact Repositories Need a Firewall

Your Artifact Repositories Need a Firewall