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

Вам нужно строго разделять активное и пассивное сканирование. Если натравить агрессивный фаззер на формы авторизации или веб-интерфейсы, базу на проде просто заклинит. При сканировании портов на сетевом уровне жестко режьте rps. А веб-сканеры гоняйте строго на стейджинге/тестовой копии, но ни в коем случае не на живой базе.

Своими собственными результатами сканирования вы не пройдёте аудит у корпоративного немецкого заказчика. Аудитор не примет ваше «мы просканировали изнутри всё чисто» — ему нужна независимая подпись и методология. К тому же большая часть стосраничного отчёта, который выдаёт инструмент, — это несущественные предупреждения а чтобы их отсеять нужны знания эксперта.

edit: выше написал неправильно, извините.

Чтобы безопасно провести сканирование, следуйте этим шагам: 1) Сделайте бэкап боевой базы данных залейте его в тестовую среду и направьте сканирование только на этот тестовый адрес. 2) В инструменте сканирования ограничьте лимит запросов до максимум 3–5 запросов в секунду. 3) Перед началом сканирования пусть будет открыта панель мониторинга использования ресурсов сервера в реальном времени.

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

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

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

Когда мы ставим эти инструменты на сервер и запускаем, остаётся ли в системе какой-то агент который оставляет постоянные файлы или дыру в безопасности или после завершения сканирования всё возвращается в исходное состояние?

Боевую машину вообще не трогайте. Для вашей кодовой базы запустите открытый инструмент статического анализа кода на своём локальном компьютере. А для серверной ОС просто выполните команду, которая выводит только security-обновления пакетного менеджера. С нулевым риском вы решите половину задачи.

Вы правы.

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

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

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

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

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

Я бы не торопился. Изменение платежных данных никогда не подтверждается через тот же канал.

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

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

Извините, но это верно не во всех случаях. Главное не цифра, а то, на основе чего она получена.

Согласен.

Есть момент, который я не понял. Безопасность не бывает абсолютной; цель — сделать атаку нецелесообразной.

Главное не цифра, а то, на основе чего она получена. Удачи.