Mini Shai-Hulud 5718개 커밋, AI 코딩 설정까지 감염

2026년 5월 22일, Cloud Security Alliance Labs가 Mini Shai-Hulud와 Megalodon 공급망 캠페인 분석을 공개했습니다. 원문은 2025년 npm 생태계를 흔든 Shai-Hulud 이름을 이어받습니다. 이번 분석에서 AI 개발자가 봐야 할 부분은 악성 패키지 자체보다 저장소 안의 실행 권한입니다. npm token, GitHub Actions secret, package lifecycle script, AI coding assistant 설정 파일이 한 저장소 안에서 같은 공격 경로로 묶입니다.

CSA는 Mini Shai-Hulud 관련 악성 활동에서 5718개 커밋과 360개 저장소를 집계했습니다. The Register는 2026년 5월 26일 이 캠페인과 관련해 3만9000개 이상의 secret이 유출됐다고 보도했습니다. 수치 자체는 기관별 집계 방식에 따라 달라질 수 있습니다. 그래도 저장소 커밋, registry publish, GitHub 계정, CI secret이 한 사건 안에서 연결됐다는 점은 분명합니다.

이 사건을 "AI가 만든 악성 코드"로 읽으면 초점이 빗나갑니다. CSA가 더 오래 붙잡은 대상은 AI 코딩 도구가 동작하는 저장소입니다. agent는 package.json을 읽고, install command를 실행하고, .github/workflows를 고치고, .cursor나 CLAUDE.md 같은 설정 파일을 지침으로 삼을 수 있습니다. 공격자가 이 파일을 바꾸면 다음 agent session의 읽기 순서와 실행 행동이 바뀔 수 있습니다.

CSA는 2026년 4월 AI coding tool 연구 노트를 공개했습니다. PDF. 이 문서는 위험을 prompt injection to RCE, slopsquatting, CI/CD 권한 결합으로 나눠 설명했습니다. 외부 사용자가 쓸 수 있는 issue, PR body, comment가 agent context에 들어가고, agent가 shell과 repository write 권한을 동시에 가지면 위험이 커진다는 내용입니다. Mini Shai-Hulud 분석은 그 경고가 package supply chain 사고와 만나는 지점을 보여줍니다.

Shai-Hulud 계열 공격에서 package lifecycle script는 오래된 문제입니다. npm install은 단순한 파일 다운로드가 아니라 preinstall, install, postinstall script 실행으로 이어질 수 있습니다. 개발자가 직접 install하든 agent가 test failure를 고치려다 install하든, 악성 package가 들어오면 workstation이나 CI runner의 환경 변수와 token을 읽을 수 있습니다. AI coding session에서는 install 명령을 사람이 매번 눈으로 검토하지 않는 경우가 더 많습니다.

Mini Shai-Hulud가 개발 조직에 불편한 이유는 공격자가 저장소를 하나의 권한 그래프로 보기 때문입니다. 패키지 하나를 바꾸면 CI가 돌고, CI는 secret을 읽고, secret은 registry publish 권한을 가질 수 있습니다. 여기에 agent 설정 파일이 들어오면 저장소는 코드와 정책의 경계를 잃습니다. CLAUDE.md는 문서처럼 보이지만, Claude Code나 유사한 agent에게는 작업 지시입니다. .cursor rules file도 개발자 문서가 아니라 editor agent가 읽는 실행 전 조건입니다.

The Register 보도에 나온 3만9000개 secret 수치는 token hygiene의 실패를 보여주는 숫자입니다. AWS key, npm token, GitHub token, package registry credential은 한 번 유출되면 같은 날 여러 경로로 재사용될 수 있습니다. 공격자가 token을 얻은 뒤 바로 package를 publish하거나 저장소에 커밋을 남기면, 방어자는 "어떤 패키지가 악성인가"와 "어떤 계정이 탈취됐는가"를 동시에 확인해야 합니다.

CSA의 Megalodon 분석은 이 문제를 계정과 자동화로 확장합니다. 공급망 공격은 더 이상 패키지 이름 하나를 차단하는 일로 끝나지 않습니다. 탈취된 GitHub 계정이 정상 프로젝트에 커밋을 남기고, 정상 namespace 아래 package를 publish하면 consumer 쪽 scanner는 평판 점수만으로 판단하기 어렵습니다. 기존 maintainer의 계정, 정상 저장소, 정상 release 절차가 모두 악성 payload의 배송 경로가 될 수 있습니다.

Socket은 2025년 CrowdStrike npm 패키지 공격을 분석했습니다. 분석은 maintainer 계정과 npm publish 경로가 공격자에게 얼마나 큰 발판이 되는지 보여줬습니다. 그 사건과 Mini Shai-Hulud는 같은 사건이 아닙니다. 다만 두 사례 모두 package registry가 단순 의존성 저장소가 아니라 identity, token, CI, release automation이 만나는 운영 시스템이라는 사실을 확인시킵니다.

StepSecurity는 wormable AI supply chain attack 분석에서 agent와 CI가 결합될 때 공격이 자기 복제 구조를 얻을 수 있다고 설명했습니다. AI coding agent가 저장소 파일을 읽고, 의존성을 설치하고, workflow를 수정하고, PR이나 commit을 만들 수 있다면 공격자는 사람의 코드 리뷰 전에 실행 표면을 만집니다. 이때 피해를 줄이는 방법은 agent prompt를 더 길게 쓰는 것이 아니라 실행 권한을 줄이고, install과 publish 지점을 정책으로 묶는 것입니다.

