샤이-훌루드와 메갈로돈: 출처만으로는 왜 충분하지 않은가

이 블로그 글의 AI 요약으로 바로 가기

요약

내용: Shai-Hulud와 Megalodon은 2026년에 발생한 소프트웨어 공급망 공격으로, 개발자들이 가장 신뢰하는 시스템인 패키지 레지스트리, GitHub Actions 워크플로, CI/CD 러너, 출처 추적 파이프라인, 클라우드 ID 페더레이션을 표적으로 삼았습니다.

영향: ‘Mini Shai-Hulud’는 TanStack, Mistral AI, Guardrails AI, UiPath, OpenSearch와 관련된 패키지를 포함해 npm 및 PyPI 패키지를 침해했으며, 유효한 SLSA 빌드 레벨 3 출처 정보를 가진 악성코드를 배포한 것으로 널리 기록된 최초의 공격 사례였습니다(CVE-2026-45321, CVSS 9.6). 이후 Megalodon은 약 6시간 동안 5,561개의 GitHub 저장소에 5,718건의 악성 커밋을 푸시하여, GitHub Actions 워크플로우에 백도어를 심고 클라우드 인증 정보, SSH 키, GitHub 토큰, OIDC 토큰 데이터 및 소스 코드 기밀 정보를 탈취했습니다.

현황: 이러한 사례들은 더 이상 최신 뉴스는 아니지만, 여기서 얻을 수 있는 교훈은 여전히 유효합니다. 노출된 인증 정보, 비활성 상태인 악성 워크플로우, 보안이 침해된 패키지 버전, 또는 정리되지 않은 지나치게 광범위한 CI/CD 신뢰 정책 등은 여전히 하류 단계에 위험을 초래할 수 있습니다.

중요도: 공급망에 미치는 영향이 크다. 이는 패치를 적용하고 넘어갈 수 있는 단일 취약점 패키지나 하나의 CVE 문제가 아니다. 소프트웨어를 빌드하고 배포하는 시스템에 대한 반복 가능한 공격 패턴이다.

패키지 도입에 있어 이것이 중요한 이유: 메갈로돈은 소스 코드와 공개 버전 간의 시차(source-to-publication gap)를 악용했습니다. 정당한 유지보수자가 자신도 모르게 악성 소스 코드를 기반으로 패키지를 공개할 수 있었기 때문에, 공격자는 npm 계정을 탈취할 필요가 없었습니다. SecureChain은 새로운 패키지 버전이 다운스트림에서 신뢰받기 전에, 온보딩 시점에 소스 코드 차이 분석, 빌드 시간 훅, 난독화된 페이로드, 숨겨진 실행 경로, 정보 유출 행동 등을 분석함으로써 바로 이러한 격차를 해소하도록 설계되었습니다.

지금 당장 다음 조치를 취하십시오: GitHub Actions 워크플로를 점검하고, 메갈로돈(Megalodon) 징후를 확인하며, 의심스러운 CI 실행기에 노출된 비밀 정보를 교체하고, 영향을 받은 패키지 도입 현황을 검토하며, OIDC 신뢰 정책을 강화하십시오.

저도 영향을 받나요?

귀하의 조직이 다음 중 하나에 해당할 경우 영향을 받을 수 있습니다:

빌드, 테스트, 릴리스, 패키지 게시 또는 배포에 GitHub Actions를 사용합니다.
워크플로가 id-token을 요청할 수 있도록 허용: 쓰기
CI/CD 환경에서 클라우드, 레지스트리, SSH, Docker, Kubernetes, Terraform 또는 Vault의 인증 정보를 저장합니다.
추가적인 도입 통제 절차 없이 공개 레지스트리의 npm 또는 PyPI 패키지를 가져옵니다.
2026년 5월 노출 기간 동안 해당 Mini Shai-Hulud 패키지를 설치했습니다.
@tiledesk/tiledesk-server 버전 2.18.6부터 2.18.12까지 설치됨
기본 브랜치로 직접 푸시할 수 있습니다
.github/workflows 변경 사항에 대해서는 검토가 필요하지 않습니다.
의존성이 안전하다는 증거로 출처, 서명 또는 익숙한 패키지 게시자를 간주합니다.

우선 시작하기 좋은 방법은 저장소에서 알려진 메갈로돈 워크플로우 이름과 C2 주소를 검색해 보는 것입니다:

grep -R "SysDiag\|Optimize-Build\|216\.126\.225\.129" .github/workflows/ 2>/dev/null

그런 다음 워크플로우 내에서 인코딩된 쉘 실행 코드를 찾아보세요:

grep -R "base64 -d.*bash\|base64.*| *bash" .github/workflows/ 2>/dev/null

두 검색 중 하나라도 예상치 못한 결과가 나오면, 파일을 삭제하거나 인증 정보를 갱신하기 전에 리포지토리 이력과 CI 로그를 검토하십시오. 어떤 작업이 언제 실행되었는지, 그리고 어떤 비밀 정보가 노출되었는지 파악하기 위해 로그가 필요할 수 있습니다.

샤이-훌루드와 메갈로돈이란 무엇인가

Shai-Hulud는 개발자 생태계, 특히 npm과 PyPI를 대상으로 하는 자가 증식형 공급망 공격 계열에 붙여진 이름입니다.

