Аудит кода в 2026: что это, как провести и по каким критериям оценивать

Обновлено в ноябре 2026: статья переписана целиком — восемь шагов аудита, проверка по OWASP Top 10:2025, российские требования (ГОСТ Р 56939-2024, ГОСТ Р 71207-2024, штрафы по 152-ФЗ), уровни критичности, сроки и пять схем.

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

Ниже — как мы проводим аудит для клиентов: по каким семи критериям оцениваем код, из каких восьми шагов состоит проверка, какие инструменты работают в России в 2026 году, как сортируем находки по критичности и что получает заказчик на выходе. Если хотите провести аудит своими силами, этот разбор тоже пригодится: критерии и порядок работы одни и те же.

Почему этот разбор пишет Фора Софт

Мы разрабатываем видеоплатформы, видеосвязь и продукты с ИИ с 2005 года: сдали больше 250 проектов, в команде около 50 инженеров. Чужой код мы читаем постоянно: когда берём проект на поддержку после другого подрядчика, когда заказчик хочет второе мнение перед сделкой или раундом, когда продукт после быстрого прототипа нужно довести до реальных пользователей.

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

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

Что такое аудит кода

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

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

По отчёту CISQ 2022 года, низкое качество ПО обходится экономике США в 2,41 трлн долларов в год, из них около 1,52 трлн — накопленный технический долг. Аудит показывает, какая часть этого счёта спрятана в вашем репозитории.

Виды аудита кода: качество, безопасность, соответствие требованиям

Виды аудита различаются вопросом, на который отвечают, а не инструментами. Аудит качества проверяет, может ли команда безопасно менять код дальше. Аудит безопасности ищет то, что можно взломать. Аудит на соответствие сопоставляет код с требованиями стандартов и регуляторов. На практике обычно сочетают два-три вида, и в задании на аудит это прописывают заранее.

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

Аудит кода, код-ревью и пентест: в чём разница

Код-ревью — постоянная внутренняя практика: разработчики читают пул-реквесты друг друга. Аудит кода — разовая независимая проверка всей кодовой базы с итоговым отчётом. Пентест атакует работающую систему снаружи и исходный код не читает. Их часто путают, и в итоге покупают не то. Ревью нужно всегда, аудит — на важных этапах, пентест — когда продаёте крупным компаниям или проходите проверку безопасности у заказчика.

Своё ревью и внешний аудит тоже не заменяют друг друга. Команда не может объективно оценить архитектуру, которую сама выбрала, а инвестор или покупатель не примет самооценку так же, как внешнее заключение. Внешний аудит нужен, когда отчёт будет читать человек не из вашей компании. Для всего остального дешевле развивать культуру ревью и автоматические проверки качества в CI.

Когда заказывать аудит кода

Аудит окупается в семи ситуациях. Общее у них одно: кто-то собирается принять дорогое и трудно отменяемое решение о коде, который плохо знает.

1. Перед покупкой компании. Кодовая база — главный актив. Аудит оценивает технический риск до того, как он станет вашей проблемой.
2. Перед раундом на унаследованном коде. Продукт писала прежняя команда, а инвесторы всё чаще просят независимое заключение.
3. Когда багов всё больше. Каждый релиз что-то ломает, скорость падает, причину никто не называет. Обычно она в структуре кода; подробнее — в статье «Что делать, если в проекте слишком много багов».
4. При смене команды. Разработчики уходят или вы забираете проект к себе. Нужен объективный срез, пока знания не ушли вместе с людьми.
5. Перед масштабированием. Продукт работает на тысяче пользователей, а впереди клиент на сто тысяч. Аудит находит то, что не выдержит нагрузку.
6. После инцидента. Утечка, потеря данных, долгий простой: нужна причина и план защиты, а не одна заплатка.
7. Когда большую часть кода написал ИИ. Прототип собран в Lovable, Bolt, v0 или Cursor, а на него уже опираются реальные пользователи. Этому случаю ниже посвящён отдельный раздел.

