Microsoft 오픈소스 도구 해킹 사건: AI 개발자가 코드를 설치하기 전 알아야 할 것들

Microsoft GitHub 저장소 해킹 사건 - Miasma 웜 공급망 공격

Microsoft 오픈소스 도구 해킹 사건: AI 개발자가 코드를 설치하기 전 알아야 할 것들

17시간 전 GeekNews에 떠오른 충격적인 보도가 있다. Microsoft의 GitHub 오픈소스 저장소 70개가 한꺼번에 해킹당해, 비밀번호 탈취용 악성코드가 코드에 주입됐다. 단순한 침해가 아니다. AI 코딩 도구를 쓰는 개발자를 노린 공급망 공격이다.

이번 글에서는 사건의 정체를 짚고, 개발자가 당장 무엇을 해야 하는지 정리한다. AI 코딩 도구의 보급이 공급망 공격 표면을 어떻게 키웠는지, 그리고 우리가 어떤 자세를 취해야 하는지를 다섯 가지 핵심 포인트로 압축한다.

사건의 정체: Miasma 웜의 재침해

해커는 GitHub에 호스팅된 Microsoft의 오픈소스 프로젝트 70여 개에 침투했다. Azure 클라우드 SDK, Claude Code, Gemini CLI, VS Code 관련 도구가 주된 표적이었다. 감염된 도구를 AI 코딩 앱에서 열면, 비밀번호와 클라우드 자격 증명이 외부로 빠져나간다.

Microsoft는 5월 중순에도 Durable Task 프로젝트가 해킹당한 바 있다. 같은 공격자가 다시 돌아온 것이다. 보안 커뮤니티는 이 신종 웜을 Miasma 웜이라 부른다. npm, pip, Go, Composer, Ruby 패키지 관리자를 가리지 않고 스스로 복제하며 퍼진다.

중요한 점은 Microsoft의 GitHub Actions 인증 토큰이 탈취됐다는 사실이다. CI/CD 파이프라인을 우회해 다수의 저장소에 자동 커밋을 쏟아부은 것이다. 모든 커밋이 github-actions 작성자로 위장되어, 자동화 도구로도 탐지하기 어려웠다. 한 Hacker News 분석가는 "49초 만에 다섯 저장소를 휩쓴 것은 사람이 한 게 아니라 자동화다"라고 지적했다.

왜 AI 개발자가 직접 표적이 되는가

AI 코딩 어시스턴트가 늘면서 개발 환경의 보안 경계가 흐려졌다. VS Code, Cursor, Claude Code, Gemini CLI 같은 도구는 MCP, 클라우드 CLI, GitHub 토큰 같은 민감한 자격 증명에 손쉽게 접근한다. 이 정보가 한 군데 모인 개발자 PC는 해커에게 금광이다.

게다가 최근 흐름이 상황을 악화시킨다. "AI로 최대한 많이 만들라"는 압박에 코드 리뷰가 형식화되고, 자동 생성된 PR이 사람의 검증 없이 머지되는 경우가 늘었다. "의도된 동작입니다"라는 AI 리뷰 코멘트가 만연하다는 HN 댓글도 흥미롭다. 실제 S&P 500 기업에서 인증·인가 시스템조차 AI가 짜고 사람이 검토하지 않는 사례가 보고될 정도다. 성과 평가가 사용한 토큰 수가 되는 조직이 적지 않다는 것이다.

공급망 공격의 작동 원리

공급망 공격은 두 단계로 일어난다. 첫째, npm이나 pip 같은 패키지 저장소를 통해 악성코드를 배포한다. 둘째, 개발자가 AI 코딩 어시스턴트 안에서 이 도구를 실행하면, 도구가 자동으로 credential을 탈취한다.

Miasma 웜의 가장 무서운 특성은 자가 전파다. 한 번 감염된 PC는 그 PC가 접근할 수 있는 모든 GitHub 저장소로 웜을 퍼뜨린다. 따라서 한 명의 개발자가 감염되면, 그가 속한 조직의 모든 저장소가 위험해진다. 이 웜의 진짜 무서운 점은 AWS, GCP, Azure, Kubernetes 같은 인프라 전반으로 횡단 전파한다는 사실이다. 일반적인 보안 가이드로 막기 어렵다.