이 웜의 최초 변종은 2025년 9월에 등장했는데, 당시 유닛 42(Unit 42)는 자격 증명을 탈취해 이를 이용해 확산되는 자가 복제형 npm 웜을 확인했습니다. 그 뒤를 이어 11월에는 더 광범위하게 확산된 변종인 ‘Shai-Hulud 2.0’이 등장했습니다. 2026년 봄이 되자, ‘TeamPCP’로 추적된 위협 행위자는 수개월에 걸쳐 신뢰도가 높은 개발자 및 보안 도구에 백도어를 심어왔습니다.

2026년 5월의 공격 물결인 ‘미니 샤이-훌루드’는 공격의 수위를 한층 높였습니다. 이 공격은 단순히 명백히 의심스러운 계정을 통해 악성 패키지를 배포하는 데 그치지 않았습니다. 정상적인 빌드 파이프라인을 장악한 뒤, 이를 이용해 유효한 출처 인증 정보를 포함하는 악성 패키지를 생성했습니다.

메갈로돈은 다른 차원의 공격을 감행했습니다. 패키지 공개에 집중하는 대신, 수천 개의 저장소에 GitHub Actions 워크플로를 대량으로 주입했습니다. 이러한 워크플로는 CI 러너 내에서 실행되며, CI/CD 시스템이 설계상 보관하고 있는 비밀 정보—클라우드 인증 정보, GitHub 토큰, SSH 키, OIDC 토큰 요청 데이터, Docker 인증 정보, 쿠버네티스 구성 정보, Terraform 인증 정보, Vault 토큰, 소스 코드 내 비밀 정보 등—를 탈취했습니다.

이 두 캠페인을 종합해 보면 동일한 추세가 드러납니다. 공격자들은 더 이상 사용자가 설치하는 패키지 자체만을 감염시키려 하지 않습니다. 그들은 해당 패키지를 빌드하고, 서명하고, 배포하며, 적용하는 시스템 자체를 감염시키려 하고 있습니다.

1차 물결: 미니 샤이-훌루드와 SLSA 문제

미니 샤이-훌루드의 가장 주목할 만한 순간은 2026년 5월 11일 19:20(UTC)에 발생했는데, 이때 6분 동안 @tanstack 네임스페이스 내 42개 패키지에 걸쳐 84개의 악성 아티팩트가 게시되었습니다. 해당 패키지들은 TanStack의 실제 OIDC 신원을 사용하여 TanStack의 실제 릴리스 파이프라인을 통해 배포된 것으로 보였습니다.

그건 그들이 실제로 그랬기 때문이다.

CVE-2026-45321 (CVSS 9.6)로 지정된 이 공격 기법은 세 가지의 알려진 GitHub Actions 취약점을 하나의 경로로 연결했습니다:

트리거가 되는 풀 리퀘스트가 포크에서 비롯된 경우에도 쓰기 권한으로 실행되는 pull_request_target 트리거로, 이를 통해 진입점을 제공합니다.
GitHub Actions 캐시 포이즌링: 수정된 종속성을 정상적인 빌드에 몰래 끼워 넣는 데 사용됩니다.
러너 프로세스 메모리에서 유효한 Sigstore 서명 인증서를 획득하는 데 사용되는 활성 OIDC 토큰을 탈취하는 공격.

실제 파이프라인에서 발급된 실제 서명 인증서를 통해, 이 웜은 악성 패키지에 대해 유효한 SLSA 빌드 레벨 3 출처 증명서를 생성했습니다.

이 부분이 바로 팀들이 출처에 대해 생각하는 방식을 바꿔야 할 부분입니다.

이는 SLSA가 원래 의도된 기능을 제대로 수행하지 못했다는 뜻은 아닙니다. 오히려 많은 팀이 프로비넌스(provenance)에 프로비넌스가 답할 수 없는 질문을 던지고 있다는 의미입니다. 프로비넌스는 아티팩트가 어디서 왔는지, 그리고 예상된 프로세스에 따라 빌드되었는지 여부를 보여줄 수 있습니다. 이 경우, 악성 패키지가 실제로 예상된 파이프라인을 통해 빌드되었기 때문에 기술적으로는 그 보장이 사실이었습니다. 문제는 파이프라인 자체가 이미 침해당해 있었다는 점입니다.

SLSA는 빌드의 무결성을 보증합니다. 그러나 이는 빌드에 포함된 코드가 안전했다는 사실, 워크플로가 손상되지 않았다는 사실, 또는 업스트림에서 유지보수자의 환경이 침해되지 않았다는 사실을 증명하지는 않습니다. 이러한 구분은 단순한 이론적 논의가 아닙니다. 지난 6월 1일, @redhat-cloud-services 네임스페이스를 겨냥한 모방 공격 물결에서는 각각 유효한 npm 출처 정보를 지닌 악성 패키지가 배포되었는데, 이 패키지들은 해킹당한 직원 계정을 통해 GitHub Actions OIDC로 게시된 것이었습니다. 출처 정보는 약속한 바를 정확히 이행했습니다. 다만 프로비넌스가 팀들이 가정하는 바를 보장하지는 않을 뿐입니다.

