Git 커밋은 왜 위조될 수 있을까: GitHub Push Attribution과 신원 검증의 조건

Git 저장소에서 커밋 목록을 볼 때, 프로필 사진과 작성자 이름이 표시되면 우리는 자연스럽게 그 동료가 작성한 코드라고 믿게 된다. 하지만 Git을 조금이라도 깊이 다뤄 본 엔지니어라면 누구나 알고 있는 사실이 있다. Git의 작성자 정보는 사실상 아무런 검증 없이 로컬에서 적어 낸 문자열에 불과하다.

단순한 사내 프로젝트에서의 실수라면 가벼운 해프닝으로 끝날 수 있지만, AI 코딩 에이전트와 자동화 봇, 오픈소스 외부 기여자가 하나의 브랜치에 코드를 밀어 넣는 오늘날의 개발 환경에서는 이것이 치명적인 공급망 보안 취약점으로 작용한다.

10월 12일 GitHub가 발표한 **Push Attribution(제한적 공개 프리뷰)**은 Git의 오랜 구조적 한계를 플랫폼 레벨에서 해결하려는 시도다. 이 글에서는 Git 커밋이 왜 쉽게 위조될 수 있는지 원리를 짚어 보고, 기존 GPG 서명의 한계와 GitHub Push Attribution의 동작 방식, 그리고 실제 저장소에 도입하기 전 확인해야 할 운영 조건을 살펴본다.

이 글은 10월 13일 테크 브리핑에서 요약한 GitHub 보안 릴리스의 상세 기술 해설이다.

1. Git 커밋은 왜 이름과 이메일을 위조하기 쉬울까?

Git은 태생적으로 분산 버전 관리 시스템(DVCS)으로 설계되었다. 중앙 서버가 존재하지 않는 오프라인 환경에서도 개발자가 커밋을 생성하고 변경 이력을 기록할 수 있어야 했기 때문이다.

이러한 설계 철학으로 인해 Git의 커밋 객체(Commit Object)는 작성자의 신원을 중앙 인증 서버에 확인받지 않고 로컬 환경의 환경 변수나 설정값을 그대로 기록한다.

# 로컬 터미널에서 누구나 실행 가능한 설정
git config user.name "Linus Torvalds"
git config user.email "[email protected]"
git commit -m "Fix critical kernel bug"

위 명령을 실행하고 커밋 객체의 내부 내용을 git cat-file -p HEAD로 열어 보면 다음과 같은 평문 텍스트가 저장되어 있다.

tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
author Linus Torvalds <[email protected]> 1791875000 +0900
committer Linus Torvalds <[email protected]> 1791875000 +0900
 
Fix critical kernel bug

Git 내부 모델의 세 가지 신원: Author, Committer, Pusher

Git 모델을 이해하려면 세 가지 주체를 명확히 구분해야 한다.

주체	정의 및 생성 위치	위조 가능 여부
Author (작성자)	코드의 변경 내용을 최초로 작성한 사람 (`git commit`)	클라이언트 메타데이터이므로 임의 변경 가능
Committer (커밋 생성자)	커밋 객체를 실제로 생성하거나 리베이스·패치를 적용한 사람	클라이언트 메타데이터이므로 임의 변경 가능
Pusher (푸시 인증자)	원격 저장소(`origin`)에 `git push` 네트워크 요청을 보낸 계정	SSH 키 또는 HTTPS 토큰(PAT) 인증 필요 (플랫폼 검증)

문제는 GitHub와 GitLab 같은 원격 호스팅 서비스가 커밋 목록을 표시할 때, 커밋 객체 내부의 author 또는 committer 이메일 주소를 조회하여 등록된 계정 프로필로 렌더링한다는 점이다.

공격자가 저장소 쓰기 권한을 가진 낮은 등급의 계정 토큰을 탈취한 뒤, 커밋 작성자를 신뢰받는 보안 담당자나 테크 리드의 이메일로 위장해 코드를 올리면 코드 리뷰어나 배포 담당자가 경계심을 늦추기 쉽다. 이는 최근 10월 11일 브리핑에서 다룬 GhostAction 악성 워크플로 주입 사례처럼 공급망 침투의 교두보로 악용될 수 있다.

2. 기존 방어책: GPG / SSH 커밋 서명은 왜 완전한 답이 되지 못했을까?

