Сегодня вопросы безопасности цепочек поставок ПО обсуждают все: от разработчиков с маленькими пет-проектами на GitHub до корпораций уровня Google. Но при всей медийности темы, реальность парадоксальна: большинство мер защиты стоят дорого, сложны в интеграции и… почти бесполезны против реальных атак.
На этом фоне предложение внедрять временную задержку обновления (dependency cooldowns) выглядит чуть ли не неприлично простым. А главное — практически бесплатным. Но именно в этой простоте скрывается один из самых эффективных способов защитить проект от атак на зависимости.
И если кратко: обычная задержка обновлений на 7–14 дней перекрывает 80–90 % известных атак на цепочку поставок.
🔥 Почему вообще нужны временная задержка обновления — и что это такое
Временная задержка обновления — это программная «выдержка»:
прежде чем обновить любую внешнюю библиотеку, проект ждёт заданное количество дней. По сути, это таймер, который даёт экосистеме время на:
🟢 обнаружение вредоносной версии
🟡 удаление её из репозитория
🔴 распространение информации вниз по цепочке
С технической точки зрения это тривиально: никаких отдельных сервисов, подписок или сложных вмешательств. Просто задержка между моментом публикации и моментом, когда вы разрешаете инструментам обновлять зависимости.
И вот почему это работает так хорошо.
📉 Что показал анализ 10 крупных supply chain атак
Автор статьи разобрал 10 громких атак последних 18 месяцев, включая инциденты с:
- xz-utils,
- chalk,
- Ultralytics,
- rspack,
- num2words
и другими.
И цифры получились почти комичными:
🟣 8 из 10 вредоносных релизов исчезли с PyPI/npm/GitHub спустя ≤ 7 дней
🟢 9 из 10 — ≤ 14 дней
Это значит:
если бы разработчики ждали хотя бы неделю, 80 % атак просто не дошли бы до них.
А если бы ждали две недели — 90 %.
Другими словами, реализовать временную задержку обновления — это всё равно что поставить фильтр, который пропускает только те пакеты, которые экосистема успела проверить и признать безопасными.
Впечатляет, учитывая цену вопроса: 0 рублей.
🛠️ Как это работает технически
Самое приятное — задержка (cooldown) уже поддерживают популярные инструменты.
🟢 Dependabot
Просто добавляешь:
# 7-дневный cooldown
- package-ecosystem: npm
directory: /
schedule:
interval: weekly
cooldown:
default-days: 7
И всё. Dependabot начнёт создавать PR только по истечении таймера.
🟢 Renovate
Работает аналогично:
нужно добавить параметр default-days в конфиг.
🟡 pnpm
Уже содержит опцию minimumReleaseAge — по сути встроенный cooldown.
🟠 uv
Имеет exclude-newer, пусть и реализованный в более жёсткой форме (по дате, а не по интервалу).
🧨 Почему cooldown оказывается эффективнее «дорогих» решений
Главное наблюдение автора:
в большинстве атак время между вводом вредоносного кода и его обнаружением очень мало — от часа до нескольких дней.
Причин несколько:
🟣 Вендоры безопасности активно мониторят PyPI/npm и соревнуются в скорости обнаружения
🟢 Сообщества моментально реагируют и репорты попадают в upstream
🟡 Сервера репозиториев очень быстро депубликуют вредоносные версии
В результате форточка эксплуатации для злоумышленников микроскопическая.
И cooldown аккуратно «перекрывает эту щель».
То есть пока атака ещё не успела повлиять на реальных пользователей — вы просто… ждёте.
Иногда лучший способ движения вперёд — пауза.
💬 Моё мнение: cooldown — это тот редкий случай, когда простое решение бьёт по самому корню проблемы
Мне особенно нравится в этой идее следующее:
✨ Она не требует менять инфраструктуру
✨ Она не создаёт ложного ощущения безопасности
✨ Она работает с реальными временными интервалами атак
✨ Она усиливает доверие без перегревания процесса CI/CD
✨ Она помогает OSS-экосистеме, не нагружая её дополнительными «сканерами»
И главное — dependency cooldown впервые делает что-то, что я давно ждал от инструментов управления зависимостями: признаёт, что не все обновления должны ставиться немедленно.
Мы слишком долго относились к обновлениям как к догме:
«обновляйся мгновенно или ты уязвим».
Но факты говорят другое:
🟢 мгновенное обновление = шанс поймать вредоносную версию
🟣 обновление через неделю = шанс ~0,2 %
И это тот редкий случай, когда статистика и инженерная практика полностью совпадают.
📎 Ссылки на источник
— Оригинальная статья:
https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns