npm v12, 보안 기본값 변경으로 개발자 준비 필요

커뮤니티에서는 npm v12의 allowScripts 기본값 비활성화가 공급망 공격(Supply Chain Attack) 방지에 긍정적이라는 평가와 함께, 실제 적용 시 개발자 경험 저하에 대한 우려가 공존함. 특히, `npm approve-scripts`를 통한 패키지별 허용 목록(Allowlist) 관리 방식이 기존의 복잡성을 어떻게 해소할지가 관건이라는 논의가 있음. 일부에서는 샌드박스(Sandbox) 환경이나 시뮬레이션 실행을 통한 사전 검증 방안을 대안으로 제시하기도 함.

이번 변경으로 allow-git 및 allow-remote 기본값 비활성화는 Git 저장소나 원격 URL에서 직접 의존성을 가져오는 경우, 명시적인 허용 없이는 설치되지 않도록 함. 이는 코드 실행 경로(Code Execution Path)를 차단하여 보안성을 높이려는 조치로 분석됨. 다만, OSS 개발자가 사전 컴파일된 바이너리를 배포하는 경우, 전역 설치(Global Install) 시에도 동일하게 적용되는지에 대한 질문이 제기됨.

오래된 보안 취약점(10년 전 보고)이 이번 릴리스에서 해결된다는 점에 주목하는 의견이 많음. 일부 사용자는 GitHub 인수 이후 보안 강화 조치가 가속화된 것으로 보인다는 분석을 내놓음. 또한, 1일의 게시물 연령 제한(1-day Age Limit)과 같은 추가적인 보안 조치 도입에 대한 제안도 있었으나, 이는 공급망 공격(Supply Chain Attack)의 복잡성을 고려할 때 근본적인 해결책이 되기 어렵다는 반론도 존재함.

댓글에서는 `package.json`에 기록되는 허용 목록(Allowlist)이 패키지 이름만 지정하는지, 특정 버전까지 포함하는지에 대한 질문이 있었음. 또한, 이러한 설정을 관리하기 위한 린터(Linter) 도구의 필요성이 제기됨. 일부 사용자는 이 변경이 책임 전가(Shifting Blame)에 불과하며, 데이터 격리 아키텍처(Data Isolation Architecture) 또는 chroot와 같은 더 강력한 보안 메커니즘 도입이 필요하다고 주장함.

이번 npm v12의 변경 사항, 특히 스크립트 실행 제어는 pnpm의 접근 방식을 따른다는 의견이 다수임. 사용자는 `--allow-scripts-pending`과 같은 명령어를 통해 어떤 패키지가 스크립트를 실행하는지 확인하고, `npm approve-scripts` 및 `npm deny-scripts`를 사용하여 신뢰하는 패키지만 허용하도록 설정해야 함. 이 과정이 기존의 npm install 동작과 크게 다르지 않다는 의견도 있으나, 명시적 허용(Explicit Opt-in)이 보안 강화의 핵심이라는 점은 분명함.