Анализ безопасности кода: что проверить кроме SAST

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

Результатом должен быть не список срабатываний, а проверяемая картина:

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

Ручной анализ безопасности кода дополняет автоматические проверки: OWASP отдельно отмечает ↗, что экспертная проверка особенно важна для бизнес-логики, сложных механизмов доступа и контекстных уязвимостей.

Когда применять

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

Когда анализа кода недостаточно

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

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

Анализ нужен перед крупным релизом или передачей системы, после изменений аутентификации, авторизации и критической бизнес-логики, при включении унаследованного проекта в новый контур разработки и после инцидента.

До запуска инструментов нужно определить предмет анализа. Формулировки «проверить репозиторий» недостаточно: содержимое основной ветки меняется, разные сервисы могут выпускаться независимо, а часть конфигурации может жить вне кода.

Минимальные границы проверки включают:

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

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

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

Порядок анализа безопасности кода

1. Зафиксировать версию и границы. Указать хеш коммита или тег, компоненты, исключения и доступные контуры.
2. Выбрать методы. Согласовать SAST, поиск секретов, SCA и области ручного анализа.
3. Разобрать критические пути. Проверить доступ, данные, бизнес-правила, состояние, файлы, исходящие запросы и ошибки.
4. Подтвердить сигналы. Отделить достижимые проблемы от предположений и ложных срабатываний.
5. Описать исправление и приёмку. Назначить владельца, критерий проверки и повторный анализ на новой версии.

Что дают автоматические проверки

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

Статический анализ

SAST — статический анализ безопасности кода без выполнения приложения. Такие инструменты могут прослеживать движение данных: источник данных → преобразования → проверка или очистка → чувствительная операция.

Например, параметр HTTP-запроса проходит через сервисный слой и попадает в SQL-запрос. Срабатывание становится подтверждённым результатом только после ответов на несколько вопросов:

• контролирует ли атакующий исходное значение;
• достигает ли оно чувствительной операции;
• есть ли параметризация, проверка или кодирование;
• подходит ли защита для конкретного контекста;
• доступна ли эта ветка в поставляемой версии;
• какие права уже нужны для её вызова.

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

Для российского контура полезно сверять организацию SAST с ГОСТ Р 71207-2024 ↗: стандарт задаёт требования к порядку выполнения статического анализа, инструментам, методам и специалистам. Он помогает формализовать SAST, но не заменяет ручную проверку бизнес-логики.

Секреты и зависимости

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

Для зависимости недостаточно увидеть высокий CVSS. Нужно установить, какая версия реально поставляется, достижим ли уязвимый код и используется ли опасная функция. CVSS, EPSS и CISA KEV отвечают на разные вопросы: CVSS 4.0 ↗ описывает техническую тяжесть, EPSS ↗ оценивает вероятность эксплуатации опубликованной CVE, а CISA KEV ↗ показывает подтверждённую эксплуатацию. Эти сигналы дополняют контекст системы, а не заменяют его.

Что проверить вручную

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

Идентификация и управление доступом

Проверяется полный путь защищаемой операции: пользователь или сервис → действие → объект → контекст → решение о доступе.

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

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

Руководство OWASP по авторизации ↗ рекомендует по умолчанию запрещать доступ и проверять полномочия для каждого запроса. Конкретная система может использовать роли, атрибуты, отношения между объектами или комбинацию этих подходов, но решение должно приниматься на доверенной стороне.

Для воспроизводимой проверки доступа на уровне запросов используйте практику проверки авторизации API: она помогает собрать матрицу прав, проверить разрешённые и запрещённые операции и зафиксировать фактический результат.

Потоки данных и интерпретация ввода

Проблема появляется, когда данные начинают интерпретироваться как код, запрос, путь или команда. Поэтому анализ охватывает SQL и другие запросы к хранилищу, системные команды, HTML и JavaScript, шаблоны, файловые пути, URL исходящих запросов, сериализуемые объекты, журналы и сообщения очередей.

Проверяется не только наличие проверки входных данных, но и её соответствие месту использования. Кодирование для HTML не защищает SQL, а фильтрация символов не заменяет параметризованный API.

Бизнес-логика и состояние

Самые значимые дефекты часто выглядят как корректный код на уровне отдельной функции. Ошибка возникает из-за разрешённой последовательности действий.

Для критических процессов проверяют:

• допустимые и запрещённые переходы состояния;
• повтор запроса и идемпотентность — отсутствие повторного эффекта при повторной отправке;
• параллельное выполнение и гонки данных;
• изменение данных после согласования;
• обход лимита через несколько одновременных операций;
• частично выполненные транзакции и откат;
• обработку повторно доставленного события.

Файлы, исходящие запросы и внешние данные

