conversations
Кейс: внедрение UC-платформы от MANGO OFFICE в Ростелеком
MAGNIT OMNI автоматизировал коммуникации с кандидатами с помощью MANGO OFFICE
Единый контакт-центр на базе Naumen Contact Center для «РКС-энерго»
За 48 часов можно проверить идею, но не доказать, что она окупится
Надежда Шалимова (ЭОС): «На «Осеннем документообороте – 2026» затронем очень много тем – актуальных, горячих, беспокоящих и CIO, и пользователей»
ЦБ
°
понедельник, 9 ноября 2026

Стало известно, как защитить разработку на скорости ИИ

Стало известно, как защитить разработку на скорости ИИ
10 августа 2026 года издание The Hacker News опубликовало материал о вебинаре «Истинная цена разработки на машинной скорости». Эксперт «Группы Астра» Максим Козлов отметил, что при машинных темпах генерации кода реактивная схема «выпустил — просканировал — исправил» перестаёт справляться.

Главная тема встречи — рост объёма программного кода на фоне внедрения ИИ. По данным организаторов, команды разработки могут выпускать в 10–50 раз больше кода за один спринт. Одновременно с этим увеличивается число компонентов, зависимостей, уязвимостей и исправлений, которые должны контролировать специалисты по безопасности.

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

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

Ключевой вывод вебинара заключается в адаптации средств безопасности к машинной скорости. Контроль должен быть встроен в процессы создания ПО и работать автоматически там, где ручная проверка уже не соответствует объёму выпускаемого кода.

Максим Козлов, технический директор GitFlic (входит в «Группу Астра») подчеркнул, что ключевой вывод вебинара нам тоже близок. 

«При машинных темпах генерации кода реактивная схема «выпустил — просканировал — исправил» перестаёт справляться. Зависимостей, компонентов и уязвимостей становится больше, чем команды успевают разбирать, и накопленный backlog начинает расти быстрее, чем его закрывают.

Логичный ответ — не тормозить разработчиков, а смещать контроль внутрь процесса: проверять происхождение компонентов, сокращать число уязвимых зависимостей и следить за артефактами на всём жизненном цикле, а не только на выходе. По сути, это переход от разовой проверки перед релизом к встроенной безопасности по умолчанию — та же логика, что заложена в ГОСТ Р 56939-2024.

Добавим один акцент, важный для российских команд: те же ИИ-модели, что ускоряют разработку, доступны и атакующим — в том числе для поиска слабых мест в цепочках поставок. Поэтому контроль над цепочкой поставки ПО в собственном, управляемом контуре становится не пожеланием, а базовым требованием — особенно для критичной инфраструктуры. Инструменты полного цикла разработки, GitFlic в их числе, движутся именно в эту сторону», — говорит эксперт Максим Козлов.

Свежее по теме

!-- Yandex.Metrika counter -->