Зависимости и supply chain

Ваш код может быть безупречен, но вы тащите за собой сотни чужих библиотек — и их уязвимости становятся вашими.

Атака на цепочку поставок (supply chain) — компрометация через сторонний компонент: библиотеку, пакет или инструмент сборки, которым вы доверяете.

Масштаб проблемы

Современное приложение состоит из вашего кода лишь на малую часть. Остальное — зависимости: фреймворки, утилиты, а у них — свои зависимости (транзитивные). В сумме это сотни и тысячи чужих пакетов. Каждый из них — потенциальная уязвимость, которую вы не писали, но за которую отвечаете перед пользователями.

Откуда берётся риск

Известные уязвимости (CVE). В популярной библиотеке нашли дыру — все, кто её используют, уязвимы, пока не обновятся.
Вредоносный пакет. Злоумышленник публикует пакет с вредоносным кодом или захватывает заброшенный популярный пакет.
Typosquatting. Пакет с именем, похожим на популярный (с опечаткой), в расчёте на то, что кто-то ошибётся при установке.
Скомпрометированная сборка. Внедрение вредоносного кода на этапе сборки или в зависимость зависимости.

Как держать зависимости под контролем

Практика	Зачем
Фиксация версий (lock-файл)	сборка воспроизводима, не подтянется неожиданная версия
Сканеры уязвимостей	предупреждают о зависимостях с известными CVE
Регулярное обновление	закрывает дыры, но проверяйте изменения
Меньше зависимостей	меньше поверхность атаки и чужого кода
Проверка пакета перед добавлением	популярность, поддержка, репутация автора

Команды-помощники

В большинстве экосистем есть встроенный аудит зависимостей — он сверяет ваш список пакетов с базой известных уязвимостей:

# Node.js — проверить зависимости на известные уязвимости
npm audit

# Python — проверить установленные пакеты (через сторонний инструмент)
pip-audit

# Обновить пакеты в рамках совместимых версий
npm update

Такой аудит стоит запускать регулярно и встраивать в процесс сборки (CI), чтобы новые уязвимости в зависимостях замечались автоматически.

Баланс «обновлять или не трогать»

Слишком редкие обновления накапливают уязвимости. Слишком поспешные — могут сами притащить проблему (как было с захваченными пакетами). Разумный баланс: следить за уведомлениями об уязвимостях, обновлять регулярно, но осознанно, читая, что изменилось, и прогоняя тесты после обновления.

Зачем нужен SBOM

Крупные команды ведут SBOM (Software Bill of Materials) — список всех компонентов и их версий в продукте, как состав на упаковке. Когда выходит новая критичная уязвимость, по SBOM мгновенно понятно, затронуты ли вы и где именно.

Итог

Большая часть приложения — чужой код, и его уязвимости становятся вашими.
Риски: известные CVE, вредоносные и подменённые пакеты, typosquatting.
Фиксируйте версии, сканируйте зависимости, обновляйте регулярно и осознанно, сокращайте их число.
SBOM помогает быстро понять, затронуты ли вы новой уязвимостью.