Цель модуля
Научить разработчика осознанно подходить к сторонним библиотекам: проверять источник и лицензию, отслеживать уязвимости, планировать обновления и не допускать попадания чужого кода с неизвестным происхождением в поставку.
Чужой код в вашей поставке
За уязвимость в сторонней библиотеке перед заказчиком отвечает не её автор, а компания, поставившая продукт. Уязвимость, опубликованная в популярной библиотеке, немедленно становится известна всем, кто собирает продукт на её основе, — включая тех, кто ищет способ навредить.
Поэтому каждая зависимость — это принятое на себя обязательство следить за её состоянием.
Правила выбора библиотеки
- Проверьте источник: официальный каталог пакетов, подтверждённый правообладатель, отсутствие похожих названий-двойников.
- Уточните лицензию: она должна допускать использование в закрытом продукте и не требовать раскрытия вашего кода.
- Оцените сопровождение: дата последнего выпуска, частота обновлений, реакция на сообщения об уязвимостях.
- Предпочтите библиотеку с меньшим объёмом: каждая лишняя зависимость расширяет поверхность риска и увеличивает поставку.
- Проверьте, не тянет ли библиотека за собой десятки косвенных зависимостей.
- Зафиксируйте выбор и его обоснование в описании задачи — это позволяет пересмотреть решение позже.
Отслеживание уязвимостей
- Включите автоматическую проверку состава зависимостей в сборочный конвейер.
- Настройте уведомления об обнаруженных уязвимостях в подключённых библиотеках.
- Разбирайте каждый случай: подтвердите, затрагивает ли уязвимость ваш способ использования библиотеки.
- Планируйте обновление в ближайший выпуск, а при критической уязвимости — внеочередным исправлением.
- Ведите перечень принятых зависимостей с версиями: без него невозможно оценить масштаб при следующем сообщении.
Типовые ошибки
- Библиотека подключена по имени, похожему на известную, но от неизвестного автора.
- Обновление запрещено «навсегда» из-за страха сломать сборку — уязвимости накапливаются.
- Обновление выполняется автоматически без проверки и без прогона проверок.
- Зависимость добавлена вручную копированием файла, без учёта в перечне зависимостей.
- Лицензия проверена по названию, без чтения условий.
- Устаревшая библиотека остаётся в продукте, потому что «она работает».
Состав поставки
Перед выпуском сверяйте перечень зависимостей с фактическим содержимым поставки. В поставку не должен попадать отладочный и вспомогательный код, тестовые данные, а также библиотеки, не разрешённые к распространению.
Проверочный список перед выходом на работу
- У каждой новой зависимости проверены источник, правообладатель и лицензия.
- Лицензия допускает использование в закрытом продукте.
- Автоматическая проверка состава зависимостей включена в конвейер сборки.
- Настроены уведомления об уязвимостях, случаи разбираются, а не откладываются.
- Обновления проходят проверки до включения в выпуск.
- Перечень зависимостей с версиями ведётся и совпадает с составом поставки.
Вопросы для самопроверки
- Кто отвечает за уязвимость в сторонней библиотеке перед заказчиком? Компания, поставившая продукт: чужая библиотека входит в вашу поставку, поэтому её состояние — ваша ответственность.
- Почему автообновление зависимостей без проверки опасно? Новая версия библиотеки может изменить поведение или привнести новую уязвимость; обновление проходит проверки и выпускается по установленному порядку.
- Зачем нужен перечень зависимостей с версиями? Чтобы быстро определить, затронуты ли вы новой уязвимостью, и оценить объём обновления.
Основание и что делать при сомнении
Модуль опирается на: ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения», приказ ФСТЭК России от 11.02.2013 № 17.
Если ситуация не описана в модуле и вы не уверены в правильном действии, не принимайте решение самостоятельно: обратитесь к руководителю и в службу информационной безопасности до того, как выполнить операцию с данными или доступами.