Для загрузки файлов проверяют размер, фактический формат, имя и путь, обработку архивов, место хранения, права доступа и возможность исполнения. Расширение файла само по себе не является достаточной проверкой. Практические защитные меры собраны в руководстве OWASP по загрузке файлов ↗.

Для исходящих запросов важно убедиться, что пользовательский URL не позволяет обратиться к внутренней сети, служебным адресам облачной среды или неожиданным протоколам. Нужны ограничения адресов, перенаправлений, DNS-разрешения, размера ответа и времени выполнения. Отдельные сценарии описаны в руководстве OWASP по предотвращению SSRF ↗.

Криптография, ошибки и журналирование

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

Ошибки не должны раскрывать трассировку стека, SQL, токены или внутренние адреса. При этом чрезмерно общая обработка исключений может скрыть отказ защитного механизма. Для чувствительных операций нужно проверить, что события фиксируются, но секреты и персональные данные не попадают в журналы. Полезные границы даёт руководство OWASP по журналированию ↗.

Как дополнительную карту классов ошибок можно использовать БДУ АСУ ТП ФСТЭК России ↗: источник связывает типовые недостатки проверки ввода с соответствующими CWE. Полнота проверки всё равно определяется архитектурой и критическими операциями конкретной системы.

Пример: проверка доступа между организациями

Синтетический пример: API обрабатывает документы нескольких организаций. Каждый запрос содержит documentId, а пользователь аутентифицирован. Если серверная часть загружает документ только по этому идентификатору и не проверяет принадлежность текущей организации, изменение documentId может открыть чужой объект. SAST может не распознать дефект: вызов ORM безопасен, внедрение кода или запроса отсутствует, типы корректны. Ручной анализ обнаруживает нарушение свойства: пользователь должен видеть только объекты своей организации.

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

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

Качественное наблюдение отделяет факт от предположения. Для каждой проблемы нужно указать не только название класса уязвимости, но и путь, по которому она проявляется.

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

Как расставлять приоритеты

Критичность не следует определять только названием CWE или цифрой сканера. Реальный приоритет зависит от сочетания факторов:

• можно ли достичь уязвимой ветки;
• доступна ли она извне или только из внутреннего контура;
• какие права нужны атакующему;
• какие данные и бизнес-операции затронуты;
• есть ли компенсирующий контроль;
• насколько критичен актив;
• эксплуатируется ли связанная CVE в реальном мире.

CWE Top 25:2025 ↗ полезен как карта распространённых причин дефектов, а OWASP Top 10:2025 ↗ — как обзор основных рисков веб-приложений. Ни один из этих списков не заменяет требования конкретной системы. Для проверяемых требований можно использовать OWASP ASVS 5.0.0 ↗, выбрав применимые разделы и уровень глубины.

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

Если анализ является частью развития процесса безопасной разработки, результат можно сопоставить с открытым DevSecOps Assessment Framework ↗: он разделяет практики работы с кодом, зависимостями, требованиями и проверками.

Ошибки и риски проверки

• Один сканер вместо программы проверки. Не покрывает бизнес-логику, состояние и контекст доступа.
• Плавающая версия. Результат нельзя воспроизвести и принять, если неизвестен точный хеш коммита или артефакт.
• Приоритет только по CVSS. Теряется достижимость, ценность актива, права атакующего и компенсирующие меры.
• Проблема без доказательства. Команда не понимает путь ошибки и не может проверить исправление.
• Закрытие по факту слияния изменений. Изменение может не перекрыть соседние маршруты или создать обход.
• Скрытые ограничения. Недоступное окружение или компонент должны быть явно указаны в результате.

Результат анализа безопасности кода

Хорошо организованный анализ превращает технические сигналы в управляемый список работ. Руководитель видит не количество предупреждений, а затронутые операции, условия эксплуатации, приоритет и стоимость следующего решения. Команда разработки получает конкретный кодовый путь, критерий исправления и регрессионный тест.

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

Если задача шире безопасности отдельных путей и нужно оценить архитектуру, сопровождаемость, сборку и риски развития, полезно начать с материала «Что проверять в аудите кода и архитектуры». Для подготовки репозитория, схем и доступов пригодится памятка «Что подготовить к ИТ-аудиту».

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

Как принимать исправления

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

Повторная проверка должна подтвердить:

• исходный путь больше не работает;
• исправление действует для соседних ролей, объектов и альтернативных маршрутов API;
• не появился обход через другой маршрут;
• изменение не сломало допустимый сценарий;
• регрессионный тест защищает правило в следующих релизах.

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

Такой подход согласуется с NIST Secure Software Development Framework ↗: задача безопасной разработки состоит не только в поиске дефектов, но и в снижении их числа, уменьшении последствий и устранении причин повторения.

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

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