인증된 푸셔 신원의 영구 기록과 신규 룰셋 추가
GitHub이 커밋을 원격 저장소에 실제로 푸시한 인증 사용자의 신원을 영구적으로 기록하고, 이를 웹 인터페이스와 API 전반에 노출하는 기능을 2026년 10월 12일 공개했습니다. 이번 변경으로 사용자는 기존에 표시되던 커밋 작성자(Author)와 커미터(Committer) 정보 옆에서 실제 푸시를 수행한 인증 계정(Pusher)을 함께 확인할 수 있게 되었습니다.
이와 함께 리포지토리 규칙 세트(Ruleset)에 '커미터와 푸셔 일치 필수(Committer must match pusher)'라는 신규 조건이 추가되었습니다. 이 규칙이 활성화되면 푸시하려는 커밋에 기재된 커미터 이메일이 해당 작업을 수행하는 푸셔 계정의 인증 완료된 이메일 목록에 포함되어 있지 않을 경우 푸시 작업 자체가 즉각 차단됩니다.
Git 클라이언트 메타데이터 조작 한계 극복 시도
Git 프로토콜의 설계 구조상 커밋 메타데이터에 기록되는 작성자와 커미터 정보는 로컬 클라이언트 환경설정값에서 가져오는 단순 텍스트 문자열에 불과합니다. 따라서 저장소에 대한 쓰기 권한만 확보되어 있다면, 공격자는 타인의 이름과 이메일을 임의로 지정하여 정상적인 메인테이너인 것처럼 커밋을 위조할 수 있었습니다. 특히 권한이 낮은 내부 계정이 탈취되었을 때 핵심 관리자의 명의를 도용해 코드 리뷰 승인 기준을 우회하거나 침해 사고 조사 시 혼선을 초래하는 문제가 지속적으로 제기되어 왔습니다.
GitHub은 이미 전송 구간에서 인증 절차를 거치고 있었으나, 해당 인증 정보를 커밋 단위의 영구 속성으로 UI와 API에 연동하여 표기하지는 않았습니다. 플랫폼 차원에서 인증된 푸셔 계정을 커밋에 직접 고정함으로써, 원격 저장소에 반영된 코드 변경의 실제 전송 주체를 명확히 추적할 수 있는 기반이 마련된 셈입니다.
도입 조건 및 서비스 제공 범위
푸시 어트리뷰션 기능은 현재 GitHub Enterprise 요금제를 이용하는 조직을 대상으로 '제한적 퍼블릭 프리뷰(Limited Public Preview)' 형태로 배포되었습니다. 저장소에 기본 활성화(Default-on)되는 방식이 아니므로, 기능을 시험하고자 하는 관리자는 담당 GitHub 계정 전담 팀에 직접 접근 권한을 요청해야 합니다.
일반 무료(Free) 계정이나 팀(Team) 플랜 사용자를 대상으로 한 공개 일정은 공개되지 않았습니다. 아울러 기업 자체 인프라에 구축되는 GitHub Enterprise Server(GHES) 환경에 언제 정식 탑재될 것인지에 대해서도 구체적인 지원 일정이 아직 확인되지 않았습니다.
자동화 파이프라인 중단 위험과 실무 적용 시 고려사항
신규 룰셋 조건인 '커미터와 푸셔 일치 필수'는 강력한 신원 위조 방지 수단이지만, 기존 CI/CD 파이프라인과의 충돌 가능성을 면밀히 살펴야 합니다. 다수의 개발 조직에서는 릴리스 봇, 코드 포매터 자동 커밋, 미러링 파이프라인 등 기계 계정(Service Account)이나 타사 CI 도구가 특정 엔지니어의 명의로 커밋을 대신 생성하고 푸시하는 패턴을 운영하고 있습니다.
해당 환경에 새 규칙을 무조건 적용할 경우 유효하지 않은 커미터 불일치로 인해 정상 빌드와 배포 파이프라인이 전면 중단될 수 있습니다. 규칙 적용 전 조직 내 자동화 계정이 자체적인 고유 인증 이메일을 사용하도록 정비하거나, 대리 푸시 작업이 발생하는 저장소의 예외 경로를 식별하는 사전 점검 작업이 반드시 선행되어야 합니다.
기능의 한계와 미확인 세부 동작 점검
GitHub 측은 이번 조치로 커밋 신원 스푸핑 경로를 차단하고 보안 조사 속도를 대폭 높일 수 있다고 강조합니다. 그러나 푸시 어트리뷰션은 푸시 당시의 신원 일관성을 담보할 뿐이며, 커밋 내용 자체의 암호학적 무결성을 증명하는 GPG 기반 서명 커밋(Signed Commits)이나 엄격한 브랜치 보호 정책, 코드 리뷰 체계를 온전히 대체하지는 못한다는 점을 유념해야 합니다.
또한 GitHub Apps나 배포 키(Deploy Keys), 리포지토리 관리자 권한 등이 신규 규칙의 우회(Bypass) 목록과 구체적으로 어떻게 상호작용하는지에 대해서는 공식 가이드 문서상 세부 정의가 부족한 상태입니다. 따라서 기업 보안 담당자는 정식 상용화 이전까지 테스트 리포지토리를 통해 권한별 예외 동작과 감사 로그 기록 양상을 면밀히 검증할 필요가 있습니다.
출처
GitHub Changelog의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
Push attribution for commits in limited public preview (새 창)
