agent-supply-chain

Этот официальный навык GitHub предназначен для проверки целостности AI-agent plugins, MCP tools и других каталогов с агентными компонентами. Его основной артефакт — детерминированный INTEGRITY.json: для каждого файла вычисляется SHA-256, а затем из хешей в отсортированном порядке строится общий chain hash. Позже тот же каталог можно пересчитать и сравнить с manifest. Совпадение означает, что зафиксированный набор файлов не изменился; несовпадение показывает, что нужно разбираться с изменением, пропажей или появлением файла. Генератор обходит файлы рекурсивно, сортирует относительные POSIX-пути и исключает .git, __pycache__, node_modules, .venv и .pytest_cache, а также .DS_Store, Thumbs.db и сам INTEGRITY.json. В manifest попадают имя плагина, время генерации, алгоритм, число файлов, отображение путь–хеш и manifest_hash. Имена и значения не должны зависеть от случайного порядка обхода. Исключения важны: кэш, окружения и сам производный manifest не становятся частью проверяемой полезной нагрузки. Если состав каталога меняется намеренно, manifest нужно пересоздать после review. Проверка integrity сначала читает существующий INTEGRITY.json. Для каждой записанной позиции она различает MISSING, когда файла больше нет, и MODIFIED, когда рассчитанный хеш отличается. Затем текущий обход выявляет UNTRACKED-файлы, которых не было в manifest. Такой отчёт помогает сделать результат операционным: можно увидеть, какие именно файлы затронуты, вместо общего сообщения о несоответствии. Сам навык не доказывает происхождение автора, качество кода, безопасность команды или доверенность внешнего сервиса; это контроль соответствия локального состояния ранее зафиксированному состоянию. Отдельный паттерн проверяет pinning зависимостей. Для package.json обнаруживаются версии с ^, ~, * и latest; wildcard и latest имеют более высокий риск, чем диапазон с мажорной границей. Для requirements.txt и pyproject.toml отмечаются записи с >= без верхней границы. Это эвристический аудит конфигурации, а не универсальный dependency resolver: он подсказывает, где результат установки может меняться, и предлагает перейти к более узкому ограничению. Для MCP-конфигурации promotion gate также проверяет аргументы с @latest, если они присутствуют. Promotion check объединяет несколько условий. Сначала должен существовать и проходить integrity manifest. Затем проверяются README.md и один из поддерживаемых plugin manifest путей — .github/plugin/plugin.json или .claude-plugin/plugin.json. Если найден .mcp.json, его аргументы анализируются на неприкреплённые latest-зависимости. Готовность promotion возвращается только при прохождении всех активных проверок; отсутствие обязательного файла или найденная проблема остаются явным failed-результатом. Workflow можно встроить в CI: после выбора каталога runner читает INTEGRITY.json, пересчитывает SHA-256 для каждой записи, завершает job с ошибкой при MISSING или MODIFIED и печатает число проверенных файлов. Практический момент — manifest создают после code review и проверяют перед promotion, чтобы контроль относился к той версии, которую действительно согласовали. Полезны также version pinning и цепочка provenance между dev, staging и production. При этом SHA-256 manifest не заменяет review, тесты, разрешения, подписи поставщика, SLSA/Sigstore или threat model. Навык фиксирует наблюдаемое состояние файлов и помогает обнаружить локальную подмену, но не превращает внешний плагин в автоматически безопасный.