Аудит кода ПО: чек-лист из 12 разделов для основателей (2026)

Почему Фора Софт написала этот плейбук

Фора Софт выпустила более 625 проектов с 2005 года и провела десятки аудитов унаследованного кода для клиентов в сделках M&A, при смене подрядчика и после поглощений. Несколько недавних кейсов под NDA: сделка Series A на 727 млн ₽, где наш двухнедельный аудит вскрыл критическую проблему с интеллектуальной собственностью и привёл к пересмотру цены; стартап в сфере здравоохранения, где аудит за 4 дня нашёл нарушения HIPAA, способные сорвать следующий раунд финансирования; основатель SaaS, меняющий подрядчика, который сэкономил 6 млн ₽ на технологическом долге.

Если вы основатель, наследующий код от прежнего подрядчика, покупатель в сделке M&A, проводящий технический due diligence, или CTO, оценивающий технический долг перед масштабированием, — этот гайд даёт чек-лист из 12 разделов, набор инструментов и шаблон отчёта, которыми пользуемся мы.

4 сценария, которые запускают аудит кода

1. Смена подрядчика. Вы расстаётесь с текущей командой. Прежде чем новая возьмётся за работу, проверьте, что именно вам передают. Аудит ловит заброшенный технический долг, недокументированные костыли, отсутствующие тесты, сломанный CI/CD — то самое, о чём уходящий подрядчик умолчит при передаче.

2. Технический due diligence в сделке M&A. Покупатель заказывает аудит до подписания. Находки могут пересмотреть цену, добавить escrow-удержания или сорвать сделку. Продавец не может позволить себе отказать в доступе к аудиту; если отказывает — это сам по себе тревожный сигнал.

3. Готовность к масштабированию перед Series A. Основатели с MVP стадии seed готовятся расти и должны понимать, что сломается при 10-кратной нагрузке. Аудит ловит обрывы в масштабируемости до того, как они случатся.

4. Разбор после инцидента. После взлома, простоя или потери данных. Криминалистический аудит определяет первопричину, смежные риски и план устранения. Часто требуется по закону.

Чек-лист из 12 разделов

Итого: 11 рабочих дней одного senior-аудитора на кодовой базе средней сложности. Обычно мы пускаем двух аудиторов параллельно и укладываемся в 5–7 календарных дней; второй аудитор перепроверяет находки, чтобы снизить долю ложных срабатываний в отчёте.

Инструменты, которыми мы пользуемся

Качество кода. SonarQube (или SonarCloud) для цикломатической сложности, дублирования и выявления code smell. CodeClimate как альтернатива. Кастомные запросы на базе Tree-sitter для нестандартных языков.

Безопасность. Snyk для уязвимостей в зависимостях и проверки лицензий. Semgrep для кастомных SAST-правил. trufflehog для поиска секретов в истории. Burp Suite или OWASP ZAP для DAST. Trivy для контейнерных образов.

Производительность. k6 / Locust для нагрузочных тестов. py-spy / clinic.js / dotnet-trace для профилирования. Sqlcheck или pgBadger для анализа медленных запросов.

Полнота документации. Кастомные скрипты обхода репозитория — считают README, ADR, runbook. Извлечение Mermaid-графов для схем архитектуры.

Анализ затрат. Экспорт из AWS Cost Explorer / GCP Billing Reports / Azure Cost Mgmt API. Разбивка по сервисам за 6–12 месяцев. Прогноз динамики на следующие 12 месяцев.

AI-ассистированный анализ. Claude или GPT-4 читают исходники, чтобы дать срез по архитектуре, выявить точки сложности и проанализировать зависимости. Используется в дополнение к традиционным инструментам, а не вместо них.

Что вы получаете на выходе двухнедельного аудита

У стандартного отчёта по аудиту такая структура:

Резюме для руководства (1 страница). Топ-3 риска, топ-3 сильные стороны, итоговая оценка стоимости устранения, рекомендация: «покупать как есть», «покупать с удержанием на сумму X», «не покупать без устранения замечаний» или «отказаться».

Находки по разделам (12 разделов, по 2–6 страниц). У каждой находки указаны критичность (critical/high/medium/low), описание влияния, доказательства (фрагмент кода, скриншот, выдержка из лога) и рекомендуемое исправление.

