Управление уязвимостями веб-приложений: от списка компонентов до закрытия находок

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

Перечень состава выпуска

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

Что инвентарь даёт кроме громких новостей

• Видны забытые сервисы. Старый стенд с боевой копией базы находится в таблице, а не в отчёте после инцидента.
• Видны устаревшие компоненты. Библиотека без обновлений — будущая уязвимость, которую некому закрыть; замену планируют заранее.
• Приоритеты опираются на факты. Находка в сервисе, доступном из интернета и работающем с персональными данными, и находка в стенде за закрытой сетью разные по срочности. Как их сравнивать, разобрано в статье «Как приоритизировать уязвимости».

Сообщение пришло утром. Задача первого дня — не исправить всё, а ответить на два вопроса: затронуты ли мы и насколько срочно. Порядок такой.

1. Прочитать условия. Какие версии затронуты, нужна ли определённая функция, нужен ли вход в систему.
2. Поиск по перечням составов. Находим все выпуски с затронутой версией и делим на три группы: работает в боевой среде, работает на стенде, давно не выкладывался. Если перечней нет, этот шаг растягивается на дни, и это главный довод в пользу инвентаря.
3. Проверить достижимость. Попадают ли в уязвимую функцию данные от внешнего пользователя. Один и тот же пакет в двух сервисах даёт разный ответ: в одном им читают загруженные клиентом файлы, в другом только собственные шаблоны.
4. Временная мера, если выпуск не сразу. Отключить функцию, закрыть доступ из внешней сети, запретить загрузку определённых типов файлов. Мера записывается с датой снятия.
5. Исправление и проверка. Обновление пакета, прогон автотестов, повторная проверка тем же способом, которым нашли. Закрывает второй человек.
6. Запись и сообщение. Решение вносится в реестр. Если договор с клиентом обязывает сообщать о таких событиях, сообщение готовит ответственный по договору, мы даём техническое описание.

Репетиция этого порядка входит в работу: берём одну прошлую громкую уязвимость и проверяем, за сколько часов вы нашли бы затронутые выпуски.

Если находок у вас пока нет и вы хотите узнать, что в приложении не так, начните с аудита безопасности или ревью кода: это разовая проверка, результат которой потом попадёт в реестр. Если проверки есть, а результаты теряются, нужна эта страница.

Если вам нужно встроить автоматические проверки в сборку и разобраться, где какую запускать, смотрите внедрение DevSecOps и анализ кода и зависимостей. Управление уязвимостями берёт их результаты и доводит до закрытия. Если проблема в самом процессе разработки, начинают с безопасной разработки, а если новая система только проектируется, помогает моделирование угроз.

Шесть шагов процесса от находки до закрытия описаны в статье «Управление уязвимостями: от находки до закрытия».