Безопасное управление зависимостями

Современные приложения импортируют сотни пакетов сторонних разработчиков. Каждая зависимость — и её транзитивные зависимости — расширяет поверхность атаки. Уязвимость в популярной библиотеке, например Log4Shell в Log4j, может одновременно подвергнуть риску тысячи приложений.

Файлы блокировки (package-lock.json, yarn.lock, Pipfile.lock) фиксируют каждую зависимость, включая транзитивные зависимости, на точной версии. Добавляйте файлы блокировки в систему контроля версий. Это обеспечивает воспроизводимые сборки и предотвращает случайные обновления версий, которые могут привести к появлению уязвимостей.

Инструменты SCA проверяют деревья зависимостей по базам данных CVE, чтобы выявлять уязвимые пакеты. OWASP Dependency-Check, Snyk и GitHub Dependabot автоматически обнаруживают известные уязвимости и предлагают исправленные версии с рекомендациями по устранению.

Dependabot и Renovate Bot автоматически создают запросы на слияние, когда доступны новые версии, не нарушающие обратную совместимость. Они отдают приоритет обновлениям безопасности. Настройте автоматическое слияние обновлений исправлений при успешном прохождении непрерывной интеграции, чтобы поддерживать зависимости в актуальном состоянии с минимальными ручными усилиями.

Перед добавлением зависимости проверьте число загрузок, активность недавних изменений, количество открытых проблем, совместимость лицензии и историю известных CVE. Отдавайте предпочтение хорошо сопровождаемым пакетам с действующими процессами реагирования на угрозы, а не альтернативам, которые больше не поддерживаются.

Ваши прямые зависимости подключают собственные зависимости. Инцидент с event-stream: злоумышленники получили контроль над транзитивной зависимостью, которую использовали миллионы пакетов. Проверяйте всё дерево зависимостей, а не только прямые зависимости.

Атаки с подменой зависимостей связаны с публикацией вредоносных пакетов в общедоступных реестрах под теми же именами, что и внутренние пакеты. Снизить риск помогают имена пакетов с заданной областью, аутентификация в частном реестре и внесение одобренных реестров в список разрешенных в .npmrc или pip.conf.

Спецификация состава программного обеспечения (SBOM) — это машиночитаемый перечень всех компонентов вашего программного обеспечения. Создавайте SBOM с помощью Syft или CycloneDX. SBOM позволяет быстро оценить влияние уязвимости после публикации новых CVE: определить затронутые версии можно за считанные минуты.

Лицензии OSS налагают определенные обязательства. GPL может требовать раскрытия исходного кода. MIT и Apache 2.0 являются разрешительными лицензиями. FOSSA и TLDR-Legal помогают оценить совместимость лицензий. Включите проверку лицензий в CI, чтобы предотвратить случайное включение компонентов GPL в коммерческие продукты.

Механизм проверки целостности подресурсов (SRI) для скриптов, размещенных в CDN, использует криптографический хеш в атрибуте integrity. В npm package.json есть поле integrity. Проверяйте контрольные суммы при загрузке пакетов в CI, чтобы обнаружить вмешательство в цепочку поставок.

Устанавливайте исправления безопасности в течение 24–48 часов после публикации CVE для критических уязвимостей. Используйте оценки CVSS и данные об эксплуатационной пригодности, чтобы расставлять приоритеты. Исправленная зависимость, вносящая несовместимое изменение, лучше уязвимости, которую можно эксплуатировать в рабочей среде.

Что такое атака с подменой зависимости?

Безопасное управление зависимостями требует закрепления версий в файлах блокировки, запуска сканирования SCA в CI/CD, автоматизации обновления исправлений, создания SBOM для оценки влияния и проверки состояния безопасности новых зависимостей перед их внедрением.