이 웜은 172개의 npm 패키지와 2개의 PyPI 패키지에 걸쳐 404개의 악성 버전을 통해 확산되었으며, TanStack, Mistral AI, Guardrails AI, UiPath 및 OpenSearch와 연계된 생태계에까지 영향을 미쳤습니다. 2.3MB 크기의 난독화된 페이로드는 100개 이상의 파일 경로를 샅샅이 뒤져 기밀 정보를 수집했으며, Claude Code와 Visual Studio Code를 포함한 개발자 도구에 재부팅 후에도 유지되는 지속성 후크를 설치했습니다. 공개 보고에 따르면, 영향을 받은 패키지의 총 다운로드 수는 5억 1,800만 건 이상으로 집계되었습니다[게시 전 정확한 수치 확인 필요; 누적 수치인지 주간 수치인지에 대해 출처마다 차이가 있음]. 따라서 이번 사건은 단순히 유지보수자 측의 사고가 아니라, 해당 기간 동안 공개 레지스트리에서 패키지를 가져온 모든 조직에 영향을 미친 다운스트림 종속성 문제였습니다.

그로부터 하루 뒤인 5월 12일, TeamPCP는 Shai-Hulud 프레임워크 전체를 MIT 라이선스 하에 GitHub에 오픈소스로 공개했으며, 이를 활용해 가장 대규모의 공급망 공격을 성공시킨 사람에게 모네로 1,000달러를 상금으로 주는 공모전도 함께 개최한 것으로 알려졌다. 수개월에 걸쳐 다듬어진 이 기능은 주말이 되자 유능한 공격자라면 누구나 포크할 수 있는 것이 되었다.

‘녹색’ 원산지 확인은 안전성에 대한 최종 판단이 아닙니다. 이는 더 광범위한 신뢰 결정 과정에서 고려되는 여러 신호 중 하나일 뿐입니다.

2단계: 메갈로돈과 CI/CD의 대세화

그 오픈소스 공개 6일 후, 메갈로돈이 등장했다.

2026년 5월 18일 UTC 기준 11:36부터 17:48 사이에, 이 공격 캠페인은 5,561개의 GitHub 저장소에 5,718건의 악성 커밋을 업로드했습니다. 공격자는 무작위로 생성된 8자 사용자 이름(rkb8el9r, bhlru9nr 등)을 가진 일회용 계정을 사용했으며, 봇 스타일의 작성자 신원을 위조했습니다:

빌드봇
auto-ci
ci-bot
파이프라인 봇

커밋 메시지는 일상적인 유지보수 작업처럼 보이도록 작성되었습니다:

ci: 빌드 최적화 단계 추가
작업: 파이프라인 실행 시간 최적화
CI와 관련된, 대충 훑어보기 쉬운 유사한 변경 사항들

공격자는 애플리케이션 코드를 악의적으로 보이게 하려는 것이 아니었다. 공격자는 파이프라인 변경 사항을 지루해 보이게 하려고 했던 것이다.

Megalodon은 두 가지 GitHub Actions 워크플로우 변형을 배포했는데, 두 변형 모두 id-token: write 및 actions: read를 요청하고, base64로 인코딩된 bash 페이로드를 실행하며, 216.126.225.129:8443에 위치한 동일한 C2 서버에 보고했습니다.

SysDiag는 소음이 심하고 범위가 넓은 변종이었습니다. 이 변종은 모든 푸시 및 풀 요청 시 트리거되는 워크플로를 추가하여, 실행 및 데이터 수집 빈도를 극대화했습니다.

Optimize-Build는 ‘조용한’ 방식이었습니다. 이 방식은 `workflow_dispatch`를 사용했기 때문에, GitHub API를 통해 수동으로 트리거될 때까지 워크플로가 비활성 상태로 유지될 수 있었습니다. 덕분에 이 방식은 백도어로 활용하기에 더욱 유용했습니다. 빌드 실패가 지속적으로 발생하지도 않고, 눈에 띄는 오류도 없으며, 유지보수 담당자가 이를 눈치챌 만한 즉각적인 이유도 없었기 때문입니다.

