GitHub에 낯선 ci-sync 브랜치가 생겼다면: Gheist 대응 순서

브랜치 이름과 워크플로 변경을 함께 확인한다

직접 만들지 않은 ci-sync- 브랜치가 보인다면 추가된 파일부터 확인해야 한다. Wiz가 10월 25일 공개한 Gheist 보고서는 이 접두사 뒤에 여섯 글자가 붙는 브랜치와 .github/workflows/sync-check.yml을 침해 지표로 제시했다. 커밋 메시지는 ci: sync config다. 이름만 보고 결론 내리지 말고 실제 변경 내용과 작성 주체를 함께 대조한다.

Wiz에 따르면 공격자는 탈취한 GitHub 토큰으로 워크플로를 심고, 비밀정보가 출력된 실행 로그를 GitHub API로 가져간 뒤 실행 기록을 삭제한다. 승인 대기 중인 의심스러운 작업을 확인 목적으로 실행해서는 안 된다.

GitHub의 사고 대응 절차는 사용 가능한 로그와 파일을 보존하면서 악용된 자격증명을 폐기하고, 진행 중인 악성 작업을 취소하도록 안내한다. 악성으로 확인한 브랜치도 제거 대상이다. 전체 조사를 마칠 때까지 공격자의 접근을 열어 둘 이유는 없다.

Actions 화면이 깨끗해도 실행하지 않았다는 뜻은 아니다

실행 기록을 삭제한 흔적은 감사 로그의 workflows.delete_workflow_run 이벤트로 조사할 수 있다. GitHub 조사 도구 안내는 워크플로 로그와 감사 이벤트를 연결해 보도록 권한다. 브랜치 생성, 푸시한 계정, 실행 시각을 같은 시간대에 놓고 비교하면 확인할 범위를 좁힐 수 있다.

조회 가능한 데이터는 요금제·권한·사전 설정에 따라 다르다. 조직 감사 로그는 조직 소유자, 기업 감사 로그는 기업 관리자가 확인한다. 실행 출력에는 모든 파일 변경이나 네트워크 동작이 남는 것도 아니다. 로그가 비어 있다는 이유로 접근 가능한 시크릿을 교체 대상에서 빼서는 안 된다.

침입 토큰과 작업이 읽을 수 있던 키를 따로 교체한다

교체 범위는 ‘GitHub 토큰 하나’가 아니라 공격 경로를 따라 정해야 한다. 워크플로를 밀어 넣은 자격증명과 그 워크플로가 얻을 수 있었던 자격증명은 서로 다르다.

GitHub는 작업에 발급된 GITHUB_TOKEN과 PAT·GitHub App 토큰·외부 키의 수명을 구분한다. 작업이 끝나면 작업용 토큰은 만료되지만, 다른 자격증명에는 각자의 만료·폐기 규칙이 적용된다. Wiz도 해당 악성 브랜치를 실행한 자체 러너와 인스턴스 역할을 침해된 것으로 취급하라고 권고했다.

별표 대신 비밀정보에 접근할 조건을 제한한다

GitHub의 보안 문서는 값이 변형될 수 있어 자동 마스킹을 보장하지 않는다고 명시한다. 로그의 ***는 악성 워크플로가 비밀정보를 읽지 못하게 하는 권한 장치가 아니다. 작업에 주는 자격증명은 필요한 권한만 갖도록 줄여야 한다.

운영 환경의 비밀정보에는 환경 보호 규칙을 적용할 수 있다. 필수 승인자를 설정한 환경은 승인이 나기 전까지 작업이 그 환경의 시크릿을 읽을 수 없다. 다만 Free·Pro·Team 요금제의 필수 승인자 기능은 공개 저장소에 한정된다. 비공개 저장소에서 같은 구성을 쓰려면 요금제의 지원 범위를 확인해야 한다.

사고 처리는 브랜치 제거에서 끝나지 않는다. 어떤 자격증명을 언제 폐기·교체했는지 기록하고, 새 워크플로·웹훅·러너·앱 권한이 남아 있는지 살펴야 다시 접근할 경로를 줄일 수 있다.