npm 취약점 차단: GitHub, 설치 스크립트 기본 비활성화

“

GitHub가 npm 12 버전부터 설치 스크립트를 기본적으로 비활성화하여 소프트웨어 공급망 공격을 차단합니다. 이는 개발자의 보안 의식을 높이고, 프로젝트의 안전성을 강화하는 중요한 변화입니다. 업계 전반에 걸쳐 보안 강화 트렌드를 가속화할 전망입니다.

”

전문가 통찰 및 한줄평 (Insight):

소프트웨어 공급망 공격의 주요 경로였던 npm 설치 스크립트의 기본 비활성화는 개발자 보안을 한 단계 끌어올리는 중요한 변화입니다.

이는 국내 개발 생태계에도 보안 강화의 필요성을 재확인시키는 신호탄이 될 것입니다.

npm, 설치 스크립트 기본 차단으로 보안 강화 나선다

소프트웨어 개발 생태계의 핵심 플랫폼인 GitHub가 npm(Node Package Manager)의 최신 버전인 12에서 ‘설치 스크립트(install scripts)’를 기본적으로 비활성화하는 ‘중대한 변경(breaking changes)’을 예고했습니다.

이는 점증하는 소프트웨어 공급망 공격(supply chain attacks)에 대응하기 위한 전략적인 결정으로 분석됩니다.

이번 업데이트는 오는 7월 배포 예정이며, 개발자들의 프로젝트 의존성 관리 방식에 상당한 변화를 가져올 것으로 예상됩니다.

왜 npm 설치 스크립트가 문제인가?

npm install 명령어는 Node.js 프로젝트에 필요한 모든 의존성을 다운로드하고 설치하는 데 사용됩니다.

이 과정에서 preinstall, install, postinstall과 같은 ‘라이프사이클 훅(lifecycle hooks)’을 통해 스크립트가 자동으로 실행될 수 있습니다.

GitHub는 이러한 설치 시점의 라이프사이클 스크립트를 ‘npm 생태계에서 가장 큰 코드 실행 표면(single largest code-execution surface)’이라고 지적하며, 이것이 악성 코드 실행의 주요 통로가 될 수 있다고 설명합니다.

즉, 전체 의존성 트리(dependency tree)의 어디 한 곳에라도 악의적인 패키지가 포함되어 있다면, 해당 패키지의 스크립트가 개발자의 로컬 머신이나 CI/CD 환경에서 임의의 코드를 실행할 위험이 있습니다.

이번 GitHub의 결정은 이러한 공격 벡터를 차단하고, 신뢰하는 패키지에 대해서만 명시적인 사용자 승인을 거쳐 스크립트가 실행되도록 함으로써 기본적으로 안전한 환경을 구축하려는 의도입니다.

GitHub는 “스크립트 실행을 선택 사항(opt-in)으로 만드는 것은 해당 공격 경로를 차단하면서도, 신뢰하는 패키지에 대해서는 단 한 번의 명령어로 스크립트 실행을 유지할 수 있도록 합니다”라고 밝혔습니다.

주요 변경 사항 분석

npm 버전 12에서 적용될 주요 변경 사항은 다음과 같습니다.

preinstall, install, postinstall 스크립트의 기본 비활성화: 프로젝트의 package.json에 명시적으로 허용되지 않는 한, 의존성 패키지의 해당 스크립트들은 더 이상 자동으로 실행되지 않습니다.
Git 의존성 해결 제한: --allow-git 옵션을 명시적으로 사용하지 않으면, 직접 또는 간접적인 Git 의존성(Git dependencies)은 더 이상 자동으로 해결되지 않습니다.
원격 URL 의존성 해결 제한: --allow-remote 옵션을 명시적으로 사용하지 않으면, HTTPS tarballs와 같은 원격 URL로부터의 의존성 해결이 차단됩니다.

특히, --allow-scripts 동작 변경에 대해 Microsoft 소유의 GitHub는 “여기에는 네이티브 node-gyp 빌드도 포함됩니다.

즉, binding.gyp 파일은 있지만 명시적인 설치 스크립트가 없는 패키지 역시 차단되며, 이는 npm이 암묵적으로 node-gyp rebuild를 실행하기 때문입니다.

Git, 파일, 링크 의존성의 prepare 스크립트 또한 동일한 방식으로 차단됩니다.”라고 설명했습니다.

이는 --ignore-scripts 플래그를 사용하더라도 .npmrc 설정 파일이 Git 실행 파일을 재정의할 수 있었던 코드 실행 경로를 --allow-git를 기본값 ‘none’으로 설정함으로써 효과적으로 차단합니다.

기존 기술과의 비교

이번 npm의 변경은 소프트웨어 공급망 보안을 강화하려는 여러 노력의 일환입니다.

