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

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

Процесс не требует дорогих систем: для команды из нескольких разработчиков хватает таблицы или трекера задач и недельной договорённости. Как проводится сама проверка, описано на страницах «Аудит безопасности веб-приложения» и «Secure code review», как встроить автоматические проверки в сборку — на странице «Внедрение DevSecOps». Здесь о том, что делать с их результатами.

Шесть шагов: от находки до закрытия

Весь процесс помещается в шесть шагов. Если какой-то пропущен, находки накапливаются или закрываются «на словах».

Шаги 2 и 6 пропускают чаще всего. Без записи находка живёт в чьей-то голове, без проверки закрытие означает «разработчик сказал, что исправил».

Откуда берутся находки и сколько в них шума

Источников несколько, и у каждого свой характер. Один даёт мало находок, но точных, другой много, и половина из них не требует действий.

Разницу между статическим анализом, динамической проверкой и анализом зависимостей подробно описывает статья «SAST, DAST, SCA: в чём разница», а настройку в вашей сборке — страница про анализ кода и зависимостей. Для процесса важно одно: все источники сходятся в один реестр, иначе приоритеты сравнивать не с чем.

Реестр: что записывать по каждой находке

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

• Номер и краткое название. «Доступ к чужим заказам по номеру в адресе», а не «IDOR».
• Место. Адрес, файл и функция либо библиотека и версия.
• Как воспроизвести. Шаги, по которым разработчик увидит проблему сам. Находка без воспроизведения плохо проверяется при закрытии.
• Источник и дата. Кто нашёл и когда. По дате считается возраст находки.
• Серьёзность, достижимость, ценность данных. Три отдельные отметки, а не одна общая.
• Владелец и срок. Фамилия человека, а не название команды.
• Статус. Новая, подтверждена, в работе, исправлена, проверена, закрыта, ложная, принят риск.
• Ссылка на исправление и на проверку. Изменение в репозитории и тест либо запись о повторной проверке.

Не копируйте в реестр секреты и данные клиентов, найденные при проверке: достаточно описания места. Сам реестр содержит сведения об уязвимостях, поэтому доступ к нему узкий.

Как расставлять приоритеты: три вопроса вместо одной оценки

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

1. Насколько опасна сама ошибка? Чтение чужих данных, выполнение чужого кода и обход входа опаснее, чем отсутствие заголовка.
2. Достижима ли она? Виден ли уязвимый адрес снаружи, нужна ли учётная запись, вызывается ли уязвимая функция библиотеки в вашем коде.
3. Что лежит за ней? Персональные данные, деньги, учётные записи администраторов или справочник городов.

Ниже условные примеры, показывающие, как одни и те же вопросы дают разный порядок.

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

Сроки и владельцы: как не превратить реестр в кладбище

Срок задаётся классом приоритета, а не настроением недели. Ниже шкала в качестве отправной точки; значения подстройте под ваш ритм релизов и запишите в регламент. Сроки считаются от подтверждения находки.

Три правила делают шкалу рабочей:

• У срока есть владелец-человек. Задача, у которой записано «команда разработки», не имеет исполнителя.
• Просрочка видна. На недельном разборе первым делом смотрят то, что вышло за срок, а не новые находки.
• Нельзя молча сдвинуть срок. Перенос оформляется записью: новая дата и причина. Три переноса подряд означают, что нужно либо выделить время, либо пересмотреть класс.

Когда находка считается закрытой, и как принимать риск письменно

«Исправлено» и «закрыто» — разные статусы. Закрыто то, что проверено вторым человеком или автоматикой.

1. Исправление прошло обычное ревью и попало в релиз, который работает у пользователей, а не только в ветке.
2. Для логической ошибки добавлен тест, который падает на старом коде: тогда ошибка не вернётся незаметно.
3. Тем же способом, которым находку нашли, проверено, что она больше не воспроизводится: тот же прогон, тот же запрос, повторное срабатывание сканера.
4. Временные меры, поставленные на время исправления, сняты или записаны как постоянные.

Исключения: принятие риска

Иногда исправлять нецелесообразно: ошибка в устаревшем модуле, который выведут из эксплуатации, или исправление дороже возможного ущерба. Это допустимо, если решение оформлено, а не забыто:

• Кто принял. Руководитель, у которого есть право отвечать за последствия, а не автор кода.
• Почему. Одна-две фразы с описанием, что именно остаётся открытым.
• Чем компенсируем. Ограничение доступа по сети, усиленный журнал, оповещение о попытках.
• Когда пересмотрим. Дата в календаре. Исключение без даты превращается в бессрочное.

Метрики и ритм: что смотреть, чтобы процесс не умер

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

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

Ритм простой. Раз в неделю короткий разбор: просроченное, новое, решения по приоритетам. Раз в квартал полный просмотр реестра: исключения с наступившей датой, находки без движения, ложные срабатывания. После крупного релиза или смены подрядчика добавляется внеочередной разбор. Для небольшой команды это полчаса в неделю, а не отдельная должность. Если проверки в сборке только внедряются, ориентиром служит статья «DevSecOps: с чего начать небольшой команде».

Признаки того, что процесс не работает

Процесс ломается тихо. По этим признакам понятно, что пора что-то менять:

Что делаем мы и с чего начать

Начинаем с обследования: 200 000 ₽ за один-два процесса и 2–3 недели, 350 000 ₽ и 3–4 недели, если приложений несколько. Если нужны находки, проводим аудит безопасности или ревью кода: отчёт содержит воспроизведение, серьёзность и порядок исправления, то есть записи, готовые для реестра. Мы помогаем завести реестр, согласовать классы и сроки, настроить проверки в сборке и разобрать первые срабатывания. Исправление найденного оценивается отдельно, от 150 000 ₽, и заказывать его у нас не обязательно. Стоимость обследования вычитается из первого этапа, если продолжаете с нами.

Мы не берём на себя круглосуточное дежурство и реакцию на инциденты в течение часа, не поставляем системы мониторинга безопасности, не проводим пентест боевых систем и аттестацию, лицензии ФСТЭК у нас нет. Исходный код и реестр остаются у вас с первого дня. Цены и сроки — на странице «Тарифы». Как проходит проверка кода — на странице «Secure code review», как встроить безопасность в весь цикл разработки — на странице «Безопасная разработка веб-приложений».