Семь критериев оценки кода

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

Рисунок 1. Пример оценочной карты. Каждый критерий оценивается отдельно, поэтому аккуратный код не скроет слабый фундамент.

Форматирование и стиль

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

Современные стандарты

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

Поддерживаемость

Оцениваем, насколько легко код менять. Главная метрика — цикломатическая сложность: её предложил Томас Маккейб в 1976 году, она считает число независимых путей через функцию. Функции с высокой сложностью ломаются, как только их трогают. Но одной цифрой не ограничиваемся: высокая сложность в стабильном и хорошо покрытом тестами платёжном модуле — меньший риск, чем та же сложность в коде, который меняется каждую неделю. Ещё смотрим дублирование, размер классов и функций и покрытие тестами.

Архитектура

Смотрим, как проект разбит на модули, насколько они связаны и можно ли их настраивать. Хорошая архитектура модульная, а связи между модулями слабые. Запутанная архитектура дорожает с каждым релизом: любое изменение требует правок в нескольких местах, а исправление ошибок затягивается. Если вопрос именно в том, выдержит ли система рост, поможет отдельная независимая ревизия архитектуры: технологии, структура данных, масштабируемость и надёжность.

Документация

Проверяем, есть ли документация, насколько она актуальна и полезна. Минимум — README с описанием проекта, установки и запуска, документация API и схемы сложных модулей. Без документации знания живут в головах нескольких людей, и уход любого из них превращается в риск для проекта.

Безопасность

Ищем уязвимости в коде: как обрабатываются пользовательские данные и нет ли SQL-инъекций и XSS, как устроены аутентификация и авторизация, как хранятся пароли, есть ли защита от перебора, шифруются ли персональные данные при хранении и передаче. Подробно о том, по какому списку мы проверяем безопасность в 2026 году, — в разделе про OWASP ниже.

Эффективность

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

Как провести аудит кода: восемь шагов

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

Рисунок 2. Восемь шагов аудита. Автоматическая проверка идёт первой, чтобы старшие инженеры тратили время на архитектуру, а не на стиль.

1. Границы и задание на аудит (1–2 дня). Какие языки и сервисы смотрим, какие риски важнее всего, что считаем результатом и кто будет читать отчёт.
2. Подключение к репозиторию (полдня). Клонируем, собираем, запускаем тесты и фиксируем хеш коммита, чтобы каждая находка указывала на код, который видят обе стороны.
3. Автоматическая проверка (1–3 дня). Статический анализ, проверка зависимостей, поиск секретов и сканирование контейнеров. Каждую находку сканера проверяет человек: сканеры ошибаются, а отчёт с ложными срабатываниями хуже, чем никакой.
4. Ревью архитектуры (3–7 дней). Старший инженер читает код по пользовательским сценариям, рисует потоки данных и проверяет границы, которые сканеры не видят. Самые дорогие находки появляются здесь.
5. Углублённая проверка безопасности (1–3 дня). Модель угроз, ручная проверка аутентификации, прав доступа и шифрования, CVE в зависимостях, секреты в истории git.
6. Проверка производительности (1–2 дня). Профилирование на реалистичной нагрузке, разбор планов запросов и три главных источника задержек или расходов — с цифрами.
7. Отчёт (2–3 дня). Находки, критичность, шаги воспроизведения, рекомендации, оценочная карта и резюме на одну страницу для руководителя.
8. Созвон с разбором (1 час). Показываем отчёт вживую, проходим главные находки и отвечаем на вопросы. Запись передаём вместе с отчётом.

Инструменты аудита кода в 2026 году

