Безопасность open source в Astral

Astral (компания, создавшая Ruff, uv и ty) подробно описывает свой подход к supply-chain-security: как они защищают GitHub Actions, релизы, управляют зависимостями и работают с социальной стороной безопасности в open source. Материал непривычно конкретен - вместо абстрактных принципов в нём описаны точные меры контроля, инструменты и конфигурации, которые могут перенять другие проекты.

CI/CD: исходить из враждебности GitHub Actions

У GitHub Actions небезопасные настройки по умолчанию. Инциденты с компрометацией Ultralytics, tj-actions и Nx использовали хорошо известные уязвимости. Ответ Astral - эшелонированная защита (defense in depth) на каждом уровне.

Запрет опасных триггеров. Триггеры pull_request_target и workflow_run запрещены на уровне всей организации. Оба открывают привилегированным секретам доступ к путям исполнения кода, на которые могут повлиять сторонние контрибьюторы. Для задач, где эти триггеры кажутся необходимыми (например, оставить комментарий во внешнем PR), Astral использует собственное GitHub App.

Фиксация action'ов по SHA коммита. Мутабельные теги позволяют злоумышленникам при компрометации upstream'а незаметно подменить код, выполняемый в ваших workflow. Astral фиксирует каждый action по полному хешу коммита, контролирует это политикой GitHub и проверяет аудитом zizmor через проверки unpinned-uses и impostor-commit. Утилита pinact автоматизирует эту фиксацию.

Но у фиксации по хешу есть уязвимое место: код зафиксированного action'а сам может скачивать свежий бинарник latest без проверки. Astral сотрудничает с upstream-проектами, чтобы внедрять криптографические хеши, сопоставляющие URL для скачивания с конкретными бинарниками, замыкая цепочку неизменяемости.

Минимальные права. Каждый workflow начинается с permissions: {} и расширяет права только для конкретных job'ов. Настройки организации по умолчанию дают доступ только на чтение.

Изоляция секретов. Никаких секретов на уровне организации или репозитория. Всё хранится в deployment environments с секретами, привязанными к конкретному окружению, что ограничивает радиус поражения при взломе одного из них.

Релизы: отказ от долгоживущих учётных данных

Пайплайн релизов - место, где скомпрометированная учётная запись наносит наибольший ущерб: именно через него вредоносный код попадает к пользователям.

Trusted Publishing заменяет долгоживущие токены реестров для PyPI, crates.io и NPM. Реестр доверяет идентификатору CI (через OIDC), а не сохранённому секрету. Красть нечего - токена просто нет.

Аттестации Sigstore создают криптографическую связь между собранными артефактами и сгенерировавшим их workflow. Пользователи могут убедиться, что бинарник действительно собрала CI Astral, а не злоумышленник, запушивший тег.

Неизменяемые релизы запрещают модификацию артефактов после публикации. В атаке на Trivy использовался force push тегов для подмены легитимного релиза скомпрометированным - неизменяемые релизы закрывают этот вектор.

Отключение кэша при релизах. Кэш сборки при релизах отключён для предотвращения атак с отравлением кэша (cache poisoning).

Согласование несколькими людьми. Активация релизного окружения требует подтверждения от ещё одного привилегированного участника организации. Для крупных репозиториев вроде uv с множеством релизных job'ов окружение release-gate с правилами защиты развёртывания (deployment protection rules) управляет согласованием, избавляя от необходимости подтверждать каждый job по отдельности.

Защита тегов. Релизные теги нельзя создать до успешного завершения развёртывания релиза, а после создания они становятся неизменяемыми. Атакующие не могут обойти пайплайн, создав тег напрямую.

Зависимости: периоды выдержки и работа с сообществом

Периоды выдержки зависимостей (cooldowns) - самая интересная практика. Astral намеренно откладывает обновление после выхода нового релиза в upstream'е, поскольку временно скомпрометированные версии наиболее опасны именно сразу после выпуска. Renovate поддерживает настройку cooldown'ов для отдельных групп: мягкие правила для собственных зависимостей, строгие - для сторонних. В самом uv поддержка cooldown'ов также встроена.

Помимо инструментов Astral поддерживает личные контакты с мейнтейнерами upstream-проектов, отправляет исправления безопасности в их CI/CD (например, apache/opendal-reqsign) и участвует в Python Packaging Authority и Python Security Response Team. Аргумент в том, что безопасность цепочки поставок отчасти социальная проблема: знать свои upstream'ы и помогать им выгодно в первую очередь вам самим.

Новые зависимости добавляются с осторожностью. Зависимостей в виде бинарных блобов избегают. Ненужные возможности отключаются на уровне конфигурации зависимостей. Фонд OSS Fund оказывает финансовую поддержку upstream-проектам.

GitHub Apps как граница безопасности

Когда CI/CD не может безопасно выполнить задачу (например, взаимодействие с внешними PR), Astral делегирует её astral-sh-bot - собственному GitHub App. Приложение получает те же данные вебхуков, что и Actions, но работает в изолированном окружении, где выполнение стороннего кода не пересекается с доступом к учётным данным. Это эшелонированная защита, а не серебряная пуля: при неаккуратном написании код самого App всё так же уязвим для атак внедрения кода (injection attacks).

См. также

• supply-chain-security - концепция в целом
• python-build-standalone - дистрибутив CPython, который устанавливает uv python install; теперь находится в репозитории astral-sh, из-за чего каждый управляемый через uv интерпретатор оказывается downstream-потребителем этого пайплайна
• hazmat - другой подход к ограничению поведения инструментов (изоляция AI-агентов в песочнице на macOS)
• if-ai-writes-your-code-why-use-python - Митчем приводит поглощение Astral компанией OpenAI (19 марта 2026 года) как пример корпоративных поглощений инструментов для Python/JS с ядром на Rust; сообщается, что uv экономит Codex около 1 миллиона минут вычислений в неделю