요약 / 핵심 포인트
- 수년 동안, 단 한 번의 `npm install` 명령으로도 사용자의 머신에 공급망 공격이 발생할 수 있었습니다.
- NPM 12는 기본적으로 자동 스크립트 실행을 중단함으로써 마침내 그 문을 닫습니다.
코드 실행 무법천지 시대의 종말
`npm 12`는 마침내 패키지 설치의 무법천지 시대에 종지부를 찍으며, `npm install`이 조용한 코드 실행 무법천지로 변질되었던 위험한 시대를 끝냅니다. 수년 동안, `pre-install` 및 `post-install` 스크립트는 `install` 스크립트와 함께 모든 의존성에 대해 자동으로 실행되어, 일상적인 작업을 은밀한 공급망 공격의 주요 벡터로 변모시켰습니다. 이러한 기본 동작은 간단한 패키지 가져오기를 위험천만한 도박으로 만들었습니다.
전체 JavaScript 생태계는 암묵적 신뢰 모델을 기반으로 했으며, 명시적인 사용자 동의 없이도 모든 패키지가 설치 중에 임의의 코드를 실행할 수 있도록 허용했습니다. 공격자들은 이 맹점을 교묘하게 악용했습니다. 예를 들어, 자가 전파하는 Shai-Hulud 웜은 수백 개의 패키지를 침해하여 자격 증명을 유출하고 자율적으로 확산되었으며, 2026년 5월의 "Mini Shai-Hulud" 변종은 GitHub Actions를 악용하여 `TanStack`과 같은 유명 프로젝트를 표적으로 삼았습니다.
커뮤니티는 시급한 보안 요구와 방대한 스크립트 의존적 생태계에서 하위 호환성을 유지해야 하는 엄청난 과제 사이에서 이 치명적인 취약점에 대해 수년 동안 논쟁했습니다. 이제 `npm 12`가 이 고르디우스의 매듭을 끊습니다. `npm 12`는 기본적으로 자동 스크립트 실행을 비활성화하고, `npm approve-scripts`를 통한 명시적인 승인 흐름을 강제합니다. 암묵적 신뢰에서 명시적 허용 목록으로의 이 오래 기다려온 전환은 마침내 보안을 우선시하며, 약간 덜 편리하더라도 더 안전한 미래를 열어줍니다.
당신의 새로운 문지기: `npm approve-scripts`
버전 12의 `npm install`은 더 이상 의존성에서 임의의 코드를 맹목적으로 실행하지 않습니다. `pre-install`, `install`, `post-install` 스크립트가 기본적으로 실행되던 시대는 확실히 끝났으며, Shai-Hulud 및 최근의 TanStack 침해와 같은 공급망 공격의 주요 벡터를 종식시킵니다. 이 전면적인 차단은 필수적인 네이티브 `node-gyp` 빌드와 Git, 파일 또는 링크 의존성에서 가져온 `prepare` 스크립트에까지 확장되어, 예상치 못한 코드 실행을 시작하기 전에 효과적으로 무력화합니다.
당신의 새로운 문지기인 `npm approve-scripts`를 소개합니다. 이 명령은 명시적이고 감사 가능한 워크플로우를 도입하여, 개발자들이 모든 스크립트를 검토하고 진정으로 신뢰하는 스크립트만 선택적으로 활성화할 수 있도록 합니다. 일단 승인되면, `npm`은 이러한 허용 사항을 `package.json` 파일 내에 직접 저장하여, 설치 중에 실행되는 허용된 코드에 대한 투명하고 버전 관리되는 기록을 생성합니다. 이는 이전의 위험한 자동화를 신중하고 정보에 입각한 동의로 대체합니다.
이것은 단순히 새로운 명령이 아닙니다. 이는 전체 JavaScript 생태계를 위한 심오한 철학적 변화입니다. `npm`은 어떤 의존성이라도 무엇이든 실행할 수 있었던 암묵적 신뢰 모델에서 명시적 허용 목록 모델로 단호하게 전환합니다. 개발자들은 자신의 머신에서 정확히 어떤 코드가 실행되는지에 대한 절대적이고 세분화된 제어권을 되찾으며, `npm install`을 잠재적인 위험에서 신중하고 안전한 작업으로 변화시킵니다. 스크립트포칼립스(Scriptpocalypse)는 흐느낌이 아니라 확고하고 감사 가능한 "아니오"로 끝납니다.
더 많은 공격 벡터 차단
While `pre-install` and `post-install` scripts were the flashiest vectors for supply chain attacks, shrewd adversaries never put all their eggs in one basket. They also leveraged less obvious pathways, like direct Git dependencies and remote URL tarballs, to sneak malicious code into unsuspecting projects. Attackers famously exploited these methods in incidents such as the Mini Shai-Hulud variant that targeted packages under the TanStack namespace, often injecting malicious `.npmrc` files via these indirect routes.
npm 12 slams these secondary doors shut with a simple, explicit mandate. Developers must now use `--allow-git` to resolve Git-based dependencies and `--allow-remote` when installing packages from URL-based tarballs. This isn't just an inconvenience; it's a critical friction point designed to force conscious decisions, eliminating implicit trust for external sources and significantly narrowing the attack surface.
No one can claim ignorance when npm 12 rolls out in July; warnings for these breaking changes have been active since npm v11.16.0+. This grace period offers ample opportunity for teams to audit their build pipelines and update dependency declarations, avoiding sudden disruptions. For more detail on the upcoming shifts, consult the Upcoming breaking changes for npm v12 - GitHub Changelog.
A Necessary Step, But Is It Enough?
Finally, npm acknowledges reality. The script execution free-for-all, a primary vector for supply chain attacks, is ending with npm 12 after years of widespread exploitation. This long-overdue shift to explicit script approval, finally catching up to more security-conscious alternatives, transforms `npm install` from a naive trust exercise into a guarded operation. It's a necessary evolution, albeit one that arrives in July 2026, years after the first alarms sounded.
Even with these welcome changes, the battle for supply chain integrity continues. Many security experts, myself included, simply advocate for pnpm, which boasts superior defaults like blocking exotic sub-dependencies and delaying new package adoption. pnpm’s proactive stance, which has long championed a more restrictive, secure posture out of the box, offers a compelling alternative for projects demanding immediate, robust protection.
These updates significantly narrow the attack surface, curtailing the `pre-install` and `post-install` script vectors that fueled incidents like Shai-Hulud and the TanStack compromise. The explicit block on Git dependencies and remote tarballs further closes well-worn attack paths. However, attackers are relentlessly adaptive. Expect a pivot to other vulnerabilities, perhaps exploiting malicious `.npmrc` files, CI/CD misconfigurations, or sophisticated social engineering. Developer vigilance, scrutinizing every dependency and build process, remains the ultimate, indispensable firewall in this evolving threat landscape.
Frequently Asked Questions
What is the biggest change in NPM 12?
The most significant change is that `npm install` will no longer automatically run pre-install, install, or post-install scripts for dependencies. Users must now explicitly approve them.
How do I run scripts for trusted dependencies in NPM 12?
You need to use the new `npm approve-scripts` command. This will prompt you to approve scripts from your dependencies, and your selections will be saved to your package.json.
Why is NPM making these security changes now?
이러한 변경 사항은 자격 증명을 훔치고 멀웨어를 확산시키기 위해 자동 스크립트 실행을 악용한 Shai-Hulud 웜과 같은 정교한 공급망 공격의 물결에 대한 직접적인 대응입니다.
PNPM 또는 Yarn과 같은 다른 패키지 관리자들은 이미 이렇게 안전한가요?
네, PNPM과 Yarn과 같은 다른 패키지 관리자들은 자동 설치 스크립트 차단과 같은 유사한 기본 보안 동작을 이미 한동안 구현했습니다.