Ответ.

Идея автоматизации проверки безопасности приложений развивалась по мере роста киберугроз. Сначала security testing был почти полностью ручным, но развитие DevOps и автоматизации позволило интегрировать security-checks в CI/CD pipelines.

История вопроса

В первые годы ручное проникновение (pentest) и сканеры были единственными инструментами проверки на уязвимости. Позже в разработке стали появляться отдельные автоматизированные сканеры, а потом — целые платформы, которые интегрируются в процессы.

Проблема

Тесты на безопасность часто долго выполняются и редко обновляются.
Множество "ложноположительных" срабатываний.
Необходимость комплексной настройки под инфраструктуру и приложение.
Не все уязвимости можно найти автоматически — часть проверок требует экспертного анализа.

Решение

Встроить автоматизированные security-тесты на этапе CI/CD: использовать DAST/SAST анализаторы, автоматические сканеры (OWASP ZAP, SonarQube, Checkmarx и др.).
Регулярно обновлять отчеты и сценарии тестирования, настроить обработку false positives.
Комбинировать автоматизацию с периодическими ручными аудитами и ретроспективами.

Ключевые особенности:

SAST/DAST/RASP сканирование
Интеграция с CI/CD
Обработка и автоматизация реакций на инциденты

Вопросы с подвохом.

Возможно ли найти все уязвимости исключительно автоматическими тестами?

Нет, автоматические проверки покрывают только часть security-рисков (например, XSS, SQL-инъекции). Для полноты необходим и ручной аудит.

Достаточно ли одного типа сканера — SAST или DAST — для качественной защиты?

Нет, SAST анализирует код статически до запуска приложения, DAST — поведение приложения во время работы. Использовать нужно оба, а также учитывать дополнительные методы.

Стоит ли отключать тесты безопасности в CI/CD для ускорения деплоя?

Нет, такой подход опасен — это ставит под угрозу безопасность продукта.

Типовые ошибки и анти-паттерны

Игнорирование отчётов сканеров (false-positive fatigue)
Отсутствие объединения ручных и автоматических подходов
Автоматизация только одной части security-процесса

Пример из жизни

Негативный кейс

Безопасность проверяется только ручным анализом на этапе релиза и иногда сканером, отчёты не интегрированы в CI/CD.

Плюсы:

"Живой" аудит сложных уязвимостей

Минусы:

Вскрытие проблем на поздних этапах
Высокая стоимость исправления

Позитивный кейс

Security-тесты развёрнуты автоматизированно в CI/CD, критические уязвимости блокируют релиз, для false-positive настроены правила фильтрации, дополнительные pentest-сессии раз в квартал.