GitHub представила расширенную подборку материалов и анонсировала планы по усилению безопасности CI/CD-процессов в GitHub Actions к 2026 году. В центре внимания — защита цепочки поставки ПО, контроль зависимостей, секретов и сетевого трафика в инфраструктуре CI/CD.
Компания отмечает рост атак на цепочку поставки программного обеспечения. За последний год зафиксированы инциденты с проектами tj-actions/changed-files, Nx и trivy-action, где злоумышленники атаковали именно автоматизацию CI/CD, а не только конечное программное обеспечение. Многие уязвимости легко внедрить и трудно обнаружить, поэтому GitHub планирует закрыть этот разрыв.
Дорожная карта GitHub Actions на 2026 год строится вокруг трёх направлений: управление зависимостями действий, централизованные политики выполнения workflow и защита инфраструктуры CI/CD на уровне конечных точек. Цель — сделать безопасное поведение настройкой по умолчанию, чтобы команды могли использовать Actions без глубоких знаний в области безопасности.
1. Жёсткая фиксация зависимостей GitHub Actions
Сегодня зависимости Actions разрешаются во время выполнения workflow и опираются на изменяемые ссылки — теги и ветки. В результате код, который запускается в CI, часто нефиксирован и плохо поддаётся аудиту. Использование неизменяемых commit SHA помогает, но плохо масштабируется, а транзитивные зависимости остаются непрозрачными.
GitHub вводит секцию dependencies: в YAML-файлах workflow. Она будет фиксировать все прямые и транзитивные зависимости по конкретным commit SHA. Это создаёт для workflow аналог go.mod + go.sum из Go: полная воспроизводимость и возможность аудита всего набора зависимостей.
Также планируется ужесточить публикацию Actions в экосистему. Компания намерена отходить от изменяемых ссылок в сторону неизменяемых релизов с более строгими требованиями к выпуску, чтобы снизить риск подмены кода после релиза.
2. Централизованные политики выполнения workflow и управление секретами
Гибкость GitHub Actions привела к тому, что по мере роста организаций связь между правами на репозиторий и запуском workflow стала слишком грубой. Разным командам и сценариям нужны разные уровни доступа, что часто заканчивается избыточными правами, размытыми границами доверия и ошибками в настройках.
GitHub вводит защиту выполнения workflow на базе фреймворка ruleset. Вместо настройки безопасности в каждом YAML-файле, организации смогут задавать центральные политики, которые определяют, какие workflow, при каких событиях и с какими правами могут выполняться. Это упрощает аудит и снижает риск неправильной конфигурации.
Например, организация сможет ограничить запуск workflow_dispatch только мейнтейнерами, чтобы пользователи с правами записи не могли вручную инициировать чувствительные деплой или релиз. Отдельно можно запретить события pull_request_target и разрешить только pull_request, чтобы workflow для внешних вкладов запускались без доступа к секретам и правам записи.
Эти политики применяются на уровне организации и масштабируются по всем репозиториям без настройки в каждом workflow. Для безопасного внедрения предусмотрен evaluate mode: в этом режиме правила не блокируют выполнение, но каждый потенциально заблокированный запуск отображается в отчётах по политике. Это позволяет проверить влияние настроек до включения жёсткого применения.
Отдельный блок изменений касается секретов. Сейчас секреты Actions привязаны к репозиторию или организации, что усложняет их безопасное использование, особенно в переиспользуемых workflow. GitHub вводит тонкую привязку секретов к конкретным контекстам выполнения, чтобы учётные данные выдавались только для явно доверенных сценариев.
Компания также разделяет управление кодом и управление секретами. Права записи в репозиторий больше не будут автоматически давать доступ к настройке секретов. Этой возможностью будут обладать отдельные кастомные роли, а также администраторы репозитория, организации и предприятия. В итоге секреты выдаются только тогда, когда доверены и workflow, и контекст выполнения.
3. Мониторинг и контроль инфраструктуры CI/CD
GitHub рассматривает инфраструктуру CI/CD как критически важную. Runners GitHub Actions запускают недоверенный код, работают с чувствительными учётными данными и взаимодействуют с внешними системами. При инцидентах организациям часто не хватает данных, чтобы понять, что именно выполнялось и как происходила компрометация.
Для решения этой задачи GitHub внедряет корпоративные средства защиты конечных точек для GitHub Actions, начиная с Actions Data Stream (видимость) и встроенного egress‑фаервола (управление сетевым трафиком). Цель — рассматривать нагрузки CI/CD как отдельный домен безопасности с явными контролями и непрерывной наблюдаемостью.
CI/CD‑видимость сейчас фрагментирована и ограничена. Actions Data Stream делает автоматизацию в CI/CD наблюдаемой по тому же принципу, как и другие продакшн‑системы. События передаются пакетами с гарантией как минимум однократной доставки и в общем формате, который упрощает индексацию и корреляцию в выбранной платформе наблюдаемости.
Отдельная проблема — неограниченный исходящий сетевой доступ GitHub‑хостинг‑раннеров. Это повышает риск утечки секретов, несанкционированных публикаций и длительного присутствия злоумышленника. GitHub разрабатывает встроенный egress‑фаервол для GitHub‑хостинг‑раннеров, который задаёт жёсткие сетевые границы для CI/CD.
Фаервол работает снаружи виртуальной машины runner на уровне Layer 7 и остаётся неизменяемым даже при получении злоумышленником root‑доступа внутри окружения. Организации смогут задавать точные политики исходящего трафика, формируя списки разрешённых направлений и типов запросов.
Фаервол сочетает два ключевых режима — мониторинг и принудительное применение. Это даёт безопасный сценарий внедрения: сначала организации наблюдают реальные шаблоны трафика, формируют точные списки разрешений на основе данных, затем включают жёсткое применение правил с минимальным риском сбоев.
GitHub подчёркивает, что runners не должны восприниматься как «одноразовые чёрные ящики». Компания движется к архитектуре, где инфраструктура CI/CD управляется и контролируется так же внимательно, как и другие критические системы предприятия.
Фокус на безопасности по умолчанию и централизованном управлении
GitHub констатирует, что рост атак на цепочку поставки ПО связан с проблемами в управлении зависимостями, размытыми границами доверия, нестрогой работой с секретами и слабой наблюдаемостью. Дорожная карта GitHub Actions на 2026 год призвана напрямую ответить на эти вызовы и перевести платформу к автоматизации, которая по умолчанию безопасна и поддаётся проверке.
При этом Actions сохранят гибкость. GitHub стремится к тому, чтобы организациям не пришлось переделывать свою модель CI/CD заново. Планируется расширение охвата политик, добавление более богатых механизмов одобрения и аттестации и консолидация разрозненных сейчас настроек в единую панель управления.
Параллельно GitHub развивает образовательные ресурсы: материалы по искусственному интеллекту и машинному обучению, генерации кода с помощью ИИ, лучшим практикам DevSecOps с применением автоматизации, работе с retrieval‑augmented generation (RAG), а также курсы по переходу в первую профессиональную роль разработчика и масштабированию разработки в распределённых командах.
Компания продолжает публиковать аналитические отчёты (включая Octoverse 2025), новости о продуктах, данные по платформе и обновления по политике и регулированию в сфере ПО, а также делится тем, как внутренние инженерные и команды безопасности используют GitHub для повышения продуктивности и раннего переноса задач безопасности в процесс разработки.
Источник: материалы GitHub.
