npm отримав два практичні supply-chain controls: staged publishing, де версія пакета стає доступною лише після 2FA approval, і install-source flags, які можуть блокувати нестандартні джерела залежностей на кшталт Git, remote tarballs, local files або directories. Обидва механізми доступні в npm CLI 11.15.0 або новішому [1].
Це важливо, бо атаки на пакети часто використовують не лише шкідливий код. Вони б’ють по release path, довірі до мейнтейнерів і install behavior, який команди роками залишали неявним. Gridinsoft вже розбирав цей патерн у матеріалах про Packagist postinstall malware та скомпрометовані Laravel-Lang packages.
Нові controls не роблять npm packages автоматично безпечними. Але вони створюють review point до того, як пакет стане installable, і дають захисникам чіткіший спосіб сказати, які dependency sources дозволені під час install.
Хто під впливом?
Найперше це стосується мейнтейнерів npm packages, особливо проєктів, які публікують релізи з CI/CD. Security teams, що перевіряють JavaScript builds, теж мають оновити baseline: безпечніший workflow тепер має конкретні команди, а не лише загальну пораду.
Користувачі npm packages залежать від цього непрямо. Якщо власник пакета увімкне staged publishing і обмежить install sources, скомпрометований workflow матиме менше шансів одразу проштовхнути шкідливу версію в registry або підтягнути код із неочікуваного джерела.
Controls і версії
| Control | Доступно в | Що змінює | Рішення |
|---|---|---|---|
npm stage publish | npm CLI 11.15.0+ | Завантажує package version у staging area, а не робить її одразу installable. | Використовуйте для пакетів, де потрібне людське release approval. |
npm stage approve <stage-id> | npm CLI 11.15.0+ | Публікує staged package після review і 2FA approval [2]. | Підтверджуйте з trusted maintainer device. |
| Trusted publishing with OIDC | npm CLI 11.5.1+ | Прибирає long-lived npm tokens із CI/CD через short-lived workflow identity [4]. | Надавайте перевагу цьому замість classic publish tokens. |
--allow-file, --allow-remote, --allow-directory | npm CLI 11.15.0+ | Контролює local file, remote URL і directory install sources [3]. | Ставте none, якщо такі джерела не очікуються. |
--allow-git | Наявний control | Контролює Git-based install sources. GitHub повідомляє, що default має змінитися з all на none у npm CLI v12 [1]. | Перевірте пакети, які ще залежать від Git URLs. |
Що зробити мейнтейнерам
Спочатку оновіть release runners і робочі машини мейнтейнерів до npm CLI 11.15.0 або новішого. Якщо реліз іде з CI, перевірте stage flow на low-risk package перед зміною процесу для популярного пакета.
Далі замініть direct publish у чутливих workflows на:
npm stage publishПісля цього перегляньте staged tarball перед approval. Важливо не лише те, що tests пройшли. Завантажте staged package, подивіться packed files, перевірте version і порівняйте tarball з очікуваним build output.
npm stage list
npm stage view <stage-id>
npm stage download <stage-id>
npm stage approve <stage-id>Для install controls почніть із проєктів, які мають ставити залежності лише з public npm registry або private registry. У таких проєктах неочікувані Git URLs чи remote tarballs є сильним сигналом для перевірки. Додавайте strict settings у checked-in config, коли це не ламає build, а винятки документуйте як release decisions.
npm install --allow-git=none --allow-remote=none --allow-file=none --allow-directory=noneНарешті, переносіть CI publishing на trusted publishing with OIDC. Це сильніше знижує ризик, бо викрадений long-lived token може публікувати поза потрібним workflow, тоді як OIDC прив’язує publish до конкретної CI identity.
Що це не вирішує
Staged publishing не знаходить шкідливий код сам по собі. Мейнтейнер усе ще може схвалити поганий пакет, якщо review був поспішним або якщо attacker змінив build output так, що це не помітили.
Install-source flags також не замінюють dependency review. Вони зменшують один клас неочікуваних джерел, але registry packages все ще можуть містити malicious postinstall scripts або obfuscated payloads. Тому source restrictions варто поєднувати з lockfile review, script policy і перевіркою репутації пакетів.
Пов’язана перевірка TrapDoor
Ще одна May 2026 supply-chain атака, TrapDoor у npm, PyPI і Crates.io, показує, чому staged publishing треба поєднувати з перевіркою install scripts та AI-конфігів.
FAQ
Чи замінює staged publishing двофакторну автентифікацію?
Ні. Staged publishing використовує 2FA на етапі approval. Пакет не потрапляє в registry, доки мейнтейнер не підтвердить staged version.
Чи потребує npm stage publish 2FA?
У документації npm сказано, що саме staging не потребує 2FA, але approval staged package потребує.
Чи треба всім блокувати Git і remote installs?
Не кожен проєкт може зробити це одразу. Спочатку визначте, чи Git, remote tarball, file або directory sources справді потрібні. Якщо ні, ставте відповідний --allow-* option у none.
Чому це важливо після npm malware waves?
Багато supply-chain incidents використовують довіру до publishing і dependency installation. Ці controls додають release checkpoint і допомагають блокувати неочікувані install sources.
Також по темі: кампанія Megalodon у GitHub Actions показує, чому publishing controls потрібно поєднувати з перевіркою workflow-файлів і доступу до secrets.
Джерела
- GitHub Changelog, “Staged publishing and new install-time controls for npm,” 22 травня 2026 року. Changelog
- npm Docs, “Staged publishing for npm packages,” остання редакція 20 травня 2026 року. Docs
- npm Docs, “npm install CLI reference,” перевірено 24 травня 2026 року. Reference
- npm Docs, “Trusted publishing for npm packages,” перевірено 24 травня 2026 року. Guide