물론 Git 진영도 이 문제를 방치한 것은 아니다. 대표적인 해결책이 암호학적 커밋 서명(Commit Signing)이다.

개발자가 로컬에서 개인키(GPG 또는 SSH 키)로 커밋 해시를 서명하고, GitHub에 등록된 공개키로 이를 검증하면 커밋 옆에 초록색 Verified 뱃지가 표시된다.

# 서명된 커밋 생성
git commit -S -m "Verified commit with GPG"

암호학적으로는 매우 강력하지만, 기업 실무 현장에서는 다음과 같은 운영상의 병목이 존재했다.

키 관리 비용과 온보딩 장벽: 모든 개발자에게 GPG 키를 발급하고 만료일 관리, 키 백업, 로컬 환경 설정을 강제하는 것은 개발 생산성을 떨어뜨리는 요인이다.
AI 에이전트와 자동화 도구의 파편화: 최근 코딩 에이전트 점검표에서 살펴보았듯, 개발자는 IDE 내부의 에이전트(Codex, Claude Code, Cursor)나 CI/CD 워크플로를 이용해 코드를 빈번하게 자동 생성한다. 이들 도구마다 서명 키를 분배하면 개인키 유출 위험이 커진다.
미서명 커밋의 묵인: 대다수 저장소는 오픈소스 생태계와의 호환성을 이유로 서명되지 않은 커밋도 기본 푸시를 허용한다. GitHub의 'Vigilant Mode(주의 모드)'를 켜더라도 미서명 커밋에는 'Unverified'가 뜰 뿐 푸시 자체가 차단되지는 않는 경우가 많다.

3. GitHub Push Attribution: 서버 레벨에서 실제 Pusher를 추적한다

10월 12일 GitHub가 공개한 **Push Attribution(Public Preview)**은 클라이언트가 적어 낸 메타데이터가 아니라, **GitHub 서버에 실제 인증을 거쳐 접속한 계정(Authenticated Pusher)**을 커밋의 영구적 속성으로 바인딩하는 기능이다.

1) 동작 원리와 화면 표시

개발자가 터미널에서 git push를 실행하면 GitHub 인증 서버는 전달받은 Personal Access Token(PAT), SSH 키, 혹은 GitHub App 토큰을 검증한다.

Push Attribution이 활성화되면 GitHub는 이 인증 결과를 커밋 객체의 외부 메타데이터로 서버에 기록하고, UI에서 다음과 같이 분리해 보여 준다.

Commit Details:
- Author: John Doe (클라이언트가 작성한 이름)
- Committer: John Doe
- Authenticated Pusher: @octocat (실제 인증을 통과해 네트워크 전송을 수행한 계정)

만약 커밋 메타데이터상의 작성자와 실제 푸시한 계정이 다르면, UI에서 명확히 불일치가 강조되어 리뷰어가 즉시 인지할 수 있다.

2) 리포지토리 규칙 세트: `Committer must match pusher`

단순히 화면에 표시하는 것에서 한 걸음 더 나아가, 저장소 거버넌스를 강제할 수 있는 규칙이 추가되었다.

GitHub 저장소의 Rulesets(규칙 세트) 설정에서 Committer must match pusher 옵션을 활성화하면, 클라이언트 커밋의 committer 이메일이 실제 푸시를 시도하는 GitHub 인증 계정과 일치하지 않을 경우 git push 요청 자체가 서버단에서 거부된다.

remote: error: GH013: Repository rule violations found for refs/heads/main.
remote: Reviewing commit metadata against authenticated pusher identity...
remote: - Commit 7a3f81c: Committer ([email protected]) does not match authenticated pusher (@contractor_bot).
To github.com:org/repo.git
 ! [remote rejected] main -> main (push declined due to repository rule)

이 규칙을 적용하면 공격자가 탈취한 하위 권한 토큰으로 관리자 명의의 커밋을 위장해 밀어 넣는 행위를 원천 차단할 수 있다.

4. 실무 도입 전 반드시 점검해야 할 조건과 한계

새로운 보안 기능이 도입될 때 가장 주의해야 할 점은 기존 빌드 파이프라인이나 정상적인 협업 흐름을 깨뜨리지 않는지 확인하는 것이다.

1) 라이선스 및 프리뷰 상태

