Как своими силами внедрить проверку безопасности кода перед релизом?

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

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

P.S.: вопрос уже задавали ниже, ответ во втором сообщении.

Самый практичный шаг, который можно внедрить буквально завтра утром — добавить блок по безопасности прямо в шаблон пулл-реквеста. Чтобы разработчик перед отправкой кода обязан был проставить галочки: «Входные данные валидировал» и «Проверку прав добавил». Даже эти два простых вопроса заставят лишний раз остановиться и подумать перед коммитом.

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

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

Обход авторизации из отчета по пентесту вашего клиента — он произошел на уровне API или прямо в запросах к базе данных? Если на эндпоинтах API нет централизованного слоя авторизации, ручные проверки внутри каждой функции рано или поздно снова приведут к дырам. У вас в архитектуре вообще предусмотрен централизованный контроль идентификации и доступа?

Не полагайтесь слишком сильно на автоматические сканеры. SAST-тулы отлично находят уязвимости в либах или банальные SQL-инъекции, но ошибки бизнес-логики вроде вашего обхода авторизации они не увидят никогда. Пока живой человек глазами не проверит логику по коду в духе «может ли пользователь А увидеть счет пользователя Б», ни один автоматический софт вас от таких факапов не спасет.

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

Я сталкивался с тем же.

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

Интересно есть ли те, кто делает иначе.

Большое спасибо сегодня попробую.

Сохранил.

Полностью согласен. Меры, принятые без инвентаризации, оставляют открытыми двери о которых вы не знаете.

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

Пишу это, чтобы вы не совершили ту же ошибку. Непроверенная резервная копия — не резервная копия.

Время обнаружения проблемы напрямую определяет ее стоимость. Интересно, есть ли те кто делает иначе.

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

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

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

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

мои сомнения развеялись спасибо.

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

Непроверенная резервная копия — не резервная копия. Я бы пошел этим путем.