GitHub 커밋 Push Attribution: author·committer·pusher 차이와 위조 방지 설정

author·committer·pusher 차이

GitHub는 author와 committer가 클라이언트가 보내는 문자열이어서 쓰기 권한을 가진 사용자가 다른 이름·이메일을 넣을 수 있다고 설명합니다. Push Attribution은 이러한 주장과 독립적인 pusher 기록을 추가합니다. 근거: 공식 발표

세 역할이 다르다고 바로 공격으로 판단하면 안 됩니다. 예를 들어 기여자의 패치를 유지관리자가 커밋해 푸시하면 작성자와 전달 주체가 다를 수 있습니다. 반면 신뢰하는 유지관리자 이름이 표시되더라도 실제 푸시 계정이 예상 밖이라면 변경 내용과 작업 경로를 확인할 필요가 있습니다.

로컬에서 커밋 작성자·커미터 확인하기

git show --no-patch --format=fuller HEAD
# 확인하려는 커밋 해시로 바꿔 사용
 git show --no-patch --format=fuller [commit-sha]

fuller 형식은 author·committer와 날짜를 확인하는 데 사용할 수 있습니다. 근거: Git show 문서 로컬 Git 커밋 정보만으로 GitHub의 인증 pusher를 알 수는 없습니다. 로컬 결과는 메타데이터 확인이고, 푸시 주체는 프리뷰가 제공하는 GitHub 기록과 대조해야 합니다.

보고서에는 커밋 SHA와 저장소를 함께 적으세요. 같은 이메일 문자열과 GitHub 계정의 검증된 이메일 관계도 별도 확인이 필요합니다. 이름이 같다는 사실이나 프로필 사진만으로 동일인을 확정하지 않습니다.

Push Attribution 프리뷰와 규칙의 적용 범위

Enterprise 고객은 account team에 프리뷰 접근을 요청하도록 안내됐습니다. 발표는 UI·API에 pusher를 표시한다고 설명하지만 상세 API 필드명, 기존 커밋의 소급 기록, 여러 번 푸시된 커밋의 귀속 방식은 명시하지 않습니다. 해당 동작은 프리뷰 문서와 계정 지원에서 확인해야 합니다. 근거: 접근 조건·기록 범위

일반 ruleset 기능의 플랜 지원과 이번 제한적 프리뷰의 접근 조건은 다릅니다. Rulesets 메뉴가 보인다는 이유로 Committer must match pusher 조건도 사용 가능하다고 가정하지 마세요.

Committer must match pusher 설정 순서

1. 조직의 Enterprise 프리뷰 접근 여부와 관리 권한을 확인합니다.
2. 저장소 Settings의 Rulesets 관리 화면에서 적용할 규칙을 검토합니다.
3. 프리뷰에서 제공하는 Committer must match pusher 조건을 추가합니다.
4. 대상 범위·집행 상태·bypass 주체를 확인합니다.
5. 별도 테스트 저장소에서 정상 개발자·자동화의 작업을 검증합니다.
6. 영향을 확인한 후 운영 적용과 실패 대응 담당자를 정합니다.

GitHub 발표는 ruleset에 새 조건을 추가하도록 안내합니다. 일반 생성·편집 경로와 Active 집행 상태는 ruleset 문서를 참고하세요. 프리뷰 조건의 정확한 하위 메뉴 위치나 모든 규칙 유형의 지원을 일반 문서만으로 단정하지 않습니다.

핵심 비교 대상은 committer 이메일과 pusher 계정의 검증된 이메일입니다. author가 pusher와 같아야 한다는 규칙으로 바꿔 읽으면 기여자 작성 정보를 잘못 수정할 수 있습니다. 규칙을 맞추기 위해 다른 사람의 작성자 정보를 지우기보다 실제 작업 방식과 인증 계정을 먼저 확인하세요.

정상 협업·CI에서도 확인할 테스트 사례

이 표는 편집부가 권하는 검증 목록입니다. 봇·App·웹 병합의 세부 처리 방식은 발표만으로 확정할 수 없습니다. 먼저 실제 결과를 확인하고 필요한 예외는 대상·책임자·만료 또는 재검토 시점을 기록하세요. 전체 자동화를 넓게 우회하도록 두면 규칙 적용 의도가 약해질 수 있습니다.

커밋 서명·코드 리뷰와 함께 써야 하는 이유

pusher 기록은 어떤 계정으로 푸시했는지 보여주지만, 그 계정의 자격증명을 실제로 누가 사용했는지까지 보장하지 않습니다. 규칙을 통과한 코드가 안전하다는 뜻도 아닙니다. 계정 보호, 서명 검증, PR 리뷰와 필수 검사를 서로 다른 목적의 통제로 검토하세요.

GitHub ruleset 문서도 메타데이터 제한이 PR 코드 리뷰 같은 보안 조치를 대신하지 않는다고 설명합니다. 근거: 메타데이터 제한 안내 신규 규칙은 committer 사칭 경로를 줄이는 역할로 해석해야 하며 모든 위조·계정 탈취를 차단한다는 표현은 피해야 합니다.

의심 커밋 조사에 남길 기록 양식

저장소 / 커밋 SHA / 확인 시각:
author 이름·이메일 / committer 이름·이메일:
GitHub pusher 계정 / 조회 위치:
기대했던 작업 주체 / 실제 작업 경로:
적용 ruleset / 집행 상태 / bypass 여부:
PR·리뷰·검사·서명 관련 기록:
추가 조사 / 담당자 / 다음 조치:

표시 이름이 다른 사례는 작업자에게 경위를 확인하고 PR·자동화 로그와 대조하세요. 인증 계정도 예상과 다르면 자격증명 사용 이력과 권한을 조사해야 합니다. 증거를 보존한 뒤 팀의 사고 대응 절차에 따라 조치하는 것이 좋습니다.

자주 묻는 질문

author와 pusher가 다르면 커밋이 차단되나요?

발표된 조건은 committer 이메일과 pusher의 검증 이메일을 비교합니다. author 일치를 요구하는 것으로 해석하지 마세요.

이메일을 Git에 설정하면 인증된 신원이 되나요?

로컬 문자열 설정과 GitHub 푸시 인증은 별개입니다. 새 규칙에서 비교하는 계정의 검증 이메일도 구분해야 합니다.

일반 GitHub 계정에서 바로 켤 수 있나요?

10월 12일 발표 기준 Enterprise 고객 대상 제한적 프리뷰입니다. 메뉴가 없으면 자격·프리뷰 접근을 확인하세요.

API로 pusher를 조회하는 예제가 있나요?

확인한 발표에는 상세 필드와 호출 예제가 없습니다. 기존 API 필드를 임의로 pusher로 간주하지 말고 프리뷰 문서에서 확인해야 합니다.

관련 GitHub 보안 점검

• AI Scan 발견·해결·Autofix 지표 해석
• 비밀키 유출 탐지와 푸시 차단 범위