'Verified' 커밋의 결함: GitHub/GitLab의 공급망 보안 부족
소프트웨어 공급망 공격은 중대한 관심사가 되었으며, 개발의 모든 단계에서 강력한 보안 조치가 필요함을 강조하고 있습니다. 코드 무결성을 확보하는 근본적인 측면은 커밋 서명(commit signing)이며, 이는 변경 사항의 작성자와 진위 여부를 확인하는 것을 목표로 합니다. 그러나 GitHub 및 GitLab과 같은 주요 Git 플랫폼이 커밋 서명을 구현하고 강제하는 방식에는 중대한 격차가 존재하며, 이로 인해 조직은 기존의 "Verified" 배지를 우회하는 정교한 공격에 취약해질 수 있습니다.
이 문제는 플랫폼이 특정 서명 키를 강제할 수 없는 능력에서 비롯되며, 공격자가 정당한, 검증된 커밋으로 위장하여 저장소에 악성 코드를 주입할 수 있게 합니다. 이 포스트에서는 현재 커밋 서명 보호 기능의 한계, 인기 있는 플랫폼에서 누락된 기능, 그리고 이러한 보안 결함을 보완하기 위해 개발 팀에 지워지는 상당한 부담에 대해 살펴봅니다.
"Verified" 커밋의 환상
GitHub와 GitLab은 "Require signed commits" 기능을 제공합니다. 이는 표면적으로는 저장소에 푸시된 모든 커밋이 커미터의 계정과 연결된 키로 서명되었는지 확인하여 보안을 강화하는 것처럼 보입니다. 그러나 이 보호 조치는 근본적으로 결함이 있습니다. 만약 공격자가 개발자의 노트북이나 GitHub/GitLab 계정을 탈취한다면, 해당 계정에 새로운 서명 키를 단순히 추가할 수 있습니다. 이 새로운, 승인되지 않은 키를 사용하여 공격자는 악성 커밋을 푸시할 수 있으며, 이는 여전히 탐나는 "Verified" 배지를 받게 됩니다.
이 시나리오는 중대한 사각지대를 생성합니다: 신뢰의 표시로 의도된 "Verified" 배지는 공급망 공격의 잠재적인 경로가 될 수 있습니다. 이 기능에만 전적으로 의존하는 조직은 악성 코드가 코드베이스에 원활하게 통합되어 정당한 것처럼 보일 수 있기 때문에 잘못된 보안 의식을 갖게 됩니다.
플랫폼 기능의 중대한 격차
핵심 문제는 GitHub와 GitLab 내의 세밀한 제어 및 강제 메커니즘의 부족에 있습니다. 구체적으로, 이 플랫폼들은 현재 다음과 같은 기능을 제공하지 않습니다:
- 조직 수준의 승인된 서명 키 허용 목록(allowlists): 조직이 커밋에 서명할 수 있도록 허용된 만의 승인된 서명 키(예: 조직에서 발급한 하드웨어 기반 YubiKeys) 목록을 지정하고 강제할 수 있는 내장된 방법이 없습니다.
- 서명 키 자체에 기반한 푸시 거부: 플랫폼은 커밋이 승인된 허용 목록에 없는 키로 서명된 경우, 비록 그것이 정당한 사용자 계정과 연결되어 있더라도 푸시를 자동으로 거부하도록 설정할 수 없습니다.
- 내장된, 세밀한 키 액세스 감사(auditing): 조직은 누가 무엇에 액세스했는지 이해하기 위해 감사 로그를 직접 스트리밍하고 파싱해야 하며, 이는 승인되지 않은 키 추가나 사용을 효율적으로 탐지지 못하게 만듭니다.
이러한 누락된 기능들은 "Require signed commits"가 활성화되어 있더라도, 단 하나의 탈취된 개발자 계정을 통해 Git 히스토리의 무결성이 훼손될 수 있음을 의미합니다.
현재 우회 방법의 한계
이러한 플랫폼의 한계에 대한 직면하여, 많은 조직은 다음과 같은 우회 방법을 사용합니다:
- 지속적 통합(CI) 파이프라인에서 서명 재검증: 이는 CI에서 내부 허용 목록과 대조하여 커밋 서명을 다시 확인하는 단계를 추가하는 것을 포함합니다.
- 승인되지 않은 키에 기반한 배포 차단: CI가 승인되지 않은 키로 서명된 커밋을 감지지 못하면 배포를 중단합니다.
- Self-hosting Git을 pre-receive hooks로 관리: 커밋이 저장소에 도달하기 전에 서명 키 정책을 강제를제한하기 위해 self-hosted Git 인스턴스에 커ustom hooks를 구현합니다.
이러한 우회 방법들은 어느 정도 수준의 탐지 또는 방지를 제공하지만, 모두 하나의 중대한 결함이 있습니다: 악성 커밋이 여전히 저장소에 도달합니다. CI는 사건이 이후에 발생한 후에 이를 포착합니다. 즉, 탈취된 코드가 배포되는 것은 막을 수 있을지언정, 이미 코드베이스에 통합되어 버린 것입니다. 이러한 "사후적" 탐지는 진정한 공급망 보안을 목표로 하는 조직에게는 불가능히 충분히 않습니다. 진정한 공급^망 보안의 목표는 악성 코드가 신뢰할 수 있는 저장소 히스토리에 절대적으로 들어오지 못하게 하는 것입니다.
조직에 가해지는 부담
이러한 근본적인 보안 기능의 부재재는 조직, 특히 규모가 작은 개발 스토어들을, 소프트웨어 공급망을 보안화하기 위해 상당하고 자원 집약적인 노력을 기울이도록 강제합니다. 이에는 다음과 같습니다:
- 모든 개발자에게 하드웨어 보안 키(예: YubiKeys)를 발급하는 것: 상당한 물류 및 재정적 부담이 됩니다.
- 맞춤형 검증 및 감사 파이프라인 구축: 키 정책을 강제제한하기 위해 맞춤형 시스템을 개발하는 데 드립니다.
- 감사 로그를 Security Information and Event Management (SIEM) 시스템으로 스트리밍하는 것: 로그 분석 및 알림을 위해 추가적인 인프라와 전문 지식이 필요합니다.
- 기본적인 가시성을 위해 엔터프라이즈 티어(enterprise tiers)로 업그레이드하는 것: 종종 표준 보안 제공 사항이어야 할 기능들을 위해 더 높은 비용을을 가합니다합니다.
이러한 수준의 노력은