Supply chain атаки нельзя оставить одной волшебной опцией. Вместо этого нужен системный подход.
Для каждого слоя разработки (не только npm, но и CI, docker, редактор) задайте себе 4 вопроса:
1. Как уменьшить зависимости
2. Изоляция
3. Контроль обновлений
4. Ревью
Тред ↓
Сейчас так много supply chain атак не из-за npm, а потому что мы начали неосознанно доверять всему («как я могу не доверять проекту, который все используют»).
Дальше будут не советы, а примеры, чтобы вы сами начали сомневаться и доверять меньше (и искать новые защитные слои).
Начнём с npm. Берём 4 шага и применяем первый — минимизация зависимостей.
Самое опасное вложенные зависимости.
Смотрите их количество на http://npmx.dev или на http://npmgraph.js.org
Не берите популярное или первое, что советует LLM — осознанно берите минималистичные
На http://npmx.dev есть предупреждения от e18e на что лучше заменить больше вещи
https://e18e.dev/docs/replaceme
nts/
Маленькие вещи, которые не нужно обновлять (типа всяких утилит на пару строк), не берите с npm — скопируйте из в свой проект (или напишите под себя с помощью LLM).
Идём дальше. Применяем к npm второй вопрос изоляции:
Используйте Dev Container, чтобы весь проект работа в контейнере и malware в зависимости не мог украсть npm-токен или ваши куки для GitHub или Slack.
Контроль обновления в npm:
Перейдите на pnpm 11 — у них лучшая защита из коробки.
База сейчас:
1. Lock-файл
2. Аналог minimumReleaseAge
3. Запрет вложенных git-зависимостей
Ревью в npm:
Во время выбора зависимости (вообще начните долго и осознанно выбирать зависимости) просмотрите исходники.
С помощью Multiocular можно потом смотреть, что изменилось в каждый версии (и diff и ChangeLog)
Но npm — лишь малая часть. Расширения редактора — такой же слой рисков и все 4 вопроса, надо применить к нему.
Минимизация:
Пройдетесь по списку расширений и выкиньте расширения, которые вы поставили из-за вирусного твита и больше не используете.
Я бы ещё рекомендовал перейти на Zed или другой редактор, где не нужны расширения для базовых функций — чтобы их было меньше.
Но это сложный этап на потом.
Изоляция расширений: снова Dev Container.
С ним не только pnpm start запускается в контейнере, но и многие расширения, линтер или проверка типов вашего редактора.
И malware в расширении или language-сервере снова не смогут украсть секреты из системы.
Контроль обновлений расширений: тут особо ничего нет. У VS Code нет lock-файла и осознанного обновления зависимостей.
Ревью расширений: не ставьте из сразу увидев вирусный ролик, изучите кто за ними стоит и какое там качество.
Следующий слой: Docker.
Минификация: берите базовые образы минимального размера. Желательно distroless типа wolfi от Chainguard (но их много кто делает).
Изоляция: желательно root-less Docker или Podman.
Контроль обновлений: указывайте в Dockerfile не latest или версию, а хеш (есть куча скриптов для автоматизации и обновления).
Ревью: тут сложно, но прогоняйте хотя бы сканеры известных CVE.
И в конце применим 4 шага на CI:
Минификация: не используйте готовые action от неизвестных людей для простых задач. LLM может часто заменить чужой action bash-скриптом на пару строк.
Только включите CodeQL в GitHub, чтобы видеть возможные injection-ошибки.
Изоляция: укажите permissions-ключ только с нужными правами.
Используйте Harden-Runner от StepSecurity, чтобы выключить sudo на CI и установить белый список серверов, к которым можно делать сетевые запросы.
Контроль обновлений:
Пропишите sha-коммиты в используемых action. Для npm это сделает actions-up, для других сред — pinact.
У actions-up есть опция --min-age 1 чтобы ждать сутки после релиза новой версии.
Ревью CI-action:
https://github.com/ai/multiocular так же помогает просматривать изменений action во время их обновления через actions-up.
Напоминаю, что этот тред не чтобы порекомендовать вам конкретные шаги (серебреной пули нет), а чтобы на этих примеров показать вам, как вы должны думать, не доверять и строить слои изоляции и контроля.
Повторите эти 4 шага на остальные языка в вашем проекте.
Андрей Ситник
