Управление агентским SDLC посредством непрерывного обеспечения соблюдения политик

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

Журнал git создавался для фиксаций изменений людьми. В нем показано, что изменилось. В нем не отображается, что сделал ИИ-агент, какую модель он использовал, какие инструменты вызывал или кто нес ответственность за результат. Каждое управляющее руководство, каждый след аудита, каждый элемент контроля соответствия в SDLC строился на одном предположении: решение принимал человек. Это предположение больше не актуально.

Почему Agentic SDLC разрушает традиционное управление?

Доверие в SDLC строилось вокруг людей. Экспертная оценка кода означала, что инженер-человек подтвердил изменения перед их слиянием. Отслеживаемое намерение означало, что фиксации сопоставлялись с личностями людей и задачами в Jira. Контрольные точки релизов означали, что человек проверил качество перед развертыванием. Стандарты соответствия от SOC 2 до FedRAMP были формализованы еще до наступления эры агентов и, следовательно, ориентированы на людей.

Agentic SDLC подвергает нагрузке эти опоры:

• Перегрузка объемами и штамповка одобрений: люди, проверяющие тысячи строк написанного агентами кода в час, испытывают утомление, из-за чего экспертные оценки могут превратиться в автоматические одобрения.
• Несогласованность агентов и галлюцинации: агенты принимают недетерминированные решения, подтягивают зависимости и привносят скрытые уязвимости, которые проходят функциональные тесты.
• Эфемерность агентов: журналы коммитов в Git фиксируют только финальное состояние, а не рассуждения агента, задействованные им инструменты, серверы MCP (Model Test/Context Protocol), к которым он обращался, или итерации промтов, приведшие к результату.

Agentic SDLC также открывает новые поверхности атак на цепочку поставок. Новые участники вашей цепочки поставки ПО (агенты, среды и большие языковые модели (LLM), которые теперь создают софт и управляют релизами) порождают новые векторы атак: инъекции промтов, вредоносные инструменты и навыки MCP, несогласованные или неутвержденные модели, а также обход систем безопасности (джейлбрейки).

Куда движутся регулирование и стандарты

Эти проблемы меняют как регулирование, так и стандарты безопасности. Закон ЕС об искусственном интеллекте (EU AI Act) устанавливает требования к ведению учета и хранению журналов для систем ИИ высокого риска, а Стандарт верификации безопасности ИИ (AISVS) от OWASP устанавливает сопоставимые требования добровольной верификации.

• EU AI Act, Article 14 (high-risk AI systems): «Системы ИИ высокого риска должны быть спроектированы и разработаны таким образом, включая использование соответствующих инструментов взаимодействия человека с машиной, чтобы физические лица могли эффективно осуществлять за ними надзор в период их использования».
• EU AI Act, Article 12 (high-risk AI systems): «Системы ИИ высокого риска должны технически обеспечивать автоматическую запись событий (логов) на протяжении всего жизненного цикла системы».
• OWASP/AISVS 12.1.1: «Убедитесь, что взаимодействия с ИИ регистрируются в журнале с контекстом сессии и телеметрией, специфичной для ИИ».
• 12.4.2: «Убедитесь, что журналы аудита фиксируют критически важные для безопасности проактивные действия, включая личность утверждающего лица, метку времени, параметры действия и результаты принятия решений».

Статьи 12, 14 и 19 накладывают обязательства на поставщиков и операторов систем ИИ высокого риска. Статья 14 касается надзора во время использования системы, а не ведения журналов задним числом. Общее направление движения по-прежнему понятно. По нашему мнению, эта практика согласуется с требованиями безопасности на этапе проектирования (security-by-design) из Закона ЕС о киберустойчивости (Cyber Resilience Act) и подходом к управлению по стандарту ISO/IEC 42001.

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

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

Именно такой стандарт предлагает JFrog. Недавняя функция JFrog AppTrust — «Прослеживаемость от промта до релиза» (Prompt to Release Traceability) — связывает журналы сессий агентов с подписанными доказательствами релизов на протяжении всего SDLC. Мы создали наше решение на основе уровней цепочки поставок для программных артефактов (SLSA), поддерживаемой OpenSSF рамки безопасности цепочки поставок, и полагаемся на совместимые с SLSA аттестации происхождения, которые связывают активность агентов с подписанными релизами. Полная спецификация находится в эталонном репозитории на GitHub.

