Чек-лист аудита кода ПО из 12 пунктов для основателей (2026)

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

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

Если вы — основатель, унаследовавший код от предыдущего подрядчика, участник сделки M&A, проводящий техническую проверку, или 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 для настройки собственных правил статического анализа. TruffleHog для поиска секретов в истории изменений. Burp Suite или OWASP ZAP для динамического тестирования. 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 страница). Три главных риска, три ключевых сильные стороны, итоговая оценка стоимости устранения, рекомендация: «покупать как есть», «покупать с удержанием на сумму X», «не покупать без устранения замечаний» или «отказаться».

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

План устранения (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-находки (дыры в безопасности, нарушения требований, единые точки отказа) ставьте в приоритет — на первые 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) самописный фреймворк для конструктора форм, в котором не разбирался никто, кроме трёх разработчиков из команды продавца (зависимость от узкой группы); (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 качества. Количество критических находок (задача аудита — найти их, а не игнорировать). Доля ложных срабатываний (цель: менее 10 % находок отзываются после проверки инженерами).

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

KPI надёжности. Аудит завершается в установленные сроки (цель — 100 %). Оценка трудозатрат через 6 месяцев отличается от реальной не более чем на ±15 %.

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

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

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

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

FAQ

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

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

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

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