
GitHub가 엔터프라이즈 클라우드 고객을 대상으로 npm 패키지 설치 요청과 다운로드를 검사하는 패키지 방화벽의 공개 미리보기를 시작했다. 개발자 PC와 AI 코딩 에이전트, CI 환경에서 쓰는 패키지를 기업의 보안 정책에 따라 걸러내는 기능이다.
GitHub는 20일 공식 변경 로그에서 패키지 방화벽을 GitHub Enterprise Cloud 고객에게 제공한다고 밝혔다. 데이터 저장 지역을 지정하는 Enterprise Cloud도 대상이다. 현재 지원하는 패키지 생태계는 npm으로 한정되며, 미리보기 기간에는 무료다. 정식 출시 뒤에는 사용량에 따라 요금을 부과할 예정이다.
방화벽은 개발 환경과 공개 패키지 저장소 사이에 놓인다. 패키지 목록을 조회하는 메타데이터 요청과 실제 다운로드를 기업이 정한 정책에 대조해, 조건을 충족하지 못하는 버전을 차단한다. 기업 관리자가 정책을 설정한 뒤 각 개발 장비와 CI 실행기, 코딩 에이전트의 패키지 요청 경로도 방화벽을 거치도록 바꿔야 한다. 기능이 공개됐다는 이유만으로 기존 환경에 자동 적용되지는 않는다.
공식 문서에는 GitHub Advisory Database에 등록된 악성코드와 취약점 확인, 새 버전의 최소 대기 기간, 소프트웨어 공급망 증명 변경 등을 검사하는 정책이 제시됐다. 알려진 악성코드 차단은 기본으로 켜져 있고, 취약점 차단의 기본 기준은 치명적 등급이다. 조직은 취약점 차단 기준을 높음 이상이나 중간 이상, 또는 모든 등급으로 조정할 수 있다.
새로 공개된 버전의 설치를 늦추는 대기 기간은 기본 1일이다. 1일부터 365일 사이로 정하거나 0으로 설정해 끌 수 있다. 앞선 버전에 있던 SLSA 공급망 증명이 새 버전에서 사라지면 다운로드를 차단하는 정책도 기본 활성화된다. 설치 때 임의 명령을 실행할 수 있는 preinstall·postinstall 같은 스크립트가 새로 추가됐는지 검사하는 기능도 포함됐다.
운영 과정에서 정상 패키지가 막히는 경우에는 예외를 요청할 수 있다. 차단된 npm 출력이나 CI 로그에 표시되는 링크로 사유를 제출하면 기업 관리자나 보안 관리자가 검토한다. 보안 수정이 담긴 최신 버전도 최소 대기 기간에 걸릴 수 있는 만큼, 공식 문서는 이런 상황을 예외 처리 사례로 설명했다.
도입하려면 npm 설정에서 기본 레지스트리 대신 기업별 방화벽 주소를 지정하고 기업 소속 사용자 또는 봇의 인증 토큰을 함께 사용해야 한다. 기존 패키지 관리 인프라를 유지할 수 있도록 JFrog Artifactory 연동 방법도 안내했지만, 이 연동은 실험적 지원 단계다.
이번 기능은 패키지가 개발 장비나 자동화 환경에 들어오는 지점에 검사 단계를 추가한다. 다만 정책과 보안 권고 데이터에 따른 차단 기능인 만큼 모든 악성 패키지를 탐지한다는 의미는 아니다. 기업은 npm에 한정된 현재 지원 범위와 요청 경로 설정, 예외 승인 절차를 함께 검토해야 한다.
출처: GitHub 공식 변경 로그 https://github.blog/changelog/2026-10-20-github-package-firewall-in-public-preview/ · GitHub 공식 문서 https://docs.github.com/en/enterprise-cloud@latest/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/protecting-endpoints-with-package-firewall