Создание открытого стандарта совместными усилиями

Переход на Agentic SDLC требует новой основы для доверия, ответственности и отслеживаемости. Доказательства агентских процессов (Agentic Process Evidence) — это открытая инициатива по совместному созданию такой основы.

Для регулирующих органов, поставщиков агентов и провайдеров инструментов SDLC

Цель состоит не в создании очередного проприетарного формата телеметрии. Цель — разработать открытый, проверяемый стандарт доказательств для Agentic SDLC, на который смогут опираться организации, регуляторы, поставщики агентов и платформы SDLC.

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

Если вы представляете регулирующий орган, организацию по стандартизации, поставщика ИИ-агентов или разработчика LLM/сред разработки, помогите нам сформировать этот стандарт. Вносите свой вклад в виде требований, вариантов использования, отзывов и реализаций, чтобы «Доказательства агентских процессов» могли стать общим языком для всей экосистемы.

→ Ознакомьтесь со спецификациями и внесите свой вклад на GitHub https://github.com/jfrog/agentic-process-evidence

Независимо от того, создаете ли вы системы контроля исходного кода, CI/CD, средства безопасности, инструменты репортажа кода, средства разработки или другую платформу SDLC, давайте работать вместе над уровнем доказательств, который объединяет их все. Организациям не должно приходиться выбирать между конкурирующими платформами ради достижения надежного и переносимого происхождения агентских процессов.

Мы можем конкурировать на уровне продуктов, сотрудничая при этом над стандартом.

→ Присоединяйтесь к инициативе Agentic Process Evidence

Под капотом: протокол доказательств агентских процессов (Agentic Process Evidence Protocol)

ИИ-агенты теперь участвуют на каждом этапе SDLC: редактируют код, продвигают артефакты, управляют развертываниями и выполняют проверки безопасности. Чтобы управлять этими процессами с той же строгостью, которая применяется к традиционным релизам, нам нужен детерминированный криптографический механизм, который регистрирует и оценивает действия агентов. Мы называем это протоколом доказательств агентских процессов (Agentic Process Evidence Protocol).

Протокол разделяет два понятия, которые легко перепутать:

• Сессия агента: единичный запуск агента или беседа с ним
• Агентский процесс: процесс достижения определенной цели с использованием агентов

Примеры процессов и связанных с ними сессий:

Протокол подтверждения агентских процессов (Agentic Process Evidence Protocol) определяет структурированную спецификацию для фиксации, заверения и проверки агентских процессов, выполняемых на протяжении жизненного цикла выпуска программного обеспечения. Каждый процесс создает «Доказательство агентского процесса» (Agentic Process Evidence): защищенное от несанкционированного вмешательства подписанное свидетельство, содержащее подтвержденные факты о том, что сделал агент, какие модели и инструменты он использовал, кто владел процессом, проверял ли его человек, а также журналы сеансов каждого взаимодействия, в результате которого был получен этот результат.

Интегрируя этот протокол в агентские фреймворки, такие как Cursor, OpenCode, Claude Code или пользовательские ИИ-агенты, действия агентов генерируют проверяемые доказательства параллельно с результатами разработки ПО. Эти доказательства затем используются на этапах SDLC и в дальнейшем для устранения неполадок, позволяя инженерным командам и специалистам по безопасности отвечать на такие вопросы, как:

• Нарушали ли агенты политику безопасности?
• Использует ли каждый агент одобренную LLM?
• Есть ли у каждого сеанса агентской разработки ответственный владелец?
• Использовал ли сеанс агентской разработки требования из корпоративной Jira?
• Следовал ли сеанс агентской разработки корпоративным рекомендациям по разработке?

Как работает протокол подтверждения агентских процессов?

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

Этап 1: Выполнение агента и сбор телеметрии

