Каждый аудит комплаенса начинается одинаково: кто-то объявляет дедлайн, команда судорожно собирает доказательства, сопоставляет контроли и доказывает, что запущенные в продакшене политики действительно соответствуют требованиям стандарта. Они справляются. Выдыхают. Через шесть месяцев появляется новый стандарт, и лихорадочная подготовка начинается сначала.
Большинство команд уходят с аудита с уверенностью, что они соответствуют требованиям. Те 59% организаций, которые заявляют о полной прозрачности происхождения своих цепочек поставок ПО, вероятно, чувствовали то же самое. Но когда JFrog опросила их, 48% потребовалось больше недели, чтобы предоставить доказательства комплаенса, когда аудиторы действительно задали этот вопрос. Точечные проверки создают иллюзию соответствия, но на самом деле не гарантируют его.
Темпы только ускоряются. NIST SSDF уже регулирует федеральные закупки, а Закон ЕС о киберустойчивости (CRA) вступает в силу в сентябре этого года. Впервые в нормативные акты заложена личная ответственность руководителей по безопасности. Готовятся новые стандарты, и каждый из них требует от вашей команды начинать работу по маппингу и политикам с нуля.
В то же время программное обеспечение, которое эти стандарты должны регулировать, меняется быстрее, чем любой ручной процесс способен отследить. ИИ-агенты теперь пишут код, проверяют PR и отправляют изменения в объемах, с которыми не справится ни одна проверка комплаенса. ПО, поставляемое вашей командой сегодня, совершенно не похоже на то, каким оно было два года назад. Стандарты, пытающиеся регулировать программное обеспечение и тем более разработку ИИ, все еще пишутся. Вы используете практики 2025 года для противодействия угрозам образца 2027 года.
Год назад на swampUP мы представили JFrog AppTrust, чтобы обеспечить непрерывное управление (continuous governance) для вашей цепочки поставок ПО. Управление, которое работает с каждым релизом, а не перед каждым аудитом.
За последний год стало очевидно одно: непрерывное управление работает только тогда, когда вы действительно можете применять политики в соответствии со стандартами, за которые ваша организация несет ответственность. Прямо сейчас превращение этих стандартов в обязательные к исполнению политики по-прежнему остается ручной работой, которая начинается с нуля каждый раз при появлении нового регламента.
В этом и заключается дилемма DevGovOps. DevGovOps — это практика превращения управления и комплаенса в непрерывный результат ваших операций по разработке ПО, а не в точечную процедуру перед каждым аудитом. AppTrust — это инструмент для ее реализации.
Устранение разрыва между требованиями и их исполнением
Разрыв заключается между пониманием того, что требует стандарт, и созданием работающей системы его исполнения. Превращение юридического контроля в применимые правила Policy-as-Code (PaC) требует человека, который глубоко понимает как нормативные акты, так и то, как их можно реализовать на платформе.
Возьмем требование CRA «соблюдать все безопасные практики кодирования, подходящие для языков разработки и сред». Во что превращается эта политика? Какой этап пайплайна ее обеспечивает? Ответ должен быть написан на Rego, языке политик за OPA (Open Policy Agent), протестирован и ограничен нужными приложениями. На это уходит время, которого у большинства команд нет при появлении каждого нового регламента.
И это только первая проблема. Даже после того, как политики созданы, по-прежнему нет возможности увидеть, какую часть стандарта они на самом деле покрывают. Сгенерированный ИИ код все равно должен соответствовать CRA и NIST SSDF, но управляющие им политики часто еще не существуют. Пробелы остаются незамеченными до тех пор, пока аудитор не выберет 20 случайных коммитов из истории вашего продакшена и не начнет задавать вопросы.
Проблема не заканчивается на принудительном исполнении. Она заканчивается на аудите.
Что готовые стандарты комплаенса на самом деле означают для вашей команды AppSec?
На этой неделе на swampUP 2026 компания JFrog выпустила готовые стандарты комплаенса в AppTrust, начиная с NIST SSDF и EU CRA. Контроли, которые ваша команда сопоставляла вручную, теперь предварительно связаны с правилами Policy-as-Code в AppTrust. Все, что вам нужно сделать, это выбрать стандарт, и начнется его исполнение.
JFrog AppTrust поставляется с каталогом комплаенса. Команды AppSec выбирают стандарт и видят каждый контроль, уже переведенный в простые требования, каждое из которых связано с определенными правилами Policy-as-Code, размещающими контроль политик на ваших релизных шлюзах. Никаких скриптов на Rego писать не нужно, ручной маппинг не требуется. Контроли, которые AppTrust не покрывает, четко отмечены. Контроли, уже удовлетворяемые за счет работы AppTrust, отображаются как покрытые по умолчанию.
Поскольку управление AppTrust сосуществует в той же системе записей, что и ваши артефакты, показатель покрытия всегда отражает реальное состояние продакшена, а не документ политики, обновленный в последний раз перед прошлым спринтом.
Готовые стандарты комплаенса решают задачу с политиками. Но исполнение надежно ровно настолько, насколько надежны данные, лежащие в его основе. Сегодня эти данные включают в себя нечто большее, чем коммиты Git, пул-реквесты и тикеты Jira. ИИ-агенты пишут код, принимают решения и автономно отправляют изменения. Без прозрачности того, что сделал агент и почему, невозможно управлять тем, что в итоге попадает в релиз.
Именно поэтому AppTrust также обеспечивает полную прослеживаемость на всех этапах вашего SDLC, фиксируя сеансы намерений агентов, коммиты Git, пул-реквесты и тикеты Jira, и все это связано с поставляемыми артефактами. Стандарт говорит вашим политикам, что проверять, а данные прослеживаемости предоставляют им реальные данные для проверки.
Менеджеры разработки контролируют развертывание; AppSec контролирует правила
Конфигурация стандартов и развертывание разделены по замыслу. AppSec владеет тем, какие контроли применяются, какие правила активны и какие политики их обеспечивают. Менеджеры по разработке отвечают за развертывание, включая то, какие приложения подпадают под действие стандартов, какие правила выполняются в качестве предупреждений, а какие — как жесткие блокировки, и сколько времени есть у команд, прежде чем предупреждение превратится в заблокированный пакет.
CISO нужны ответы, а не электронные таблицы
Вопрос, который задает аудитор, заключается не в том, какие политики у вас есть, а в том, можете ли вы доказать, что они выполнялись для каждого релиза в каждом приложении. CRA делает этот вопрос личным: CISO теперь несут личную ответственность за ответ. Документальные доказательства должны быть доступны за считанные часы, а не собираться неделями.
Согласно исследованию The CISO Society за 2025 год «Состояние непрерывного мониторинга средств контроля» (The State of Continuous Controls Monitoring), 48% CISO называют сбор доказательств одной из своих главных операционных проблем. Согласно CRA, задокументированный пробел в комплаенсе влечет за собой штраф в размере до 17 млн долларов или 2,5% от общемирового годового дохода.
Готовые стандарты комплаенса уже доступны
Готовые стандарты комплаенса поставляются в составе JFrog AppTrust как часть пакета Ultimate Security Bundle и доступны повсеместно в этом месяце. Стандарты CRA и NIST SSDF уже запущены. Дополнительные стандарты находятся в активной разработке.
Если ваша организация отслеживает CRA, NIST SSDF или любой регламент с компонентом SDLC, JFrog AppTrust убирает уровень трансляции между тем, что требует регламент, и тем, что обеспечивают ваши релизные шлюзы. Результат: более простое обеспечение соблюдения, полная прослеживаемость, непрерывное управление и аудит по умолчанию.
Посмотрите JFrog AppTrust в действии. Запланируйте демо или пройдите онлайн-тур.