과거에도 유사한 맥락의 보안 강화 조치들이 있었습니다.

항목	npm v12 (예정)	이전 npm 버전	Go Modules (GoLang)	Pip (Python)
설치 스크립트 실행	기본 비활성화, 명시적 승인 필요 (–allow-scripts)	기본 활성화	빌드 스크립트(Go generate)는 별도 실행	설치 스크립트(setup.py)는 기본 실행
Git 의존성	기본 차단, `--allow-git` 필요	기본 활성화	지원하지 않음	지원하지 않음 (Git URL 직접 설치 가능)
원격 URL 의존성	기본 차단, `--allow-remote` 필요	기본 활성화	지원하지 않음	지원하지 않음
보안 초점	공급망 공격 방어, 명시적 제어 강화	개발 편의성 중심, 상대적으로 보안 취약 노출	모듈 무결성, 버전 관리 중심	패키지 무결성, 옵션으로 보안 검증 가능

이 표에서 볼 수 있듯이, npm은 이번 업데이트를 통해 다른 언어의 패키지 관리 시스템에서 기본적으로 제공하는 수준의 보안 제어 기능을 강화하고 있습니다.

특히 Python의 Pip는 여전히 설치 시 임의 코드를 실행할 수 있는 여지가 남아있어, npm의 이번 조치가 개발자들에게 더 안전한 환경을 제공할 가능성을 시사합니다.

시장 파급 효과 및 전망

npm의 이번 결정은 전 세계 수백만 명의 Node.js 개발자에게 직접적인 영향을 미칠 것입니다.

특히 CI/CD 파이프라인에서 자동화된 빌드를 수행하는 경우, 기존 스크립트가 더 이상 작동하지 않아 빌드 실패를 경험할 수 있습니다.

개발자들은 프로젝트의 package.json 및 .npmrc 설정을 검토하고, 신뢰하는 패키지의 스크립트 실행을 명시적으로 승인하는 과정을 거쳐야 합니다.

이 과정은 초기에는 다소 번거로울 수 있으나, 장기적으로는 소프트웨어 공급망의 보안 수준을 한층 높이는 데 기여할 것입니다.

GitHub는 이와 관련하여 npm 11.16.0 이상 버전으로 업그레이드하고, 경고 메시지를 검토하며, npm approve-scripts --allow-scripts-pending 명령어를 사용하여 승인되지 않은 스크립트를 검토하고 승인할 것을 권고하고 있습니다.

한국 시장에서의 시사점

이번 npm의 보안 강화 움직임은 한국의 IT 생태계에도 중요한 시사점을 던집니다.

국내 IT 기업들은 이미 다양한 오픈소스 라이브러리를 적극적으로 활용하고 있으며, 이 과정에서 npm 패키지 또한 광범위하게 사용됩니다.

따라서 GitHub의 이번 npm 버전 12 업데이트는 국내 개발팀들에게도 코드 보안 강화에 대한 새로운 기준을 제시할 것입니다.

보안 인식 제고 및 실무 적용: 국내 스타트업부터 대기업까지, Node.js를 사용하는 모든 개발 조직은 이번 변경 사항을 숙지하고, 프로젝트의 의존성 관리 방식을 점검해야 합니다. 기존의 관행대로라면 예상치 못한 빌드 오류나 보안 취약점에 노출될 수 있습니다. 당장 npm 11.16.0 이상 버전으로 점진적 업그레이드를 진행하며, npm audit 명령어를 주기적으로 실행하여 잠재적인 보안 이슈를 파악하는 것이 중요합니다.
내부 라이브러리 및 도구 재검토: 기업 내부에서 자체적으로 개발하여 사용하는 npm 패키지가 있다면, 해당 패키지에 포함된 스크립트의 보안성 또한 철저히 검토해야 합니다. --allow-scripts와 같은 설정을 통해 신뢰할 수 있는 내부 라이브러리의 스크립트만 허용하도록 정책을 수립하는 것이 바람직합니다.
새로운 보안 솔루션 기회: 이번 npm의 변화는 보안 공급망 관리를 전문으로 하는 솔루션 기업들에게 새로운 기회가 될 수 있습니다. 국내에서도 이러한 공급망 보안 강화 트렌드에 발맞춘 기술 개발 및 서비스 제공이 더욱 활발해질 것으로 전망됩니다.

결론적으로, npm의 기본 설치 스크립트 비활성화는 개발 편의성보다는 보안을 우선시하는 IT 업계의 흐름을 반영하는 중요한 변화입니다.

한국의 개발자 및 기업들도 이러한 변화에 적극적으로 대응하여 더욱 안전하고 견고한 소프트웨어 개발 환경을 구축해야 할 것입니다.