Пентест нашёл 40 уязвимостей — как организовать их исправление, не утонув?

Не полагайтесь слепо на CVSS-оценки. Например, высокооценённая уязвимость на внутреннем API-эндпоинте, если она за аутентификацией, имеет низкий реальный риск. А вот средняя утечка информации в параметре, открытом в общий интернет, может ударить быстрее. Обязательно учитывайте контекст эксплуатируемости.

В прошлом году мы прошли похожий процесс с отчётом на 38 находок. Команда сначала думала, что неделями не сможет писать новые фичи. Когда разобрались, увидели, что 14 из 38 уязвимостей закрылись сами собой простым обновлением двух старых зависимостей пакетов. Обновления пакетов за 3 часа срезали треть рабочей нагрузки.

Сразу спросите у тестирующей компании срок вашего права на повторный тест (re-test) по договору. В договорах обычно есть 30 или 45 дней бесплатной проверки исправлений. Если не успеете закрыть критические и высокие до истечения этого срока и получить отчёт об одобрении, придётся платить компании дополнительно.

Чтобы не ломать рабочий процесс, вот вам правило по емкости спринта: 1) Выделите 30% следующего спринта чисто под критические уязвимости. 2) На оставшихся 70% продолжайте пилить основные задачи по обязательствам перед клиентами. 3) Низкоприоритетные баги скиньте в бэклог техдолга и разгребайте в следующих итерациях.

Когда после нашего первого пентеста прилетел отчет на 50 страниц, разработчики восприняли все на свой счет и встали в позу, мол, безопасники сгущают краски. Тут самое главное — сберечь боевой дух команды. Отчет разрабам надо преподносить не как табель с двойками, а как обычный список техдолга со свежим взглядом со стороны. Иначе начнется бессмысленная война между разработкой и безопасниками.

Из этих 11 низких уязвимостей как минимум штук 5 — это наверняка шаблонная ерунда вроде поддержки старых TLS, флагов у cookie или светящейся версии сервера. Злоумышленнику от них ни горячо ни холодно, так что не тратьте на них время и сразу беритесь за дыры в авторизации и управлении сессиями.

Корпоративный клиент прописал вам в договоре официальные сроки на исправление (SLA)? Если там нет жестких рамок вроде 14 дней на критические и 30 дней на высокие уязвимости можете спокойно подстроить график под свой темп разработки.

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

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

Конечно, если ваша ситуация отличается, всё меняется.

В прошлом году мы столкнулись практически с тем же самым. Начните с небольшого эксперимента не привязывайте всё сразу.

Не полагайтесь на одну меру защиты; действуйте слоями.

Именно так, и при этом об этом мало кто знает. Все, кто торопится с процесс устранения уязвимостей, спотыкаются на одном и том же.

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

Если напишете результат здесь, это поможет и другим.

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

Этот совет подойдет не всем, на мой взгляд. Две недели ведения заметок дают лучший результат, чем шестимесячные прогнозы.

Это мое мнение не утверждаю, что оно единственно верное.

не знал об этом.

Буду рад если напишете о результате.

Мне тоже интересно.

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

изменение платженых данных никогда не подтверждается через тот же канал и честно это мое мнение не утверждаю, что оно единственно верное.