도난된 것으로 보이는 토큰으로 GitHub 계정 약 4,800개 악용, CI 시크릿과 클라우드 자격 증명 탈취(2026년 11월): 저장소 소유자가 오늘 할 일

계정이 쓸 수 있는 모든 저장소(협력자로 참여한 조직 포함)에서 11월 10일 이후의 다음 세 가지를 확인하세요. 업체 A에 따르면 탐색용 풀 리퀘스트 61,839건 가운데 10,431건은 계정이 소유하지 않은 저장소로 갔고, 협력자나 조직 권한을 통해 도달했습니다.

• 본인이나 팀원이 열지 않은 풀 리퀘스트. 제목이 무해해 보여도(문서 업데이트 등) 여러 저장소에서 같은 패턴이 보이면 경고 신호입니다
• 모르는 단명 브랜치, 또는 브랜치가 만들어졌다가 삭제된 흔적
• 모르는 실행이 있거나 실행 번호가 비어 있는 Actions 실행 이력. 업체 A와 C는 공격자가 약 1분 안에 실행과 로그를 삭제한다고 적었으므로 번호의 빈 곳이 단서입니다. 조직 감사 로그도 확인하세요

하나라도 있으면 아래를 계속하세요. 업체 A는 탐색용 풀 리퀘스트가 있는 계정은 이후 단계가 실행되지 않았더라도 침해된 것으로 취급하라고 적었습니다.

이 순서는 업체 B와 C의 지침을 따릅니다.

• 개인 액세스 토큰, 서드파티 앱(OAuth 앱과 GitHub 앱) 인증, SSH 키, 활성 세션을 폐기한 뒤 필요한 것만 다시 만드세요
• 2단계 인증을 켜세요. 이미 도난된 토큰은 2단계 인증 없이도 작동하므로 토큰 폐기가 먼저입니다(이 사이트의 견해)
• 탐색용 풀 리퀘스트를 닫고 모르는 브랜치를 삭제하세요. 삭제하기 전에 어느 계정으로 만들어졌는지 기록하세요

업체 A와 B는 악성 변경이 실행되었다면 그 워크플로가 쓸 수 있던 모든 시크릿과 클라우드 역할을 도난된 것으로 취급하라고 적었습니다.

• Actions 시크릿과 변수(저장소, 환경, 조직 수준), 게시용 토큰(패키지용 포함), 배포 키를 재발급하고 이전 것을 무효화하세요
• OIDC로 클라우드 계정에 접근한다면 그 클라우드 권한도 포함하세요(다음 단계)
• 악성 변경을 받았을 수 있는 저장소를 개발 머신에서 빌드했다면 그 머신이 읽을 수 있던 자격 증명(SSH 키, 클라우드 자격 증명, 패키지 게시 토큰 등)도 교체하세요. 업체 B와 C는 패키지 설치 시점에 실행되는 변경을 보고했습니다
• 11월 10일 이후 패키지를 게시했다면 게시된 버전에 악성 변경이 없는지 확인하세요. 있다면 철회하고 깨끗한 상태에서 다시 게시하세요

시크릿 교체 후에도 남는 변경으로 업체 A는 AWS 역할 신뢰 정책의 재작성과 Azure 페더레이션 자격 증명의 추가를 들었습니다(업체 B는 남겨진 AWS 액세스 키도 언급). 감사 로그와 현재 설정 양쪽에서 이 두 영역을 확인하세요.

• AWS: 새로 만들어진 액세스 키, 역할 신뢰 정책의 변경(의도하지 않은 계정이나 조건으로 신뢰가 넓어졌는지)
• Azure(Entra ID): 애플리케이션에 추가되어 저장소를 가리키는 페더레이션 자격 증명

별도로, 훔친 자격 증명을 통한 권한 상승 점검으로 Google Cloud(비정상적인 서비스 계정 사용이나 토큰 발급 호출)와 Vault나 Kubernetes(모르는 GitHub OIDC 로그인)도 살펴보세요.

아무것도 찾지 못해도 OIDC 신뢰 조건이 저장소, 브랜치, 환경으로 좁혀져 있는지 확인하세요(아래 「점검할 것」 참조).

GitHub 설정에서 다음 목록을 만들고 불필요하거나 모르는 것을 제거하세요.

• 개인 액세스 토큰: 쓰지 않는 것은 삭제하고 나머지는 저장소, 권한, 수명을 제한하세요
• 인증해 준 OAuth 앱과 GitHub 앱(호스팅이나 CI 배포용으로 연결한 것 포함). 더 이상 쓰지 않는 것은 인증을 취소하세요
• SSH 키와 배포 키: 쓰지 않는 키와 소유자 없는 키를 제거하세요
• 봇과 자동화 계정의 권한: 보호된 브랜치 규칙을 우회할 수 있는 것이 있는지 확인하세요

클라우드 사업자의 안내에 따르면 그 사업자의 앱은 다시 연결해야 합니다. 이용한다면 사업자의 지침을 따르세요.

같은 사업자는 GitHub를 통해 배포된 일부 앱이 빌드 디렉터리 전체를 공개하여 거기에 남은 토큰을 가져갈 수 있었다고 설명합니다. 앱의 공개 URL이 버전 관리 폴더(.git)의 내용을 제공하지 않는지 확인하세요. 제공한다면 이미지에서 제외하고 다시 배포한 뒤 그 안에 있던 자격 증명을 교체하세요. 배포 플랫폼이 비슷한 방식을 쓰는지도 확인하세요.

이번에는 도난된 유효한 토큰이 쓰였습니다. 개인 액세스 토큰은 특정 저장소와 권한으로 제한하고, 수명을 짧게 하고, 쓰지 않으면 삭제하세요(세분화된 유형을 사용). 서드파티 앱은 필요한 범위에만 인증하세요(이 사이트의 견해).

워크플로의 기본 권한을 읽기 전용으로 하고 쓰기는 필요한 곳에만 부여하세요. 클라우드 OIDC 신뢰를 저장소, 브랜치, 환경으로 좁혀 모든 워크플로가 들어갈 수 없게 하세요. 환경 시크릿에 승인자를 두면 고쳐 쓴 워크플로가 운영 시크릿을 그냥 읽을 수 없습니다(이 사이트의 견해).

업체 A는 코드에 브랜치 보호를 우회하려는 장치가 들어 있다고 적었습니다. 검사 이름만 믿지 말고 코드 소유자의 승인 리뷰를 요구하고 봇 계정에 예외를 두지 마세요(이 사이트의 견해).

이번에는 실행과 로그가 삭제되었고 번호의 빈 곳이 단서였습니다. 조직 감사 로그를 보관하고, 워크플로 변경과 클라우드 액세스 키 생성, 신뢰 정책 변경, ID 연동 추가에 알림을 설정하세요. 업체 C는 CI의 외부 통신을 허용 목록으로 제한하는 것도 권고합니다.

CI 시크릿과 별개로, 코드 이력에 있는 자격 증명은 그것을 읽을 수 있는 사람의 도난된 토큰과 함께 가져갈 수 있습니다. 커밋 전에 잡는 방법은 gitleaks로 커밋 전에 시크릿 막기를, 폐기 순서는 GitHub에 노출된 자격 증명 54만 건이 여전히 유효를 참고하세요.