Коротко: криптографически подписанный пакет может быть вредоносным, если атакующий захватил легитимный конвейер сборки или его временную идентичность. Поэтому ИИ-агенту нельзя разрешать установку только по наличию подписи или provenance. Решение должно приниматься до исполнения install-скрипта и отдельно проверять имя, источник, версию, ожидаемый builder, поведение пакета и полномочия среды.
Материал предназначен для CTO, руководителей разработки, DevSecOps-команд и владельцев AI coding agents. В scope входят npm, PyPI и похожие реестры, CI/CD и рабочие станции разработчиков. Статья не доказывает распространённость одной техники во всех компаниях, не заменяет анализ конкретного инцидента и не обещает абсолютную защиту цепочки поставки.
Содержание
- Что произошло в сентябре 2026 года
- Почему подпись не равна безопасности
- Как ИИ-агент меняет точку риска
- Какие проверки нужны до установки
- Что именно проверять в provenance
- Метод ДОПУСК
- Как настроить режимы allow, quarantine и block
- Как провести пилот
- Какие метрики собирать
- Что делать при подозрительной установке
- Ограничения доказательств
- Частые вопросы
- Как AIrassvet помогает встроить контроль зависимостей
- Вывод
Что произошло в сентябре 2026 года
8 сентября Google Threat Intelligence Group опубликовала AI Threat Tracker, основанный на данных Mandiant incident response, наблюдениях за группами и защите платформ Google. В отчёте описана UNC6780: с марта 2026 года группа проводила атаки на PyPI, npm и Docker Hub, компрометировала аккаунты разработчиков и распространяла троянизированные пакеты и форки MCP-серверов.
Особенно важен механизм обхода доверия. Вредонос DUSTMAKER извлекал OIDC-токены из памяти GitHub Actions runner, после чего публиковал пакеты как trusted publisher. По данным GTIG, такие версии получали криптографически валидные SLSA Build 3 attestations и могли пройти автоматическую проверку ИИ-агента. Отдельно вредонос прятал команды в .claude/, .vscode/ и .cursor/, а также добавлял prompt injection в JavaScript-комментарии, чтобы LLM-сканер отказался анализировать следующий код.
В том же отчёте есть более широкий сигнал скорости. Подозреваемый финансово мотивированный актор использовал AI-чат, промпт и набор инструкций, чтобы менее чем за шесть часов спланировать, собрать и запустить массовый сбор учётных данных. Фреймворк сам управлял сканированием, устранял ошибки и менял IP без ручного вмешательства; позднее открытый C2-сервер показывал панель для управления более чем 23 800 собранными секретами.
Эти числа нельзя превращать в среднюю вероятность атаки: GTIG не раскрывает полный знаменатель всех расследований, а Google одновременно продаёт защитные продукты. Но наблюдение меняет инженерный вопрос. Важно не только «подписан ли пакет», а какую границу доверия покрывает подпись и что успеет выполниться до следующей проверки.
Почему подпись не равна безопасности
Подпись, provenance, одобрение исходника и безопасность поведения отвечают на разные вопросы.
| Сигнал | Что он подтверждает | Чего он не подтверждает |
|---|---|---|
| хеш | полученные байты совпадают с ожидаемыми | кто и зачем их создал |
| цифровая подпись | артефакт подписан конкретной идентичностью | что идентичность не была захвачена |
| build provenance | где, когда, из какого source и каким builder создан артефакт | что source и workflow были добросовестными |
| source provenance и review | какой процесс изменения исходника соблюдён | что runtime-поведение безопасно в вашей среде |
| sandbox-анализ | что пакет делал в тестовой среде | что все ветви поведения проявились |
| локальная policy | допустим ли пакет для конкретного проекта | что он безопасен вообще |
SLSA 1.2 определяет provenance как проверяемые сведения о том, где, когда и как произведён программный артефакт. Build Track повышает доверие к сборке и её описанию, а Source Track — к процессу создания revision. Это полезные гарантии, но потребитель всё равно должен знать, какой builder, source, ref, параметры и уровень SLSA он ожидает.
Разбор OpenSSF Mini Shai-Hulud: Where SLSA’s Boundaries Fall показывает эту границу на конкретном инциденте. В мае 2026 года были скомпрометированы 84 артефакта в 42 пакетах @tanstack, а распространение затронуло более 170 пакетов. Аттестации были валидны, потому что атакующий получил легитимный OIDC-токен. Они точно записали наблюдаемую сборку — проблема была внутри доверенного конвейера.
Практический вывод: provenance — это доказательство происхождения, а не сертификат добрых намерений. Даже более строгая изоляция builder не оценивает смысл исходного кода. Корень доверия не исчезает; он перемещается в платформу сборки, правила source review и политику потребителя.
Как ИИ-агент меняет точку риска
Человек обычно видит команду pip install или изменение package.json перед запуском. ИИ-агент способен прочитать README, выбрать библиотеку, изменить lockfile и выполнить установку в одном цикле. Если проверка происходит после команды, install hook уже мог получить доступ к исходникам, переменным окружения, SSH-ключам, registry-токенам или облачной идентичности.
Предварительная работа Understanding Security Risks of AI Agents’ Dependency Updates проанализировала 117 062 изменения зависимостей в pull request по семи экосистемам. В выбранной авторами выборке агенты чаще людей выбирали известные уязвимые версии: 2,46% против 1,64%; 36,8% таких агентных выборов требовали major upgrade для исправления против 12,9% у человеческих. Это корреляционное исследование реальных PR, а не рандомизированный эксперимент, поэтому оно не доказывает, что агент сам вызвал разницу.
Другой preprint, Setup Complete, Now You Are Compromised, проверил 12 сценариев пяти классов на девяти комбинациях harness и модели. В сценарии с уязвимой закреплённой версией все девять конфигураций устанавливали её во всех прогонах — 0 из 30 предотвращений для каждой конфигурации. Модель могла назвать CVE после установки, но это уже не предотвращение. Детерминированный pre-install hook примерно из 400 строк проверял имя, существование, возраст, источник, скрытые директивы, конфигурацию и OSV до запуска команды.
Обе работы предварительные и не измеряют production-инциденты. Их ценность — в воспроизводимой границе: безопасность определяется не только моделью, а сочетанием модель + harness + права среды + момент enforcement.
Какие проверки нужны до установки
Минимальный gate должен срабатывать до скачивания с исполнением и до install/build hooks. Проверки полезно разделить по типу отказа.
| Проверка | Пример правила | Решение при неизвестности |
|---|---|---|
| имя | точное имя из approved manifest; защита от typo/slopsquatting | quarantine |
| реестр | только утверждённый registry для scope и проекта | block |
| версия | lockfile/digest, отсутствие запрещённой CVE, допустимый возраст | quarantine или block |
| provenance | ожидаемые builder, repository, workflow, ref и SLSA level | block при несовпадении |
| source control | защищённая ветка, требуемое review, связанный commit/tag | quarantine |
| содержимое | новые install scripts, обфускация, секреты, сеть, shell | sandbox и ручное решение |
| контекст | пакет нужен для заявленной задачи и разрешённой лицензии | reject или запрос человеку |
| среда | установка без production-секретов и write-доступа | block до изоляции |
OpenSSF в материале What Is a Dependency Firewall? рекомендует проверять прямые и транзитивные зависимости до исполнения, а не ограничиваться ночным сканированием. Среди сигналов: новое имя или версия, необычная смена maintainer, новый install script, неожиданный рост размера, несоответствие release исходному commit, обфускация и сетевые обращения.
Ни одно правило не достаточно само по себе. Возраст пакета в 24–72 часа может дать время threat intelligence обнаружить кампанию, но задерживает срочный security patch. Allowlist снижает пространство выбора, но может сохранить уже скомпрометированную версию. Sandbox уменьшает последствия, но не гарантирует проявление условного payload. Поэтому политика должна собирать несколько независимых сигналов.
Для соседних уровней контроля полезны материалы «Безопасность навыков ИИ-агентов» — о проверке skills, плагинов и MCP-компонентов — и «Обвязка ИИ-агента» — о разделении модели, runtime, инструментов и evaluation harness.
Что именно проверять в provenance
Проверка «attestation exists = true» слишком слабая. Для каждого экосистемного пакета нужна ожидаемая политика.
- Subject: digest скачанного артефакта совпадает с аттестацией.
- Source: repository и commit/ref принадлежат ожидаемому проекту.
- Builder: используется разрешённый builder и конкретный workflow.
- Parameters: параметры сборки не расширяют поверхность неожиданным образом.
- SLSA level: заявленный уровень действительно оценён для build platform, а не выведен из наличия подписи.
- Run outcome: публикация из failed или cancelled workflow создаёт отдельный alert.
- Source controls: branch protection, review и идентичности соответствуют вашей policy.
- Consumer decision: результат верификации связан с exact digest и конкретной средой, а не бессрочно доверяет имени пакета.
В разборе OpenSSF вредоносные публикации происходили из workflow runs со статусом failure. Стандартная provenance-проверка это не учитывала, но сопоставление publish event с итогом run могло обнаружить аномалию в течение минут. Это пример сигнала, который находится между формальной аттестацией и операционным мониторингом.
Метод ДОПУСК
Предлагаем метод ДОПУСК — редакционный синтез SLSA, OpenSSF и наблюдений GTIG, а не отдельный отраслевой стандарт.
- Д — зависимость (dependency). Зафиксируйте точное имя, scope, registry, версию или digest, прямую/транзитивную роль и владельца внутри компании.
- О — происхождение. Проверьте source, expected builder, workflow, ref, provenance и source-review evidence; валидная, но неожиданная цепочка не проходит.
- П — политика до исполнения. Перехватывайте команды package manager и изменения manifest до install scripts; заранее определите allow, quarantine, block и exception.
- У — урезанная среда. Запускайте неизвестное без production-секретов, signing identity, облачных прав и записи в основные репозитории; ограничьте сеть и файловую систему.
- С — сигналы поведения. Ищите обфускацию, shell/network/file access, новые hooks, смену maintainer, молодой release, failed build с publish event и расхождение rebuilt artifact.
- К — карантин и контроль последствий. Свяжите решение с digest, сохраните журнал, предусмотрите revoke токенов, очистку runner/cache, откат lockfile и повторную сборку из доверенного source.
Метод специально разделяет доказательство и разрешение. Подпись входит в «О», но окончательное решение принадлежит «П» и зависит от среды «У» и сигналов «С».
Как настроить режимы allow, quarantine и block
Одна бинарная политика либо тормозит разработку, либо пропускает слишком многое. Практичнее назначать режим по сочетанию риска и доказательств.
| Режим | Когда применять | Что делает агент |
|---|---|---|
| allow | digest закреплён, source/builder ожидаемые, версия ранее принята | устанавливает в ограниченной среде и логирует |
| quarantine | новый release, новый maintainer, новая транзитивная зависимость, неполная provenance | скачивает без исполнения, строит SBOM, запускает анализ, ждёт решения |
| block | неожиданный registry, известный malware/CVE по policy, provenance mismatch, скрытый install hook | не выполняет команду, сохраняет evidence и предлагает безопасную альтернативу |
| exception | срочный patch с измеримым риском ожидания | запрашивает владельца, ограничивает TTL и scope, планирует повторную проверку |
Человеческое одобрение не должно быть кнопкой «продолжить всё». Оно связывается с exact package digest, проектом, задачей, средой и сроком. Изменение любого из этих полей требует нового решения.
Как провести пилот
Пилот можно провести на одном репозитории без немедленного блокирования всей команды.
- Неделя наблюдения. Логируйте запросы агента к package manager, manifest/lockfile diffs, registry, версии и install scripts. Секреты в журнал не копируйте.
- Теневая policy. Рассчитывайте allow/quarantine/block, но не останавливайте команды; разберите ложные срабатывания с владельцами платформы и AppSec.
- Блокировка очевидного. Запретите неожиданные registries, известный malware, несуществующие имена и несовпадение digest/provenance.
- Карантин нового. Добавьте анализ новых версий, maintainer changes, source-review и поведения в sandbox.
- Инцидентное упражнение. Смоделируйте stolen publisher token, публикацию из failed workflow и prompt injection в README; измерьте обнаружение, изоляцию и revoke.
- Расширение scope. Подключайте следующие репозитории только после устойчивого exception-процесса и подтверждённого восстановления.
Проверяйте не только npm или PyPI на ноутбуке. Тот же gate нужен в CI, container build, devcontainer и agent sandbox: обход через другую точку установки разрушает единую policy.
Какие метрики собирать
| Метрика | Как считать | Зачем |
|---|---|---|
| install requests | все запросы агента и человека к package manager | базовый знаменатель |
| pre-execution block rate | блокировки до первого исполняемого hook / запросы | отличает предотвращение от сообщения после факта |
| quarantine precision | подтверждённо рискованные / разобранные quarantine | показывает шум policy |
| exception latency | время от запроса до ограниченного решения | контролирует влияние на delivery |
| provenance mismatch rate | неожиданные source/builder/ref / проверенные пакеты | выявляет дрейф цепочки |
| secret exposure window | от первого исполнения до revoke/изоляции | измеряет возможный blast radius |
| reproducible rebuild match | совпавшие независимые rebuild / попытки | усиливает доверие к artifact |
| bypass attempts | установки вне утверждённых точек / все установки | проверяет полноту enforcement |
Не объединяйте их в один «security score» без заранее заданной функции потерь. Нулевая доля блокировок может означать чистый поток или неработающий контроль; высокая — эффективное предотвращение или непригодную policy. Решение принимается по набору метрик и разобранным случаям.
Что делать при подозрительной установке
Если пакет уже исполнился, удаление строки из manifest недостаточно.
- Остановите agent session, CI job и связанные runners; сохраните логи и digest.
- Отзовите доступные среде OIDC, registry, GitHub, cloud и API credentials.
- Проверьте workspace hooks, скрытые каталоги IDE/агента, workflow files, caches и startup configuration.
- Сопоставьте publish event, build run, commit, builder и сетевые обращения.
- Пересоберите окружение из чистого образа и утверждённого lockfile; не доверяйте только локальному uninstall.
- Найдите все проекты и артефакты с тем же digest, транзитивной версией или publisher identity.
- После containment обновите policy и повторите exercise с тем же вектором.
Это общий инженерный порядок, а не forensic-рецепт для любого инцидента. В реальной атаке scope и сохранение доказательств должны определять incident response и юридические требования организации.
Ограничения доказательств
- GTIG сообщает о реальных наблюдениях, но не раскрывает полный датасет и знаменатели, а также является подразделением поставщика AI и security-продуктов.
- Формулировка GTIG о «SLSA Build 3 attestations» отличается от разбора OpenSSF майского инцидента, где npm provenance оценена как Build L2, а платформа не выполнила требования L3 isolation. Статья не смешивает эти два эпизода и не считает наличие строки SLSA доказательством уровня.
- Оба академических исследования — preprint. Выборки PR и лабораторные сценарии не дают частоту production-компрометаций.
- Dependency firewall закрывает точку установки, но не заменяет code review, SBOM, SCA, patching, endpoint protection, изоляцию сборки и incident response.
- Российские production-данные о частоте таких атак, стоимости контроля, влиянии на скорость выпуска и ROI не наблюдались.
Search volume, keyword difficulty, текущие позиции, traffic, CTR, backlinks и AI citations также Unknown. Статья описывает проверяемую архитектуру контроля, а не прогноз SEO- или бизнес-результата.
Частые вопросы
Достаточно ли проверить цифровую подпись пакета?
Нет. Подпись подтверждает связь артефакта с идентичностью, но идентичность или pipeline могли быть захвачены. Нужны expected source/builder/ref, source controls, анализ содержимого и локальная policy.
Что такое dependency firewall для ИИ-агента?
Это контроль до установки, который перехватывает запрос к package manager, проверяет имя, источник, версию, provenance и policy и разрешает, изолирует или блокирует пакет до исполнения его кода.
Почему проверка после установки опаздывает?
Install-скрипт уже мог прочитать секреты, изменить workspace, открыть сеть или закрепиться в конфигурации агента. Сообщение о CVE после выполнения документирует риск, но не предотвращает его.
Нужно ли запрещать ИИ-агенту устанавливать любые зависимости?
Не обязательно. Для известных закреплённых digest можно использовать allow, для новых и неполностью проверенных версий — quarantine, для явных нарушений policy — block, а для срочных исключений — ограниченное одобрение с TTL.
SLSA Build L3 решает проблему полностью?
Нет. L3 усиливает изоляцию build platform и защищает от ряда подмен конвейера, но не определяет, добросовестен ли исходный код. Нужны Source Track, consumer policy и runtime-анализ.
Какие данные нельзя отдавать агентной среде установки?
По умолчанию убирают production-секреты, долгоживущие registry/cloud tokens, signing identity и широкую запись в репозитории. Точный набор зависит от задачи и threat model компании.
Как AIrassvet помогает встроить контроль зависимостей
AIrassvet может помочь встроить безопасный execution path в проект с AI-агентами:
- описать один процесс разработки, его package managers, registries, agent tools, текущие права и критерий приёмки;
- собрать MVP с перехватом install-команд, policy для allow/quarantine/block, журналом и ограниченными approvals;
- интегрировать контроль с CI/CD, контейнерной средой и корпоративными системами без расширения прав модели;
- провести тестирование сценариев, запуск, обучение команды и передачу владельцам артефактов контроля.
Первый шаг — выбрать один репозиторий, зафиксировать baseline установок, источники зависимостей, ограничения и критерий принятого результата. Обсудить задачу.
Вывод
Свежие данные GTIG показывают, что атакующие уже используют агентные конвейеры, крадут идентичности публикации и воздействуют на AI coding environments. Формальные подписи остаются необходимыми, но их надо читать как ограниченное доказательство, а не как универсальный знак безопасности.
Практический порядок таков: точная зависимость → ожидаемое происхождение → policy до исполнения → урезанная среда → сигналы поведения → карантин и контроль последствий. ИИ-агент может выбирать и устанавливать пакеты только тогда, когда организация способна доказать, какой exact artifact был разрешён, почему он прошёл gate и как ограничен ущерб при ошибке.