software

공급망 보안 강화: 다음 멀웨어 캠페인에 대비하기

발행: (2025년 12월 24일 오전 08:52 GMT+9)
14 분 소요
원문: GitHub Blog

Source: GitHub Blog

개요

오픈‑소스 생태계는 손상된 자격 증명과 악성 패키지‑라이프사이클 스크립트를 통해 퍼지는 조직적이고 적응적인 공급‑체인 위협에 계속 직면하고 있습니다. 가장 최근 사례는 다중 파동 Shai‑Hulud 캠페인입니다.

우리가 보고 있는 현황

  • 빠른 학습: 적대자는 전술을 신속하게 적응합니다.
  • 대상형 유지관리자 워크플로우: 공격자는 패키지 유지관리의 인간 및 프로세스 요소에 집중합니다.
  • 신뢰 경계 악용: 배포 파이프라인을 이용해 악성 코드를 주입합니다.

지속 가능한 교훈

  1. Assume breach: 모든 자격 증명이 잠재적으로 손상되었다고 가정합니다.
  2. Secure the pipeline: 누가 배포할 수 있는지, 어떤 스크립트를 실행할 수 있는지에 대해 엄격한 제어를 시행합니다.
  3. Monitor for anomalies: CI/CD, 배포 및 자격 증명 사용에서 비정상적인 활동을 감시합니다.

Actionable Recommendations

  • Rotate credentials 정기적으로 회전하고 비밀 관리자를 사용해 저장하세요.
  • Enable two‑factor authentication (2FA) 모든 유지보수자 계정에 적용하세요.
  • Restrict write access 필요한 사람에게만 부여하고 최소 권한 원칙을 따르세요.
  • Audit package‑lifecycle scripts 병합하거나 실행하기 전에 검토하세요.
  • Implement supply‑chain scanning 도구를 사용해 악성 코드 패턴을 탐지하세요.
  • Set up alerts 패키지 다운로드 급증이나 게시 빈도 급변에 대한 알림을 설정하세요.

앞으로의 전망

  • 향상된 credential‑leak detection 메커니즘.
  • 보안 규칙의 자동 적용을 위한 새로운 policy‑as‑code 기능.
  • 의존성 출처 및 무결성 검증에 대한 visibility 향상.

이 게시물은 유지보수자와 조직이 시스템을 강화하고 다음 캠페인에 대비하도록 돕는 지속 가능한 교훈과 행동을 정리합니다—단지 지난 캠페인에만 대응하는 것이 아니라.

최근 Shai‑Hulud 캠페인

Shai‑Hulud는 JavaScript 공급망을 목표로 하는 다중 파동(coordinated, multi‑wave) 캠페인입니다. 초기의 기회주의적 침해에서 엔지니어링된 표적 공격으로 진화했습니다.

파동 1 – 손상된 유지관리자 계정

  • 패키지에 악성 post‑install scripts를 삽입했습니다.
  • 목표: 의존성에 악성 코드를 삽입하고, 비밀을 유출하며, 자체 복제하기.
  • 단일 발판이 생태계 전체에 어떻게 파급될 수 있는지를 보여주었습니다.

파동 2 – Shai‑Hulud 2.0

  • Self‑replication이 업그레이드되어 피해자 간 자격 증명 노출을 가능하게 함.
  • 자체 호스팅 러너 등록을 통한 endpoint command‑and‑control 추가.
  • 더 넓은 범위의 비밀을 수집해 추가 전파에 활용하고 파괴 기능을 도입.
  • CI 환경에 초점 전환:
    • CI 파이프라인 내부에서 실행될 때를 감지.
    • 특정 빌드 에이전트를 목표로 하는 권한 상승 기법을 배포.
  • 첫 번째 파동 페이로드보다 탐지하기 어려운 multi‑stage payload 사용.
  • 변종 사이의 짧은 타임라인은 커뮤니티 방어를 연구하고 빠르게 반복하는 조직적인 적을 시사합니다.

파동 전반에 걸친 공통 특성

  • 자격 증명 인접 침해

    • 손상된 자격 증명 또는 OAuth 토큰을 통한 초기 발판.
    • 추가 비밀(NPM 토큰, CI 토큰, 클라우드 자격 증명) 수집으로 피벗.
    • 단일 실패 지점 없이 조직 간 및 향후 파동에 재사용 가능.

  • 설치 시점 실행 및 난독화

    • 패키지(또는 의존성 체인)에 삽입된 악성 post‑install 또는 lifecycle 스크립트.
    • 페이로드는 조건부로 활성화(예: 환경 검사, 조직 스코프).
    • 유출 기법은 런타임 환경에 맞게 맞춤화.

  • 신뢰받는 네임스페이스 및 내부 패키지 이름 표적

    • 인기 있고 신뢰받는 패키지에 영향을 줌.
    • 감염된 패키지는 기존 이름으로 게시됨.
    • 파동 2는 정식 업데이트처럼 보이도록 버전 번호를 패치하여 정상적인 유지관리자 활동과 혼합.

  • 방어에 대한 빠른 반복 및 엔지니어링

    • 변종 사이의 짧은 간격.
    • 이전 완화 조치를 우회하기 위한 의도적인 변경.
    • 목표: 일회성 기회주의가 아니라 지속 가능한 접근과 확장 가능한 확산.

  • 출판 파이프라인의 검토 사각지대

    • 소스와 게시된 아티팩트 간 불일치.
    • Lifecycle 스크립트와 빌드‑타임 변환이 격차를 만듦.
    • 아티팩트 검증이나 단계적 승인 없이 삽입된 동작이 눈에 띄지 않고 통과될 수 있음.

