Сканирование безопасности ИИ-кода требует нового барьера

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

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

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

Сгенерированный код меняет объем, вариативность и доверие

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

Из-за объема эта вариативность обходится дорого. Разработчик, который медленно пишет один обработчик, может заметить, что проверка авторизации выполняется после чтения из базы. Агент способен повторить такой порядок во всех созданных обработчиках еще до открытия pull request. Затем проверяющие видят аккуратное и единообразное изменение, а единообразие создает ложную уверенность.

В сгенерированных изменениях постоянно встречаются четыре вида сбоев:

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

Традиционный SAST уже умеет работать с частью этой проблемы. В рекомендациях OWASP Source Code Analysis Tools сказано, что статический анализ хорошо масштабируется, запускается многократно и способен находить такие дефекты, как SQL-инъекции. Там же прямо перечислены слабые стороны: ложные срабатывания, слепые зоны в конфигурации, ограничения вокруг контроля доступа и проекты, которые невозможно собрать. Сгенерированный код усиливает эти слабости, а не устраняет их.

Метки авторства не решают проблему доверия. Один коммит может смешивать результат агента, сгенерированные миграции, скопированные фрагменты и правки человека. Метаданные также исчезают после rebase и squash. Применяйте строгую политику нового кода к каждому изменению. Если вы надежно помечаете pull request, созданные агентами, используйте метку для измерений, но никогда не делайте ее единственным условием запуска анализа безопасности.

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

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

SAST и проверка с помощью LLM отвечают на разные вопросы

Сканер следует воспроизводимым правилам и моделям потока данных, а проверка с помощью LLM трактует намерение и окружающую архитектуру. Нужны оба подхода, но только один из них должен принимать детерминированные решения о слиянии.

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

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

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

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

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

Полезное сравнение начинается с глубины анализа

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

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

1. GitHub CodeQL подходит для глубокого анализа поддерживаемых языков в командах, работающих в GitHub. Он строит базу из кода, выполняет запросы и публикует предупреждения сканирования. Для компилируемых языков может потребоваться рабочая сборка, а для неподдерживаемых языков нужен другой сканер.
2. Semgrep подходит для быстрых проверок pull request и локальных правил политики. Структурные шаблоны и правила анализа помеченных данных легко хранить рядом с кодом, а semgrep ci умеет проверять изменения. Глубина анализа в открытом и коммерческом движках отличается, особенно когда данные переходят между файлами.
3. Snyk Code подходит для управляемого процесса в IDE, репозитории, CLI и CI. Проверки pull request и snyk code test помещают находки прямо в рабочий процесс разработки. Отдельно оцените требования к учетной записи, интеграцию репозитория, обработку данных и ограничения тарифа.
4. SonarQube подходит для единой политики качества, сопровождаемости, надежности и безопасности. Анализ pull request применяет барьер качества к новому коду и может передавать статус в репозиторий. Убедитесь, что глубина проверки безопасности, функции редакции, эксплуатация сервера и работа с новым кодом соответствуют вашей модели управления.

CodeQL я рассматриваю первым, когда важен глубокий анализ потока данных, а код хранится в GitHub. Документация GitHub описывает два этапа: создать базу, представляющую код, затем выполнять к ней запросы. Поддерживаются C и C++, C#, Go, Java и Kotlin, JavaScript и TypeScript, Python, Ruby, Rust, Swift и рабочие процессы GitHub Actions. Для компилируемых языков проверяйте журналы извлечения. Зеленый процесс, который собрал один маленький подпроект, не проанализировал весь репозиторий, хотя вам могло показаться обратное.

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

Snyk Code подходит командам, которым нужен управляемый путь через IDE, систему управления исходным кодом, CLI и CI. Контракт CLI полезен для автоматизации: snyk code test возвращает 0, когда проверка завершилась без находок, 1, когда находки требуют действий, 2 при сбое сканирования и 3, когда поддерживаемые проекты не обнаружены. Считайте коды 2 и 3 ошибками конвейера. Иначе сломанный сканер будет выглядеть как чистый код.

SonarQube подходит организациям, которые хотят включить находки безопасности в общий барьер качества нового кода. В документации по pull request сказано, что анализ PR сообщает о проблемах, внесенных изменением, тогда как анализ основной ветки может найти то, что не видно в PR. Поэтому полный анализ основной ветки нужно запускать по расписанию, а не пытаться скрыть этот нюанс более строгим порогом PR.

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

Три линии сканирования сохраняют скорость и честное покрытие

Запускайте быструю проверку изменений на каждом pull request, более глубокий анализ перед слиянием или в очереди слияния и полное сканирование основной ветки по расписанию. Эти линии решают разные задачи по времени, поэтому объединение в одно задание либо замедлит каждое изменение, либо оставит слепые зоны.

