깃허브, 악성 패키지 설치 막는 '패키지 방화벽' 공개…GHEC 한정
깃허브가 CI 러너와 코딩 에이전트가 악성 코드를 내려받지 못하게 가로채는 ’패키지 방화벽’을 공개 프리뷰로 열었지만, 깃허브 엔터프라이즈 클라우드 전용이고 지금은 npm만 지원한다.
깃허브(GitHub)는 10월 20일 자 블로그에서 공급망 보안 기능인 패키지 방화벽(Package Firewall)의 공개 프리뷰를 시작했다고 밝혔다. 이 기능은 개발자 PC나 CI 러너, 코딩 에이전트가 패키지를 내려받아 설치할 때 악성 스크립트가 실행되는 공격을 차단하는 인라인 검사 레이어다. 데이터 상주 옵션을 쓰는 고객을 포함해 깃허브 엔터프라이즈 클라우드(GHEC) 고객 전체에 열렸다.
누가 쓸 수 있고 요금은 어떻게 되나
패키지 방화벽은 모든 깃허브 사용자가 쓸 수 있는 기능이 아니다. 현재는 대기업 및 조직용 플랜인 깃허브 엔터프라이즈 클라우드에서만 켤 수 있으며, 개인 계정(Free·Pro)이나 Team 요금제는 지원 대상에서 빠졌다.
| 구분 | GitHub Free / Team | GitHub Enterprise Cloud (GHEC) |
|---|---|---|
| 패키지 방화벽 지원 | 미지원 | 지원 (데이터 상주 포함) |
| 프리뷰 요금 | 해당 없음 | 무료 |
| 정식 출시(GA) 요금 | 해당 없음 | 사용량 기반 종량제 (예정) |
| 지원 패키지 생태계 | 해당 없음 | npm (단일 지원) |
지금 열린 퍼블릭 프리뷰 기간에는 추가 비용 없이 무료로 쓸 수 있다. 깃허브는 인프라를 확장하고 기능을 다듬은 뒤 정식 출시 시점에 액션(Actions)처럼 사용량에 따라 요금을 매기는 종량제로 전환할 계획이라고 설명했다. 다만 정식 출시 시점과 구체적인 과금 단가는 아직 공개하지 않았다.
무엇을 검사하고 어디에 못 쓰나
지금까지의 패키지 보안은 저장소에 올라간 코드를 사후에 스캔하거나 의존성 업데이트 알림을 보내는 방식이 많았다. 하지만 최근 공격자들은 패키지가 설치되는 순간(preinstall 스크립트 등)에 실행 환경의 토큰과 비밀 키를 탈취하는 수법을 자주 쓴다. 특히 코딩 에이전트와 CI 러너는 사람의 확인 없이 스스로 의존성을 내려받아 작업을 끝내려 하므로 이러한 설치 시점 공격에 취약하다.
패키지 방화벽은 엔드포인트와 공개 저장소(registry.npmjs.org) 사이에 자리 잡아 패키지 목록 메타데이터와 실제 내려받는 압축 파일을 모두 실시간으로 검사한다. 관리자가 조직 정책으로 설정할 수 있는 핵심 규칙은 네 가지다.
- 알려진 악성코드 차단: 깃허브 자문 데이터베이스(GitHub Advisory Database)에 등록된 악성 패키지를 즉시 막는다.
- 취약점 경보 차단: 보안 취약점 경보를 바탕으로 위험도 기준을 정해 위험 패키지의 다운로드를 제한한다.
- 어테스테이션 다운그레이드 차단: 이전 버전에는 빌드 출처를 증명하는 서명인 어테스테이션(Attestation)이 있었는데, 새로 요청한 버전에서 갑자기 서명이 빠진 경우 변조 가능성을 의심해 차단한다.
- 신규 버전 쿨다운: 새로 배포된 패키지 버전을 일정 시간 동안 설치하지 못하게 묶어 두어, 오픈소스 커뮤니티가 악성 여부를 검증하고 신고할 시간을 번다.
가장 큰 한계는 지원 범위다. 이번 공개 프리뷰에서는 오직 npm 패키지만 지원한다. 파이썬의 PyPI, 자바의 Maven, 러스트의 Cargo 같은 다른 언어 생태계는 방화벽을 거쳐 보호받을 수 없다.
도입 방법과 예외 처리의 함정
패키지 방화벽을 쓰려면 엔터프라이즈 관리자가 정책 화면에서 기능을 켠 뒤, 개발 장비나 CI 러너의 패키지 매니저 설정(.npmrc)에서 레지스트리 주소를 방화벽 경로로 돌려야 한다.
정상적인 사내 패키지나 급히 배포된 패키지가 쿨다운 또는 정책에 걸려 잘못 차단된 경우, 터미널 출력이나 CI 로그에 예외 신청 전용 링크가 뜬다. 개발자가 이 주소를 열어 관리자에게 사유를 적어 제출하면, 기존 고급 보안 도구인 GHAS(GitHub Advanced Security)와 유사한 관리자 승인 절차를 거쳐 설치를 허용할 수 있다.
다만 자율 코딩 에이전트가 백그라운드에서 수십 개의 작업을 동시에 돌리는 파이프라인에서는 오탐이 발생했을 때 사람이 직접 링크를 열고 승인하기 전까지 작업 전체가 멈출 수 있다. 쿨다운 시간을 너무 길게 잡으면 신규 라이브러리 판올림 작업이 지연될 수 있으므로, 초기 도입 시에는 쿨다운 기간을 짧게 설정하고 예외 승인 권한자를 미리 지정해 두는 편이 안전하다.
앞으로 볼 것
깃허브는 피드백을 받아 인프라를 확장하면서 지원 기능을 넓혀 가겠다고 밝혔다. Python이나 Java 등 다른 패키지 저장소로 검사 대상이 언제 넓어질지, 그리고 정식 출시 때 도입될 종량제 요금이 대규모 CI 환경의 운영 비용에 얼마나 부담이 될지가 관건이다.
출처
- GitHub package firewall in public preview (The GitHub Blog)
- Protecting endpoints with package firewall (GitHub Docs)
출처: github.blog