Ни один инструмент не проводит аудит сам. Настоящий аудит складывается из слоёв: статический анализ, проверка зависимостей, поиск секретов и динамическое тестирование, а над ними — старший инженер, который читает и вывод инструментов, и сам код. Автоматика быстро и дёшево делает первый проход. Человек находит то, что поиск по шаблонам не видит в принципе: ошибки архитектуры и бизнес-логики, которые понятны, только если знать, что продукт должен делать.

Рисунок 3. Слои инструментов. Каждый автоматический слой ловит свой класс проблем, ревью инженера стоит над всеми.

Snyk прекратил работу в России и Беларуси в марте 2022 года, поэтому для проверки зависимостей чаще используют открытые Trivy и OWASP Dependency-Check. Среди российских статических анализаторов — PVS-Studio, Svace (ИСП РАН), PT Application Inspector и Solar appScreener. Если продукт проходит сертификацию или идёт к госзаказчику, анализатор выбирают с оглядкой на ГОСТ Р 71207-2024 — о нём ниже.

SonarQube остаётся рабочей лошадкой для качества и безопасности с порогом качества, который можно встроить в CI. В версии SonarQube Server 2026.4 появился отдельный порог «Sonar way for Agentic AI»: он строже к безопасности и к выдуманным или подменённым зависимостям, которые подтягивают ИИ-ассистенты. На GitHub прежний пакет Advanced Security с апреля 2025 года продаётся двумя продуктами: Secret Protection за 19 долларов и Code Security за 30 долларов за активного коммитера в месяц.

Меняется и сама практика. Проверки с помощью ИИ-агентов стали готовым продуктом: в августе 2025 года Anthropic добавила в Claude Code команду /security-review и GitHub Action, а OpenAI в марте 2026 года выпустила Codex Security в статусе исследовательской версии. Такие агенты находят настоящие ошибки, но и ложных срабатываний дают много: человек всё равно должен их отсортировать и воспроизвести. Как ИИ встраивают в проверки на ранних этапах разработки, мы разобрали в статье «Как ИИ делает код безопаснее: подход Shift-Left».

Безопасность: проверка по OWASP Top 10:2025

Безопасность — самая ценная часть аудита и самая устаревшая во многих руководствах. В ноябре 2025 года OWASP выпустил Top 10:2025 — первое обновление списка с 2021 года, и чек-лист изменился. Если аудит в 2026 году всё ещё проверяет код по списку 2021 года, он ищет угрозы прошлого десятилетия. Вот актуальный список, по которому мы оцениваем код:

A03 выводит аудит за пределы вашего кода — в зависимости и конвейер сборки: перечень компонентов ПО, секреты в CI, пакеты, которые вы не выбирали, но унаследовали. A10 нацелена на обработку исключений, которая выглядит нормально, пока продакшен не пришлёт что-то неожиданное. Каждую находку мы привязываем к категории OWASP, а эксплуатируемые — ещё и оцениваем по CVSS v4.0, чтобы критичность была не нашим мнением, а шкалой, которой пользуется любая команда безопасности.

Рисунок 4. Как находке присваивается критичность. Первое «да» задаёт уровень, уровень задаёт срок исправления.

Требования в России: ГОСТ Р 56939-2024, ГОСТ Р 71207-2024 и 152-ФЗ

Для российского продукта аудит безопасности — это ещё и подготовка к требованиям регуляторов и крупных заказчиков. Три документа встречаются чаще всего.

Если продукт работает в государственной информационной системе, учитывайте и приказ ФСТЭК России №117 о защите информации в ГИС: он действует с 1 марта 2026 года и заменил приказ №17. Мы не подменяем аттестацию и сертификацию — это работа лицензированных организаций. Но аудит заранее находит то, на чём проект споткнётся при такой проверке: секреты в коде, незашифрованные персональные данные, уязвимые зависимости, отсутствие регулярного статического анализа.

Как мы присваиваем находкам критичность

Находка без уровня критичности — это шум. Каждая проблема в отчёте получает один из пяти уровней и срок исправления, поэтому команда знает, что чинить на этой неделе, а что подождёт квартал. Каждую находку прогоняем по одной и той же цепочке вопросов и берём первое «да». Так оценка не зависит от того, кто из аудиторов её писал.

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

Что вы получаете по итогам аудита

По итогам аудита вы получаете шесть материалов, и пользоваться ими можно ещё долго после проверки:

1. Резюме для руководителя. Одна страница: вердикт, главные риски, ключевая цифра. Для директора или покупателя, у которого пять минут.
2. Оценочная карта. Семь критериев с баллами от 1 до 5 и одним предложением-доказательством к каждому. По ней удобно сравнивать результаты повторных аудитов.
3. Реестр находок. Каждая проблема с критичностью, местом в коде, доказательством, шагами воспроизведения и рекомендацией. С этим документом работают инженеры.
4. План исправлений. Находки, отсортированные по критичности и трудоёмкости, чтобы ответ на вопрос «что чиним первым» был готов к концу созвона.
5. Приложение с доказательствами. Вывод инструментов, отчёты по зависимостям и хеш проверенного коммита — то, что выдерживает проверку покупателя.
6. Запись разбора. Чтобы те, кто не был на созвоне, получили логику выводов, а не только документ.

Сколько длится и сколько стоит аудит кода

Срок и цена зависят от объёма кода и глубины проверки, поэтому честный ответ до знакомства с репозиторием — диапазон. Экспресс-аудит мы проводим бесплатно за 3 рабочих дня: он показывает главные риски и даёт находки с готовыми исправлениями. Полный аудит по восьми шагам занимает от полутора до шести недель.

Рисунок 5. Сроки аудита в рабочих днях. Чем больше сервисов и строк кода, тем дольше ревью архитектуры и безопасности.

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

Аудит кода, написанного ИИ: Cursor, Lovable, Bolt

У прототипов, собранных в Lovable, Bolt, v0, Cursor или Cline, узнаваемый почерк. Снаружи — аккуратные React-компоненты, внутри — ключи API прямо в коде, хрупкая обработка ошибок, ни одного теста и проверка прав, которая выглядит правильной, но разваливается за пять минут ревью. Такие проекты мы видим каждую неделю, и ошибки в них повторяются настолько, что для них есть отдельный чек-лист.

Что проверяем первым делом: проверяются ли права на сервере или только скрыты в интерфейсе; нет ли секретов в клиентском бандле или в истории git; не притащил ли генератор зависимости с известными CVE; есть ли хотя бы один тест. Это прямо ложится на новую категорию OWASP A03 и на A01: генераторы отлично пишут правдоподобный код и плохо понимают, что не должно покидать сервер. Независимые данные это подтверждают: по отчёту Veracode о безопасности кода от генеративного ИИ (июль 2025 года), 45 % образцов кода от более чем 100 языковых моделей содержали уязвимость из OWASP Top 10, а от XSS модели не защитились в 86 % случаев.

Если аудит показывает, что прототипу нужна серьёзная доработка, наша команда по доработке и оптимизации ПО переносит проверку прав на сервер, убирает секреты из бандла и закрывает тестами сценарии с деньгами. Типичные ошибки таких приложений и цену их исправления мы разобрали в статье «Баги в Lovable-приложениях в 2026 году».

Пример из практики: аудит перед сделкой за 12 рабочих дней

Аудиты конфиденциальны, поэтому детали обезличены, а цифры округлены, но сама история типичная. Ситуация. Покупатель из США готовился подписать соглашение о намерениях на покупку SaaS-компании после раунда A. У компании была небольшая команда и три года кода, и покупатель хотел независимое заключение до сделки.

План на 12 дней. Дни 1–2 — границы проверки и подключение к репозиторию. Дни 3–5 — автоматическая проверка: статический анализ, зависимости, секреты. Дни 6–9 — ревью архитектуры четырёх основных сервисов. Дни 10–11 — отчёт. День 12 — созвон с разбором. Один аудитор, один специалист по безопасности, один зафиксированный коммит.

Результат. Три блокера: ключи от продакшена открытым текстом в истории git, сломанная изоляция клиентов в сервисе аналитики и ни разу не проверенное восстановление из резервной копии. Семь критичных находок, включая риск инъекции и слабую проверку токенов, и 22 находки уровня Major. Покупатель снизил цену на стоимость исправлений, добавил в договор гарантию по блокерам и закрыл сделку через две недели, понимая, что покупает. Стоимость аудита оказалась ничтожной по сравнению с тем, во что блокеры обошлись бы после сделки.

Пять вопросов перед заказом аудита

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

1. Кто будет читать отчёт? Директору нужно резюме, совету директоров — оценочная карта, аудитору по безопасности — находки с привязкой к требованиям стандартов. Отчёт собираем под читателя.
2. Что стало поводом? Покупка компании — широкий охват, упор на безопасность и права на код. Раунд A — архитектура и масштабируемость. После инцидента — сначала причина и защита.
3. Какой объём кода? До 30 тыс. строк — один аудитор и около полутора недель. От 30 до 200 тыс. — два аудитора и три недели. Больше 200 тыс. — группа и четыре-шесть недель.
4. Нужен ли ещё пентест? Если продаёте крупным компаниям или проходите проверку безопасности у заказчика — да, вместе с аудитом. В остальных случаях аудит закрывает большую часть рисков дешевле.
5. Может ли результат сорвать сделку? Обсудите это честно в первый же день. Аудитор, который подгоняет отчёт под «зелёный» результат, бесполезен уже через год: вы платите за честный вывод.

Пять ошибок, которые мы видим каждый квартал

1. Аудит только инструментами. Выгрузка из SonarQube — ещё не аудит. Без оценки старшего инженера пропускаются все архитектурные проблемы: сканер не знает, что должен делать ваш продукт.
2. Находки, которые нельзя воспроизвести. У каждой находки должны быть файл, строка, доказательство и путь исправления. Формулировка «в целом небезопасно» никому не помогает и подрывает доверие ко всему отчёту.
3. Оценка команды вместо кода. Аудитор, который принял версию событий текущей команды, перестаёт видеть ясно. Он должен прийти к коду без предубеждений.
4. Нет резюме для руководителя. Тот, кто принимает решение, читает по диагонали. Если первая страница не даёт вердикт простыми словами, остальные пятьдесят никто не прочтёт.
5. Аудит как разовая акция. Код меняется. Полный аудит — раз в год, облегчённый — раз в квартал, и отслеживайте исправления между циклами. Находка, которая вернулась через квартал, — проблема процесса, а не кода.

Какие метрики отслеживать после аудита

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

• Закрытие находок. Доля блокеров и критичных находок, закрытых в срок, процент Major, закрытых за квартал, и среднее время закрытия по каждому уровню.
• Качество кода. Динамика порога качества в SonarQube, число открытых CVE в зависимостях, покрытие тестами рискованных сценариев и задержка P95 на горячих участках.
• Поставка. Метрики DORA: частота релизов, время от изменения до продакшена, доля неудачных изменений, время восстановления и пятая метрика — доля незапланированных релизов-исправлений после инцидентов. У лучших команд в отчёте DORA 2024 года доля неудачных изменений не выше 5 %, а восстановление занимает меньше часа.

Если после аудита код придётся долго и системно поддерживать, пригодится разбор «Что делать, если в проекте много устаревшего кода»: там о том, когда рефакторить, когда переписывать и когда заменять.

Когда аудит кода не нужен

Есть три ситуации, когда деньги на аудит лучше не тратить, и мы скажем об этом, а не возьмём заказ. Первая — рабочий прототип меньше 5 тыс. строк, который команда меняет каждую неделю: через квартал код будет совсем другим, и вы проверите черновик. Вторая — стабильный продукт с сильной культурой ревью и свежим отчётом о проверке безопасности: доказательства, которые дал бы аудит, у вас уже есть. Третья — руководство не готово выделить деньги на исправления: аудит, по которому никто не будет действовать, превращается в список претензий и бьёт по мотивации команды.

В первом случае продолжайте выпускать версии и вкладывайтесь в ревью и тесты; о том, как поддерживать качество без отдельного аудита, — в статье «Что такое рефакторинг кода и когда он нужен».

Частые вопросы об аудите кода

Что такое аудит кода простыми словами?

Это независимая проверка кода, после которой вы получаете отчёт: насколько код надёжен, безопасен и понятен, где главные риски и что исправить первым. Аудитор не переписывает код, а оценивает его и даёт план.

Сколько длится аудит кода?

Экспресс-аудит — 3 рабочих дня. Полный аудит MVP занимает 1–1,5 недели, среднего SaaS — 2–3 недели, крупной платформы с десятком сервисов — 4–6 недель.

Сколько стоит аудит кода?

Экспресс-аудит за 3 рабочих дня мы проводим бесплатно. Стоимость полного аудита зависит от объёма кода, числа сервисов и глубины проверки безопасности, поэтому называем её после того, как посмотрим репозиторий.

Чем аудит кода отличается от код-ревью?

Код-ревью — постоянная внутренняя практика: команда проверяет каждый пул-реквест. Аудит — разовая независимая проверка всего кода с письменным отчётом и находками по уровням критичности. Нужны оба, но с разной частотой.

Аудит кода и пентест — это одно и то же?

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

По каким критериям оценивают код при аудите?

Мы используем семь критериев: форматирование и стиль, современные стандарты, поддерживаемость, архитектура, документация, безопасность и эффективность. Каждый оцениваем от 1 до 5 баллов с доказательствами.

Какие инструменты используют для аудита кода?

Статический анализ (SonarQube, Semgrep, PVS-Studio, CodeQL), проверку зависимостей (Trivy, Dependabot, OWASP Dependency-Check), поиск секретов (gitleaks, TruffleHog) и динамическое тестирование (OWASP ZAP, Burp Suite). Над ними — ревью старшего инженера: без него это не аудит.

Нужно ли давать полный доступ к репозиторию?

Достаточно доступа только на чтение к зафиксированной ветке. Мы подписываем NDA, работаем в изолированной среде и не храним ваш код после аудита.

Можно ли проверить код, написанный в Cursor или Lovable?

Да, такие проекты мы проверяем каждую неделю. Ошибки в них предсказуемы: права проверяются только в интерфейсе, ключи открыты, зависимости с CVE, тестов нет. Чек-лист настроен под них.

Исправляете ли вы то, что нашли?

Можем, отдельным проектом, или передадим отчёт вашей команде. Чтобы аудит оставался независимым, исправления делает другая команда Фора Софт, а не те, кто проводил проверку.

Нужен независимый взгляд на код?

Аудит кода отвечает на один вопрос и подкрепляет ответ доказательствами: можно ли этот код выпускать, покупать или масштабировать. Заказывайте его перед сделкой, раундом, сменой команды или миграцией и после серьёзного инцидента. Оценивайте семь критериев по отдельности, чтобы аккуратный код не скрыл слабую архитектуру. Проверяйте безопасность по OWASP Top 10:2025, а для российского продукта — с учётом ГОСТ Р 56939-2024, ГОСТ Р 71207-2024 и штрафов по 152-ФЗ. Сочетайте инструменты с опытом старших инженеров и требуйте отчёт, который руководитель прочтёт за пять минут, а инженер начнёт исправлять в первый же день.

Мы проводим аудиты перед сделками и раундами, проверяем код, написанный ИИ, и разбираем причины инцидентов, а если аудит не нужен, так и говорим.

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