에스코어 인사이트
원문에 앞서 국내 개발·보안·플랫폼 조직이 함께 점검할 만한 사항을 간단히 정리했습니다.
•
의존성 설치 이전을 보안 통제 지점으로 설정: 악성 패키지는 애플리케이션 빌드가 끝나기 전에 개발자 PC나 CI Runner에서 실행될 수 있습니다. 저장소와 외부 패키지 유입 경로에서 설치 전 검증과 차단 체계를 두는 것이 중요합니다.
•
CI/CD 자격 증명은 최소 권한·단기 수명 원칙으로 관리: 패키지 설치 과정에서 토큰이 노출되더라도 소스 저장소, 레지스트리, 클라우드, 배포 시스템 전체로 피해가 확산되지 않도록 권한 범위와 유효 기간을 최소화해야 합니다.
•
AI가 늘리는 의존성 선택 속도에 맞춰 정책을 자동화: AI 코딩 도구가 더 많은 컴포넌트를 더 빠르게 제안하는 만큼, 수동 검토만으로는 대응하기 어렵습니다. 패키지 행위·무결성·게시자 패턴·캠페인 연관성을 자동 평가하는 정책 가드레일이 필요합니다.
Sonatype 원문 번역
악성 오픈소스 패키지가 CI/CD 자격 증명을 주요 표적으로 삼는 이유는 자격 증명에 부여된 권한이 매우 크기 때문입니다. 권한 범위에 따라 소스 코드, 빌드 시스템, 패키지 레지스트리, 클라우드 인프라, 운영 배포 환경까지 접근할 수 있습니다.
탈취한 자격 증명 하나만으로도 공격자는 감염된 의존성 하나를 소프트웨어 공급망 전체로 이어지는 침투 경로로 바꿀 수 있습니다.
악성 패키지는 공격자가 이러한 권한에 이른 단계부터 접근할 수 있게 해줍니다. 패키지가 설치 과정에서 실행되면 Pull Request가 생성되거나 빌드가 완료되거나 기존 애플리케이션 보안 스캔이 시작되기 전에 토큰, 시크릿, 기타 민감 정보를 수집할 수 있습니다.
패키지 설치는 공격의 진입점일 수 있습니다. 하지만 공격자의 더 큰 목적은 신뢰받는 소프트웨어 배포 체계를 장악하는 데 있습니다.
탈취된 토큰이 가진 권한
CI/CD 자격 증명은 소프트웨어 배포 과정 전반에서 여러 작업을 승인할 수 있기 때문에 공격자에게 특히 가치가 높습니다. 탈취된 자격 증명의 권한 범위에 따라 공격자는 다음과 같은 작업을 수행할 수 있습니다.
•
비공개 소스 저장소와 빌드 정의에 접근
•
코드나 파이프라인 설정 변경
•
신뢰받는 패키지나 릴리스 게시
•
클라우드와 배포 환경 접근
•
내부 서비스에서 시크릿 조회
탈취한 자격 증명으로 확보한 접근 권한은 공격자에게 강력한 수단이 됩니다. 공격자는 조직과 고객이 이미 신뢰하는 시스템의 권한을 이용해 활동할 수 있습니다.
악성 패키지는 많은 보안 통제가 작동하기 전에 자격 증명에 접근할 수 있습니다. 예를 들어 npm에서는 공격자가 preinstall과 postinstall 스크립트를 악용해 호스트 정보를 조사하고, 시크릿을 수집하거나, 추가 페이로드를 내려받을 수 있습니다. 개발자 워크스테이션에서는 소스 제어 토큰, SSH 키, 클라우드 자격 증명을 찾을 수 있습니다. CI Runner에서는 빌드 시크릿, 레지스트리 토큰, 아티팩트 저장소, 배포 서비스에 접근할 가능성이 있습니다.
따라서 완성된 애플리케이션을 스캔하기 전에도 침해가 발생할 수 있습니다. 악성 패키지 하나가 여러 애플리케이션을 빌드하고 배포하는 인프라로 이어지는 경로를 만들 수 있으므로, 컴포넌트가 선택되고 다운로드되어 설치되는 순간을 보호하는 것이 중요합니다.
공격자에게 필요한 것은 완벽한 복제가 아니라 그럴듯한 패키지다
패키지 사칭 공격을 설명할 때 흔히 등장하는 방식은 타이포스쿼팅입니다. 인기 프로젝트 이름에서 한두 글자만 바꾼 악성 패키지를 게시하는 수법입니다.
타이포스쿼팅은 여전히 사용되지만, 최근 패키지 위장 방식은 더 정교해졌습니다.
Sonatype이 악성 패키지 4,309개를 분석한 결과, 브랜드를 사칭한 악성코드의 91%는 기존 타이포스쿼팅을 넘어선 이름을 사용했습니다. 공격자는 정상 프로젝트 주변에 있을 법한 플러그인, 설정 패키지, SDK, 래퍼, 유틸리티, 스코프 모듈, 버전 변형 패키지처럼 보이는 이름을 사용했습니다.
이런 이름이 효과적인 이유는 개발자가 프레임워크와 도구 주변에 수많은 지원 패키지가 존재한다고 자연스럽게 예상하기 때문입니다. 악성 패키지가 신뢰받는 프로젝트와 시각적으로 완전히 같을 필요는 없습니다. 같은 생태계에 속한 패키지처럼 보이기만 해도 충분합니다.
자격 증명을 노리는 공격자에게는 짧은 순간의 신뢰만으로도 충분할 수 있습니다. 악성 패키지는 한 번만 실행되면 됩니다.
자격 증명 탈취가 패키지 설치를 공급망 공격으로 바꾸는 과정
정상 플러그인이나 유틸리티처럼 보이는 패키지를 생각해 보겠습니다. 개발자나 코딩 에이전트가 해당 패키지를 프로젝트에 추가하면, 패키지는 워크스테이션이나 CI Runner에 설치되는 과정에서 실행됩니다. 숨겨진 코드는 자격 증명, 토큰, 설정 데이터, 호스트 정보를 찾아 공격자에게 전송합니다.
탈취한 자격 증명으로 소스 제어 시스템, 패키지 레지스트리, 빌드 시스템, 클라우드 서비스, 배포 인프라에 접근할 수 있다면 의존성 하나를 설치한 것만으로도 무단 코드 변경, 악성 릴리스, 오염된 빌드, 더 깊은 시스템 침투로 이어질 수 있습니다.
최근 Sonatype 연구에 따르면 이름 변형 악성코드 데이터셋에서 호스트 정보 및 시크릿 유출이 전체 위협 라벨의 절반 이상을 차지했습니다. 공격 대상에는 API 키, 레지스트리 및 GitHub 토큰, 클라우드 시크릿, SSH 자격 증명, CI/CD 시크릿이 포함됐습니다.
피해 규모는 어떤 자격 증명이 노출됐는지, 그리고 해당 자격 증명이 어떤 권한을 가졌는지에 따라 달라집니다. 패키지 관리자 토큰은 특히 가치가 높습니다. 공격자가 동일한 신뢰 생태계를 이용해 악성 업데이트를 게시할 수 있기 때문입니다. 스스로 확산하는 공격에서는 탈취한 토큰 하나로 패키지 사용자가 다음 악성 릴리스의 게시자가 될 수 있습니다.
AI가 의존성 선택 속도를 높인다
AI 코딩 어시스턴트와 에이전트는 의존성 선택의 속도와 횟수를 늘립니다. 어시스턴트는 몇 초 만에 컴포넌트를 추천할 수 있고, 에이전트는 개발 작업을 수행하면서 패키지를 직접 추가할 수 있습니다. 그 결과 더 많은 라이브러리와 업데이트가 검토 대상에 들어오지만, 각각의 선택에 들이는 시간은 줄어들 수 있습니다.
소프트웨어 선택이 빨라질수록 공격자가 패키지 선택에 영향을 줄 기회도 늘어납니다. Sonatype은 2025년에 3,430건의 악성코드 어드바이저리를 확인했습니다. AI 도입 이전의 연간 기준치인 931건보다 3.69배 많습니다. 대규모 저장소 악용 캠페인을 제외해도 서로 다른 악성 페이로드 수는 50% 이상 증가했습니다.
모든 의존성 추천을 사람이 일일이 조사하는 방식으로는 이런 속도를 따라갈 수 없습니다. 컴포넌트 인텔리전스와 정책 가드레일도 에이전트형 워크플로가 움직이는 속도에 맞춰 의존성 선택을 평가해야 합니다.
기존 보안 통제가 결정적 순간을 놓치는 이유
알려진 취약점, 명백한 타이포스쿼팅, 완성된 아티팩트에 초점을 맞춘 통제는 설치 시점에 실행되는 악성코드를 막기에는 늦을 수 있습니다.
그럴듯한 이름을 가진 신규 패키지는 처음 등장했을 때 평판 정보가 거의 없을 수 있습니다. 패키지의 행위, 무결성, 게시자 활동, 이름 패턴, 광범위한 공격 캠페인과의 연관성을 함께 평가해야 위험이 드러나는 경우도 있습니다.
평판 데이터가 쌓이는 데에도 시간이 필요합니다. 외부 신호가 충분히 축적돼 위험한 패키지로 보일 때쯤이면 이미 개발자 워크스테이션이나 CI 작업, 임시 실행 환경에 도달했을 수 있습니다.
의존성을 삭제했다고 해서 사고 대응이 끝나는 것은 아닙니다. 보안팀은 해당 패키지가 어디에서 실행됐는지 확인하고, 어떤 시크릿에 접근할 수 있었는지 파악하고, 자격 증명을 교체하고, 후속 활동을 조사하고, 영향을 받은 아티팩트를 다시 빌드해야 할 수 있습니다.
보안의 사각지대는 최종 빌드만이 아니라 의존성을 채택하는 순간에도 존재합니다.
악성 코드가 실행되기 전에 자격 증명을 보호하라
오픈소스 악성코드에 대응하는 가장 중요한 방어는 악성 패키지가 개발 환경에 들어오기 전에 차단하는 것입니다. 패키지가 개발자 워크스테이션이나 CI Runner에서 실행된 뒤에는 이미 자격 증명, 시크릿, 환경 데이터에 접근했을 가능성이 있습니다.
조직은 다음과 같은 통제를 적용해야 합니다.
•
AI 지원 워크플로에서 추가되는 컴포넌트를 포함해, 설치 전에 의존성 선택을 관리합니다.
•
저장소와 업스트림 접근 경로를 개발 환경으로 유입되는 소프트웨어의 통제 지점으로 활용합니다.
•
개발자 워크스테이션, 저장소, CI/CD 시스템, 임시 실행 환경에 일관된 통제를 적용합니다.
•
이미 알려진 악성 패키지 이름만 확인하지 말고 패키지 행위, 무결성, 게시자 패턴, 명명 규칙, 공격 캠페인 연관성을 함께 평가합니다.
•
예방에 실패하더라도 피해 범위를 줄일 수 있도록 최소 권한의 단기 자격 증명을 사용하고, 필요한 작업에만 시크릿 접근을 허용합니다.
자격 증명과 시크릿 관리 원칙은 여전히 중요한 보호 수단입니다. 다만 이러한 원칙은 악성 패키지가 환경에 들어오는 것 자체를 막기보다 침해가 발생했을 때의 피해를 줄이는 역할을 합니다. 선제적 보호 체계를 갖추면 처음부터 위험을 낮출 수 있습니다.
파이프라인이 가진 권한을 보호하라
악성 패키지가 개발자 워크스테이션이나 CI Runner에서 실행될 때는 자격 증명과 환경 데이터가 이미 노출됐을 수 있습니다. 따라서 가장 강력한 통제 지점은 컴포넌트를 다운로드하고 설치하기 전의 업스트림 구간입니다.
Sonatype Firewall은 Sonatype의 오픈소스 인텔리전스와 악성코드 연구 정보를 활용해 다운로드 시점에 컴포넌트를 평가하고, 의심스럽거나 악성인 패키지가 저장소와 개발 워크플로에 들어오기 전에 차단하거나 격리합니다. 타사 저장소 관리자를 사용하는 조직은 저장소를 마이그레이션하지 않고도 Sonatype Firewall Pro를 이용해 악성 패키지를 차단할 수 있습니다.
공격자가 CI/CD 자격 증명을 노리는 이유는 자격 증명 하나로 단순한 패키지 설치를 신뢰받는 소프트웨어 배포 체계에 대한 권한 탈취로 바꿀 수 있기 때문입니다. CI/CD 자격 증명이 제공하는 권한을 보호하려면 파이프라인 자체뿐 아니라 파이프라인으로 들어가는 의존성 선택 과정도 함께 보호해야 합니다.
자주 묻는 질문
공격자는 왜 CI/CD 자격 증명을 노리나요?
CI/CD 자격 증명은 소스 저장소, 빌드 시스템, 패키지 레지스트리, 클라우드 인프라, 배포 환경에 접근할 수 있는 권한을 제공할 수 있습니다. 공격자는 이미 소프트웨어 빌드와 배포에 신뢰받고 있는 시스템의 권한을 이용해 활동할 수 있습니다.
악성 오픈소스 패키지가 CI/CD 시크릿을 탈취할 수 있나요?
그렇습니다. 악성 코드가 워크스테이션이나 CI Runner에서 실행되면 환경 변수, 설정 파일, 자격 증명 저장소, 토큰과 시크릿이 들어 있는 기타 위치를 조사할 수 있습니다.
패키지 설치가 어떻게 빌드 파이프라인 침해로 이어지나요?
악성 패키지는 설치 과정에서 실행되어 자격 증명을 수집하고 공격자에게 전송할 수 있습니다. 탈취된 자격 증명은 소스 코드, 빌드 워크플로, 패키지 게시 시스템, 연결된 인프라에 접근하는 데 사용될 수 있습니다.
이름 변형 공격이란 무엇인가요?
이름 변형 공격은 신뢰받는 소프트웨어와 관련된 플러그인, SDK, 설정 패키지, 래퍼, 유틸리티처럼 보이도록 패키지 이름을 설계하는 공격입니다. 단순 철자 오류만 노리는 대신 소프트웨어 생태계의 명명 관습을 악용합니다.
조직은 오픈소스 악성코드로부터 CI/CD 자격 증명을 어떻게 보호할 수 있나요?
조직은 최소 권한의 단기 자격 증명과 설치 전 의존성 평가 통제를 함께 적용해야 합니다. 또한 시크릿 노출 범위를 줄이고, 패키지와 게시자의 행위를 모니터링하고, 개발 환경 전반에 일관된 정책을 적용하고, 저장소나 업스트림 접근 경로에서 악성 컴포넌트를 차단해야 합니다.
에스코어는 Sonatype 공식 파트너로서 소프트웨어 공급망 보안 및 오픈소스 거버넌스 구축을 지원합니다.
도입이나 구축이 필요하시면 언제든 문의해 주세요.
지원 솔루션: Nexus Repository · Repository Firewall · Lifecycle · Sonatype Guide