게다가 코드를 작성하는 사람의 수가 폭발적으로 늘었다. AI 어시스턴트 덕분에 한 사람이 동시에 수십 개 프로젝트를 손댈 수 있다. 그만큼 의존성 설치 빈도가 늘고, 그만큼 공격 표면이 넓어진다.

개발자가 당장 해야 할 다섯 가지

첫째, 어제 사용한 도구 중 Microsoft 소유의 GitHub 저장소에서 받은 것이 있다면 즉시 삭제하고, 자격 증명을 모두 재설정한다. Microsoft는 영향받은 저장소를 일시적으로 내렸지만, 일부 도구를 이미 내려받은 경우 피해가 발생할 수 있다. MFA 알림을 받았다면 단순한 로그인 시도일 수 있으나, 실제 자격 증명 탈취 가능성도 배제할 수 없다.

둘째, GitHub Personal Access Token을 Classic PAT에서 Fine-grained PAT로 전환한다. Classic PAT는 한 번에 모든 저장소에 접근 가능해, 탈취 시 피해가 크다. Fine-grained PAT는 필요한 저장소와 권한만 허용한다. Classic PAT가 침해 경로였다면, 공개 저장소 외에도 비공개 저장소가 위험해질 수 있다.

셋째, AI 코딩 어시스턴트에 사람 계정의 토큰을 넘기지 않는다. 별도의 AI 에이전트 계정을 만들고, 최소 권한만 부여한다. 사람용 토큰을 AI에 그대로 넘기는 건 "비밀번호를 포스트잇에 적어 두기"와 다르지 않다. AI 에이전트는 별도의 보안 주체로 다루는 게 안전하다.

넷째, npm install, pip install 같은 의존성 설정을 적절한 샌드박스 안에서 실행한다. Docker 컨테이너도 만능은 아니지만, 무방비 PC보다는 안전하다. 루트리스 컨테이너 기반 샌드박스 도구를 활용하면 피해를 크게 줄일 수 있다. 감염 범위를 최소화하는 가장 현실적인 첫 단계다.

다섯째, AI로 생성한 코드라도 100% 직접 읽어본다. 자동화된 PR 리뷰는 공급망 공격의 가장 큰 약점이다. PR을 머지할 수 있는 권한이 탈취되면 리뷰 자체가 무의미해지므로, AI 리뷰 의존도를 낮춰야 한다. 보안 감사는 AI로 보조하되, 최종 판단은 사람이 해야 한다.

오픈소스 생태계의 책임

이번 사건은 오픈소스 생태계의 구조적 문제를 드러낸다. Microsoft 같은 대형 기업이 침당했다는 점이 충격적인 이유다. 대형 기업은 방어 자원이 충분하다고 가정했기 때문이다.

CISA 보고서는 이미 Microsoft의 보안 문화가 고객 보호를 충분히 우선시하지 않았다고 비판했다. 2025년 GitHub 침해와 2026년 5월 Durable Task 해킹에 이르기까지, 같은 패턴이 반복된다. Microsoft는 Secure Boot과 같은 핵심 신뢰 루트를 관리하면서도, 내부 GitHub Actions 잠금에 실패했다. "Microsoft에 조직적 보안 문제가 있다"는 지적은 이번이 처음이 아니다.

다만, 일부 보도에서 "오픈소스의 잘못"처럼 묘사한 부분은 정정할 필요가 있다. 오픈소스는 원래 분산된 신뢰 모델을 전제로 한다. 문제는 분산된 신뢰를 유지하기 위한 보안 투자를 중앙 관리자가 소홀히 한 데 있다. 오픈소스 자체의 결함이 아니다.

마무리: 같은 위치에 선 우리

이번 사건은 오픈소스만 쓰는 우리 개발자도 "같은 위치에 서 있다"는 사실을 환기시킨다. 우리가 매일 설치하는 도구, 매일 의존하는 라이브러리가 우리의 자격 증명을 들고 있다. 보안은 도구를 만든 회사의 몫이 아니라, 그것을 설치하는 우리 자신의 몫이기도 하다.

AI 시대의 공급망 보안은 더 이상 옵션이 아니다. 개발자 한 명 한 명이 샌드박싱, 토큰 분리, 직접 코드 리뷰 같은 기본기를 다시 점검해야 할 때다. RBAC 모델이 한계에 다다랐다는 시각도 나왔다. capability 기반 보안 모델로의 전환이 다음 분기 핵심 화두가 될 것이다. 다음에 도구를 설치할 때, 한 번만 더 생각해보자.