GitHub закрывает пути атак на цепочки поставок
GitHub внес изменения в npm и GitHub Actions, направленные против распространённых методов атак на цепочки поставок ПО. Обновления затрагивают взломанные аккаунты сопровождающих, небезопасные триггеры CI/CD, кражу учётных данных и несанкционированную публикацию пакетов. Эти меры снижают риск, но не заменяют безопасные процессы выпуска внутри отдельных проектов.
Атака на цепочку поставок ПО происходит, когда злоумышленники получают контроль над доверенным компонентом, рабочим процессом или путём распространения зависимостей, чтобы добраться до конечных пользователей. Наибольшая опасность возникает, когда реестры пакетов, системы автоматизации и долгоживущие секреты связаны между собой без строгого разделения доступа.
Что изменилось в npm и GitHub Actions#
GitHub сосредоточился на разрыве цепочек атак в точках, где злоумышленники чаще всего получают преимущество: доступ к аккаунтам сопровождающих, выполнение workflow, получение секретов и публикация пакетов.
Для важных аккаунтов npm GitHub добавил защитный этап: после определённых событий восстановления доступа, таких как смена email или использование кода восстановления 2FA, аккаунты переводятся в режим только для чтения на 72 часа. Это даёт сопровождающим время обнаружить захват аккаунта до того, как злоумышленник успеет опубликовать вредоносные пакеты.
В GitHub Actions появились новые изменения безопасности workflow. Поведение по умолчанию для workflow с pull_request_target изменили: в распространённых опасных сценариях система больше не выполняет checkout недоверенного кода из fork-репозиториев, если пользователь явно не отключил защиту. Это закрывает частый путь атаки, когда CI запускает код, контролируемый злоумышленником, с доступом к секретам или разрешениям проекта.
Новые политики выполнения workflow позволяют организациям и репозиториям контролировать, кто может запускать workflow и какие типы триггеров разрешены. Это добавляет принцип минимальных привилегий для CI/CD, который раньше во многом зависел от того, насколько правильно автор workflow настроил защиту.
Почему это важно для безопасности цепочек поставок#
Главное изменение — не одна отдельная функция защиты, а устранение обходных путей, из-за которых один скомпрометированный компонент мог превратиться в проблему для всей экосистемы.
Атаки на open source-проекты часто строятся из нескольких слабых мест. Украденный аккаунт сопровождающего может привести к выпуску вредоносной версии. Уязвимый workflow может раскрыть секреты. Затем эти данные используются для компрометации других пакетов или систем публикации.
GitHub также работает над снижением риска утечки секретов. npm trusted publishing теперь поддерживает CircleCI, позволяя проектам заменять долгоживущие ключи публикации на авторизацию по идентичности от поддерживаемых CI/CD-провайдеров. Это уменьшает ценность секретов, которые атакующие пытаются украсть из сред сборки.
GitHub тестирует дополнительные возможности контроля сетевой активности GitHub Actions. Логи исходящих соединений из workflow могут помочь командам безопасности выявлять неожиданные подключения, включая возможную кражу секретов или загрузку вредоносных файлов.
Общий тренд очевиден: безопасность реестров пакетов движется от доверия к тому, у кого есть токен, к проверке того, где и каким способом создаётся релиз.
Связанный контекст: Риск цепочек поставок ПО смещается выше по цепочке и Контроль трафика пакетов переносит безопасность цепочек поставок на уровень границы.
Что проверить#
Новые механизмы защиты работают лучше всего, когда команды пересматривают собственные процессы выпуска. Проверьте следующие пункты:
- Удалите долгоживущие ключи публикации из CI/CD, если доступен trusted publishing.
- Проверьте GitHub Actions workflow, которые используют pull request из fork-репозиториев или повышенные разрешения.
- Ограничьте, кто может запускать workflow и какие события могут выполнять автоматизацию.
- Разделите права на сборку и права на публикацию пакетов.
- Мониторьте неожиданный сетевой доступ из задач автоматизации.
Также проведите аудит работы с зависимостями. Безопасный реестр пакетов не защитит проект, если каждый workflow получает широкие права или производственные секреты хранятся внутри процессов сборки.
Для пользователей open source вывод другой: при оценке доверия учитывайте не только популярность пакета, но и то, как проект создаёт и публикует релизы.
Дополнительное чтение: Ошибки AI делают потребление open source сложнее.
Чего не стоит утверждать#
Эти изменения сокращают распространённые пути атак, но не делают пакеты npm или GitHub Actions автоматически безопасными. Атаки на цепочки поставок обычно используют несколько ошибок одновременно, а злоумышленники адаптируются после закрытия одного маршрута.
Изменения GitHub направлены против конкретных техник, которые наблюдались в недавних атаках. Они не заменяют проверку кода, мониторинг зависимостей, контроль доступа и аккуратное управление секретами.
Главное практическое изменение состоит в том, что меньше проектов теперь вынуждены полагаться только на неявное доверие к сопровождающим, токенам и настройкам автоматизации по умолчанию. Оставшийся риск зависит от того, как каждая организация настроит и использует эти системы.
FAQ#
Полностью ли это остановит атаки на цепочки поставок npm?#
Нет. Обновления мешают распространённым методам атак, но не устраняют все возможные пути компрометации. Проектам всё ещё нужны безопасные настройки аккаунтов, проверка workflow и надёжные процессы выпуска.
Почему CI/CD workflow считаются серьёзным риском для цепочек поставок?#
CI/CD-системы часто получают доступ к секретам, правам публикации и средам развёртывания. Скомпрометированный workflow может превратить локальную проблему с кодом в более масштабный инцидент для цепочки поставок ПО.