Среда выполнения фиксирует операционный контекст агента во время его работы: запросы пользователя, токены рассуждений, правки файлов и вызовы инструментов. Затем она записывает эти действия в журналы сеансов и привязывает их к соответствующей сущности SDLC, например, к git-коммиту, который создал агент.

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

Этап 2: Криптографическое заверение и передача доказательств

Протокол создает, подписывает и сохраняет доказательства происхождения в виде слоя метаданных, прикрепленного непосредственно к соответствующей сущности SDLC (git-коммит, артефакт, выпущенная версия), которую обрабатывает агентский процесс, и привязывает их к журналам, также подписывая их статус.

Этап 3: Автоматизированные шлюзы качества, соответствия требованиям и согласованности

Перед тем как программное обеспечение перейдет на этап тестирования или производства, шлюзы развертывания оценивают результаты сканирования безопасности бинарных файлов, происхождение сборки, ручные одобрения, автоматическое тестирование, а также приложенные доказательства агентского процесса. Политики как код (Policy-as-code) теперь могут проверять, что:

• Работа агента соответствовала запрошенной задаче
• Агент соответствует политикам компании
• За операцию несет ответственность человек
• Код был разработан с участием человека (проверкой)
• Агент не пытался выполнять несанкционированные побочные операции
• Код был сгенерирован одобренной LLM
• Агент использовал одобренные инструменты MCP

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

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

Этап 4: Аудит и устранение неполадок

Привязка доказательств агентского процесса и журналов сеансов к стандартным сущностям SDLC (git-коммиты, артефакты, выпущенные версии) позволяет проводить аудит после выпуска и устранять проблемы, выявленные в агентских инструментах, моделях или агентах, точно так же, как спецификации состава программного обеспечения (SBOM) сделали отслеживаемым состав артефактов.

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

Что именно фиксирует протокол подтверждения агентских процессов?

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

• Идентификация агента: Протокол криптографически привязывает параметры каждого агента к его результату, фиксируя версию агента, версию обвязки и ID модели для управления языковыми моделями.
• Отслеживаемость выполнения: Протокол записывает полные журналы сеансов в виде структурированного JSON, охватывая каждый вызов инструмента, вызов API, входные данные и источник контекста на временной шкале.
• Происхождение: Протокол привязывает сущность SDLC (коммит, артефакт или релиз) обратно к агентскому процессу и его журналам.
• Целостность и защита от несанкционированного вмешательства: In-toto и Dead Simple Signing Envelope (DSSE) подписывают полезную нагрузку выполнения, делая любое изменение после факта немедленно обнаруживаемым.
• Проверка политик как код: Движки управления автоматически оценивают правила соответствия и могут заблокировать выпуск перед развертыванием.

Пример артефактов

Вот как это выглядит от начала до конца, от первого действия агента до подписанного доказательства, прикрепленного к коммиту. Допустим, разработчик хочет реализовать тикет FIN-3678, который определяет новую функцию ограничения скорости (rate limit) для существующего API /api/orders. Пользователь по имени «me» запрашивает у агента в IDE реализацию этой функции и следит за ходом разработки. Как только пользователь удовлетворен, он делает коммит функции (или просит агента сделать это), создавая журнал агентского сеанса и доказательство процесса. Для простоты предположим, что разработка потребовала только одного агентского сеанса и сопровождалась одним git-коммитом.

Журнал агентского сеанса

Ниже приведен пример макета журнала сеанса, созданного во время разработки агентом в IDE функции ограничения скорости для API под названием /api/orders.

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

Доказательство агентского процесса: пример вывода

Ниже приведен пример макета доказательства агентского процесса, определенного выше, при фиксации этого кода в git.

Скорость разработки встречается с бескомпромиссным управлением

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

Готовы обезопасить свой агентский SDLC?

Перенос этих открытых стандартов доказательств в ваши существующие конвейеры выпуска не означает создание всего с нуля.

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

JFrog AppTrust уже реализует этот уровень доказательств как «Прослеживаемость от промпта до релиза» (Prompt to Release Traceability), соединяя журналы сеансов агента с подписанными доказательствами релиза. Запланируйте демонстрацию, чтобы увидеть AppTrust в действии.

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