안녕하세요,
그로메트릭 입니다. 🐸
오픈소스 패키지를 설치하는 개발팀과 CI/CD 파이프라인을 운영하는 조직이라면 눈여겨봐야 할 분석입니다.
소나타입(Sonatype)이 공식 블로그에서 악성 오픈소스 패키지가 왜 유독 CI/CD 자격증명을 노리는지 짚었습니다.
자격증명 하나만 손에 넣어도 소스 코드, 빌드 시스템, 패키지 레지스트리, 클라우드 인프라, 운영 배포 환경까지 닿을 수 있기 때문입니다.
2025년 소나타입이 분석한 악성 패키지 가운데 53%는 설치 단계에서 개발 환경을 노리도록 만들어져 있었습니다.
의존성 하나를 설치했을 뿐인데 악성 릴리스 배포와 빌드 오염으로 번질 수 있다는 점에서, 공급망 보안 관점의 실질적인 비즈니스 리스크로 이어질 수 있는 사안입니다.
*아래 글은 소나타입(Sonatype)의 애런 린스켄스(Aaron Linskens) | 테크니컬 라이터의 공식 블로그 글을 번역하여 작성되었습니다.
공격자는 왜 오픈소스 패키지를 통해 CI/CD 자격증명을 노릴까?
요약
- CI/CD 자격증명 하나로 소스 저장소, 빌드 시스템, 패키지 레지스트리, 클라우드, 배포 환경에 접근할 수 있어 악성 패키지의 핵심 표적이 됩니다. 2025년 소나타입 분석에서 악성 패키지의 53%가 설치 단계에서 개발 환경을 침해하도록 설계돼 있었습니다.
악성 패키지 4,309개를 분석한 결과, 브랜드재킹 악성코드의 91%가 단순 타이포스쿼팅을 넘어선 이름을 사용했습니다.
2025년 소나타입이 식별한 악성코드 어드바이저리는 3,430건으로, AI 확산 이전 연간 기준치(931건)의 3.69배입니다.
방어의 핵심은 패키지가 실행된 뒤가 아니라, 다운로드되어 설치되기 전 단계입니다.
Sonatype은 2026년 1분기에 21,764개의 오픈 소스 악성코드 패키지를 식별했으며, 이로써 2017년 이후 기록된 총 악성코드 수는 1,346,867개에 달합니다. - 이번 분기 악성 패키지 중 npm이 75%를 차지했습니다. 트로이 목마가 주를 이루었으며, 대부분의 활동은 자격 증명 탈취, 호스트 정찰 및 단계별 페이로드 전달에 집중되었습니다.
- 이번 분기의 주요 패턴은 신뢰 악용이었습니다. 공격자들은 신뢰할 수 있는 패키지, 신뢰할 수 있는 릴리스 경로 및 신뢰할 수 있는 워크플로 뒤에 숨어 공격에 성공했습니다.
- 특히 SANDWORM_MODE, LiteLLM 침해, axios 침해라는 세 가지 사건이 두드러졌습니다.
탈취된 CI/CD 토큰은 어떤 권한을 열어줄까? 🚪
CI/CD 자격증명이 특히 위험한 이유는 소프트웨어 전달 과정 전반에 걸쳐 작업을 승인할 수 있는 막강한 권한이 실려 있기 때문입니다. 자격증명의 범위에 따라 공격자는 다음과 같은 일을 할 수 있습니다.
- 비공개 소스 저장소와 빌드 정의에 접근
- 코드나 파이프라인 설정 변경
- 신뢰받는 패키지와 릴리스 게시
- 클라우드 및 배포 환경 접근
- 내부 서비스에 저장된 시크릿 조회
이런 접근 권한은 공격자에게 강력한 발판이 됩니다. 조직과 고객이 이미 신뢰하고 있는 시스템 안에서 움직일 수 있기 때문입니다.
악성 패키지는 여러 보안 통제보다 먼저 이 자격증명에 닿을 수 있습니다. 예를 들어 npm에서는 preinstall, postinstall 스크립트를 악용해 호스트 환경을 살펴보고, 시크릿을 수집하거나, 추가 페이로드를 내려받을 수 있습니다.
개발자 워크스테이션에서는 소스 관리 토큰, SSH 키, 클라우드 자격증명과 마주칠 수 있고, CI 러너에서는 빌드 시크릿, 레지스트리 토큰, 아티팩트 저장소, 배포 서비스까지 접근할 수 있습니다.
보안 검사는 보통 애플리케이션이 만들어진 뒤에 이뤄지지만, 침해는 그보다 앞선 패키지 설치 단계에서 이미 시작될 수 있습니다. 악성 패키지 하나가 수많은 애플리케이션을 빌드하고 배포하는 인프라로 들어가는 통로가 될 수 있으므로, 컴포넌트를 선택하고 내려받아 설치하는 순간을 지키는 것이 중요합니다.
악성 패키지는 어떻게 정상 프로젝트처럼 보일까? 🩺
패키지 위장 하면 흔히 타이포스쿼팅을 떠올립니다. 유명 프로젝트와 한두 글자만 다른 이름으로 악성 패키지를 올리는 수법입니다.
이 수법은 지금도 쓰이지만, 최근의 위장은 훨씬 교묘해졌습니다.
소나타입이 분석한 악성 패키지 4,309개 가운데 브랜드재킹 악성코드의 91%는 전통적인 타이포스쿼팅을 넘어선 이름을 사용했습니다.
정상 프로젝트 곁에 있을 법한 이름, 즉 플러그인, 설정 패키지, SDK, 랩퍼, 유틸리티, 스코프 모듈, 버전 변형 같은 이름입니다.
개발자는 프레임워크나 도구 주변에 여러 보조 패키지가 있을 수 있다는 걸 알기 때문에, 이런 이름은 쉽게 받아들여집니다.
악성 패키지가 정상 프로젝트와 똑같아 보일 필요는 없습니다. 그 근처에 있는 것처럼 보이기만 하면 됩니다.
자격증명이 목적인 공격자에게는 이 잠깐의 신뢰로 충분할 수 있습니다. 패키지는 딱 한 번만 실행되면 되니까요.
패키지 설치 한 번이 공급망 공격으로 이어지는 과정은? 🏹
정상적인 플러그인이나 유틸리티처럼 보이는 패키지가 있다고 가정해 보겠습니다. 개발자나 코딩 에이전트가 이 패키지를 프로젝트에 추가하면, 워크스테이션이나 CI 러너에 설치되는 순간 코드가 실행됩니다.
숨겨진 코드는 자격증명, 토큰, 설정 데이터, 호스트 정보를 뒤져 쓸 만한 것을 공격자에게 보냅니다.
그 자격증명이 소스 관리, 패키지 레지스트리, 빌드 시스템, 클라우드 서비스, 배포 인프라에 접근할 수 있다면, 의존성 하나를 설치한 것만으로 무단 코드 변경, 악성 릴리스, 빌드 오염, 더 깊은 침투로 이어질 수 있습니다.
소나타입의 최근 연구에서 네이밍 변형(naming-variant) 악성코드 데이터셋의 위협 라벨 중 호스트 정보 및 시크릿 유출이 절반 넘게 차지했습니다. 노려진 정보에는 API 키, 레지스트리 및 GitHub 토큰, 클라우드 시크릿, SSH 자격증명, CI/CD 시크릿이 포함됩니다.
피해 규모는 어떤 자격증명이 노출됐는지, 그 권한이 얼마나 큰지에 달려 있습니다. 그중 패키지 매니저 토큰은 특히 위험합니다. 같은 생태계를 통해 악성 업데이트를 직접 배포할 수 있기 때문입니다. 스스로 퍼지는 캠페인에서는 토큰 하나가 패키지 사용자를 다음 악성 릴리스의 배포자로 바꿔 놓기도 합니다.
이렇게 되면 공격자는 신뢰받는 개발자, 빌드 프로세스, 메인테이너의 권한으로 움직이게 됩니다.
AI 코딩 어시스턴트는 왜 의존성 공격 표면을 넓힐까?
AI 코딩 어시스턴트와 에이전트는 의존성을 고르는 속도와 양을 미친듯이 끌어올립니다. 어시스턴트는 몇 초 만에 컴포넌트를 추천하고, 에이전트는 개발 작업을 수행하다가 패키지를 직접 끌어옵니다. 결국 검토해야 할 라이브러리와 업데이트는 늘어나는데, 시간은 한정되어 있습니다.
공격자로서는 소프트웨어 선택에 개입할 기회가 늘어나는 셈입니다. 소나타입은 2025년에 악성코드 어드바이저리 3,430건을 식별했는데, 이는 AI 상용화 이전 데이터인 931건의 3.69배입니다. 대규모 저장소 남용 캠페인을 제외하고 봐도 고유한 악성 페이로드는 50% 넘게 늘었습니다.
추천된 의존성을 사람이 하나하나 조사하는 방식으로는 이 속도를 따라갈 수 없습니다. 그래서 컴포넌트의 위험 정보와 정책 기반 안전장치가 에이전트의 속도에 맞게 즉시 평가하고 걸러내야 합니다.
기존 보안 통제는 왜 설치 시점의 악성코드를 놓칠까? 🕹️
알려진 취약점, 뻔한 타이포스쿼트, 빌드가 끝난 결과물에 초점을 맞춘 통제는 설치 시점의 악성코드를 잡기에 너무 늦을 수 있습니다.
그럴듯한 이름의 신규 패키지는 평판 데이터가 거의 없습니다. 위험성은 동작, 무결성, 게시자 활동, 네이밍 패턴, 더 큰 캠페인과의 연관성을 함께 놓고 봐야 드러납니다.
평판이 쌓이는 데도 시간이 걸립니다. 패키지가 위험하다고 판단될 시점 즈음에는 이미 개발자 워크스테이션, CI 작업, 임시 환경에 들어가 있을 수 있습니다.
의존성을 제거한다고 침해가 종결되는 것도 아닙니다. 패키지가 어디서 실행됐는지 파악하고, 어떤 시크릿에 접근할 수 있었는지 확인하고, 자격증명을 교체하고, 후속 활동을 조사하고, 영향받은 아티팩트를 다시 빌드해야 할 수 있습니다.
빈틈은 최종 빌드 순간뿐만 아니라 컴포넌트를 처음 도입하는 순간에도 있습니다.
자격증명을 지키려면 악성 코드가 실행되기 전에 무엇을 해야 할까? ✅
오픈소스 악성코드에 대한 1차 방어는 애초에 개발 환경으로 들어오지 못하게 막는 것입니다. 패키지가 개발자 워크스테이션이나 CI 러너에서 한 번 실행되고 나면, 자격증명과 시크릿, 환경 데이터에 이미 접근했을 수 있습니다.
조직은 다음과 같이 대응해야 합니다.
- 설치 전에 의존성 선택을 관리합니다. AI 지원 워크플로우로 들어오는 컴포넌트도 예외가 아닙니다.
- 저장소와 업스트림 접근 경로를 통제 지점으로 삼습니다. 개발 환경에 무엇이 들어오는지 이 경로에서 걸러냅니다.
- 모든 환경에 일관된 통제를 적용합니다. 개발자 워크스테이션, 저장소, CI/CD 시스템, 임시 환경이 모두 대상입니다.
- 알려진 악성 이름만 보지 않습니다. 패키지의 동작, 무결성, 게시자 패턴, 네이밍 규칙, 캠페인 맥락을 함께 평가합니다.
- 방어에 실패했을 때의 피해 범위를 줄입니다. 최소 권한의 단기 자격증명을 쓰고, 시크릿은 꼭 필요한 작업에만 제공합니다.
자격증명과 시크릿 관리는 여전히 중요한 안전장치입니다. 다만 이는 침해의 영향을 줄여줄 뿐, 악성 패키지가 환경에 들어오는 것 자체를 막아주지는 못합니다. 사전 보호 체계를 갖추면 처음부터 위험을 낮출 수 있습니다.
결론: 핵심 통제 지점은 패키지 다운로드 이전 단계입니다
악성 패키지가 개발자 워크스테이션이나 CI 러너에서 실행될 즈음에는 자격증명과 환경 데이터가 이미 노출됐을 수 있습니다. 그래서 가장 효과적인 통제 지점은 컴포넌트를 내려받아 설치하기 전, 즉 업스트림 단계입니다.
Sonatype Firewall은 소나타입의 오픈소스 인텔리전스와 악성코드 연구를 바탕으로 다운로드 시점에 컴포넌트를 평가해, 의심스럽거나 악성인 패키지가 저장소와 개발 워크플로우로 들어오기 전에 차단하거나 격리합니다. 서드파티 저장소 관리자를 쓰는 조직이라면
Sonatype Firewall Pro로 저장소를 옮기지 않고도 악성 패키지 보호를 적용할 수 있습니다.
공격자가 CI/CD 자격증명을 노리는 이유는, 패키지 설치 한 번을 신뢰받는 소프트웨어 배포 체계에 대한 권한으로 바꿀 수 있기 때문입니다. 이 권한을 지키려면 파이프라인 자체와, 파이프라인으로 들어오는 의존성 결정을 함께 보호해야 합니다.
소나타입이 위험한 컴포넌트가 개발 및 CI/CD 환경에 닿기 전에 악성 오픈소스 행위를 식별하고 차단하는 방식은 소나타입 악성코드 보호 솔루션 페이지에서 확인할 수 있습니다.
출처
소나타입 블로그 : Why Are OSS Attackers Always After CI/CD Credentials?
Why Are OSS Attackers Always After CI/CD Credentials?
Learn why attackers target CI/CD credentials through malicious open source packages and how organizations can block malware before it reaches development.
www.sonatype.com
'Security Insights & Trends' 카테고리의 다른 글
| TensorLake 악성 릴리즈 npm 공급망 공격 - 설치 한 번에 자격증명 위협까지 (0) | 2026.10.14 |
|---|---|
| AI 코딩 에이전트가 바꾸는 SDLC: 오픈소스 의존성 거버넌스 전략 (0) | 2026.10.02 |
| SBOM·소프트웨어 공급망 지속가능성, 오픈소스 배포 최적화부터 🏋️♂️ (1) | 2026.09.16 |
| AI 토큰 비용 최적화, 초기 의존성 결정이 좌우한다 (0) | 2026.09.11 |
| 스프링 CVE 91건 대량 발견: AI 시대 오픈소스 취약점 리스크 (0) | 2026.08.26 |