GitHub 패키지 방화벽, npm 설치 전에 거른다
취약점을 고친 npm 새 버전이 방금 올라왔는데, 패키지 방화벽을 켠 CI에서는 설치가 멈춘다. 급한 보안 수정은 어떤 절차로 들여보낼까?

- GitHub가 npm 패키지 요청과 다운로드를 정책으로 검사하는 방화벽을 공개했다.
- npm 설치는 스크립트 실행으로 이어질 수 있다. 패키지가 개발 환경에 들어오는 경로가 검사 대상이다.
- 기업 정책을 정한 뒤 CI·에이전트의 레지스트리 설정과 별도 다운로드 경로를 확인해야 한다.
Enterprise Cloud용 npm 프리뷰다
GitHub는 10월 20일 패키지 방화벽 공개 프리뷰를 발표했다. 데이터 레지던시를 사용하는 환경을 포함한 Enterprise Cloud 고객이 대상이다. 현재 npm 패키지만 지원하며 프리뷰 기간에는 무료다. 정식 출시 뒤에는 사용량에 따른 과금이 예정돼 있다.
방화벽은 개발 머신·에이전트·CI와 상위 패키지 저장소 사이에 놓인다. 패키지 목록을 받는 메타데이터 요청과 실제 다운로드를 모두 검사한다. 관리자는 게시 후 대기시간, 보안 경보, 공급망 관련 조건으로 허용 범위를 정한다.
의존성 설치도 코드를 실행하는 단계다
npm 11의 스크립트 문서는 npm ci와 npm install의 수명주기에 preinstall, install, postinstall 등이 포함된다고 설명한다. 패키지를 가져오는 일을 파일 복사로만 볼 수 없는 이유다.
이런 스크립트는 빌드에 쓰이기도 하며, 실행 파일이 반드시 JavaScript일 필요도 없다. 사람이 패키지를 하나씩 살펴보지 않는 자동 설치에서도 다운로드 단계에 정책 검사를 적용할 수 있다. 설치 스크립트가 있다는 사실 자체를 악성 판정으로 바꾸어서는 안 된다.
관리자 설정과 실제 레지스트리 연결이 모두 필요하다
GitHub 설정 문서는 패키지 게시 후 기본 대기시간을 1일로 정하고 있다. 정책을 정한 뒤 엔드포인트가 기업별 방화벽 URL을 사용하도록 연결해야 한다. 각 요청에는 해당 기업의 구성원인 사용자 또는 봇 계정의 인증 토큰도 필요하다. 기본 토글이 켜져 있다는 사실만으로 모든 개발 머신의 요청이 경유하는 것은 아니다.
| 확인 대상 | 확인할 내용 |
|---|---|
| 기업 정책 | 게시 후 대기시간과 차단 조건 |
| CI·개발 머신·에이전트 | 패키지 요청이 기업 방화벽 URL로 향하는지 |
| 프로젝트 설정 | scope별 저장소와 잠금 파일의 다운로드 경로 |
마지막 항목은 npm의 레지스트리 선택 방식 때문이다. scope에 연결된 저장소가 있으면 해당 설정이 적용된다. 사용자 지정 레지스트리로 만든 잠금 파일은 나중에 기본 레지스트리를 바꿔도 원래 경로를 사용할 수 있다. 실제 설치 경로를 확인하는 것이 도입 점검의 핵심이다.
차단 로그와 보안 경보를 함께 읽는다
차단된 설치의 npm 출력이나 CI 로그에는 예외 요청 URL이 표시된다. 필요한 보안 수정 버전도 게시 직후에는 대기시간에 걸릴 수 있으므로, 버전과 사유를 갖춘 예외 검토가 필요하다. 예외는 정책에 남고 이후 제거할 수 있다.
GitHub Advisory Database의 기본 조회는 검토된 취약점 경보다. 악성코드 경보는 type:malware, npm 대상은 ecosystem:npm으로 좁힐 수 있다. 경보 번호와 영향받는 패키지를 확인하면 차단 사유를 이해하는 데 도움이 된다. 검색 결과가 없다는 사실만으로 안전이 증명되지는 않는다.
자주 묻는 질문
Python 패키지도 검사하는가?
이번 프리뷰의 지원 대상은 npm이다.
기업 설정만 켜면 모든 CI에 적용되는가?
아니다. 해당 CI의 패키지 요청이 방화벽을 경유하도록 연결돼 있어야 한다.
도입의 첫 확인 대상은 실제 다운로드 경로다. 정책이 있어도 요청이 그 경로를 지나지 않으면 검사할 수 없다.