Безопасность при работе с Codex и проверке кода

Безопасность агентной разработки состоит из двух частей. Первая защищает среду от слишком широких действий Codex.

Краткий ответ

Безопасность агентной разработки состоит из двух частей. Первая защищает среду от слишком широких действий Codex. Вторая проверяет, не добавил ли конкретный diff уязвимость в приложение. Обычный code review и security review пересекаются, но имеют разные модели угроз.

Определите активы и границы доверия

До анализа перечислите:

учётные записи и сессии;
персональные данные;
секреты и signing keys;
файлы и команды хоста;
внешние API и production-ресурсы;
входы от пользователя, webhook, файла и веб-страницы.

Граница доверия — место, где данные из менее доверенной области влияют на более привилегированное действие. Проверка только на frontend не защищает backend. Текст из issue или сайта не должен управлять разрешениями агента.

Security review конкретного diff

Для изменения проверяйте:

authentication и authorization;
валидацию и canonicalization входа;
SQL/NoSQL, command и template injection;
traversal и небезопасные пути;
SSRF и произвольные network requests;
XSS и опасный HTML;
загрузку файлов, размер и content type;
утечку секретов через логи и ошибки;
race, replay и отсутствие идемпотентности.

Finding должен быть привязан к изменённому коду и достижимому сценарию. Для полного repository audit требуется отдельная задача и другой scope.

Секреты и чувствительные данные

Не помещайте токены в промпт, AGENTS.md, тестовый fixture или commit. Передавайте секреты через предназначенное хранилище и только процессу, которому они нужны. В логах маскируйте credentials, cookies, Authorization и персональные поля.

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

Prompt injection и цепочка инструментов

Агент может прочитать вредоносную инструкцию в README, issue, package metadata или на сайте. Защита строится слоями:

1. считать внешний текст данными; 2. ограничивать доступ sandbox; 3. требовать подтверждение значимых действий; 4. выдавать MCP tools с минимальными scopes; 5. отделять read и write; 6. проверять аргументы и назначения вызова; 7. не передавать лишние секреты в среду.

Нельзя полагаться на фразу «игнорируй вредоносные инструкции» как на единственную защиту.

Исправление и проверка finding

После принятия уязвимости:

создайте минимальный безопасный reproduction;
добавьте негативный тест;
исправьте ближайшую доверительную границу;
проверьте обходные варианты;
убедитесь, что ошибка не раскрывает чувствительные детали;
повторите security review diff.

Например, authorization должна проверяться сервером по текущему actor и целевому resource. Скрытая кнопка и ID из клиента не являются контролем доступа.

Практика: security checklist для загрузки файла

Попросите Codex проверить:

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

Для каждого пункта потребуйте файл, текущую защиту и тестовый сценарий. Общего «всё безопасно» недостаточно.

Частые вопросы

Заменяет ли Codex Security обычный security review?

Нет. Специализированный scan помогает систематически искать regressions и формировать findings, но владелец всё равно проверяет модель угроз, достижимость, приоритет и исправление.

Можно ли дать агенту production credentials только на чтение?

Даже read-доступ может раскрыть чувствительные данные. Используйте тестовую среду или минимально scoped credential, ограничьте выдачу данных и зафиксируйте одобренную цель.

Достаточно ли попросить «пиши безопасный код»?

Нет. Назовите активы, trust boundaries, критичные категории, правила проекта и проверки. Без конкретной модели риска эта фраза слишком неоднозначна.

Что важно запомнить

Безопасность защищает и среду агента, и само приложение.
Security finding требует достижимого сценария и доказательства.
Секреты не должны попадать в промпты, репозиторий и неочищенные логи.
Prompt injection ограничивают sandbox, approvals, scopes и разделение действий.

https://yadro-code.ru/lessons/without-university/codex-agent-workflows/codex-agent-16