개발팀이 지금 볼 첫 번째 파일은 package.json입니다. 의존성 이름, registry scope, script 항목, lockfile 변경을 agent가 만든 diff와 분리해 확인해야 합니다. 특히 새 package가 test fix나 lint fix의 부수 변경처럼 들어오면 리뷰어가 놓치기 쉽습니다. malicious package scanner와 registry allowlist는 PR 끝에서만 돌리기보다 agent가 install을 실행하기 전 지점에 붙어야 합니다.

두 번째 파일군은 .github/workflows입니다. CI workflow는 secret 접근과 package publish를 동시에 다룹니다. Pull request에서 실행되는 job이 secrets를 읽을 수 있는지, fork PR에서 publish job이 트리거되는지, GITHUB_TOKEN permission이 contents: write나 packages: write를 갖는지 확인해야 합니다. agent가 workflow를 수정할 수 있다면 해당 diff에는 일반 코드보다 더 강한 review rule이 필요합니다.

세 번째 파일군은 AI assistant 설정입니다. .cursor/rules, .windsurf, CLAUDE.md, AGENTS.md, MCP server definition, tool allowlist는 agent의 행동 조건을 바꿉니다. 공격자가 "이 명령을 먼저 실행하라"는 식의 지시를 설정 파일에 넣으면, 사람에게는 문서 변경처럼 보이고 agent에게는 다음 session의 입력이 됩니다. 이 파일들은 README와 같은 문서가 아니라 executable configuration에 가깝게 다뤄야 합니다.

네 번째는 token 회전입니다. The Register 보도처럼 secret 유출 규모가 크다면, 단일 패키지 삭제만으로는 충분하지 않습니다. npm token, GitHub PAT, cloud credential, package signing key, CI secret, deploy key를 저장소별로 확인해야 합니다. 회전 순서도 중요합니다. 먼저 publish 권한을 막고, 악성 package를 unpublish 또는 deprecate하고, CI trigger를 정리한 뒤 새 token을 발급해야 합니다.

AI 코딩 도구를 쓰는 팀은 "agent가 코드를 얼마나 잘 쓰는가"보다 "agent가 어디까지 실행할 수 있는가"를 먼저 inventory해야 합니다. local agent는 developer shell의 권한을 물려받고, cloud agent는 연결된 repository와 secret scope를 물려받습니다. CI agent는 workflow permission을 물려받습니다. 모델이 같은 이름이어도 실행 위치가 달라지면 위험은 달라집니다.

이 지점에서 Cursor hooks, Endor Labs AURI, Snyk, Semgrep, 1Password, MCP broker 같은 제품이 같은 시장을 향합니다. 목표는 agent 답변을 검열하는 것이 아니라 tool call, package install, secret access, commit 전 지점을 정책으로 묶는 것입니다. Mini Shai-Hulud는 이런 제품군의 광고 문구가 아니라 요구 조건을 보여줍니다. agent가 의존성을 설치하기 전에 package 평판을 확인하고, MCP server를 부르기 전에 allowlist를 확인하고, commit 전에 설정 파일 변경을 따로 표시해야 합니다.

단, 방어 제품만 붙이면 끝나는 문제도 아닙니다. 공격자는 정상 maintainer 계정과 정상 namespace를 사용할 수 있습니다. scanner가 모든 package를 악성으로 판정할 수는 없습니다. 그래서 권한 최소화가 남습니다. publish token은 developer workstation에 오래 두지 않고, CI token은 job별로 좁히고, registry publish는 provenance와 2FA를 요구하고, agent가 읽는 설정 파일에는 code owner를 붙여야 합니다.

이번 사건의 커뮤니티 반응은 대규모 공개 토론보다 보안 업체와 운영팀의 짧은 경고에 가깝습니다. npm 공급망 공격은 이미 여러 번 있었기 때문에 "또 npm인가"라는 피로도 있습니다. 그러나 AI 코딩 설정 파일이 저장소 공격 표면에 들어온 부분은 다릅니다. 과거에는 악성 패키지를 설치한 사람이 피해자였습니다. 이제는 agent가 설정 파일을 읽고 install, test, commit을 이어갈 수 있어 저장소 내부의 문서성 파일도 실행 권한에 가까운 영향력을 갖습니다.

이 글의 결론은 "AI 코딩 도구를 쓰지 말라"가 아닙니다. 더 좁은 결론은 agent session을 CI/CD와 같은 운영 시스템으로 다루라는 것입니다. agent가 shell을 쓰고, package를 설치하고, workflow를 고치고, PR을 만든다면 그 session은 개발자 메모장이 아닙니다. token, network, registry, workflow permission을 가진 실행 환경입니다.

Mini Shai-Hulud와 Megalodon 분석은 AI 개발팀에 한 가지 질문을 남깁니다. 우리 저장소에서 agent가 읽는 파일과 CI가 실행하는 파일을 같은 review 강도로 보고 있는가. 답이 아니라면 첫 작업은 어렵지 않습니다. .github/workflows, package lockfile, AI assistant 설정, MCP server definition, registry token을 한 표로 묶고, 누가 바꿀 수 있으며 어떤 자동화가 실행하는지 표시해야 합니다. 공급망 공격은 package 이름에서 시작할 수 있지만, 피해는 저장소 권한 전체로 번집니다.

출처

• CSA 분석.
• CSA AI 공급망 note.
• CSA AI coding PDF.
• The Register 보도.
• Socket 분석.
• StepSecurity 분석.