Зависимости и 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 помогает быстро понять, затронуты ли вы новой уязвимостью.