Что проверяют при анализе безопасности кода: на что рецензент обращает внимание в диффе и почему

Проверка безопасности исходного кода — это целенаправленное чтение исходного кода с конкретной целью: найти способы заставить его делать то, что не входило в намерения автора. Это определение кажется очевидным, пока не сравнишь его с тем, что большинство команд на самом деле проводит, — а именно функциональную проверку с чек-листом безопасности под рукой. OWASP Secure Code Review Cheat Sheet проводит точную границу: проверка безопасности отличается от функциональной проверки тем, что нацелена на валидацию входных данных, аутентификацию, авторизацию, реализацию криптографии и векторы атак, а не на корректность. Патч, который работает идеально, всё равно может дать атакующему путь в систему, и только одна из этих двух проверок ищет его.

То, что делает тему достойной статьи сейчас, а не в 2020 году, — это способность языковой модели компетентно, дёшево и непрерывно читать дифф, что меняет экономику ревью, не меняя ни одного из измерений, по которым проводится ревью. Чек-лист старше моделей и остался неизменным. Изменилось лишь то, как часто вы можете позволить себе его прогонять.

Что рецензент на самом деле ищет при чтении

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

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

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

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

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

Бизнес-логика. Может ли последовательность быть переупорядочена, воспроизведена или управляться значениями, выбранными клиентом. Цена, количество, роль или переход состояния, которые приходят от клиента и не пересчитываются заново на стороне сервера, — это уязвимость, независимо от того, как они валидируются.

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

Проверка базовой версии против проверки диффа

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

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

Методы и что каждый из них выявляет

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

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

Что ИИ изменил, а что — нет

Исследования кода, написанного ИИ, обострили узкое место ревью, а не создали его. Исследование NYU предложений GitHub Copilot, опубликованное на IEEE S&P в 2022 году, показало, что примерно 40% сгенерированных фрагментов содержали эксплуатируемый паттерн в 18 категориях CWE. Работа Stanford о поведении разработчиков, опубликованная на ACM CCS в 2023 году, выявила более существенный эффект: разработчики, использующие ассистентов, были более уверены в безопасности своего кода, при этом создавая измеримо менее безопасный код. Больший объём вывода в сочетании с большей уверенностью — это проблема ревью.

Языковая модель в роли рецензента меняет одну переменную в этом уравнении — пропускную способность. Она может прочитать каждый pull request, по цене за токен, а не за место, и ей можно явно задать шесть вопросов выше. Она не меняет вопросы и не приобретает два свойства, которые делают рецензирование заслуживающим доверия: детерминизм и способность исполнять код. Один и тот же diff, проверенный дважды, может дать разные находки, серьёзность меняется между запусками, и рецензент не может доказать, что отмеченный путь достижим.

OrcaCode Review— это продуктизированная форма этой идеи, и на неё стоит посмотреть внимательно, потому что сделанные в дизайне выборы раскрывают режимы отказа. Ревью, которое выделяет сбойный случай как конкретное воспроизводимое замечание — «этот ключ всё ещё зависит от времени, поэтому повторная попытка списания создаёт новый ключ и может привести к двойному списанию; вот изменение в одну строку» — делает работу, которую делает ревьюер. Ревью, которое сообщает «потенциальная проблема безопасности» без воспроизведения, занимается анализом паттернов с точностью хуже, чем у сопоставителя паттернов. А движок правил и гейтов, опубликованный под открытой лицензией, делает неявное утверждение, которое стоит проверить: что суждение ревьюера тоже должно подлежать проверке.

Двухслойная схема, которая работает

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

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

Рассматриваем изменение, а не всю кодовую базу

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

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

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