Последние пять лет специалисты по безопасности задавали разработчикам, по сути, один и тот же вопрос: что у вас внутри кода? Какие open-source пакеты подключены, какие версии стоят, какие транзитивные зависимости тянутся вглубь на три-четыре уровня, о которых сама команда часто и не подозревает. Вопрос логичный и обоснованный – именно так и работают современные приложения, собранные из сотен чужих библиотек. Но пока эта модель мышления оттачивалась годами, в конвейер разработки тихо вошёл новый участник, который эту модель ломает.
Три инцидента последних лет стоит вспомнить не ради истории, а потому что они формируют логику происходящего сейчас. SolarWinds показал, как атака на цепочку поставок программного обеспечения может затронуть тысячи организаций через одно скомпрометированное обновление. Log4Shell продемонстрировал, что критическая уязвимость в одной крошечной библиотеке логирования способна парализовать половину корпоративного интернета. XZ Utils – совсем недавняя история про бэкдор, который годами и очень терпеливо внедрялся в открытый проект человеком, годами зарабатывавшим доверие сообщества. Урок из всех трёх один: риск живёт не столько в коде, который пишет команда, сколько во всём, что этот код производит и доставляет.
Дальше появился более свежий урок – кампания под названием Shai-Hulud, самораспространяющийся вредоносный пакет, который в этом году прошёлся по инструментарию разработчиков. Она показала простую вещь: знать, что находится внутри вашего кода, уже недостаточно. Необходимо, но недостаточно – разница принципиальная.
Примерно 20 месяцев назад был запущен Model Context Protocol, MCP. За это время AI-инструменты, модели и вся инфраструктура вокруг них успели превратиться из экспериментальной надстройки в несущие конструкции того, как программное обеспечение пишется, собирается, разворачивается и работает. Код теперь пишут AI-агенты. Пакеты подключают автономные инструменты, которые сами принимают решения о том, что нужно подтянуть в проект. А промпт – обычный текстовый запрос к модели – стал полноценным входным параметром сборки. А значит, и новым вектором атаки, о котором никто не думал, когда проектировались нынешние программы безопасности.
Ошибка, которую легко совершить: воспринимать сгенерированный ИИ код просто как ещё один код и прогонять его через привычные сканеры. Этого мало, и дело не в лени, а в том, что сам вопрос происхождения расширился. Раньше спрашивали: откуда это взялось и можно ли этому доверять – применительно к пакету или библиотеке. Теперь тот же вопрос нужно задавать модели, агенту и инструментам, которые этот агент вызывает. Финальный артефакт кода – только последнее звено в цепочке.
Сценарии, которые раньше казались теоретическими, стали рабочими. AI-ассистент предлагает разработчику зависимость, тот соглашается одним нажатием – и пакет ни разу не проходит через модель угроз человека, потому что человек просто нажал «принять». Автономный агент через MCP вызывает один инструмент, тот вызывает следующий – и выстраивается цепочка непроверенных действий, ни одно звено которой не видел ни один живой сотрудник. Или вредоносный промпт, подброшенный атакующим в контент, который модель прочитает как часть контекста – и этот промпт незаметно направляет, какой код будет написан и какие пакеты будут подключены.
Проверять сгенерированный ИИ код перед коммитом – это уже базовый минимум, само собой разумеющееся требование. Настоящая сложная задача – научиться управлять самими агентами, которые этот код пишут, и инструментами, которые они вызывают по собственной инициативе.
При этом у команд безопасности проблема не в нехватке находок – они и так тонут в потоке предупреждений. Просто добавить ещё одну проверку «давайте сканировать и вывод ИИ тоже» не решает ничего, стопка алертов станет выше, но не станет от этого полезнее.
Здесь нужны два сдвига в подходе. Первый – расширить отслеживание происхождения на всё, что входит в конвейер разработки, включая сами модели и агентов. Прослеживать активность, происхождение и изменения конфигурации от первого коммита до момента, когда код реально работает в проде. Модели и агенты должны проходить ту же строгую проверку, что и любая другая зависимость, без исключений и скидок на новизну технологии.
Второй сдвиг – расставлять приоритеты не по количеству находок, а по реальной эксплуатируемости. Сопоставлять уязвимости с runtime-контекстом: что действительно достижимо и может быть использовано атакующим прямо сейчас. Из сырого списка уязвимостей это превращает работу в анализ реальных цепочек эксплуатации – вещь гораздо более практичная. И это важнее, чем когда-либо, потому что агент способен написать тысячу правдоподобных строк кода ещё до обеда.
В июне Gartner опубликовал свой первый Magic Quadrant по безопасности цепочки поставок программного обеспечения. Формальность, казалось бы, но за ней стоит признание рынком: то, от чего команды защищались годами без отдельной строки в бюджете, превратилось в категорию, достойную систематической оценки со стороны аналитиков.
22 июля исследователи OX проведут вебинар "How AI Is Reshaping Supply Chain Security As We Know It" – о том, как именно ИИ изменил поверхность атаки. Обещают показать результаты первого системного исследования MCP-серверов в реальных условиях и рассказать, как выглядит программа безопасности цепочки поставок, когда ИИ заложен в неё с самого начала, а не пристёгнут задним числом. Организаторы прямо просят участников приходить с неудобными вопросами.
Три инцидента последних лет стоит вспомнить не ради истории, а потому что они формируют логику происходящего сейчас. SolarWinds показал, как атака на цепочку поставок программного обеспечения может затронуть тысячи организаций через одно скомпрометированное обновление. Log4Shell продемонстрировал, что критическая уязвимость в одной крошечной библиотеке логирования способна парализовать половину корпоративного интернета. XZ Utils – совсем недавняя история про бэкдор, который годами и очень терпеливо внедрялся в открытый проект человеком, годами зарабатывавшим доверие сообщества. Урок из всех трёх один: риск живёт не столько в коде, который пишет команда, сколько во всём, что этот код производит и доставляет.
Дальше появился более свежий урок – кампания под названием Shai-Hulud, самораспространяющийся вредоносный пакет, который в этом году прошёлся по инструментарию разработчиков. Она показала простую вещь: знать, что находится внутри вашего кода, уже недостаточно. Необходимо, но недостаточно – разница принципиальная.
Примерно 20 месяцев назад был запущен Model Context Protocol, MCP. За это время AI-инструменты, модели и вся инфраструктура вокруг них успели превратиться из экспериментальной надстройки в несущие конструкции того, как программное обеспечение пишется, собирается, разворачивается и работает. Код теперь пишут AI-агенты. Пакеты подключают автономные инструменты, которые сами принимают решения о том, что нужно подтянуть в проект. А промпт – обычный текстовый запрос к модели – стал полноценным входным параметром сборки. А значит, и новым вектором атаки, о котором никто не думал, когда проектировались нынешние программы безопасности.
Ошибка, которую легко совершить: воспринимать сгенерированный ИИ код просто как ещё один код и прогонять его через привычные сканеры. Этого мало, и дело не в лени, а в том, что сам вопрос происхождения расширился. Раньше спрашивали: откуда это взялось и можно ли этому доверять – применительно к пакету или библиотеке. Теперь тот же вопрос нужно задавать модели, агенту и инструментам, которые этот агент вызывает. Финальный артефакт кода – только последнее звено в цепочке.
Сценарии, которые раньше казались теоретическими, стали рабочими. AI-ассистент предлагает разработчику зависимость, тот соглашается одним нажатием – и пакет ни разу не проходит через модель угроз человека, потому что человек просто нажал «принять». Автономный агент через MCP вызывает один инструмент, тот вызывает следующий – и выстраивается цепочка непроверенных действий, ни одно звено которой не видел ни один живой сотрудник. Или вредоносный промпт, подброшенный атакующим в контент, который модель прочитает как часть контекста – и этот промпт незаметно направляет, какой код будет написан и какие пакеты будут подключены.
Проверять сгенерированный ИИ код перед коммитом – это уже базовый минимум, само собой разумеющееся требование. Настоящая сложная задача – научиться управлять самими агентами, которые этот код пишут, и инструментами, которые они вызывают по собственной инициативе.
При этом у команд безопасности проблема не в нехватке находок – они и так тонут в потоке предупреждений. Просто добавить ещё одну проверку «давайте сканировать и вывод ИИ тоже» не решает ничего, стопка алертов станет выше, но не станет от этого полезнее.
Здесь нужны два сдвига в подходе. Первый – расширить отслеживание происхождения на всё, что входит в конвейер разработки, включая сами модели и агентов. Прослеживать активность, происхождение и изменения конфигурации от первого коммита до момента, когда код реально работает в проде. Модели и агенты должны проходить ту же строгую проверку, что и любая другая зависимость, без исключений и скидок на новизну технологии.
Второй сдвиг – расставлять приоритеты не по количеству находок, а по реальной эксплуатируемости. Сопоставлять уязвимости с runtime-контекстом: что действительно достижимо и может быть использовано атакующим прямо сейчас. Из сырого списка уязвимостей это превращает работу в анализ реальных цепочек эксплуатации – вещь гораздо более практичная. И это важнее, чем когда-либо, потому что агент способен написать тысячу правдоподобных строк кода ещё до обеда.
В июне Gartner опубликовал свой первый Magic Quadrant по безопасности цепочки поставок программного обеспечения. Формальность, казалось бы, но за ней стоит признание рынком: то, от чего команды защищались годами без отдельной строки в бюджете, превратилось в категорию, достойную систематической оценки со стороны аналитиков.
22 июля исследователи OX проведут вебинар "How AI Is Reshaping Supply Chain Security As We Know It" – о том, как именно ИИ изменил поверхность атаки. Обещают показать результаты первого системного исследования MCP-серверов в реальных условиях и рассказать, как выглядит программа безопасности цепочки поставок, когда ИИ заложен в неё с самого начала, а не пристёгнут задним числом. Организаторы прямо просят участников приходить с неудобными вопросами.