Попробовали сами провести аудит безопасности своего кода и застряли — какие тут типичные грабли?

Грамотно настройте taint analysis (анализ потока непроверенных данных) в анализаторе. Отслеживайте путь параметра от ввода пользователем до базы или системной команды — санитизируется он или нет. Выключите правила, которые триггерятся на любую конкатенацию строк как на SQL-инъекцию, и две трети мусорных алертов сразу отвалятся.

Заставлять разработчика без подготовки по безопасности проверять собственный код на уязвимости — чистая формальность. Автор кода в упор не увидит своих же косяков в архитектуре. Если бюджет ограничен, гораздо дешевле и эффективнее заказать точечный внешний аудит на 2–3 дня не на всю систему целиком, а чисто под модули авторизации и оплаты.

Не наступайте больше на те же грабли, пытаясь отсмотреть 12 000 строк за один присест. Разбейте проверку безопасности по пулреквестам. Не больше 300 строк на один мердж и максимум 5 критических пунктов по безопасности в чек-листе. И проверять надо прямо по ходу написания кода, а не впопыхах под конец спринта.

У нас при первом скане вылезло 410 алертов. Мы всей командой две недели с ними возились. Потом настроили фильтры безопасности строго под топ-10 критических веб-уязвимостей, и число предупреждений сразу упало до 19. Причем из этих 19 реальный риск представляли и требовали фикса всего 4 штуки.

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

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

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

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

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

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

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

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

согласен.

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

Безопасность не бывает абсолютной; цель — сделать атаку нецелесообразной. Удачи.

У нас было так. Непроверенная резервная копия — не резервная копия.

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

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

Удачи.

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

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

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

у меня та же ситуация поэтому и спрашиваю. честно если делаете впервые начните с малого масштабиррование потом.

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

Не упустите: Большая часть потерь времени копится на задачах, ожидающих согласования.

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