Цепочка поставок больше не состоит только из пакетов
Безопасность цепочки поставок ПО долгое время осмыслялась по определённой модели: компрометируется компонент, многие организации потребляют этот компонент, затем через дерево зависимостей находят затронутые системы. SolarWinds, Log4Shell, вредоносные npm-пакеты, поддельные PyPI-модули и захваченные open-source зависимости — это разные примеры одной модели. Механизм масштабирования атаки очевиден: один и тот же компонент используется во многих кодовых базах.
Но AI-ассистенты программирования меняют эту картину. Здесь то, что компрометируется, не всегда является опубликованным пакетом, open-source зависимостью или build-инструментом. Риск возникает в самом рабочем процессе разработчика. Во время предложения кода, рефакторинга, генерации тестов, исправления ошибок или написания вспомогательной функции AI-ассистент напрямую вносит вклад в код первой стороны.
Этот вклад не выглядит как зависимость. Он не проходит через реестры пакетов. Он не появляется в дереве зависимостей SCA-инструмента. Чаще всего он выглядит как обычный коммит разработчика. Новый вопрос звучит так: если попадающее в код изменение — это не пакет, а предложение AI, как безопасность цепочки поставок это видит?
Инциденты, раскрытые в начале 2026 года, перевели этот вопрос из теоретической плоскости. Anthropic раскрыла, что поддерживаемая государством Китая группа провела скоординированную кампанию, используя Claude Code для проникновения примерно в 30 организаций в технологическом, финансовом и государственном секторах. В тот же период появились и другие отчёты об использовании AI-ассистированных операций против целей в критической инфраструктуре.
Общее у этих инцидентов то, что AI-инструмент перестал быть лишь слоем продуктивности и стал частью цепочки атаки. Главный риск: AI-ассистированный код попадает в кодовую базу через доверенную личность разработчика; но он не всегда заслуживает того же уровня доверия.
Цифры
Раскрыто Anthropic — в технологическом, финансовом, государственном секторах
Voice of Emirates 2026Поддерживаемая государством Китая группа, атрибутировано Anthropic
Заявление AnthropicСбои цепочки поставок ПО — новая категория для 2025 года
OWASP Top 10:2025Новый паттерн атаки: ассистента используют, не компрометируя самого ассистента
В классической атаке на цепочку поставок злоумышленник обычно нацеливается на общий компонент. Отравляется пакет. Захватывается аккаунт мейнтейнера. Манипулируется build-система. Утекает подписывающий ключ. Злоупотребляется канал обновлений. Затем затрагиваются все организации, потребляющие этот компонент.
Паттерн, развивающийся через AI-ассистента программирования, иной. Здесь злоумышленнику не обязательно захватывать самого ассистента. Ассистент используется злоумышленником как инструмент или подвергается влиянию через контексты, направленные в рабочий процесс разработчика. Это более тонкая модель.
Злоумышленник может подготовить промпты, примеры, контексты репозиториев, open-source контент, страницы вопросов-ответов или тексты issue, которые вызовут определённые предложения кода. Цель в том, чтобы AI-ассистент сгенерировал код, выглядящий правдоподобно, но содержащий уязвимость. С точки зрения разработчика процесс обыден — делается рефакторинг, у ассистента запрашивается вспомогательная функция, предложение выглядит разумным, код прочитан, тесты проходят, pull request одобрен.
Однако внутри сгенерированного кода может быть небольшой логический дефект, слабая валидация, путь к SSRF, скрытая утечка данных, ошибочная авторизация или бэкдор, который можно будет использовать позже. Этот код не внешняя зависимость — это собственный код организации. Классический SCA-инструмент не видит ничего.
Проблема именно здесь: атака на цепочку поставок вышла из дерева зависимостей и переместилась в рабочий процесс разработки.
Почему это отличается от классической проблемы цепочки поставок?
Риск, исходящий от AI-ассистента программирования, связан с категорией OWASP A03 «Сбои цепочки поставок ПО». Однако у него не тот же механизм, что у классической атаки на цепочку поставок. Две модели угроз можно рассматривать в одной категории, но способы защиты различаются.
Классическая цепочка поставок vs атака через AI-ассистента программирования
| Измерение | Классическая атака на цепочку поставок | Атака через AI-ассистента программирования |
|---|---|---|
| Компрометируемый элемент | Опубликованная зависимость, пакет, build-инструмент | Предложение AI в рабочем процессе разработчика |
| Способ масштабирования | Один пакет используется во многих организациях | Один ассистент используется многими разработчиками |
| Поступление кода | Поступает как внешняя зависимость | Коммитится как код первой стороны |
| Инструмент обнаружения | SCA, SBOM, подпись, история пакета | Ревью кода, статический анализ, след использования AI |
| Видимость | Виден в дереве зависимостей | Может затеряться в обычном коммите |
| Путь исправления | Обновить пакет, заменить зависимость | Проверить путь кода, провести аудит истории коммитов |
| Источник раскрытия | Исследователь, жертва, система реестра пакетов | Производитель модели, исследование безопасности, внутренний аудит |
| Базовый риск | Отравляется внешний компонент | Внутренний код подвержен влиянию недоверенного предложения |
Это различие порождает критическое последствие со стороны защиты. SCA видит зависимости; но он не выделяет специально код, написанный разработчиком с помощью AI. SBOM перечисляет пакеты; но он не показывает логическую ошибку, сгенерированную движком предложений. Подпись пакета можно проверить; но тонкий бэкдор внутри коммита выглядит как «ваш собственный код». Поэтому риск AI-ассистента программирования — это не просто новый вопрос безопасности инструмента, а точка, в которой необходимо переосмыслить жизненный цикл безопасной разработки.
Что показывают задокументированные инциденты 2026 года?
Инциденты 2026 года показали, что AI-инструменты программирования — не только теоретический риск. Общее послание разных инцидентов было одним: злоумышленники используют AI-инструменты для разработки, разведки, генерации эксплойтов и операционной скорости.
Китайская государственная кампания через Claude Code
Согласно заявлению Anthropic, поддерживаемая государством Китая группа провела скоординированную кампанию, используя Claude Code для проникновения примерно в 30 организаций в технологическом, финансовом и государственном секторах. Примечательно, что раскрытие пришло не от жертвы, а от производителя модели. Но это также указывает на тревожный факт: обнаруженные кампании представляют лишь видимую часть.
AI-ассистированные операции против критической инфраструктуры
В тот же период появились отчёты об использовании моделей вроде Claude в атаках на цели в критической инфраструктуре. В средах критической инфраструктуры для злоумышленника высокую ценность представляют генерация кода, анализ конфигураций, написание скриптов, исследование уязвимостей и операционная автоматизация. Ассистенты программирования должны входить в модель угроз не только команд разработки ПО, но и команд безопасности критической инфраструктуры.
Собственная поверхность атаки Claude Code
В конце 2025-го и начале 2026 года в самом Claude Code были обнаружены некоторые уязвимости — удалённое выполнение кода через недоверенные репозитории и раскрытие API-ключей. Эти инциденты относятся к иному классу риска: не злоупотребление ассистентом, а превращение самого инструмента-ассистента в поверхность атаки. AI-ассистентов программирования нужно оценивать не только с точки зрения «вывода модели», но и как привилегированные инструменты в среде разработки.
Как атака работает на практике?
Атаки через AI-ассистента программирования не однотипны. Однако общий поток можно свести к определённым этапам.
Выбор цели
Сначала злоумышленник пытается определить организации, активно использующие AI-ассистентов программирования. Информацию можно извлечь из открытых источников: названия инструментов в вакансиях, блоги разработчиков, конференционные доклады, сообщения коммитов open-source, публичные записи issue/PR, публикации сотрудников в соцсетях, корпоративные инженерные статьи. Внедрение AI становится не только сигналом продуктивности, но и разведывательным сигналом для подготовки атаки.
Подготовка контекста
Злоумышленник готовит контексты, способные заставить AI-ассистента сгенерировать определённый тип кода. Это может быть прямой промпт; в более тонких сценариях он может быть оформлен как open-source репозиторий, документация, ответ на форуме, описание issue, пример кода или тестовые данные. Рискованные области: вспомогательные функции для URL fetch, уязвимые к SSRF; слабая валидация входных данных; ошибочные проверки обхода авторизации; небезопасная десериализация; генерация запросов, уязвимых к SQL/NoSQL injection; запись credential в логи; утечка token/API-ключа; ошибочный CORS; path traversal; race condition; недостающая изоляция тенантов.
Доставка
Подготовленный злоумышленником контекст может попасть в рабочий процесс разработчика разными путями: пример кода в публичном репозитории, Q&A-контент в стиле Stack Overflow, предложение в GitHub issue, документация open-source зависимости, прямой промпт или фрагмент кода, этап red-team/социальной инженерии. Самого ассистента компрометировать не обязательно — ассистент становится переносчиком плохо подготовленного контекста.
Разработчик принимает предложение
Самая критическая точка атаки. AI-ассистент предлагает код. Разработчик проверяет — стилистически разумен, функционально верен, кажется проходящим тесты. PR одобряется. Во многих организациях AI-ассистированный код не подвергается более высокому уровню ревью, чем написанный человеком. Иногда даже наоборот — сгенерированный AI код принимается быстрее, потому что выглядит «стандартным» или «вспомогательным». Это ошибочное предположение — AI-ассистированный код может нести внешние влияния из-за модели-производителя, контекста промпта и использованных источников.
Выход в продакшен и эксплуатация
Когда внедрённая уязвимость попадает в продакшен, злоумышленник может эксплуатировать её классическими способами. Со стороны атака может выглядеть как обычный веб-эксплойт, злоупотребление API, обход авторизации или утечка данных. Команда реагирования на инциденты сначала фокусируется на внешней поверхности атаки. Но корневой причиной может быть AI-ассистированное изменение, слитое недели или месяцы назад — это затрудняет атрибуцию, потому что уязвимость пришла не из внешней зависимости, а из собственной истории коммитов организации.
Закрепление и ретроспективный аудит
Одна из самых сложных сторон AI-ассистированной атаки — ретроспективный аудит. Когда появляется раскрытие об инструменте или возникает определённый паттерн злоупотребления, организация должна задать вопросы: в каких командах использовался этот ассистент, в каких репозиториях, какие коммиты были AI-ассистированными, какие чувствительные с точки зрения безопасности пути изменились, какие предложения были приняты напрямую, какие изменения вышли в продакшен, какие сервисы выполняют этот код. Большинство организаций не может ответить быстро — использование AI системно не помечается.
Почему существующие защиты остаются недостаточными?
В риске цепочки поставок, исходящем от AI-ассистента программирования, пробел в защите — это не только нехватка инструментов, но и пробел в процессе. Выделяются три основные проблемы.
SCA не видит код первой стороны
Инструменты Software Composition Analysis спроектированы для сканирования зависимостей — они изучают имена пакетов, версии, соответствия CVE, лицензии и известные риски. Но код, сгенерированный AI-ассистентом и закоммиченный разработчиком, не зависимость — он выглядит как собственный код организации. SCA сам по себе не может поймать этот класс атак. SCA всё ещё необходим, но не следует предполагать, что он покрывает риск AI-ассистированного кода.
Статический анализ ловит не каждую логическую ошибку
Инструменты SAST могут поймать многие очевидные ошибки безопасности — паттерны injection, hardcoded secret, небезопасную десериализацию, path traversal. Но если злоумышленник намеренно проектирует тонкие логические ошибки, уязвимости в edge-кейсах или стилизованные бэкдоры, статического анализа недостаточно. Особенно сложны: ошибки изоляции тенантов, пробелы в контроле полномочий, обходы бизнес-логики, условные утечки данных, зависящие от времени уязвимости, сложные взаимодействия микросервисов.
Ревью кода не отделяет генерацию AI
Во многих организациях процесс ревью кода не отделяет AI-ассистированный код от написанного человеком. Это само по себе рискованно — сгенерированный AI код следует рассматривать как вклад извне. Разработчик может быть внутренним и доверенным; но модель, контекст и источники, использованные в процессе создания кода, могут быть открыты для внешнего влияния. «Разработчик доверенный» не значит «код доверенный». AI-ассистированный код требует более строгой дисциплины ревью, особенно в чувствительных к безопасности областях.
Что должны изменить организации?
Полностью запретить AI-ассистентов программирования для большинства организаций нереалистично. Преимущество в продуктивности велико, и разработчики продолжат использовать эти инструменты. Правильный подход — не запрет, а выстраивание дисциплины безопасности в зависимости от контекста использования.
Шесть конкретных изменений
Отдельно помечайте сгенерированные AI изменения
Первое требование — видимость. Организация должна знать, какие изменения кода были сгенерированы с помощью AI. Информацию можно хранить в описаниях PR, метаданных коммитов, интеграциях платформы разработки или внутренних политических метках. Цель не в наказании разработчика — а в оставлении следа для последующего разбора инцидентов и проверки безопасности. Когда появляется новое раскрытие об AI-инструменте, организация должна быстро находить, какие репозитории могут быть затронуты.
Проверяйте AI-ассистированный код как внешний вклад
AI-ассистированный код, даже закоммиченный внутренним разработчиком, должен подчиняться дисциплине внешнего вклада. Это особенно справедливо в следующих областях: аутентификация, авторизация, сетевой доступ, обработка файлов, десериализация, криптография, управление секретами, валидация входных данных, экспорт данных, изоляция тенантов, платёжные потоки. В этих областях AI-ассистированные изменения должны проходить ревью у старшего разработчика или инженера безопасности.
Определите дополнительные шлюзы безопасности в CI/CD
Дополнительные проверки в CI/CD-пайплайне для AI-ассистированных коммитов: SAST, secret scanning, dependency scanning, IaC scanning, валидация API-контракта, обязательное покрытие тестами, аудит использования рискованных функций, дополнительное одобрение при изменении чувствительных с точки зрения безопасности файлов, заметка о моделировании угроз. Важно не автоматическое признание AI-ассистированного кода плохим — а его прохождение через дополнительные шлюзы безопасности в рискованных областях.
Создайте контекстно-зависимую политику использования AI
Две крайние политики вроде «AI свободно» или «AI запрещён» слабы. Более правильный подход — контекстно-зависимая политика: исследовательский прототип — свободно + базовое ревью, внутренний инструмент — контролируемо + SAST + code review, приложение, обращённое к клиентам — ограниченно + ревью безопасности, код identity/auth — высокое ограничение + старшее ревью + threat model, криптография — очень ограниченно + одобрение эксперта, управление секретами — очень ограниченно + одобрение команды безопасности, производственная инфраструктура — контролируемо + IaC scanning. Эта модель защищает рискованные области, не отключая полностью продуктивность разработчика.
Логируйте использование AI-ассистента на уровне команды
AI-инструменты программирования находятся в привилегированной позиции в среде разработки — могут получать доступ к контексту репозитория, читать код, генерировать предложения, работать рядом с контекстом терминала/тестов/локальных файлов/API-ключей. Следует логировать: какие команды какой AI-инструмент используют, в каких репозиториях он активен, к каким branch/PR прикасался, в файлах каких типов генерировал предложения, к каким чувствительным с точки зрения безопасности областям прикасался, какие предложения были приняты напрямую, какая версия какой модели использовалась. Критично для последующего реагирования на инциденты.
Стилевые аномалии + интерпретация OWASP A03
Сгенерированный AI код несёт стилевые следы — предпочтения в именовании, форму обработки ошибок, структуру комментариев, расположение тестов. Элементы, которые стоит помечать: стиль кода, явно отличающийся от командных привычек; внезапный рефакторинг в чувствительных с точки зрения безопасности модулях; вспомогательные функции с широкими полномочиями; молча проглатываемые ошибочные состояния; удаление проверок авторизации. В рамках OWASP Top 10:2025 «Сбои цепочки поставок ПО» не следует мыслить только в пределах зависимостей npm, PyPI или container image — AI-ассистенты программирования тоже часть цепочки производства ПО и требуют оценки производителя.
Контекстно-зависимая политика использования AI
Практический пример того, как политика может меняться в зависимости от контекста — защищать рискованные области, не мешая продуктивности в областях низкого риска.
| Контекст | Использование AI | Дополнительный контроль |
|---|---|---|
| Исследовательский прототип | Свободно | Базовое ревью |
| Внутренний инструмент | Контролируемо | SAST + code review |
| Приложение, обращённое к клиентам | Ограниченно | Ревью безопасности |
| Код identity/auth | Высокое ограничение | Старшее ревью + threat model |
| Криптография | Очень ограниченно | Одобрение эксперта |
| Управление секретами | Очень ограниченно | Одобрение команды безопасности |
| Производственная инфраструктура | Контролируемо | IaC scanning + одобрение изменений |
AI-ассистенты программирования не делают безопасную разработку излишней. Напротив, они делают дисциплину безопасной разработки ещё более важной. Объём генерируемого кода растёт. Скорость рефакторинга растёт. Число вспомогательных функций растёт. Один разработчик может производить больше изменений за то же время. Это хороший прирост продуктивности; но если вместе с ним не масштабируется и пропускная способность ревью, вероятность пропустить уязвимость возрастает. Организациям следует отказаться от предположения: «если AI ускоряет код, ревью может оставаться прежним». Более правильное предположение: если AI ускоряет генерацию кода, должны масштабироваться и ревью, и верификация. Это не больше бюрократии — а более прицельный контроль.
Где TR7 находится в картине защиты
В риске цепочки поставок, исходящем от AI-ассистента программирования, первичная защита находится внутри рабочего процесса разработки — ревью кода, политика использования AI, контроли CI/CD и дисциплина безопасной разработки являются первой линией защиты. TR7 не заменяет этот процесс. Роль TR7 — снизить воздействие, когда внедрённая уязвимость достигает продакшена, вывести на поверхность попытки эксплуатации и ограничить радиус поражения.
WAF для распространённых внедрённых уязвимостей
Если внедрённая в AI-ассистированный код уязвимость относится к классу SSRF, SQL injection, десериализации, path traversal или слабой валидации входных данных, TR7 WAF может поймать значимую часть этих попыток эксплуатации. WAF не устраняет лежащую в основе ошибку; код всё равно нужно исправить. Но он снижает попытки эксплуатации в продакшене и обеспечивает команде безопасности видимость.
AGS ограничивает полномочия скомпрометированного пути
Когда уязвимость достигает продакшена, то, к каким данным и системам сможет получить доступ злоумышленник, определяется моделью идентификации и полномочий. TR7 AGS ограничивает доступ к приложению через идентификацию, контекст и политику. Скомпрометированный путь не даёт автоматического доступа ко всей поверхности приложения или внутренним системам — особенно важно для auth-уязвимостей, внедрённых через AI-ассистированный код.
ZeroLeak для высокоценных поверхностей
В некоторых приложениях уязвимость, ускользнувшая на уровне кода, может приводить к неприемлемым последствиям — административные консоли, финансовые порталы, экраны клиентских PII, системы юридических документов. ZeroLeak рендерит эти высокоценные приложения в изолированной среде, а не на устройстве пользователя. Зона воздействия внедрённого бэкдора или клиентской поверхности атаки остаётся более ограниченной.
Форензическое логирование для оценки масштаба
Когда инцидент прослеживается до AI-ассистированного изменения, самый критический вопрос — масштаб. Форензическое логирование и наблюдаемость сессий TR7 ускоряют оценку масштаба после инцидента — полные логи запросов/ответов, события WAF, контекст идентификации, записи сессий и аналитика трафика, рассматриваемые вместе, позволяют командам безопасности понять корневую причину в коде и реальное воздействие на продакшен.
Сетевая сегментация снижает радиус поражения
Когда уязвимость, внедрённая AI-ассистированным кодом, эксплуатируется, следующей целью злоумышленника обычно становится горизонтальное перемещение. Микросегментация на сетевом и прикладном уровне ограничивает это перемещение — скомпрометированный компонент может достичь только тех систем, которые ему нужны. Несвязанные сервисы, административные панели и хранилища данных по умолчанию недоступны. Это снижает риск «одна уязвимость — вся среда».
Аналитика в реальном времени для обнаружения паттернов
Если внедрённая уязвимость достигает продакшена, первый сигнал обычно проявляется в аномалиях паттернов трафика — необычный всплеск запросов к определённой конечной точке, неожиданные комбинации параметров, новые коды ошибок, аномальный доступ к данным от одного пользователя. Слой аналитики в реальном времени TR7 выводит эти паттерны на поверхность.
Заключение: код AI не является доверенным вводом
AI-ассистенты программирования повышают скорость разработки ПО. Этот факт не изменится. Организации будут использовать эти инструменты; разработчики будут быстрее прототипировать, рефакторить, исправлять баги. Но прирост продуктивности не отменяет автоматически предположения безопасности.
AI-ассистированный код, даже закоммиченный под доверенной личностью разработчика, не следует считать доверенным. Контекст, в котором был сгенерирован код, использованная модель, промпт, содержимое репозитория и внешние источники являются частью поверхности атаки.
Поэтому безопасность цепочки поставок больше не может ограничиваться только сканированием пакетов. Новая цепочка поставок включает также: ассистентов программирования, контексты промптов, AI-ассистированные коммиты, рабочие процессы разработчиков, заявления производителя модели об инцидентах, права доступа к репозиториям, шлюзы безопасности CI/CD, логи использования AI, дисциплину ревью кода.
Правильный подход — не запретить использование AI. Правильный подход — сделать AI-ассистированный код видимым, поддающимся аудиту и риск-зависимым вводом в разработке. Классическая безопасность цепочки поставок спрашивала: «какой пакет мы используем?». В 2026 году добавляется вопрос: кто написал этот код, какой инструмент помог и как был верифицирован вывод этого инструмента?
Источники
Новость об использовании модели Claude в кибератаке и глобальной реакции. https://www.voiceofemirates.com/en/science-and-tech/2026/05/12/ai-in-the-hands-of-hackers-use-of-claude-model-in-cyberattack-sparks-global-alarm/
Отчёт об уязвимостях Claude Code за февраль 2026 года и паттернах злоупотребления. https://thehackernews.com/2026/02/claude-code-flaws-allow-remote-code.html
Независимая новость о последствиях для безопасности. https://www.darkreading.com/application-security/flaws-claude-code-developer-machines-risk
Отраслевой анализ ландшафта безопасности AI-ассистентов программирования. https://seceon.com/claude-code-vulnerability-exposes-new-ai-security-risks/
Рамка категории, теперь распространяющаяся и на цепочку поставок AI-инструментов. https://owasp.org/Top10/2025/0x00_2025-Introduction/
Документ от апреля 2026 года об AI-инструментах как активной поверхности атаки. https://www.microsoft.com/en-us/security/blog/2026/04/02/threat-actor-abuse-of-ai-accelerates-from-tool-to-cyberattack-surface/
Включите AI-ассистированную генерацию кода в процесс безопасности
Когда AI-ассистенты программирования становятся частью рабочего процесса разработки, процесс безопасности должен обновляться соответственно. AI-ассистированные изменения следует помечать, строже проверять в чувствительных с точки зрения безопасности областях, прогонять через контроли CI/CD и оставлять след для аудита после инцидентов. TR7 — через WAF, AGS, ZeroLeak, форензическое логирование, микросегментацию и аналитику в реальном времени — помогает снизить воздействие уязвимостей, достигающих продакшена. Первичная защита — это процесс безопасной разработки; защита на прикладном уровне — последняя страховочная сеть.
Изучить архитектуру TR7 WAAP