Аудит кода: как проверить проект после фрилансера или студии

Типовых ситуаций три. Первая — приёмка: подрядчик сдаёт проект, и до финального платежа хочется понять, что под капотом. Вторая — «проект тормозит»: продукт живёт, но каждая доработка занимает недели, разработчики меняются, и никто не может объяснить почему. Третья — передача: команда уходит, и новому исполнителю нужно понять, что он наследует.

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

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

Важно понимать: цель — не эстетика, а стоимость владения. «Некрасивый», но структурированный код может спокойно жить годами. Красный флаг — другое: изменения в одном месте непредсказуемо ломают другое, логика размазана копипастой по десяткам файлов, а критичные участки не покрыты даже смоук-тестами.

Второй слой — безопасность, и здесь находки самые неприятные. Классика: секреты и ключи API прямо в коде репозитория, пароли пользователей без нормального хеширования, эндпоинты без проверки прав («любой залогиненный видит чужие данные, если подставит ID»), SQL-запросы, собранные конкатенацией строк.

К коду добавляется инфраструктура: HTTPS и заголовки безопасности, настройки CORS, доступность служебных панелей и файлов снаружи, актуальность серверного окружения. У нас в студии это отдельное направление — аудит безопасности, где проект проверяется и по коду, и по «внешнему периметру», как его видит атакующий.

Результат аудита — не ощущение, а документ. Нормальный отчёт содержит список находок с приоритетами (критично / важно / желательно), объяснение каждой проблемы человеческим языком — что это и чем грозит бизнесу — и план починки с оценкой трудоёмкости. По такому отчёту можно торговаться с текущим подрядчиком или ставить задачи новому.

Главный пункт отчёта — вердикт: чинить или переписывать. Вопреки стереотипу, «всё переписать» — редкий и обычно невыгодный ответ; чаще проект лечится точечно, начиная с критичных дыр. Честный аудитор прямо говорит, где достаточно недели работ, а где фундамент действительно не спасти.

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

Отдельный совет: не заказывайте аудит у того, кто будет чинить найденное, без фиксации отчёта заранее — иначе у исполнителя есть соблазн «найти» побольше работы. Либо разделите аудит и починку между разными подрядчиками, либо требуйте отчёт в формате, который можно показать третьей стороне для перепроверки.