Кто проверяет код ИИ: вызов безопасности open source

Инструменты ИИ генерируют код с open source-зависимостями, которые часто проходят без проверки безопасности. ActiveState предупреждает: традиционные ревью не успевают за масштабом, и компаниям нужно контролировать пакеты на этапе выбора.

Когда разработчик просит ИИ-ассистента написать фрагмент кода, тот часто предлагает готовые решения с использованием open source-библиотек. Эти зависимости могут содержать уязвимости или быть полностью выдуманными — и попадают в продакшен быстрее, чем служба безопасности успевает их проверить. Проблема масштаба стала настолько острой, что вендор ActiveState выпустил предупреждение: традиционные процессы ревью не поспевают за скоростью ИИ, и компаниям нужно менять подход к управлению зависимостями.

Проблема: ИИ-код и неотслеживаемые open source-зависимости

По данным ActiveState, ИИ-инструменты для написания кода, такие как GitHub Copilot или ChatGPT, генерируют код с зависимостями от open source-пакетов, которые могут быть непроверенными, устаревшими или даже галлюцинированными — то есть несуществующими. Разработчик, доверяя ИИ, вставляет такой код в проект, и зависимость попадает в систему без ведома команды безопасности. Традиционные проверки, которые проходят на этапе сборки или после коммита, не успевают за этим потоком.

Масштаб проблемы огромен: в экосистемах вроде npm или PyPI ежедневно появляются тысячи новых пакетов, и вручную проверить каждый невозможно. ИИ усугубляет ситуацию, потому что он не просто использует известные библиотеки, а может предложить редкие или недавно созданные пакеты, о которых служба безопасности даже не слышала. Это создает слепые зоны в цепочке поставок ПО.

Предыстория: как мы дошли до этого

Проблема не нова: атаки на цепочки поставок open source участились за последние годы. Вспомним инциденты с компрометацией пакетов в npm и PyPI, когда злоумышленники публиковали вредоносные библиотеки под именами, похожими на популярные. Однако раньше разработчики сами выбирали зависимости и несли за них ответственность. Теперь ИИ-ассистенты автоматизируют этот выбор, и ответственность размывается.

ActiveState — компания, которая специализируется на управлении open source-средами, — видит рост обращений от клиентов, которые хотят понять, какие зависимости попадают в их код через ИИ. Они отмечают, что большинство организаций до сих пор полагаются на ручные проверки или сканеры уязвимостей на этапе CI/CD, но это уже неэффективно.

Чем отличается подход ActiveState?

ActiveState предлагает управлять пакетами на этапе выбора, до того как они попадут в пайплайн разработки. Это означает, что разработчик или ИИ-инструмент должен получать доступ только к проверенному репозиторию пакетов, который уже прошел сканирование на уязвимости и лицензионные риски. Такой подход блокирует небезопасные зависимости на входе, а не пытается поймать их после.

Это отличается от традиционных методов, которые фокусируются на обнаружении проблем после сборки. Контроль на этапе выбора позволяет автоматически отклонять пакеты с известными CVE или сомнительным происхождением, не замедляя разработку.

Технические детали: как работает управление пакетами на входе

ActiveState использует свою платформу, которая создает «сборочные» репозитории с предварительно одобренными пакетами. Она интегрируется с популярными менеджерами пакетов, такими как pip и npm, и перехватывает запросы на установку. Если пакет не прошел проверку, установка блокируется, а разработчик получает уведомление с причиной отказа.

Платформа также отслеживает происхождение пакетов — откуда они взялись, кто их поддерживает, есть ли у них цифровые подписи. Это помогает выявлять «галлюцинированные» зависимости, которые ИИ мог выдумать. В сочетании с автоматическим сканированием на уязвимости, такое решение закрывает основные пробелы.

По оценкам ActiveState, организации, внедрившие такой контроль, сокращают время на проверку зависимостей до 80%, потому что отпадает необходимость вручную разбирать каждый пакет после обнаружения проблемы.

Кого затронет и как

Разработчики почувствуют это сразу: им придется работать с ограниченным набором пакетов, но зато с гарантией, что они безопасны. Это может замедлить эксперименты с новыми библиотеками, но снизит риск инцидентов. Менеджерам по безопасности такой подход дает прозрачность и контроль, а бизнесу — защиту от дорогостоящих утечек данных.

Для российских и СНГ-компаний, которые активно используют open source, эта проблема особенно актуальна. Санкционные ограничения и рост числа атак на цепочки поставок делают контроль зависимостей критически важным. Локальные разработчики, работающие с ИИ-инструментами, должны обратить внимание на подобные решения, чтобы не стать жертвой атаки через скомпрометированный пакет.

Что будет дальше

Ожидается, что спрос на инструменты управления зависимостями будет расти, особенно с учетом распространения ИИ-кодинга. ActiveState планирует расширять поддержку языков и экосистем, а также улучшать интеграцию с популярными ИИ-ассистентами. Возможно, в будущем появятся стандарты для проверки ИИ-сгенерированного кода на уровне платформ.

Вероятно, что крупные облачные провайдеры, такие как GitHub и GitLab, также усилят встроенные механизмы безопасности, чтобы конкурировать с нишевыми решениями. Но пока ActiveState предлагает один из немногих комплексных подходов к проблеме.

Итог

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