요약

최근 파동은 방어자가 출판 모델과 자격 증명 흐름을 사전적으로 강화해야 함을 재확인시킵니다. 변종 하나에 맞춘 완화가 아니라, 아티팩트의 지속적인 검증, 엄격한 CI 파이프라인 제어, 그리고 철저한 자격 증명 관리가 Shai‑Hulud 공급망 위협을 차단하는 핵심입니다.

npm의 다음 단계

우리는 변화하는 위협 환경에 대응하기 위해 보안 로드맵을 가속화하고 있습니다. 앞으로 우리의 즉각적인 초점은 다음을 지원하는 데 있습니다:

  • Bulk OIDC onboarding – 수백 개의 패키지를 규모 있게 신뢰할 수 있는 퍼블리싱으로 마이그레이션하도록 돕는 간소화된 도구.
  • Expanded OIDC provider support – GitHub Actions와 GitLab 외의 추가 CI 제공자를 지원하도록 확대.
  • Staged publishing – 패키지가 실시간으로 공개되기 전에 유지 관리자가 검토 기간을 가질 수 있게 하는 새로운 퍼블리케이션 모델로, 패키지 소유자의 MFA‑인증 승인을 필요로 합니다. 이는 팀이 의도치 않은 변경을 다운스트림 사용자에게 전달되기 전에 포착할 수 있게 하며, 커뮤니티가 수년간 요청해 온 기능입니다.

이러한 투자를 통해 유지 관리자는 퍼블리케이션 프로세스의 모든 단계에서 패키지를 보다 강력하고 유연하게 보호할 수 있는 도구를 얻게 됩니다.

GitHub 및 npm 사용자와 유지관리자를 위한 조언

Shai‑Hulud와 같은 악성코드는 npm 패키지에 악성 코드를 삽입함으로써 퍼집니다. 이 코드는 설치 과정에서 실행되어 패키지를 설치하는 모든 사용자를 위험에 빠뜨립니다. npm 패키지는 보통 많은 의존성을 가지고 있기 때문에, 하나의 패키지만 손상돼도 간접적으로 많은 다른 패키지에 영향을 줄 수 있습니다. 공격자는 수집한 토큰을 보관해 두었다가 몇 주 혹은 몇 달 뒤에 새로운 공격을 시작하기도 합니다.

아래는 핵심 권고 사항을 간략히 정리한 것입니다. 보다 자세한 분석과 추가 지침은 아래 “References” 섹션을 참고하십시오.

모두를 위한 조언

  • 모든 계정에 피싱 방지 MFA를 활성화하세요. 특히 다음과 같은 패키지 관리자에 적용합니다.

  • 토큰 만료일을 설정하고 정기적으로 토큰을 교체하세요. 조직에서는 최대 수명 정책을 적용할 수 있습니다.

  • 사용하지 않는 GitHub/OAuth 앱에 대한 감사 및 권한 회수를 수행하세요.

  • 샌드박스(예: GitHub Codespaces, 가상 머신, 컨테이너)에서 개발하여 실수로 실행되는 악성코드의 영향을 최소화하세요.

유지관리자를 위한 조언

  • 브랜치 보호를 활성화해 공격자가 유효한 토큰을 입수하더라도 메인 브랜치에 직접 푸시할 수 없게 하세요.

  • 신뢰할 수 있는 퍼블리싱을 사용하고 장기 토큰 사용을 피하세요. 신뢰할 수 있는 퍼블리싱은 다음에서 제공됩니다.

    • npm
    • PyPI
    • RubyGems
    • NuGet

  • CI 의존성 고정, 코드 스캔 활성화, 그리고 알림이 발생하면 즉시 해결하세요.

    • 의존성 고정:
    • 코드 스캔:
    • 알림 해결:

  • 배포된 아티팩트 검증(예: Subresource Integrity 또는 아티팩트 빌드 증명)으로 배포된 tarball/번들이 원본과 일치하는지 확인하세요.

    • SRI:
    • 아티팩트 증명:

침해가 의심될 경우, **GitHub Support**에 연락하여 도움을 받으세요.

참고 문헌

작성자

Madison Oliver

Madison Oliver는 취약점 투명성 옹호자이자 GitHub의 선임 보안 매니저로, Advisory Database 큐레이션 팀을 이끌고 있습니다. 그녀는 취약점 보고, 대응 및 공개에 열정을 가지고 있으며, 관련 Open Source Security Foundation (OpenSSF) 워킹 그룹의 공동 의장을 맡고 CVE 프로그램 보드에도 참여하고 있습니다. 그녀의 관점은 GitHub에서 제품 사고 대응 분석가로 일한 경험과 Carnegie Mellon University 소프트웨어 엔지니어링 연구소의 CERT Coordination Center에서 취약점 코디네이터로 활동한 이전 경험에 의해 풍부해졌습니다.

관련 게시물

(목록 없음)

GitHub에서 더 알아보기

Docs Docs
GitHub를 마스터하는 데 필요한 모든 것을 한 곳에서 제공합니다.		문서로 이동 →
GitHub GitHub
누구든지 어디서든 무엇이든 만들 수 있는 GitHub에서 다음을 구축하세요.		시작하기 →
Customer stories Customer stories
GitHub와 함께 구축하는 기업과 엔지니어링 팀을 만나보세요.		자세히 보기 →
The GitHub Podcast The GitHub Podcast
오픈소스 개발자 커뮤니티의 주제, 트렌드, 스토리, 문화 등을 다루는 팟캐스트를 들어보세요.		지금 듣기 →
Back to Blog

관련 글

더 보기 »