Сканирование зависимостей (SCA)

Что это такое

Анализ состава программного обеспечения следит за пакетами, от которых зависит проект, — прямыми и транзитивными — и сообщает о тех, у кого есть известные уязвимости, сверяясь с базой рекомендаций. Он отвечает на вопрос «есть ли в этом дереве известная плохая версия?», который отличается от вопроса «безопасно ли написан этот код?». Он сообщает о подверженности; он ничего не исправляет.

Почему это важно

Большая часть кода в современном приложении написана кем-то другим и приходит транзитивно: вы устанавливаете библиотеку форм и получаете сорок пакетов, которых не выбирали. Уязвимость в любом из них — уязвимость в вашем продукте. Самые частые серьёзные случаи не экзотичны: старая библиотека разбора с недостатком отказа в обслуживании, инструмент сборки с рекомендацией о внедрении команд, зависимость зависимости, закреплённая три года назад. Сканеры делают это видимым на каждой сборке, а это единственный способ довести до исправления.

Ключевые идеи

Сканируйте разрешённое дерево, а не манифест

Манифест перечисляет то, что вы запросили; лок-файл хранит то, что вы получили, включая транзитивные пакеты, где живёт большинство рекомендаций. Сканируйте лок-файл в непрерывной интеграции, чтобы результат совпадал с развёрнутым.

На каждом пул-реквесте:  сканировать лок-файл, падать на высокой серьёзности
Ночью:                   пересканировать тот же лок-файл на новые рекомендации
Результат:               id рекомендации, пакет, установленная версия, исправленная

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

Сортируйте по достижимости, а не по количеству

Сто алертов без приоритизации не дают ни одного исправления. Спросите, вызывается ли уязвимая функция на самом деле, достижим ли путь кода из недоверенного ввода и существует ли исправленная версия.

Высокий  уязвимый парсер обрабатывает загруженные файлы, достижим из API
Низкий   инструмент времени сборки, только для разработки, не работает в продакшене
Нет      рекомендация касается возможности, которую проект не использует

Заведите путь исправления до того, как добавите сканер

Вывод бесполезен без политики: при высокой серьёзности с доступным исправлением патчите в заданный срок; где исправления нет, записывайте компенсирующий контроль и дату возврата к вопросу.

Считайте сканер одним сигналом среди нескольких

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

Следите за цепочкой поставок, а не только за рекомендациями

Только что опубликованные пакеты, имена-опечатки и скомпрометированные аккаунты сопровождающих — ещё не рекомендации. Закрепляйте версии, проверяйте изменения лок-файла в пул-реквестах и будьте осторожны с пакетами, которыми никто не пользуется.

Практика

Просканируйте лок-файл и отсортируйте пять главных

Запустите сканирование разрешённого дерева зависимостей и классифицируйте пять находок наивысшей серьёзности по достижимости кода.

Готово, когда: у каждой из пяти есть суждение о достижимости, исправленная версия где она существует, и владелец.

Исправьте одну транзитивную зависимость

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

Готово, когда: сканирование больше не сообщает эту рекомендацию, а приложение по-прежнему собирается и работает.

Частые ошибки

Сканирование только манифеста — транзитивные пакеты, где сидит большинство рекомендаций, пропущены; исправить: сканируйте разрешённый лок-файл.
Длинный нерасставленный список — никто по нему не действует; исправить: сортируйте по достижимости и серьёзности и задайте срок исправления.
Сканирование только на релизе — подверженность существует весь цикл разработки; исправить: запускайте на каждом пул-реквесте и ночью.
Убеждение, что сканирование означает безопасность приложения — оно не покрывает ни ваш код, ни конфигурацию; исправить: держите его одним из нескольких контролей.
Никогда не обновлять — исправленная версия существует и не берётся; исправить: планируйте регулярные обновления зависимостей, чтобы патчи стали рутиной, а не аварийной ситуацией.

Что читать дальше

Управление пакетами (npm) (02-frontend/04-package-management-npm) — читайте первым; лок-файл и разрешение версий, на которых держится это сканирование.
Управление секретами (07-security/03-secrets-management) — другой частый путь компрометации проекта извне.
Веб-безопасность (OWASP Top 10) (07-security/01-web-security-owasp-top-10) — недостатки в вашем собственном коде, которых не найдёт ни один сканер.
CI/CD (06-cloud-devops/08-ci-cd) — где запускается сканирование и где оно должно валить сборку.