Эксперт Синадский: рост уязвимостей отражает разрыв между скоростью ИИ и традиционным контролем
изображение: recraft
Алексей Синадский, ведущий исследователь УЦСБ, прокомментировал для CISOCLUB данные Sonatype о росте числа критических и высокоопасных уязвимостей в корпоративном ПО на фоне ускорения разработки с помощью ИИ. По его мнению, показатель 4,31 скорее говорит не о прямом падении качества программного кода, а о том, что традиционные механизмы контроля не успевают за темпами его генерации.
«Приведенный в статье коэффициент 4,31, скорее, не про падение качества кода, а про разрыв между скоростью генерации и скоростью традиционного контроля», — отметил Алексей Синадский.
Эксперт считает, что предложение переносить проверки безопасности непосредственно в процесс создания программного обеспечения не является новым. Такой подход известен как shift-left и предполагает, что безопасность должна учитываться на ранних этапах разработки, а не проверяться только после того, как продукт уже создан.
«Озвученное предложение встраивать проверки безопасности в момент генерации кода — давно известный shift-left, и в России такой подход уже закреплен нормативно. Базовый ГОСТ Р 56939-2024 «Разработка безопасного программного обеспечения» требует встраивать безопасность в процессы разработки, а не только проверять готовый продукт», — пояснил Синадский.
При этом нормативная база продолжает развиваться с учетом распространения ИИ. Сейчас обсуждается проект ГОСТ Р «Разработка безопасного программного обеспечения, реализующего технологии искусственного интеллекта. Общие требования», который предусматривает дополнительные процессы, связанные с безопасностью ИИ.
«Сейчас идет публичное обсуждение его развития: проект ГОСТ Р «Разработка безопасного программного обеспечения, реализующего технологии искусственного интеллекта. Общие требования», который добавляет ИИ-специфичные процессы: управление наборами данных и их происхождением, безопасное обучение моделей, guardrails, паспорта моделей», — рассказал эксперт.
По словам Синадского, одним из важных элементов нового подхода становится контроль цепочки поставок программного обеспечения. Предполагается, что для каждого заимствованного компонента будет формироваться машиночитаемая информация, что позволит контролировать состав продукта и потенциальные риски зависимостей.
«Как минимум, стандарт вводит обязательный контроль цепочки поставок и перечень программных компонентов, машиночитаемый документ о каждом заимствованном компоненте, что уже закроет часть проблем, указанных в отчете», — отметил исследователь.
Однако существующие и разрабатываемые требования пока не полностью охватывают сценарий, в котором ИИ выступает непосредственно инструментом разработки. Агент, способный самостоятельно подключать зависимости, генерировать код и выполнять действия в инфраструктуре, создает отдельный класс рисков.
«Однако стоит отметить, что обсуждаемый стандарт регулирует ИИ как продукт, а не ИИ как инструмент разработки. Агент, который сам подключает зависимости и генерирует код, остается вне его прямого охвата», — подчеркнул Синадский.
В таких условиях, считает эксперт, полагаться только на человеческое ревью становится все сложнее. При многократном увеличении скорости генерации специалист физически не сможет масштабировать ручную проверку в той же пропорции, поэтому контроль должен становиться автоматизированной частью самого конвейера разработки.
«Человеческое ревью при росте скорости генерации не масштабируется, поэтому контролировать агента должен такой же автоматизированный контур, встроенный в конвейер, а не еще один финальный аудит. Единого универсального решения тут пока не выработано. Лучшие практики вроде принципа наименьших привилегий и изоляции агентов только формируются», — заключил Алексей Синадский.
