🧷 Запиннили зависимости? Проверьте, что workflow подтягивает дальше — 22 июля 2026 г. в 09:07:36.969
🧷 Запиннили зависимости? Проверьте, что workflow подтягивает дальше Даже SHA-пиннинг не закрывает все риски: workflow может подтянуть вредоносную зависимость во время выполнения. В CI/CD нужно контролировать доступы к сборке и код, который она подтягивает во время работы: GitHub Actions, контейнерные образы, Go-модули. Продолжаем рассказывать о защите CI/CD-конвейера. В прошлый раз говорили о том, кто может запускать сборки и какой CI-код разрешено исполнять. Сейчас речь пойдет про уровень зависимостей: какой код эти сборки подтягивают и как убедиться, что его не подделали. 🔎 Как Cilium контролирует зависимости в CI/CD: ⭐ фиксирует GitHub Actions по полному 40-символьному SHA-коммиту, чтобы изменение или подмена тега не привели к загрузке другого кода; ⭐ фиксирует контейнерные образы по @sha256-дайджесту, чтобы сборка использовала конкретное неизменяемое содержимое; ⭐ обновляет зависимости через Renovate: бот поднимает SHA и открывает отдельный PR; ⭐ ждет пять дней перед обновлением, чтобы скомпрометированную версию успели обнаружить и удалить до обновления; ⭐ вендорит Go-модули, проверяет согласованность go.mod, go.sum и vendor/ и отправляет изменения зависимостей на ревью; ⭐ проверяет workflow с помощью CodeQL и actionlint еще до ручного ревью. ⚠️ Но у пиннинга есть слепое пятно Запинненный по SHA action может ссылаться на транзитивные зависимости по тегам. Они разрешаются во время выполнения и остаются незаметными. В 2026 году GitHub планирует добавить секцию dependencies для фиксации всех зависимостей по SHA. Автоматически сливаются только обновления из разрешенного списка, остальные проходят ревью. Форкать все сторонние actions слишком затратно: форки нужно синхронизировать, иначе они сами становятся уязвимостью. Поэтому Cilium фиксирует зависимости, контролирует обновления и проверяет workflow статическим анализом. 👉 Подробнее об этом читайте на Хабре — в новой статье о защите CI/CD