22 июня 2026 года руководители агентств кибербезопасности Five Eyes выступили с прямым предупреждением для бизнес-лидеров и технических специалистов: ИИ стремительно меняет ландшафт киберрисков, и устоявшиеся предположения могут устареть не за годы, а за месяцы. ИИ увеличивает скорость, масштаб и изощренность атак, сокращая время между обнаружением уязвимости и ее эксплуатацией, что делает базовые средства контроля еще более необходимыми.
Тот же сдвиг трансформирует процесс разработки программного обеспечения. Агенты кодирования генерируют код, внедряют зависимости и вносят все более сложные изменения с темпом, к которому ручная проверка не приспособлена. Злоумышленники могут использовать слабые места быстрее, в то время как объем кода, требующего проверки, постоянно растет.
Это создает проблему формального управления. Политика цепочки поставок ПО может определять правильные намерения, но сама по себе она не может доказать, что средства контроля были применены к выпущенным изменениям. Периодические проверки также ограничены: они фиксируют лишь один момент времени, в то время как разработчики и агенты продолжают вносить изменения в рабочие процессы разработки, pull-запросов и CI/CD.
В заявлении Five Eyes говорится, что лидеры должны быть уверены в том, что средства контроля будут работать под нагрузкой, а принципы «безопасность по проектированию» (secure-by-design) и «безопасность по умолчанию» (secure-by-default) должны стать стандартной практикой, а не просто стремлением. Следование этому курсу означает перенос превентивных мер непосредственно в кодовую базу: перевод политики в проверяемые стандарты, независимую верификацию каждого изменения независимо от его источника, обеспечение условий выпуска и создание доказательств работы этих средств контроля.
Что требуют NIS2 и Закон ЕС о киберустойчивости (EU Cyber Resilience Act) для безопасности ПО?
Для организаций, подпадающих под действие директивы, NIS2 требует принятия соответствующих и соразмерных технических, операционных и организационных мер кибербезопасности. Статья 21 прямо включает безопасность цепочки поставок; безопасность при приобретении, разработке и обслуживании сетевых и информационных систем; обработку и раскрытие уязвимостей; а также политики и процедуры для оценки эффективности мер кибербезопасности. NIS2 действует через национальные законы, и ее точное применение зависит от сектора, размера, роли и юрисдикции организации.
Закон ЕС Cyber Resilience Act идет дальше для производителей продукции с цифровыми элементами. Он требует обеспечения кибербезопасности на этапах проектирования, разработки, производства, поставки и обслуживания продукта. Он также требует обработки уязвимостей, регулярных проверок безопасности, должной осмотрительности при интеграции сторонних компонентов и машиночитаемого спецификационного состава ПО (SBOM), охватывающего как минимум зависимости верхнего уровня. Обязательства CRA по отчетности применяются с 11 сентября 2026 года; большинство других положений вступают в силу с 11 декабря 2027 года.
Эти законы технологически нейтральны, но они делают ожидания регуляторов все более ясными: организации должны уметь показать, как меры кибербезопасности внедряются и оцениваются, а не просто демонстрировать наличие политики.
Необязательные публикации правительственных и кибер-агентств подкрепляют это направление. Японские METI и Национальное управление кибербезопасности связывают использование SBOM с управлением уязвимостями, прозрачностью цепочки поставок и подотчетностью в рамках secure-by-design, в то время как японское руководство определяет SBOM как часть усиленного управления рисками цепочки поставок. Французское агентство ANSSI поддерживает принципы secure-by-design, аудируемость, управление уязвимостями, проверку кода и SBOM в своей политике в отношении открытого исходного кода. CISA и партнеры по G7 также опубликовали необязательные минимальные элементы SBOM для систем ИИ. Эти источники не создают единого глобального правила, но указывают на одни и те же приоритеты: безопасная разработка, прозрачность компонентов, эффективная обработка уязвимостей и доказательства функционирования средств контроля.
Политика доказывает намерения; операционные доказательства доказывают реализацию
Периодические аудиты фиксируют состояние на определенный момент времени. В промежутках между аудитами код продолжает меняться в рамках множества рабочих процессов. Если стандарты проверяются только в конце или доказательства восстанавливаются из электронных таблиц и скриншотов, записи фрагментированы и часто устаревают еще до того, как их увидит аудитор.
Это создает три практические проблемы:
- Стандарты применяются непоследовательно в разных командах, репозиториях и путях доставки.
- Руководители могут лишь показать, что средства контроля были задокументированы, но не могут доказать, что они применялись к выпущенным изменениям.
- Нечеткие средства контроля для агентного кода замедляют его внедрение в регулируемых и чувствительных к рискам средах.
Более сильная позиция — это превентивные меры с доказательствами, генерируемыми в процессе работы средств контроля.
Как внедрить непрерывные средства контроля безопасности в конвейер разработки?
Sonar описывает свой более широкий подход как «Цикл разработки, ориентированный на агентов» (Agent Centric Development Cycle), организованный вокруг этапов «Руководство» (Guide), «Верификация» (Verify) и «Решение» (Solve). Эти этапы представляют собой полезную модель для непрерывного управления кодом.
Руководство: Установление и доведение стандарта
Этап «Руководство» начинается с определения ограничений и стандартов, в рамках которых работают агенты. Профили качества SonarQube кодируют стандарты качества и безопасности организации, а «ворота качества» (quality gates) устанавливают обязательные условия, которым должны соответствовать изменения, внесенные агентами.
Sonar Vortex переносит эти стандарты и контекст конкретной кодовой базы непосредственно в рабочий процесс агента еще до начала работы. Вместе они превращают политику в четкие автоматизированные границы, которые направляют агентов в процессе генерации и модификации кода, вместо того чтобы полагаться на то, что каждый агент будет интерпретировать требования управления самостоятельно.
Верификация: Анализ каждого изменения независимо от его источника
Руководство формирует то, что создает агент; верификация определяет, можно ли доверять результату. Sonar предоставляет независимый уровень анализа, который оценивает агентский код и зависимости на соответствие установленным стандартам, вместо того чтобы полагаться на то, что агент сам проверит свой вывод.
Верификация сопровождает изменение на протяжении всего агентского рабочего процесса. Sonar Vortex проверяет изменения, созданные агентами, внутри рабочего процесса, в то время как SonarQube независимо анализирует завершенное изменение и применяет соответствующие «ворота качества». Репозиторий или платформа CI/CD могут затем использовать этот результат, чтобы блокировать изменения, не соответствующие требуемому стандарту. Настроенная как обязательная проверка, она делает превентивные меры принудительными: код, созданный агентом, не может продвинуться дальше, если он не соответствует заданным условиям.
Решение: Устранение выявленных проблем и верификация результата
Выявленные проблемы должны проходить по управляемому пути от обнаружения до верифицированного устранения. Gitar проверяет pull-запросы и может предлагать исправления для выявленных проблем и сбоев CI. Агент устранения SonarQube (SonarQube Remediation Agent) работает с подходящими проблемами технического долга и бэклога, верифицирует каждое предложенное исправление с помощью нового анализа и возвращает успешные исправления в виде проверяемых pull-запросов.
Агент Hunter усиливает обнаружение проблем безопасности в кодовой базе, выявляя уязвимости контроля доступа, бизнес-логики и аутентификации, которые обычный анализ может пропустить. Его находки затем могут поступать в тот же процесс сортировки и устранения, что и другие проблемы SonarQube.
В совокупности эти возможности превращают результаты анализа в превентивные меры, помогая организациям выявлять, устранять и повторно проверять уязвимости до того, как они закрепятся или распространятся по всей кодовой базе.
Как организации могут доказать аудиторам, что средства контроля безопасности программного обеспечения работают?
Формальное управление требует доказательств того, что средства контроля были установлены, функционировали и приносили результат. Sonar может предоставить доказательства:
- Как были установлены средства контроля: настроенные профили качества, правила анализа, шлюзы качества и их назначение для проектов.
- Как функционировали средства контроля: история анализа, записи о проблемах и решения шлюзов качества, показывающие, что код был проверен на соответствие назначенному стандарту.
- Что обнаружили и устранили средства контроля: результаты проверок безопасности, риски зависимостей и лицензий, ответственность за проблемы и их статус, предлагаемые исправления и результаты повторного анализа.
- Что можно извлечь в качестве доказательств: конфигурации профилей и шлюзов качества, зависимости, данные анализа, проблемы и их устранение, результаты шлюзов качества, SBOM и журналы аудита.
Эти записи показывают, как средства контроля на уровне кода были настроены, применялись и использовались с течением времени.
Кто несет ответственность за безопасность программного обеспечения при использовании ИИ в разработке?
Использование ИИ не снимает ответственности. Организация по-прежнему несет ответственность за безопасность программного обеспечения, которое она разрабатывает, эксплуатирует или выпускает на рынок. Поэтому средства контроля должны быть всеобъемлющими, последовательно применяемыми и надежными при каждом изменении кода.
Эта ответственность должна трансформироваться в четкое распределение обязанностей:
- Руководители по безопасности устанавливают требования к безопасной разработке, зависимостям и лицензированию, включая пороги риска, исключения и пути эскалации.
- Руководители инженерных и платформенных направлений преобразуют эти требования в автоматизированный анализ, контроль репозиториев, проверки в конвейере и условия выпуска.
- Продуктовые и юридические команды определяют нормативные и договорные требования, применимые к каждому продукту и рынку.
- Команды по комплаенсу и обеспечению качества определяют необходимые доказательства, тестируют средства контроля и связывают полученные записи с конкретными обязательствами.
Начните с продуктов и приложений, несущих наибольшие регуляторные или операционные риски, а затем расширяйте модель на весь портфель.
Измеряйте четыре показателя: охват контроля, управление исключениями, результаты безопасности и готовность доказательств. Полезные индикаторы включают долю изменений, проанализированных до слияния, репозитории с принудительными шлюзами, срок действия исключений, повторяющиеся находки, время устранения, охват зависимостей и SBOM, а также время, необходимое для получения доказательств выпуска.
Как ИИ меняет риски кибербезопасности для команд разработки ПО?
ИИ сократил дистанцию между изменением программного обеспечения и киберриском. Поэтому управление должно осуществляться там, где программное обеспечение создается, проверяется и выпускается. Политики и документация остаются важными, но они должны быть подкреплены средствами контроля, которые работают при каждом изменении кода.
Защищенная цепочка поставок программного обеспечения напрямую связывает управление с доставкой кода. Стандарты определяют работу агентов, каждое изменение проходит независимую проверку, условия выпуска соблюдаются, результаты проверок проходят через верифицированное устранение, а доказательства показывают, как эти средства контроля функционировали.
SonarQube обеспечивает базовый технический контроль и уровень доказательств для этой модели. Он помогает организациям применять последовательные стандарты качества и безопасности, проверять код и зависимости, управлять решениями о выпуске и отслеживать результаты с течением времени, создавая воспроизводимые доказательства для кода, созданного как разработчиками, так и агентами.
Возьмите под контроль киберриски эпохи ИИ там, где они проникают в программное обеспечение. Узнайте, как SonarQube превращает политику в непрерывные, проверяемые средства контроля для каждого изменения кода.
