스낵 3줄 요약
- GitHub이 커밋을 푸시한 인증 계정을 별도로 기록하는 기능을 한정 공개 프리뷰로 선보였습니다.
- 화면과 API에서 작성자·커미터 정보와 푸시 계정을 함께 볼 수 있어 의심스러운 커밋을 살펴보는 데 도움이 됩니다.
- GitHub Enterprise 고객은 담당 팀에 프리뷰 접근 권한을 요청해야 하며, 이메일 일치에 따른 차단 규칙은 별도로 설정합니다.
GitHub이 2026년 10월 12일, 커밋마다 실제로 푸시한 인증 계정을 남기는 기능을 발표했습니다. GitHub Enterprise 고객 대상 한정 공개 프리뷰로, 클라이언트가 적은 커미터 정보와 GitHub이 인증한 푸시 계정을 구분해 볼 수 있습니다.

스낵걸즈 한마디
AIKO: 클라이언트가 적은 이름과 푸시 인증에서 남은 계정, 정보가 생기는 경로부터 다르네. 둘을 나란히 볼 수 있는 구조가 흥미로워.
네아: 익숙한 이름을 보면 그냥 지나치기 쉬울 것 같아요. 그 옆의 푸시 계정까지 살펴보면 커밋 기록에서 어떤 맥락이 보일지 궁금하네요.
커밋에 적힌 이름과 푸시 계정은 별개
커밋의 작성자(author)와 커미터(committer) 이름·이메일은 푸시 클라이언트가 제공하는 문자열입니다. 저장소에 쓰기 권한이 있으면 이 값을 원하는 이름과 이메일로 설정할 수 있습니다. 푸시한 계정(pusher)은 GitHub이 푸시 과정에서 인증한 사용자로, 새 기능은 그 계정을 커밋마다 별도로 기록해 보존합니다.
GitHub은 쓰기 권한이 있는 낮은 권한의 계정이 탈취되면, 공격자가 신뢰받는 관리자의 이름을 넣어 검토 정책을 피하거나 감사 기록을 혼란스럽게 할 수 있다고 설명합니다. 다만 커미터와 푸시 계정은 정상적인 상황에서도 다를 수 있어, 불일치 자체가 공격의 증거는 아닙니다.
차단 규칙은 커미터 이메일을 대조합니다
새 저장소 규칙 조건인 Committer must match pusher는 커미터의 이메일을 인증된 푸시 계정의 확인된 이메일 주소와 대조합니다. 확인된 주소 가운데 하나와 일치하면 조건을 충족하고, 어느 주소와도 일치하지 않으면 푸시를 차단합니다. 작성자 이메일이나 표시 이름을 같게 만드는 규칙은 아닙니다.
이 차단 조건은 규칙 세트(ruleset)에 직접 추가해야 적용됩니다. 푸시 계정을 기록하는 기능과 차단 규칙은 별개이므로, 기록만으로 모든 사칭이나 계정 탈취가 막히는 것은 아닙니다.
프리뷰 접근 권한을 받은 뒤 살펴볼 기록
프리뷰에 참여하려는 GitHub Enterprise 고객은 GitHub의 계정 담당 팀에 접근 권한을 요청해야 합니다. 모든 GitHub 사용자에게 자동으로 제공되는 기능은 아닙니다.
참여 후에는 화면과 API에 표시되는 푸시 계정을 의심스러운 활동의 점검이나 보안 조사에 활용할 수 있습니다. 익숙한 관리자 이름이 표시돼도, 그 커밋을 실제로 푸시한 계정을 함께 살펴보는 식입니다.
출처 및 확인일: 2026년 10월 13일

댓글
0로그인 없이 남길 수 있어요. 작성한 브라우저에서 수정·삭제할 수 있어요.
전체 댓글 0
한국어 · English · 日本語아직 댓글이 없어요. 첫 이야기를 남겨 주세요.