Линия pull request должна завершаться достаточно быстро, чтобы разработчики ее ждали. Там, где продукт это умеет, проверяйте только изменения, добавьте поиск секретов и небольшой набор собственных правил с высокой точностью. Блокируйте новые находки, соответствующие вашей политике серьезности и уверенности. Не отклоняйте новый pull request из-за 900 унаследованных предупреждений в нетронутых файлах: так разработчики быстро решат, что барьер не связан с их работой.

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

Один процесс GitHub Actions может разделить быструю обратную связь Semgrep и более глубокое задание CodeQL:

name: code-security

on:
  pull_request:
  push:
    branches: [main]
  schedule:
    - cron: "17 3 * * 2"

permissions:
  contents: read
  security-events: write

jobs:
  semgrep:
    runs-on: ubuntu-latest
    container: semgrep/semgrep
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - run: semgrep ci

  codeql:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        language: [javascript-typescript, python]
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: ${{ matrix.language }}
      - uses: github/codeql-action/analyze@v3

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

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

Базовая линия сдерживает долг, не разрешая новые дефекты

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

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

Одной серьезности для политики мало. «Средняя» инъекция команды в обработчике, доступном из интернета, может требовать немедленной блокировки, а «высокая» находка в неиспользуемом примере может требовать удаления вместо экстренной реакции. Учитывайте достижимость, доступность извне, уверенность и роль ресурса. Политика должна быть достаточно короткой, чтобы разработчик мог предсказать результат до отправки изменений.

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

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

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

Собственные правила превращают инциденты в постоянные проверки

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

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

Это правило Semgrep показывает узкий запрет на прямую передачу значения HTTP-запроса в запуск команды Node.js:

rules:
  - id: request-data-to-child-process
    message: Request data reaches a shell command. Use an argument array and validate each value.
    severity: ERROR
    languages: [javascript, typescript]
    mode: taint
    pattern-sources:
      - pattern: $REQ.$FIELD
    pattern-sinks:
      - pattern-either:
          - pattern: child_process.exec(...)
          - pattern: child_process.execSync(...)

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

Храните собственные правила и тесты рядом с приложением или в версионируемом центральном репозитории политик. Закрепите ревизию политики в CI. Назначьте владельца, который понимает и уязвимость, и механизм сопоставления. Иначе правила превратятся в непонятные падения сборки, которые разработчики научатся обходить.

Возвращайте подтвержденные находки проверки в эту библиотеку. Если LLM дважды замечает отсутствующую обертку авторизации, не добавляйте в запрос длинное напоминание на следующий раз. Закрепите инвариант в правиле, абстракции фреймворка или тесте, который конвейер применит к каждому коммиту.

Опаснее всего зеленое сканирование с неполным покрытием

Зеленый результат доказывает лишь то, что настроенный сканер выполнил настроенную работу. Он не доказывает, что сканер изучил код, который вы развертываете.

Представьте монорепозиторий с API на TypeScript и платежным сервисом на Java. Команда включает CodeQL, соглашается с автоматическим определением языков и видит успешные проверки. Java-сервис использует особую команду сборки, зависящую от шага генерации исходников. Автосборка пропускает этот модуль, но процесс все равно анализирует TypeScript и загружает результаты. Позже сгенерированная конечная точка Java соединяет управляемое пользователем поле отчета со строкой запроса. Pull request остается зеленым, потому что уязвимый сервис не попал в базу анализа.

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

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

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

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

Инструмент выбирают инженерным испытанием, а не голосованием за функции

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

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

Придайте больший вес владению политикой. Semgrep часто выигрывает, когда небольшой команде нужно быстро писать точные локальные проверки. CodeQL часто выигрывает, когда поддерживаемые языки, интеграция с GitHub и более глубокий запрашиваемый поток данных важнее простоты написания правил. Snyk Code оправдывает место, когда управляемый процесс для разработчиков и более широкая программа безопасности снижают рабочую нагрузку. SonarQube подходит, когда единая принудительная политика нового кода в качестве и безопасности уже соответствует работе организации.

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

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

Во время Team & AI Audit в oleg.is я привязываю этот барьер к реальному процессу генерации и узким местам поставки команды, потому что выбор сканера без данных о процессе остается догадкой. Та же проверка должна назвать владельца политики, ожидаемую реакцию на заблокированное слияние и порядок работы с просроченными исключениями.

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

Сгенерированный код безопасен лишь при независимом барьере

Полезное переосмысление SAST касается организации, а не косметики. Генерация кода сокращает время реализации, поэтому обратная связь по безопасности должна попасть в тот же pull request и оставаться независимой от системы, которая написала код.

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

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

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

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