Забрали кодовую базу у агентства — как провести аудит безопасности кода и с чего начать?

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

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

В прошлом году забирали чужой проект на 30к строк, сразу натравили статический анализатор. Вылезло 142 варнинга. Разраб перепроверил руками — 8 оказались критическими дырами, через которые реально можно было слить базу. Закрыли все 8 штук за три дня.

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

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

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

Перечитайте договор с агентством. В большинстве договоров прямо или косвенно прописаны гарантии соответствия сдаваемого кода отраслевым стандартам и базовым практикам безопасности. Хардкод паролей — это явный дефект оказания услуг, у вас могут быть все основания выставить агентству официальную претензию на исправление.

а как инструменты статического анализа кода проверяют его без запуска? как именно эти тулы понимают что функция уязвима если код не развернут на боевом сервере и нет подключения к БД?

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

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

мне тоже интересно.

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

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

Я тоже об этом думал. Автоматический отчет о сканировании и пентест — это не одно и то же.

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

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

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

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

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

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

У меня та же ситуация, поэтому и спрашиваю. ну если разрешение и объем тестирования не зафиксированы письменно тест не начинать.

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

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

Если путь уведомления длинный, уведомление не приходит; а не пришедшее уведомление — это поздно обнаруженный инцидент.

Мои сомнения развеялись, спасибо. Время обнаружения проблемы напрямую определяет ее стоимость.

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