PyPI 악성 깃허브 액션스(GitHub Actions) 워크플로우 공격 + 토큰 무효화 조치 📦🔐

PyPI 악성 깃허브 액션스(GitHub Actions) 워크플로우 공격 + 토큰 무효화 조치 📦🔐

부제: 공개 저장소 워크플로우에 숨겨진 위협, 어떻게 발견되고 어떻게 대응됐는가

---

사건 개요: 무슨 일이 있었나

• 최근 “GhostAction”이라는 공급망 공격(supply chain attack) 캠페인이 발견됨. 공격자들이 GitHub Actions 워크플로우 내에 악의적 코드를 주입해서, 저장된 **PyPI 퍼블리싱 토큰(publishing tokens)**을 외부 서버로 보내도록 유도했어. 파이썬 패키지 인덱스 블로그+2BleepingComputer+2
• 이 토큰들은 PyPI에 패키지를 퍼블리시할 수 있는 권한을 가진 것들이고, 일부는 실제로 탈취된 것으로 보이지만, 현재까지 PyPI 측에서는 “해당 토큰들이 실제로 악의적 사용으로 패키지 발행에 이용된 증거는 없음”이라고 발표됨. 파이썬 패키지 인덱스 블로그+1
• 토큰이 저장된 방식(예: GitHub Secrets)이나 워크플로우의 취약한 설정이 공격 포인트가 됐고, 여러 저장소가 영향을 받음. 파이썬 패키지 인덱스 블로그+1

---

대응 조치: PyPI 및 커뮤니티의 반응

조치구체 내용

영향 받은 토큰 전부 무효화(Invalidate)	PyPI 운영진이 영향을 받은 모든 퍼블리싱 토큰을 무효화해서 더 이상 사용되지 못하도록 함. 파이썬 패키지 인덱스 블로그+1
프로젝트 유지관리자(maintainers) 연락 & 지원	영향을 받은 저장소 유지관리자들에게 연락해서 워크플로우의 악성 부분 제거, 변경점 리버트(revert), GitHub Action 워크플로우를 정상 상태로 복원하도록 도움. 파이썬 패키지 인덱스 블로그+1
토큰 관리 방식 개선 권고	오래 지속되는 토큰 대신 Trusted Publishers 옵션을 쓰라고 권고함. 이 기능은 특정 저장소에 한정되고 단기간 유효한(short-lived) 토큰을 사용하도록 하므로, 탈취당하는 위험을 줄일 수 있음. 파이썬 패키지 인덱스 블로그
보안 기록(Security History) 및 로그인 기록 검토	사용자들에게 본인 계정의 최근 보안 활동(history)에 이상한 접근이나 활동이 없는지 확인하라고 안내됨. 파이썬 패키지 인덱스 블로그

---

왜 이런 일이 가능했나? 배경 & 취약점

• 많은 프로젝트들이 GitHub Actions 워크플로우 내에 PyPI 퍼블리싱 토큰을 GitHub Secrets에 저장해두고 있음. 이 토큰들은 워크플로우가 정상 작동하려면 필요함. 하지만 워크플로우가 수정되면, 이 토큰이 외부로 전송될 수 있음. 파이썬 패키지 인덱스 블로그+1
• 일부 유지관리자의 워크플로우 변경이 공격자에 의해 이루어졌고, 이 변경이 리포지토리의 히스토리(history)에 남아 있었던 경우도 있음 (예: force push로 변경사항 제거 등) 파이썬 패키지 인덱스 블로그
• 보고된 바에 따르면, 처음 GitGuardian 연구자가 발견했을 때 PyPI 보안팀에게 이메일 보냈는데 스팸 폴더에 들어가는 등의 지연이 발생 — 이런 지연이 대응 속도를 늦춤. 파이썬 패키지 인덱스 블로그

---

사용자(프로젝트 유지관리자) 입장에서 꼭 해야 할 것들

1. GitHub Actions 워크플로우 점검
   • 워크플로우 파일 중 “publish to PyPI” 또는 퍼블리싱 관련 액션(action)이 있는 워크플로우 살펴보기
   • 최근 커밋(history)이나 리뷰에서 워크플로우가 누군가에 의해 변경된 적 있는지 확인
   • Unsuspicious한 외부 서버로 데이터를 전송하는 curl 등의 명령이나 “exfiltrate token” 같은 의심되는 코드 있는지 검토
2. 토큰(rotating tokens) 또는 Trusted Publishers 적용
   • PyPI 퍼블리싱에 쓰는 토큰이 오래 지속되는(long-lived) 토큰인지 확인 → 가능하면 단기간 유효한(short-lived) Trusted Publishers 토큰으로 바꾸기 파이썬 패키지 인덱스 블로그
   • 토큰이 노출되었을 가능성 조금이라도 있다면 즉시 회전(rotating)시킬 것
3. 보안 설정 강화
   • 2단계 인증(2FA; Multi-factor Authentication) 켜두기
   • 계정의 보안 이력(Security History) 확인 → 로그인 시도, 비정상적인 퍼블리싱 기록 등이 있는지
   • 이메일 주소가 유출되거나 도메인이 만료된(custom domain) 경우 도메인 소유 상태 확인
4. 커뮤니티 및 보안 알림체계 확인
   • 보안 리포트나 감사(audit) 도구 활용: GitGuardian 등의 서비스가 이상 발견 시 알림 제공함
   • 저장소에 영향 받는 워크플로우가 있는지 GitHub Issues 등 공개적으로 알림 올라왔는지 체크

---

한계 및 조심해야 할 점

• 무효화된 토큰만으로 완전한 보안 확보라고 할 수 없음 — 이미 워크플로우 코드가 노출되었거나 누군가 액세스 권한을 가지면 또 다른 지점에서 위협이 발생 가능함.
• Trusted Publishers 기능도 단거리(short-lived) 토큰을 쓰더라도 노출되면 위험이 있으므로 워크플로우 자체의 보안이 중요함.
• 이메일 보고가 스팸함으로 빠지는 등의 커뮤니케이션 지연 문제는 사전 대비가 쉬운 건 아니어서, 각 조직이 내부 보안 알림 루트를 잘 관리해야 함.
• 사용자 측에서도 의심 되는 이메일, PR(pull request), 워크플로우 변경 요청 등에 대해 항상 경계를 가져야 함. 개발자 계정 탈취나 Credential 노출은 작은 변화로 시작되는 경우가 많아.

---

결론

이번 사건은 PyPI 자체가 침해된 것은 아니었지만, 토큰 저장 방식 + 워크플로우 취약점이 공급망 보안(supply chain security)에 얼마나 중요한지를 보여주는 좋은 사례야. 앞으로 Python 패키지를 관리하거나 퍼블리싱할 일이 있다면, 토큰 관리 방식 개선 + 워크플로우 보안 점검 + 보안 알림 루트 정비를 우선순위로 두는 것이 좋겠고, 이번 일이 큰 경각심을 불러일으킬 수 있는 계기가 될 거야.