Получили отчет по уязвимостям, там сплошные уровни критичности — как превратить это в понятный план действий?

Баллы CVSS показывают общую критичность, но сами по себе не отражают реальную вероятность атаки. Разбирая пункты отчета, смотрите, есть ли эксплойт в открытом доступе. Уязвимость, для которой в сети гуляет готовый скрипт, даже с оценкой 7.5 куда опаснее бага на 9.0, который на практике крайне сложно проэксплуатировать.

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

В прошлом году на подобном аудите мы словили 52 бага. Стали разбираться — оказалось, 18 из них тянулись всего от двух устаревших опенсорсных JavaScript-библиотек. На обновление библиотек и чистку зависимостей ушло полдня, и почти треть отчета закрылась одним махом.

По процессу советую действовать так: 1) Критические и высокие уязвимости на публичных серверах берете в первый же спринт, 2) Косяки конфигурации вроде заголовков и шифрования скидываете девопсам единым тикетом, 3) Оставшиеся средние и низкие закидываете в техдолг и раскидываете по одной-две на каждый спринт.

мы тоже скоро будем заказывать похожее сканирование а что конкретно знначит этот ложноположительный результат о котором вы говорите? то есть уязвимость, которая есть в отчете безопасников, на самом деле может вообще у нас отсутствовать?

Компании по безопасности иногда просто натравливают автоматический сканер и скидывают клиенту сырой PDF на 70 страниц. Если в отчете нет пруфов с эксплойтами и скриншотами, вы имеете полное право потребовать от них ручного разбора и верификации; 4.800 USD явно платятся не за то, чтобы просто кнопку нажать.

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

Подытоживая: без паники отсейте false positive, быстро закройте обновлениями критические дыры, торчащие наружу, отправьте корпоративному клиенту план действий на 30 дней и ждите повторного сканирования.

Хорошо, что вы создали эту тему. Если путь уведомления длинный, уведомление не приходит; а не пришедшее уведомление — это поздно обнаруженный инцидент.

Интересно, есть ли те, кто делает иначе.

Взял на заметку спасибо.

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

оставлю как заметку, пригодится.

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

Решения, работающие в малом масштабе, рушатся при росте, я узнал это слишком поздно.

Очень актуальная тема.

Я думаю иначе. Время обнаружения проблемы напрямую определяет ее стоимость.

Если не зафиксировать это письменно с самого начала, потом возникнут споры. Надеюсь, это будет полезно.

Вопрос будет немного наивным, извините заранее. Люди защищают не процесс, а привычку. Сопротивление идет оттуда.

Исправьте, если я ошибаюсь.

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

Первые три месяца все идет хорошо, проблемы всплывают на четвертом. Интересно, есть ли те, кто делает иначе.

Пишу это, чтобы вы не совершили ту же ошибку. Если на один вопрос вы получаете три разных ответа, вопрос задан неправильно.

Оставлю как заметку, пригодится.