깃허브 내부 저장소 3,800개 털림…이번엔 오픈소스 공급망이 제대로 맞았다

• 깃허브가 내부 코드 저장소 약 3,800개 침해를 확인함. 시작점은 직원 기기에 설치된 악성 VS Code 확장 프로그램이었음

  • 해커 그룹 팀PCP는 약 4,000개 저장소에 접근했다고 주장했고, 깃허브는 최소 3,800개 저장소 침해를 인정함
  • 깃허브 설명상 고객 코드가 아니라 깃허브 자체 내부 코드가 대상이었지만, 일부 저장소에는 고객 지원 활동 관련 정보가 포함됐을 가능성은 남아 있음

• 이번 사건이 찝찝한 이유는 “깃허브가 털렸다”보다 “개발자 도구가 공격 경로였다”는 점임

  • 공격 원인으로 지목된 건 마이크로소프트의 코드 편집기 VS Code 확장 프로그램
  • 개발자는 확장 프로그램, 패키지, CLI 도구를 매일 설치하고 업데이트하니, 한 번 오염되면 조직 내부망과 저장소 권한까지 자연스럽게 이어짐

• 보안업체 소켓(Socket)은 팀PCP가 최근 몇 달 동안 20차례 공급망 공격을 벌였고, 500개 이상 소프트웨어에 악성코드를 심었다고 봄

  • 탈취된 코드의 여러 버전까지 포함하면 영향 범위가 1,000개를 넘는다는 언급도 있음
  • 위즈(Wiz)는 이 악성코드가 설치된 수백 개 기업을 공격하는 데 쓰였다고 설명함

• 팀PCP의 전술은 개발자를 “유통 경로”로 쓰는 방식에 가까움

  • VS Code 확장 프로그램, 데이터 시각화 소프트웨어 AntV, 오픈소스 보안 스캐너 Trivy 같은 개발자용 도구가 언급됨
  • 도구에 악성코드를 심으면 그 도구를 설치한 개발자 PC에서 토큰과 자격 증명을 빼내고, 다시 다른 저장소나 패키지로 퍼질 수 있음

• 기사에서 나온 “미니 샤이훌루드(Mini Shai-Hulud)”는 자가 확산형 웜으로 설명됨

  • 웜이 만든 깃허브 저장소에는 피해자에게서 훔친 암호화된 자격 증명이 들어 있었다고 함
  • 저장소에는 “A Mini Shai-Hulud Has Appeared”라는 문구가 들어갔고, 9월에 있었던 유사 공급망 웜 “Shai-Hulud”를 떠올리게 하는 이름임

• 공격자는 단순히 털고 끝내는 게 아니라, 훔친 데이터를 범죄 포럼에서 팔려고 했음

  • 팀PCP는 브리치포럼에 깃허브 소스 코드와 내부 정보를 판매한다고 올림
  • “몸값이 아니라 구매자를 찾는 것”이라는 식으로 말했지만, 구매자가 없으면 무료로 유출하겠다는 압박도 같이 걸었음

• 피해 범위도 깃허브 하나로 끝나는 분위기가 아님

  • 기사에는 앤트로픽, Mercor, 유럽위원회 공개 웹사이트, 오픈AI 사내 디바이스, PyPI의 LiteLLM, Checkmarx 인프라, pgserve 등이 연쇄 영향 사례로 언급됨
  • 특히 Trivy에 정보 탈취 악성코드를 심고, 탈취한 계정 정보로 다른 패키지와 인프라를 공격했다는 흐름이 나옴

• 개발팀 입장에서 바로 할 일은 꽤 명확함
  • 깃허브·깃랩 개인 액세스 토큰을 확인하고, 오래된 토큰은 폐기하거나 짧은 만료 정책으로 바꿔야 함
  • AWS, Azure, GCP, Alibaba Cloud, Oracle Cloud 같은 클라우드 자격 증명도 최근 사용 이력과 권한 범위를 확인해야 함
  • 새로 올라온 오픈소스 업데이트를 무조건 바로 당기는 대신, 보안 업데이트와 일반 업데이트를 나눠 검토하는 유예 장치도 필요함

---

기술 맥락

• 이번 사건의 핵심은 저장소 하나가 털렸다는 사실보다, 개발자가 신뢰하는 실행 경로가 오염됐다는 점이에요. VS Code 확장 프로그램은 편집기 안에서 돌아가지만, 실제로는 로컬 파일과 개발 환경의 인증 정보에 가까이 갈 수 있거든요.

• 개인 액세스 토큰이 위험한 이유는 권한이 사람 계정처럼 넓게 붙는 경우가 많기 때문이에요. 공격자가 토큰 하나를 얻으면 저장소 읽기에서 시작해 패키지 배포, CI 설정 접근, 클라우드 키 탈취까지 이어질 수 있어요.

• 그래서 대응도 백신 돌리고 끝낼 문제가 아니에요. 토큰 만료 시간을 줄이고, 권한을 저장소별로 쪼개고, CI와 로컬 개발 환경에서 쓰는 비밀값을 분리해야 해요.

• 오픈소스 업데이트 유예도 무작정 늦게 받자는 뜻은 아니에요. 보안 패치는 빠르게 보되, 방금 올라온 낯선 릴리스가 빌드 파이프라인에 바로 들어가지 않도록 검증 구간을 만들자는 쪽에 가까워요.