В отчете по пентесту требуют устранить всё за 30 дней — что это вообще значит на практике?

Ориентируйтесь на баллы CVSS в отчете. Все, что от 7.0 и выше — это высокий и критический уровень. Чаще всего туда попадают косяки аутентификации и известные дыры в старых библиотеках. Бросайте разрабов в первую очередь на обновление зависимостей и валидацию входящих данных.

Мы проходили через такой же аудит. Из 12 уязвимостей 4 были высокого уровня. Разработчики бросили все задачи на две недели и занимались только ими. 3 косяка по инфраструктуре закрыли за 2 дня правилами фаервола в облаке. Пентестеры через 5 дней провели ретест и выдали чистый отчет.

Требование клиента закрыть вообще всё за 30 дней — обычный бюрократический формализм. Всякие низкоуровневые штуки вроде раскрытия версий софта реальной угрозы сервису не несут. Сосредоточьтесь на том, через что реально могут увести данные клиентов.

Срочно свяжитесь с компанией, проводившей пентест, и уточните, входит ли по договору повторное тестирование (ретест). Если да, четко зафиксируйте в календаре дедлайн, до которого нужно всё исправить и запросить проверку.

Базовые шаги по устранению уязвимостей: 1) Разделите находки на баги в коде и проблемы серверов/сети, 2) В первую очередь беритесь за уязвимости с CVSS 7 и выше, 3) Для каждого исправленного бага в коде пусть разработчики прогоняют тест-кейс, 4) После всех правок запросите у тестировщиков официальное письмо с подтверждением (attestation letter).

когда впервые видишь такой толстенный отчет вполне норрмально запаниковать и но там половина — это просто скриншоты и общие описания. сядете со свежей головой и увидите что там логические ошибки, которые ваши разрабы разгребут за 1-2 недели.

по серверной части обычо чисто конфиги поправить, а вот логика в коде может занять время и кстати не стесняйтесь задавать вопросы тестировщикам напрямую они обязаны подробно объяснить каждую уязвимость.

Если коротко: код правит ваша команда, настройки серверов крутите в облачной панели. За 30 дней закрываете критические уязвимости, по остальным расписываете временные решения (workaround), а в конце заказываете ретест у той же компании и отдаете клиенту чистое подтверждение.

исправление: ошибся в цифре, было чуть меньше.

Хочу предупредить. Если делаете впервые, начните с малого, масштабирование потом.

Я бы пошел этим путем.

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

Я бы пошел этим путем.

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

я бы пшел этим путем.

Поделюсь своим опытом. Главное не цифра, а то, на основе чего она получена.

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

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

То, что делают все, не значит, что это правильно. Я бы пошел этим путем.

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

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

пишите, если есть вопросы, отвечу по мере возможности.

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

На этом всё, извините, если затянул.

Слежу за темой.

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

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