Обновить

node-ipc снова взломали — но не код, а домен за $9. Разбор атаки через DNS-туннели, которой не увидел ни один SIEM

Уровень сложностиСредний
Время на прочтение10 мин
Охват и читатели7.7K
Всего голосов 1: ↑1 и ↓0+3
Комментарии3

Комментарии 3

Если ваш CI собирался в окно с 14:25 до 16:30 UTC 14 мая, и ваш package-lock.json допускал автоматические обновления в диапазоне ^9.x или ^12.x

А это вообще как? Что нужно сделать с пакетным менеджером, чтобы package-lock.json в принципе начал допускать какие-то там автоматические обновления?

За эти два часа пакет успел разойтись по миру через npm install и npm ci во всём, что собиралось в это окно.

Про npm install тут всё понятно, но с npm ci как это возможно?

Я не призываю удалять node-ipc отовсюду. Я призываю задуматься: сколько таких пакетов у вас в зависимостях прямо сейчас?

Задуматься-то дело нехитрое, но что с этими пакетами делать-то?

Тут формулировка была упрощена. package-lock.json сам по себе не разрешает апдейты. Тут речь о том, что npm install может пересобрать lockfile, если в package.json стоят диапазоны версий, а потом npm ci поставит уже зафиксированную в lockfile версию. То есть npm ci не обходится мимо lockfile, а наоборот, воспроизводит его как есть. В статье я именно за это и топлю: lockfile должен быть фиксированным, а в production-сборках только npm ci, никогда npm

Базовые меры, которые стоило сделать ещё вчера:

npm config set min-release-age 3

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации