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

Аудит безопасности кода — статический анализ: исходники изучаются без запуска программного обеспечения. Это отличает его от пентеста, где система атакуется в рабочем состоянии. Оба метода дополняют друг друга — статический аудит находит то, что не проявляется в динамическом тестировании, и наоборот.

Code review как часть аудита — это не просто проверка стиля. Это поиск архитектурных проблем, потенциальных точек отказа, нарушений принципов безопасной разработки. Внешний аудит кода особенно ценен, когда внутренняя команда слишком погружена в контекст, чтобы увидеть системные проблемы.

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

Процесс аудита кода состоит из двух этапов. Первый — автоматический статический анализ с помощью SAST-инструментов (Semgrep, SonarQube, Bandit и аналоги в зависимости от стека). Они быстро находят типовые паттерны уязвимостей и проблем качества. Второй этап — ручной code review: специалист проверяет результаты автоматического анализа, убирает ложные срабатывания и исследует бизнес-логику, которую автоматика не видит.

Аудит безопасности кода особенно важен для программного обеспечения, которое обрабатывает пользовательские данные или работает с внешними интеграциями. Точки входа пользовательских данных — формы, API, файловые загрузки — проверяются на все типы инъекций: SQL, NoSQL, OS command, LDAP, XML, шаблонные движки.

Отдельное направление — аудит зависимостей. Современные программные проекты содержат сотни сторонних библиотек. Каждая из них потенциально несет уязвимости. База CVE регулярно пополняется — библиотека, которая была безопасной три месяца назад, может оказаться уязвимой сегодня. Проверяем все зависимости по актуальным базам уязвимостей.

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

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