Зависимости и риск цепочки поставок

Установить — значит запустить код

Главный факт, переформулирующий безопасность зависимостей: npm install выполняет произвольный код. Задумайся об этом в следующий раз, когда потянешься за новой удобной библиотекой — каждая транзитивная зависимость, которую она тянет за собой, имеет те же привилегии. Пакет может объявить lifecycle-скрипты (хуки установки) — preinstall, install, postinstall — и npm запускает их на твоей машине, с правами твоего пользователя, в тот момент, когда пакет приземляется. Нет ни ревью-гейта, ни песочницы, ни диффа, который ты прочитаешь заранее. У postinstall полный доступ к файловой системе, сети и process.env, а в CI именно там живут твои registry-токены, облачные ключи и деплой-креды. Это не теоретический пограничный случай: это самый прямой вектор цепочки поставок, потому что он срабатывает до кода твоего приложения — и любых тестов или сканеров, которые могли бы поймать вредоносное поведение.

Защитная позиция — перестать считать установку инертной. Для недоверенных установок и особенно в CI запускай со скриптами, выключенными по умолчанию:

# Установить строго из lockfile И пропустить все lifecycle-скрипты
npm ci --ignore-scripts

# Или сделать это дефолтом на всю машину для недоверенного окружения
npm config set ignore-scripts true

--ignore-scripts пропускает lifecycle-хуки каждого пакета. Компромисс реален: некоторым легитимным пакетам (нативные аддоны, компилирующие биндинги, например сборки node-gyp) скрипт действительно нужен для работы, и тихая их блокировка даёт сломанную установку, а не вредоносную. Поэтому ты проверяешь небольшой набор тех, кому скрипты нужны, и разрешаешь их намеренно, вместо того чтобы выдавать тотальное право на выполнение всему транзитивному дереву. А более глубокий рычаг — количество: бóльшая часть кода, который едет в Node-сервисе, — сторонняя, часто сотни транзитивных пакетов от авторов, которых ты никогда не проаудируешь. Каждая удалённая зависимость — это удалённая поверхность атаки.

Lockfile — твоя граница целостности

package.json записывает версии, которые ты хочешь (часто диапазоны вроде ^4.2.0). package-lock.json записывает точные версии, которые ты реально получил, — и, что критично, SRI-хеш целостности (SRI — Subresource Integrity, проверка подлинности по хешу содержимого; sha512) для тарбола каждого пакета. Этот хеш — свидетельство неподделанности: если байты, скачанные из реестра, не хешируются в записанное значение, установка падает. Вот почему lockfile — это не досада, которую надо в .gitignore: это и есть твоя граница воспроизводимости и целостности, и она должна быть закоммичена.

Команда, которая это обеспечивает, — npm ci, а не npm install:

# CI: детерминированно, с проверкой целостности, только из lockfile
npm ci

npm ci устанавливает строго из package-lock.json, громко падает, если package.json и lockfile рассинхронизированы (вместо того чтобы тихо «починить» lock, как делает npm install), сначала удаляет node_modules ради чистого дерева и проверяет каждый хеш целостности. npm install, напротив, может разрезолвить новые версии, мутировать lockfile и подтянуть свежеопубликованный вредоносный патч внутри твоего диапазона ^. Правило механическое: npm ci в CI и воспроизводимых сборках, npm install только локально, когда ты намеренно меняешь зависимости — и ревью получившегося диффа lockfile как кода.

Сканирование известных уязвимостей

Закоммиченный lockfile делает сборки воспроизводимыми, но он же замораживает известные уязвимости на месте — пиннинг безопасен, только если ты продолжаешь следить за тем, что запинил. npm audit сверяет твоё установленное дерево с базой advisory реестра и сообщает о CVE с серьёзностью и путём фикса:

# Сообщать об уязвимостях; ронять CI только на high/critical, чтобы срезать шум
npm audit --audit-level=high

# Применить безопасные (semver-совместимые) фиксы; --force может взять breaking-мажоры
npm audit fix