이 페이로드는 광범위한 정보를 수집했습니다. CI 환경 변수와 /proc/*/environ, 구성된 프로필 전반의 AWS 자격 증명, Google Cloud 토큰, AWS IMDSv2 및 Azure IMDS 엔드포인트에서 추출한 인스턴스 역할 자격 증명, SSH 개인 키, Docker, .npmrc, .netrc, 쿠버네티스, Vault, 테라폼 자격 증명, 셸 기록, 30개 이상의 정규식 패턴으로 구성된 API 키 및 연결 문자열, 그리고 무엇보다도 GitHub Actions OIDC 토큰 요청 URL과 토큰은 물론 GITHUB_TOKEN, GitLab 및 Bitbucket 토큰까지 수집했습니다.

OIDC 절도 사건이 중요한 이유

많은 조직이 CI/CD 환경에서 수명이 긴 클라우드 키를 사용하지 않고 OIDC 페더레이션 방식으로 전환하고 있습니다. 이는 올바른 방향입니다. GitHub Actions에 AWS, Google Cloud 또는 Azure의 영구적인 인증 정보를 저장하는 대신, 워크플로는 필요할 때마다 수명이 짧은 인증 정보를 요청합니다.

메갈로돈은 그 모델에 여전히 어떤 안전장치가 필요한지 보여줍니다.

악의적인 워크플로가 ‘id-token: write’를 요청할 수 있다면, 신뢰할 수 있는 워크플로 신원을 사칭하는 데 필요한 OIDC 토큰 요청 데이터를 확보할 수 있습니다. 해당 클라우드 신뢰 정책의 적용 범위가 지나치게 넓게 설정되어 있다면, 해당 악성 워크플로는 공격자의 컴퓨터에서 유효 기간이 짧은 클라우드 자격 증명을 생성할 수 있습니다.

문제는 OIDC 자체가 나쁘다는 것이 아닙니다. 문제는 OIDC 기반 신뢰 관계가 제한적이어야 한다는 점입니다. 안전한 구성은 다음 질문에 답할 수 있어야 합니다:

정확히 어떤 리포지토리가 이 역할을 요청할 수 있나요?
어떤 브랜치, 태그 또는 환경이 허용됩니까?
어떤 워크플로가 허용되나요?
이 워크플로우에 id-token: write가 정말 필요한가요?
새로 추가된 워크플로가 동일한 신뢰 수준을 상속받을 수 있습니까?
릴리스 브랜치가 아닌 브랜치의 워크플로가 프로덕션 인증 정보를 요청할 수 있나요?

신뢰 정책이 사실상 “이 저장소는 신뢰할 수 있다”고 규정한다면, 그 영향 범위는 필요 이상으로 넓어집니다. OIDC는 장기간 유지되는 정적 비밀 정보로 인한 위험을 줄여줍니다. 하지만 악의적으로 조작된 워크플로우 실행 문제는 해결하지 못합니다.

틸데스크 사례는 하류 부문의 위험을 보여준다

메갈로돈은 단순히 저장소 소유자의 문제만은 아니었다.

최소 한 개의 하위 패키지인 @tiledesk/tiledesk-server가 2.18.6부터 2.18.12까지의 모든 버전에서 손상된 형태로 공개되었습니다. 중요한 점은 npm 계정이 침해의 초기 발원지가 아니었다는 것입니다. 공격자는 악성 GitHub Actions 워크플로 파일을 삽입하여 소스 저장소를 변조했고, 정당한 유지보수자는 이를 알지 못한 채 변조된 소스를 바탕으로 릴리스를 공개했습니다.

바로 그 때문에 2단계 인증(2FA)과 코드 서명만으로는 충분하지 않았습니다. 공격자가 npm 계정을 탈취할 필요가 전혀 없었기 때문에, 게시 이벤트는 여전히 정상적으로 보였습니다. 두 가지 보안 조치 모두 해당 릴리스가 실제 유지보수자가 배포한 것임을 확인해 주었고, 실제로도 그랬습니다. 무결성 문제는 그보다 앞선 단계, 즉 소스 코드와 게시 사이에서 발생했습니다.

이것이 바로 소스 차이 분석이 중요한 이유이기도 합니다. 온보딩 시점에 새로운 패키지 버전을 이전 버전과 비교하여 검토하는 탐지기는, 새로운 릴리스를 신뢰하기 전에 2.18.5에서 2.18.6으로의 변경 사항을 면밀히 조사할 것입니다. 주입된 워크플로 파일과 페이로드는 경고 신호를 유발해야 할 범주에 정확히 해당합니다. 즉, 빌드 시 실행 후크, CI/CD 방식의 실행 경로, 난독화된 페이로드, 숨겨진 실행, 자격 증명 수집, 의심스러운 네트워크 활동 등이 있으며, 이는 event-stream 및 ua-parser-js와 동일한 백도어 형태입니다.

SecureChain은 바로 이러한 구체적인 취약점을 해결하기 위해 개발되었습니다. SecureChain은 게시 이벤트를 맹목적으로 신뢰하는 대신 소스 코드 차이점을 분석하므로, 서명, 출처 추적, 레지스트리 2단계 인증(2FA) 등이 모두 놓치는 ‘유지 관리자가 악성 소스 코드를 게시하는’ 시나리오를 포착하도록 설계되었습니다. 또한, 릴리스가 다운스트림으로 배포되기 전에 보안 팀에 추론 결과물, 문제가 있는 차이점 구간, 근거 및 판정 결과를 제공합니다.

메갈로돈은 한 가지를 분명히 보여주었습니다. 바로 신뢰는 설치 전에 쌓여야 한다는 점입니다.	SecureChain 다운로드
SecureChain은 설치 시 의심스러운 디프(diff), 숨겨진 후크, 정보 유출 행위 등을 포함해 오픈소스 구성 요소를 철저히 검사한 뒤, 제품 수명 주기 종료(EOL) 이후까지 이를 안전하게 보호합니다.

전체적인 연쇄 반응은 다음과 같습니다:

저장소는 도난당하거나 악용된 접근 권한을 통해 변경됩니다.
GitHub Actions 워크플로가 삽입되거나 대체됩니다.
이 워크플로는 신뢰할 수 있는 CI 환경 내에서 실행됩니다.
주자로부터 비밀을 캐낸다.
패키지는 손상된 소스 코드로부터 빌드되거나 배포될 수 있습니다.
하류 사용자들은 겉보기에는 정상적인 패키지인 것처럼 보이는 것을 설치합니다.

소비자 입장에서는 패키지 이름이 익숙하고, 게시자가 신뢰할 수 있으며, 예상했던 계정에서 출시된 것으로 보입니다. 하지만 그 배후의 출처와 워크플로는 이미 침해당한 상태였습니다. “신뢰할 수 있는 게시자”와 “안전한 패키지”는 같은 의미가 아닙니다.

저작권 귀속을 둘러싼 논쟁, 그리고 그것이 여러분의 대응 방식을 바꾸지 않는 이유

바로 이 부분에서 대중 매체의 보도가 혼란스러워집니다.

TeamPCP는 이전의 공급망 공격 캠페인과 5월 12일 웜 프레임워크 공개를 포함해, Shai-Hulud의 광범위한 활동과 밀접한 관련이 있는 것으로 보입니다. 일부 보도에 따르면 Megalodon은 TeamPCP의 소행으로 직접 지목되고 있습니다.

좀 더 면밀히 살펴보면, 메갈로돈은 샤이-훌루드(Shai-Hulud) 스타일의 활동과 작전 기법 면에서 상당한 중복성을 보이지만, 직접적인 귀속 여부는 아직 확정되지 않았다. 메갈로돈의 페이로드를 분석한 OX Security는 유사한 행동 양식과 스타일을 보이지만, 공유된 코드가 거의 없고, 직접적인 연결고리도 없으며, 공통된 식별 지표도 없고, 책임 주장의 흔적도 없다는 점을 지적하며, 이를 모방작일 가능성이 가장 높다고 평가했다. 또한 메갈로돈은 TeamPCP가 자체 콘테스트 참가에 요구하는 공개 암호화 키를 갖추지 않았으므로, 콘테스트 출품작으로조차 볼 수 없습니다. 미니 샤이-훌루드는 TeamPCP와의 연관성이 매우 높은 반면, 메갈로돈은 정황적 유사성만 있을 뿐입니다. 직접적인 귀속 가능성은 신뢰도가 낮은 것으로 간주하십시오.

방어 측에서는 이러한 구분이 대응 속도를 늦춰서는 안 됩니다. 메갈로돈이 TeamPCP였든, 모방범이었든, 아니면 오픈소스 도구를 사용한 또 다른 행위자였든 간에 대응 방안은 동일합니다. 즉, 악용된 워크플로를 찾아내고, 노출된 기밀 정보를 주기적으로 교체하며, OIDC 보안을 강화하고, 워크플로 변경을 제한하며, 개발자 엔드포인트와 CI/CD 신원을 공급망의 일부로 취급해야 합니다. 브랜드 이름이 아니라 그 수법에 대비해야 합니다.

근본 원인도 캠페인 이름이 암시하는 것만큼 특이하지는 않습니다. 허드슨 록(Hudson Rock)은 메갈로돈(Megalodon)의 커밋 뒤에 숨겨진 GitHub 사용자 이름을 자사의 정보 탈취형 악성코드 데이터베이스와 대조해 분석한 결과, 978건 중 331건(3분의 1 이상)이 이미 정보 탈취형 악성코드에 감염된 시스템과 일치하는 것을 확인했으며, 이에 따라 해당 접근이 정보 탈취형 악성코드 로그에서 비롯된 것이라고 결론지었습니다. 이러한 공격의 전제 조건은 대개 GitHub 제로데이가 아닙니다. 이미 해킹당한 개발자 워크스테이션이나 유지보수 담당자의 환경이 그 원인입니다.

기존 스캐너가 왜 이러한 유형의 공격을 탐지하지 못하는가

대부분의 취약점 스캐너는 다음과 같은 질문에 답할 수 있도록 설계되어 있습니다:

이 패키지에 알려진 CVE가 있나요?
이 종속성이 오래된 것입니까?
이 컨테이너가 취약점이 있는 라이브러리를 사용하고 있습니까?
이 아티팩트가 알려진 악성코드와 관련이 있습니까?

그 질문들은 여전히 중요합니다. 하지만 샤이-훌루드와 메갈로돈은 전혀 다른 차원에서 작용합니다.

GitHub Actions 워크플로가 악용되었다고 해서 반드시 취약한 종속성인 것은 아닙니다. .github/workflows 내부의 base64로 인코딩된 쉘 페이로드는 SBOM에 나타나지 않을 수 있습니다. 도난당한 OIDC 토큰은 CVE가 아닙니다. 공격자가 해당 패키지를 생성한 파이프라인을 장악한 경우, 악성 패키지라도 유효한 출처 정보를 가질 수 있습니다. 합법적인 유지보수자가 배포하는 소스 자체가 이미 악용된 상태라면, 그 유지보수자조차도 악성 릴리스를 배포할 수 있습니다.

공급망 보안은 최종 산출물 그 이상을 살펴야 합니다. 팀은 다음 사항을 점검할 수 있는 통제 수단을 마련해야 합니다:

설치 전 패키지 동작
소스 레벨 변경 사항 및 버전 간 차이점
워크플로우 무결성 및 빌드 시 실행 후크
CI/CD 권한 및 러너 동작
출처 및 확인 맥락
클라우드 ID 범위
유지보수 담당자 및 개발자의 인증 정보 유출
게시 후 취약점 및 침해 징후

레지스트리는 단지 한 단계에 불과합니다. 이제 빌드 시스템이 주요 목표가 되었습니다.

완화

Shai-Hulud와 메갈로돈을 소프트웨어 전달 프로세스를 점검하고 보안을 강화할 계기로 삼으십시오. 특히 2026년 5월 이후로 CI/CD 관련 취약점을 검토하지 않았다면 더욱 그러합니다.

1. 저장소를 찾아보세요

GitHub 저장소 및 포크에서 다음을 검색하세요:

SysDiag 및 Optimize-Build 워크플로 이름
C2 주소 216.126.225.129
base64 -d | bash 실행
예기치 않은 workflow_dispatch 트리거
원인을 알 수 없는 ID 토큰: 쓰기 권한
익숙하지 않은 봇과 유사한 계정이 수행한 워크플로 커밋
.github/workflows를 변경한 직접 푸시

2026년 5월 18일 경에 발생한 워크플로우 변경 사항, 특히 풀 리퀘스트 검토 절차를 거치지 않은 변경 사항에 각별히 주의를 기울여 주십시오.

2. 알려진 출구를 차단하고 검토한다

CI 러너에서 216.126.225.129:8443으로 향하는 아웃바운드 트래픽을 차단하고, 빌드 시스템이나 자체 호스팅 러너에서 발생한 연결에 대한 과거 프록시, 방화벽 및 넷플로우 로그를 검토하십시오. 인프라가 빠르게 변경되기 때문에 해당 IP를 차단하는 것만으로는 완벽한 방어책이 될 수 없지만, 과거 기록을 검토하고 즉시 문제를 해결하는 데는 유용합니다.

3. 노출된 비밀 정보를 주기적으로 변경하기

의심스러운 워크플로가 실행된 경우, 러너 환경이 노출된 것으로 간주하십시오. GitHub PAT 및 세분화된 토큰, 배포 키, Actions 시크릿, GitHub 앱 자격 증명, npm 및 PyPI 게시 토큰, Docker 레지스트리 자격 증명, SSH 개인 키, AWS, Google Cloud 및 Azure 자격 증명, Kubernetes 구성, Terraform 자격 증명, Vault 토큰, 그리고 영향을 받은 워크플로와 연결된 OIDC 신뢰 관계의 교체에 우선순위를 두십시오.

자격 증명을 취소하기 전에 주의해야 할 점이 하나 있습니다. 일부 Shai-Hulud 계열 페이로드에는 자격 증명 취소와 연동된 파괴적인 안전 장치(failsafe)가 포함되어 있습니다. 이러한 동작이 Megalodon 페이로드의 기능인지는 확인되지 않았지만, 감염이 의심되는 호스트가 있다면 자격 증명을 취소하기 전에 해당 호스트를 격리하고 이미지를 생성한 뒤, CI 로그, 워크플로 실행 내역 및 감사 이벤트를 보존해야 합니다.

4. 보안 취약점이 확인된 패키지 버전을 격리한다

@tiledesk/tiledesk-server를 사용 중이라면, 버전 2.18.6부터 2.18.12까지를 확인해 주십시오. 해당 버전이 설치, 빌드 또는 배포된 경우, 영향을 받는 환경을 검토하고 빌드 또는 실행 시 사용되는 시크릿을 갱신하십시오. 마지막으로 검증된 정상 릴리스인 2.18.5로 고정하고, 락파일을 검증하십시오.

5. OIDC 트러스트 강화

민감한 클라우드 역할에 대해서는 리포지토리 수준에서 광범위한 신뢰를 허용하지 마십시오. 가능한 경우, 리포지토리, 브랜치, 태그, 환경, 워크플로 파일, 대상, 릴리스 경로별로 OIDC 신뢰를 제한하십시오. 예를 들어, `sub restricted to repo:org/name:ref:refs/heads/main`과 같은 조건을 설정하면, 사이드 브랜치에서 실행되는 악의적인 워크플로가 프로덕션 자격 증명을 생성하는 것을 막을 수 있습니다.

다음과 같은 요청이 포함된 모든 워크플로를 검토하십시오:

permissions:
id-token: write

워크플로우에서 토큰을 요청해야 할 명백한 사유가 명시되어 있지 않은 한, 이를 제거하십시오.

6. 워크플로우 변경 시 검토를 의무화한다

.github/workflows를 보안상 민감한 코드로 취급하십시오. 워크플로 파일의 경우 CODEOWNERS 승인을 적용하고, 브랜치 보호, 필수 풀 리퀘스트 검토, 적절한 경우 서명된 커밋, 기본 읽기 전용 Actions 권한, 변경 가능한 태그 대신 커밋 SHA에 고정된 타사 액션, 제한된 러너 외부 트래픽, 그리고 민감한 릴리스 워크플로 전용 러너를 사용하십시오. 워크플로 파일은 프로덕션 배포 코드만큼 강력한 영향을 미칠 수 있습니다. 따라서 변경하기가 더 쉬워서는 안 됩니다.

탐지

단일 스캐너 결과만으로는 샤이-훌루드나 메갈로돈의 노출을 입증할 수 없습니다. 관련 증거는 저장소 이력, 워크플로 파일, CI 실행 로그, 네트워크 로그, GitHub 감사 이벤트, 클라우드 ID 로그, 패키지 잠금 파일 등 다양한 곳에 분산되어 있습니다. 또한 운영자가 인프라를 순환적으로 교체하기 때문에, 행동 신호는 개별 지표보다 더 오래 지속됩니다.

유용한 신호로는 다음이 있습니다:

.github/workflows에 대한 예기치 않은 변경 사항
CI 환경 내 base64 디코딩된 쉘 실행
새로 생성되거나 원인이 밝혀지지 않은 workflow_dispatch 워크플로우
ID 토큰을 요청하는 워크플로우: 명확한 사유 없이 기록
기본 브랜치로 직접 푸시하기
낯선 봇처럼 보이는 작성자 이름과 위조된 커밋 날짜
216.126.225.129로 전송되는 CI 러너의 아웃바운드 트래픽
새로운 배포 키, OAuth 승인 또는 GitHub 앱 설치
GitHub Actions ID를 기반으로 한 비정상적인 클라우드 역할 할당
의심스러운 워크플로 변경이 발생한 직후 패키지 게시물
노출 기간 동안 락파일에서 발견된 예상치 못한 npm 또는 PyPI 버전

GitHub 검색어 예시:

"216.126.225.129"
"SysDiag"
"Optimize-Build"
"base64 -d | bash"
"id-token: write"

지역 워크플로우 검색 예시:

grep -R "216\.126\.225\.129\|SysDiag\|Optimize-Build\|base64 -d" .github/workflows/ 2>/dev/null

이러한 점검은 시작점일 뿐, 문제가 전혀 없다는 보장은 아닙니다.

우선순위별 개선 조치 체크리스트

저장소 검토: GitHub Actions 워크플로우 변경 사항, 특히 2026년 5월 18일 경의 변경 사항을 검토하십시오.

IOC 검색: SysDiag, Optimize-Build, 의심스러운 base64 실행, 그리고 보고된 C2 주소를 확인하십시오.

로그 보존: 정리 작업 전에 워크플로 실행 로그, GitHub 감사 로그, 패키지 잠금 파일 및 빌드 아티팩트를 보관하십시오.

비밀 정보 순환: 의심스러운 실행 환경에 노출된 인증 정보를 순환하여 관리합니다.

OIDC 강화: 클라우드 신뢰 정책을 특정 워크플로, 브랜치, 태그 또는 환경에 한정하여 적용합니다.

워크플로우 변경 제한:.github/workflows에 대한 변경 시 풀 리퀘스트 검토 및 CODEOWNERS의 승인을 필수로 합니다.

패키지 도입 검토: 보안 취약점이 확인된 패키지 버전이 환경에 도입되었는지 확인하십시오.

CI/CD 강화: 타사 작업을 커밋 SHA에 고정하고, 러너의 외부 트래픽을 제한하며, 기본 워크플로 권한을 최소화합니다.

개발자 엔드포인트 검사: 개발자 워크스테이션을 공급망의 일부로 간주해야 하며, 특히 관리자가 영향을 받은 패키지를 설치했거나 로컬에 인증 정보가 저장되어 있는 경우에는 더욱 그러합니다.

이것이 단순한 한 번의 캠페인보다 더 중요한 이유

샤이-훌루드와 메갈로돈의 중요한 점은 단순히 규모뿐만이 아닙니다. 바로 이동 방향입니다. 공격자들은 취약한 대상에서 상류 쪽으로 이동하며, 그 뒤편에 있는 신뢰 시스템으로 침투하고 있습니다:

유지 관리자 자격 증명
개발자용 엔드포인트
CI/CD 실행기
GitHub Actions 워크플로
OIDC 식별자
패키지 게시 자동화
출처 및 서명 체계
클라우드 배포 역할

이는 오픈소스 보안이 의미하는 바를 변화시킵니다. 더 이상 패키지가 환경에 도입된 후에 스캔하는 것만으로는 충분하지 않습니다. 패키지의 출처, 빌드 방식, 빌드 프로세스의 신뢰성, 이전 버전 대비 변경 사항, 설치 또는 빌드 과정에서 의심스러운 동작이 있는지 여부, 배포자나 저장소가 해킹당했는지 여부, 그리고 배포 후에도 해당 구성 요소가 지속적으로 보안 패치를 받을 수 있는지 여부 등을 파악해야 합니다.

이것이 바로 SecureChain이 해결하기 위해 개발된 문제입니다. SecureChain은 조직에 오픈소스 구성 요소를 위한 검증된 소스를 제공하며, 구성 요소의 전체 수명 주기 동안 악성코드 검사, 소스 코드 수준 검사, 출처 추적, 지속적인 CVE 수정 조치를 수행합니다. 새로운 패키지 버전의 경우, 버전 간 차이점을 분석하여 빌드 시 실행 후크, 난독화된 페이로드, 숨겨진 실행 경로, 정보 유출 행위 등을 포함해 의심스러운 변경 사항이 하류 단계에서 신뢰받기 전에 이를 식별하도록 설계되었습니다.

메갈로돈 방식의 시나리오에서는, 해당 패키지가 정식 관리자가 정식 계정을 통해 배포했을 가능성이 있기 때문에 이 점이 중요합니다. 악의적인 변경 사항은 레지스트리 경계에서 발생하는 것이 아닙니다. 레지스트리에 도달한 이미 변조된 소스 코드에 포함되어 있습니다.

샤이-훌루드와 메갈로돈은 소프트웨어 공급망이 단순히 사용자가 설치하는 코드 그 자체만이 아니라는 점을 상기시켜 줍니다. 소프트웨어 공급망은 코드를 선정하고, 빌드하고, 서명하고, 배포하며, 지속적으로 유지 관리하는 시스템 그 자체입니다. 이제 이 시스템 역시 운영 환경 인프라와 마찬가지로 보안이 강화되어야 합니다.

SecureChain 알아보기 →

자주 묻는 질문

메갈로돈은 샤이-훌루드와 같은 존재인가요?

아닙니다. ‘Shai-Hulud’는 특히 npm과 PyPI를 대상으로 하는, 자체적으로 확산되는 일련의 공급망 공격을 지칭합니다. ‘Megalodon’은 2026년 5월 18일에 발생한 대규모 GitHub Actions 워크플로 주입 공격 캠페인이었습니다. 두 사건은 발생 시기와 공격 기법 면에서 관련이 있지만, ‘Megalodon’이 동일한 작전이나 공격 주체라는 사실은 확인되지 않았습니다.

메갈로돈은 확실히 TeamPCP가 제작한 것입니까?

아닙니다. TeamPCP는 주변의 Shai-Hulud 활동과 밀접한 관련이 있으며, Megalodon은 해당 공격 방식과 일치하는 부분이 있지만, 직접적인 연관성은 확인되지 않았습니다. Megalodon 코드를 분석한 연구진은 이를 모방 공격일 가능성이 가장 높다고 평가합니다. 보안 담당자들은 공격 주체의 명칭보다는 공격 기법에 초점을 맞춰야 합니다.

SLSA 출처 정보가 이런 상황에서 저를 보호해 줄 수 있나요?

그 자체만으로는 아닙니다. Mini Shai-Hulud 사례에서 보듯이, 공격자가 빌드 파이프라인을 장악할 경우 악성 패키지에도 유효한 SLSA 빌드 레벨 3 출처 정보가 포함될 수 있습니다. 출처 정보는 코드의 출처와 빌드 무결성을 입증하는 데 도움이 됩니다. 하지만 코드가 안전하다는 것을 증명하지는 않습니다.

OIDC를 사용하면 CI/CD가 인증 정보 도용으로부터 안전하게 보호될 수 있나요?

OIDC는 수명이 긴 클라우드 키를 CI에 저장하는 것보다 안전하지만, 여전히 엄격한 범위 지정이 필요합니다. 악의적인 워크플로가 id-token: write를 요청할 수 있고 클라우드 신뢰 정책이 너무 광범위할 경우, 공격자는 신뢰된 파이프라인 ID를 통해 수명이 짧은 자격 증명을 생성할 수 있습니다.

왜 2단계 인증(2FA)과 서명 절차가 Tiledesk 해킹을 막지 못했나요?

공격자가 npm 계정을 해킹할 필요가 없었기 때문입니다. 메갈로돈은 소스 저장소를 변조했고, 정당한 관리자는 그 변조된 소스를 바탕으로 배포를 진행했습니다. 2단계 인증(2FA)과 서명은 배포 과정을 보호할 뿐, 배포된 소스가 안전하다는 것을 보장하지는 않습니다.

제가 운영하는 GitHub 저장소는 많지 않습니다. 그래도 보안 위험에 노출되어 있을까요?

그럴 수도 있습니다. 직접적인 영향을 받지 않았더라도, 상류 의존성 패키지가 해킹당한 저장소에서 빌드되거나 배포되었을 가능성이 있습니다. 오픈소스 패키지를 사용하는 모든 조직은 해당 패키지 뒤에 있는 빌드 파이프라인으로부터 어느 정도의 위험을 떠안게 됩니다.

가장 중요한 장기적인 해결책은 무엇일까요?

CI/CD를 운영 인프라로 간주하십시오. 워크플로 변경을 제한하고, OIDC의 적용 범위를 엄격히 제한하며, 러너의 동작을 모니터링하고, CI 내의 시크릿을 줄이며, 설치 전에 패키지를 검사하고, 출처나 익숙한 게시자를 절대적인 안전 지표로 간주하지 마십시오.

출처

클라우드 보안 연합(Cloud Security Alliance) – “샤이-훌루드/메갈로돈: 두 차례에 걸친 AI 개발자 공급망 공격”
프로토스 랩스 – “팀PCP의 샤이-훌루드 캠페인과 모방 열풍”
SafeDep – 메갈로돈 캠페인 분석 (커밋 데이터셋, Tiledesk 캐스케이드)
OX Security – 메갈로돈 및 샤이-훌루드 모방 사례의 출처 분석
StepSecurity – Megalodon GitHub Actions 비밀 정보 유출 분석; Mini Shai-Hulud / TanStack 분석
Tenable – Mini Shai-Hulud CVE-2026-45321 자주 묻는 질문
허드슨 록 – 메갈로돈 정보 탈취형 악성코드 근본 원인 분석
Unit 42 (Palo Alto Networks) – 2025년 9월, Shai-Hulud 웜 최초 보고
The Hacker News – 메갈로돈과 미니 샤이-훌루드 캠페인 관련 보도
Socket – npm 토큰 무효화 및 Shai-Hulud 캠페인 분석