План устранения (2–4 страницы). Приоритизированный список работ, оценка трудозатрат по каждому пункту, рекомендуемый порядок, зависимости, итоговый диапазон.

Приложения. Выгрузки из инструментов (отчёт SonarQube, скан уязвимостей Snyk, дерево зависимостей, разбивка инфраструктурных расходов). Опционально: подробные аннотации к фрагментам кода.

Объём отчёта: 30–60 страниц в зависимости от размера кодовой базы. Поставляется как PDF плюс машиночитаемый JSON для интеграции с инструментами due diligence у покупателя.

Как ставить задачу внешнему аудитору

1. Назовите сценарий. Аудит для M&A, смена подрядчика, готовность к масштабированию — все они скоупируются по-разному. Скажите аудитору прямо, не заставляйте угадывать.

2. Дайте read-only доступ ко всему. Репозиторий (все ветки), CI/CD, инфраструктура (read-only IAM), дашборды мониторинга, отчёты по биллингу. Аудитор не найдёт того, чего не видит.

3. Опишите ICP-контекст. Кто пользователи, какие SLA, какой регуляторный режим. Без этого аудитор не сможет оценить, критичны ли пробелы в нефункциональных требованиях или приемлемы.

4. Заложите 1 час с действующим инженерным лидом. Это вылавливает недокументированный контекст, который аудит иначе пропустит. Не пропускайте этот шаг: без интервью с инженерами теряется 20–40 % контекста.

5. Убедитесь, что аудитор независим от проверяемого подрядчика. Самопроверка тем же подрядчиком — это конфликт интересов. Нанимайте третью сторону.

Тревожные сигналы, срывающие сделку

1. Нет escrow для исходников. Если продавец не положил исходный код у независимого escrow-агента, шансы получить его при банкротстве или отказе подрядчика туманны. Покупатель должен потребовать оформить escrow до закрытия сделки.

2. Критические зависимости от пользовательских SaaS. Боевые данные идут через бесплатный тариф Zapier, бизнес-логика живёт в общедоступной Google-таблице, платежи проходят через чей-то личный Stripe-аккаунт. Норма до MVP, фатально на сделке.

3. Один разработчик с ключами от всего царства. Один человек знает, где зарыты тела, катит все деплои с личного ноутбука и держит все доступы в голове. Если он уходит — компания перестаёт выпускать релизы.

4. PHI/PII в открытом виде. В логах имена пациентов, email клиентов, номера платёжных карт. trufflehog находит это за один проход. Нарушение HIPAA / GDPR / PCI-DSS, мгновенный риск утечки.

5. Самописные проприетарные фреймворки. Подрядчик зашил внутрь поставки собственный ORM, фреймворк или библиотеку компонентов. Покупатель не сможет развивать продукт без этого подрядчика — это vendor lock-in под другим именем.

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

Сортируйте по критичности. Critical-находки (дыры в безопасности, нарушения требований, единые точки отказа) идут первыми — недели 1–4. High (покрытие тестами, пробелы в мониторинге, обрывы в масштабируемости) — недели 4–12. Medium и low уходят в квартальный спринт по техническому долгу.

Оценивайте каждую находку. Каждый пункт получает оценку в человеко-неделях из рекомендаций аудита. Сумма плюс 15 %-ный буфер = общий бюджет на устранение. Типовой бюджет после полного аудита: 15–30 % от исходной стоимости разработки.

Решайте: чинить или переписывать. Если бюджет на устранение превышает 50 % стоимости полной переразработки, разумнее переписать. Аудит даёт вводные для этого решения, но не решает за вас.

Работайте через change-order. Устранение идёт через формальные change-order. Новый объём, обнаруженный в процессе, оценивается отдельно и подписывается обеими сторонами до начала работ.

Мини-кейс — сделка Series A на 727 млн ₽, спасённая аудитом

SaaS-покупатель под NDA пригласил нас в середине 2025 года на двухнедельный аудит цели Series A стоимостью 727 млн ₽. Продавец заявлял: «чистая кодовая база, недавний SOC 2 Type 1, клиенты только из США».

