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