현재 이 기능은 GitHub Enterprise 고객 대상의 제한적 공개 프리뷰(Limited Public Preview) 단계다. 개인 계정이나 무료 조직 저장소에는 아직 메뉴가 노출되지 않으며, 기능 안정화와 피드백 수렴을 거쳐 점진적으로 확대 배포될 예정이다.

2) 파이프라인 및 AI 에이전트와의 충돌 가능성

Committer must match pusher 규칙을 켜기 전에 다음 워크플로가 저장소에 존재하는지 반드시 확인해야 한다.

공용 서비스 계정(Machine User) 기반 푸시:
개발자가 로컬에서 본인 명의로 커밋한 뒤, 사내 게이트웨이나 배포 봇의 공용 토큰으로 푸시하는 구조라면 커밋 작성자와 푸시 계정이 달라 푸시가 차단된다.
AI 코딩 에이전트의 로컬 설정:
AI 도구가 독자적인 서비스 계정 토큰으로 푸시하면서 커밋 메타데이터는 로컬 Git 설정의 개발자 이메일을 물려받는 경우 충돌이 발생할 수 있다. 에이전트의 전용 토큰 계정과 커밋 생성 계정을 일치시켜야 한다.
웹 UI 및 Rebase 머지:
GitHub 웹 UI를 통한 'Rebase and merge'나 'Squash and merge'는 GitHub 내부 시스템 계정(web-flow)이 committer로 들어가는 경우가 있으므로, 규칙 세트의 바이패스(Bypass) 목록에 GitHub 앱이 적절히 지정되어 있는지 확인해야 한다.

3) 이것이 막아주지 못하는 것

Push Attribution은 커밋 메타데이터 '위조'를 막아줄 뿐, 푸시 인증 계정 자체의 탈취를 막아주는 마법의 방패는 아니다.

만약 관리자의 Personal Access Token(PAT) 자체가 유출되었거나 개발자의 로컬 PC가 장악되어 정상 인증 세션을 통해 푸시가 일어난다면, GitHub 입장에서는 정당한 푸셔로 인식된다. 따라서 다음과 같은 기본 보안 체계가 여전히 함께 작동해야 한다.

PAT 생성 시 세분화된 권한(Fine-grained PAT) 및 짧은 유효기간 적용
조직 차원의 2단계 인증(MFA) 및 SSO 세션 관리
중요한 보호 브랜치(main, release)에 대한 최소 2인 이상 코드 리뷰(Pull Request Review) 강제

5. 엔지니어링 팀을 위한 단계별 보안 점검표

사내 저장소와 오픈소스 프로젝트의 커밋 신뢰성을 확보하기 위해 지금 바로 점검할 수 있는 항목을 정리했다.

단계	점검 항목	권장 조치
기본 점검	Git 로컬 설정 확인	`git config user.email`이 회사 SSO 인증 계정과 동일한지 확인
규칙 세트	GitHub Ruleset 확인	Enterprise 환경이라면 Push Attribution 프리뷰 및 `Committer must match pusher` 테스트 브랜치 적용
에이전트 거버넌스	코딩 봇·에이전트 인증	사내 AI 도구(Claude Code, Codex 등)가 푸시할 때 사용하는 토큰과 커밋 작성자 일치 여부 점검
공급망 방어	Actions 및 워크플로	`.github/workflows`의 서드파티 액션 해시 고정 및 최소 권한(`permissions: read-all`) 부여
서명 병행	커밋 서명(GPG/SSH)	고위험 릴리스 저장소는 Push Attribution과 함께 GPG 서명 강제(Require signed commits) 병행

Git의 자유로운 로컬 메타데이터는 협업의 진입 장벽을 낮추었지만, 소프트웨어 공급망이 복잡해진 오늘날에는 의도치 않은 신뢰의 구멍이 되었다.

GitHub의 Push Attribution은 개발자에게 복잡한 키 관리의 짐을 지우지 않으면서도 플랫폼 레벨에서 명확한 신원 추적성을 제공하는 실용적인 접근이다. 조직의 상황에 맞춰 프리뷰 기능을 검토하고 사내 자동화 도구의 커밋 설정을 선제적으로 점검해 두자.

참고 자료

Push Attribution Public Preview Changelog — GitHub, 2026-10-12
About commit signature verification — GitHub 공식 문서, 확인일 2026-10-13
Managing rulesets for repositories — GitHub 공식 문서, 확인일 2026-10-13
Git Internals - Git Objects — Git 공식 문서, 확인일 2026-10-13