GitHub за июнь и июль 2026 года не выпустил один «большой пакет» безопасности, а последовательно закрыл несколько типовых сценариев атак на цепочку поставок в npm и GitHub Actions. Для разработчиков это практическая история: меньше шансов, что чужой пакет, форк или скомпрометированная учётная запись quietly доедут до вашего CI/CD.
Главная мысль простая: GitHub режет не абстрактные риски, а конкретные пути атаки, которыми злоумышленники уже пользовались в open source.
Рост атак заставил GitHub чинить самые слабые места
Повод понятный. В 2025–2026 годах экосистема open source регулярно ловила атаки через npm-пакеты, CI/CD и скомпрометированные аккаунты разработчиков. Один из свежих примеров описывал Ars Technica: злоумышленники массово загружали вредоносные пакеты с невидимым Unicode-кодом, чтобы обойти привычные проверки.
На этом фоне GitHub пошёл не по пути общих обещаний, а начал закрывать конкретные дыры в своей инфраструктуре: публикацию пакетов через захваченные аккаунты, отравление кэша в Actions, опасные сценарии с pull_request_target и запуск подозрительных workflow.
Что изменилось в npm
25 июня 2026 года GitHub включил для «высокоактивных» аккаунтов npm временный режим только для чтения на 72 часа после смены e-mail или использования кода восстановления 2FA. Это сделано против понятного сценария: атакующий перехватывает аккаунт, меняет почту, выпускает новый токен и публикует заражённую версию пакета.
Во время этой паузы пакеты остаются доступными для установки, но владелец не может публиковать новые версии, менять токены, управлять видимостью пакета и составом команд. Для maintainers это неприятная, но здравая цена за защиту от компрометации.
8 июля GitHub добавил ещё один слой: в npm v12 скрипты жизненного цикла при установке по умолчанию больше не запускаются автоматически, если их явно не разрешили. Для команд, которые тянут зависимости без жёсткой проверки, это особенно полезно: именно такие скрипты часто становятся удобной точкой входа для вредоносного кода.
GitHub Actions получил защиту от «pwn request» и отравления кэша
В Actions GitHub закрыл сразу несколько популярных схем. 18 июня компания представила workflow execution protections: администраторы теперь могут задавать, кто именно вправе запускать workflow и какие события вообще разрешены. Это снижает риск, когда у разработчика есть доступ в репозиторий, но запускать чувствительные сценарии CI/CD ему уже не дают.
В тот же день GitHub ужесточил поведение actions/checkout для сценария pull_request_target. По формулировке самой компании, новая версия action теперь refuses common pwn request patterns by default
. Иными словами, речь не о полном запрете кода из форков, как было в исходном тексте, а о защите от конкретного класса опасных конфигураций, где непроверенный код мог получить привилегии базового репозитория.
26 июня GitHub перевёл кэш Actions в режим только для чтения для недоверенных триггеров. Это закрывает атаку через cache poisoning, когда злоумышленник подсовывает вредный кэш, а потом более доверенный workflow восстанавливает его и запускает уже у себя.
Наконец, 28 июля GitHub добавил ещё одну страховку: некоторые потенциально вредоносные workflow в публичных репозиториях теперь ставятся на ручное одобрение до запуска. Важная деталь: эта мера сейчас относится к публичным репозиториям на github.com и не распространяется на GitHub Enterprise Server.
Что это меняет для рынка
Для русскоязычных команд вывод приземлённый. Если вы публикуете пакеты в npm, держите публичные репозитории на GitHub или гоняете CI/CD через Actions, платформа стала безопаснее по умолчанию, но не настолько, чтобы можно было расслабиться. Trusted publishing через OIDC, жёсткие правила на триггеры workflow, ревизия pull_request_target и запрет лишних install-скриптов по-прежнему стоит внедрять руками.
Для аутсорса, продуктовых команд и open-source maintainers это ещё и сигнал рынка: supply chain security окончательно перестала быть темой только для больших корпораций. Теперь это базовая гигиена разработки, как 2FA или секреты вне репозитория.
Следующий логичный шаг для GitHub — дожать отказ от обхода 2FA через старые токены и дальше переносить автоматическую публикацию на более безопасные схемы вроде OIDC.
Источники: GitHub Changelog: защита аккаунтов npm, GitHub Changelog: safer pull_request_target defaults, GitHub Changelog: read-only Actions cache, GitHub Changelog: approval for suspicious workflows, Ars Technica.