Что мы нашли за 2 недели. Три критические находки: (1) самописный фреймворк для конструктора форм, в котором не разбирался ни один инженер вне 3-человечной команды продавца (lock-in); (2) email клиентов в открытом виде в боевых логах (нарушение CCPA, риск утечки); (3) аттестация SOC 2 Type 1 ссылалась на контроли, которых в кодовой базе не было — аудит был «нарисован».

Итог. Покупатель использовал находки, чтобы пересмотреть условия — снизил предложение на 90 млн ₽, добавил escrow-удержание на 60 млн ₽ под устранение замечаний и сделал закрытие сделки условным: вычистить логи за 60 дней. Сделка закрылась на 577 млн ₽ вместо 727 млн ₽; устранение заняло 11 недель. Если у вас на столе цель для сделки — позвоните или напишите нам.

Как выбрать глубину аудита — пять вопросов

В1. Какой триггер? M&A → полный аудит. Смена подрядчика → полный аудит. Подготовка к Series A → фокус на производительности и архитектуре. После инцидента → фокус на безопасности.

В2. Какой размер кодовой базы? <100k LoC: 5–7 дней, один аудитор. 100k–500k LoC: 10–14 дней, два аудитора. >500k LoC: 3–5 недель, команда из 3+ человек.

В3. Важны ли требования соответствия? Если регулируемая сфера (HIPAA, SOC 2, PCI), раздел 9 ощутимо расширяется — закладывайте дополнительное время.

В4. Доступна ли действующая команда? Часовое интервью с инженерным лидом — не опция. Если они отказываются, это уже находка.

В5. Насколько срочно? Быстрый просмотр перед LOI: 5-дневная сводка тревожных сигналов. Due diligence перед закрытием сделки: двухнедельный полный аудит. Планирование устранения после закрытия: 3–4 недели глубокого погружения.

Чего избегать

1. Самопроверка проверяемым подрядчиком. Конфликт интересов. Аудитор всегда внешний.

2. Аудит без интервью с инженерами. Теряется 20–40 % контекста. Часовое интервью обязательно.

3. Выгрузка инструмента вместо отчёта. Сам по себе отчёт SonarQube — ещё не аудит. Инструменты дают шум; аудитор интерпретирует и расставляет приоритеты.

4. Нет плана устранения. Находки без оценки трудозатрат и приоритетов — это претензии, а не задачи.

5. Доверие к собственной аттестации SOC 2 продавца. Иногда аттестации «рисуют». Проверяйте контроли независимо.

KPI, по которым измеряется ценность аудита

KPI качества. Количество critical-находок (задача аудита — найти их, а не обойти стороной). Доля ложных срабатываний (цель: <10 % находок отозваны после ревью инженерами).

Бизнес-KPI. Изменение цены сделки на основе аудита (в M&A): обычно 37–225 млн ₽ влияния на оценку. Сэкономленные расходы на устранение (при смене подрядчика): обычно 2–5× от стоимости аудита.

KPI надёжности. Завершение аудита в плановые сроки (цель: 100 %). Точность оценки трудозатрат через 6 месяцев (цель: ±15 %).

Когда аудит кода избыточен

Код до MVP / хакатонный код. Кодовая база и так одноразовая. Пропустите аудит; перепишете после product-market fit.

Продолжаете работать с тем же подрядчиком. Если команда вас устраивает и вы просто добавляете функции, аудит не нужен — кодовая база на её ответственности.

Свободный отбор перед сделкой. Если вы оцениваете 30 целей для поглощения, а закроется только 3, одностраничная сводка тревожных сигналов дешевле. Полный аудит — только на финальных кандидатах.

FAQ

Что почитать дальше

Готовы провести аудит кодовой базы, в которой пока не уверены?

Двухнедельный аудит кода стоит 1,5–3,7 млн ₽ и окупается в 2–5 раз за счёт пересмотра цены в M&A или экономии на устранении после смены подрядчика. Чек-лист из 12 разделов закрывает всё, что убивает проекты. Сочетайте выгрузку инструментов с экспертной оценкой; интервью с инженерами обязательно; результат — план устранения с оценкой трудозатрат, а не список претензий.

Пять тревожных сигналов всплывают в первые 2 дня любого аудита: пробелы в escrow-депонировании, зависимость от одного разработчика, PII в открытом виде, самописные проприетарные фреймворки, потребительские SaaS как критическая инфраструктура. Поймайте их раньше, чем они поймают вас.