Механизм — это дифф дерево-vs-advisory, так что его слабость та же, что у любого сигнатурного сканера: он видит только опубликованные, известные проблемы, несёт ложные срабатывания и шум («critical» в dev-only транзитивной зависимости, которую ты никогда не вызываешь), а npm audit fix --force может тихо поднять зависимость через мажорную версию и сломать тебя. Поэтому гейти CI на --audit-level=high, чтобы снизить усталость от алертов, автоматизируй churn апгрейдов через Dependabot или Renovate (которые открывают ревьюабельные PR) и положи сверху поведенческий инструмент — Snyk или Socket — который инспектирует install-скрипты и поведение пакета, а не только номера версий, чтобы поймать совсем свежий вредоносный релиз, у которого ещё нет CVE. Аудит — это пол, а не потолок.

Prototype pollution и недоверенный ввод

Не каждый сбой цепочки поставок — это украденный секрет; некоторые — это порча логики. Prototype pollution (отравление прототипа — ключ __proto__ в данных мутирует общий Object.prototype для всего процесса) случается, когда контролируемый атакующим ввод, содержащий ключи __proto__ или constructor.prototype, мержится в объект уязвимым кодом — наивным рекурсивным deep-merge, вольным циклом Object.assign или парсером query-строки. Поскольку почти каждый объект наследуется от Object.prototype, запись через __proto__ мутирует этот общий прототип, и загрязнение протекает в каждый объект процесса: подложенный isAdmin: true может перевернуть проверку авторизации, читающую user.isAdmin, а в худших случаях загрязнённое свойство кормит путь кода, доходящий до child_process или шаблонизатора, и становится RCE.

// УЯЗВИМО: наивный deep-merge ведёт __proto__ прямо в Object.prototype
function badMerge(target, src) {
  for (const k in src) {
    if (typeof src[k] === "object") badMerge(target[k] ??= {}, src[k]);
    else target[k] = src[k];        // k === "__proto__" загрязняет всё
  }
}

// ЗАЩИТА: отклоняй опасные ключи и используй map с null-прототипом
function safeMerge(target, src) {
  for (const k of Object.keys(src)) {
    if (k === "__proto__" || k === "constructor" || k === "prototype") continue;
    target[k] = src[k];
  }
  return target;
}
const lookup = Object.create(null); // нет прототипа, который можно загрязнить

Защиты складываются: валидируй и allowlist-и ключи ввода (валидатор схемы отклоняет __proto__ сразу), используй Object.create(null) для объектов-словарей, чтобы не было прототипа для порчи, держи merge/clone-библиотеки пропатченными и на уровне процесса рассмотри Object.freeze(Object.prototype) или запуск с флагом --disable-proto=delete, чтобы убрать аксессор __proto__ целиком.

Нельзя засендбоксить недоверенный код через vm

Когда нужно запустить код, которому не доверяешь — присланную пользователем формулу, плагин, — соблазнительный неверный ответ — встроенный модуль vm в Node. vm — это не песочница безопасности. Так говорит его собственная документация. Он запускает код в отдельном контексте V8, но этот контекст делит прототипы и ссылки с хостом: недоверенный код может вскарабкаться от конструктора переданного объекта вверх к Function realm-а хоста и реконструировать полный доступ, целиком сбежав из «песочницы».

const vm = require("node:vm");
// Побег: достать конструктор Function хоста через цепочку переданного объекта.
const escape = "this.constructor.constructor('return process')().env";
// vm.runInNewContext(escape, { /* "sandboxed" */ }) // → утечёт process.env

Реальная изоляция требует реальной границы. Запускай недоверенный код в отдельном процессе или worker-потоке со сброшенными привилегиями, внутри контейнера или microVM с ограниченными syscall-ами и без сети, или в специально построенном изоляте вроде isolated-vm (настоящий отдельный V8-изолят) или закалённого SES/vm2-наследника. Важен тот механизм, что недоверенный код не должен делить ни граф объектов, ни процесс с твоими секретами — другой контекст V8 на той же куче этой границей не является.