Справочник по безопасному использованию

Найдите информацию о лучших практиках безопасности при написании рабочих процессов и использовании GitHub Actions функций безопасности.

Написание рабочих процессов

Использование секретов для конфиденциальной информации

Так как можно преобразовать значение секрета несколькими способами, автоматическое редактирование не гарантируется. Придерживайтесь следующих рекомендаций, чтобы ограничить риски, связанные с секретами.

• Принцип наименьших привилегий
  • Любой пользователь с доступом на запись в репозиторий имеет доступ на чтение ко всем секретам, настроенным в репозитории. Поэтому необходимо убедиться, что учетные данные, используемые в рабочих процессах, имеют наименьшие требуемые разрешения.
  • Действия могут использовать GITHUB_TOKEN, обращаясь к нему из контекста github.token. Дополнительные сведения см. в разделе Справочник по контекстам. Поэтому необходимо убедиться, что для GITHUB_TOKEN предоставлены минимальные требуемые разрешения. В целях безопасности рекомендуется установить разрешение по умолчанию для GITHUB_TOKEN на чтение только содержимого репозитория. Затем при необходимости можно увеличить разрешения для отдельных заданий в файле рабочего процесса. Дополнительные сведения см. в разделе Использование GITHUB_TOKEN для проверки подлинности в рабочих процессах.
• Маскирование конфиденциальных данных
  • Конфиденциальные данные никогда не** должны **храниться в виде обычного текста в файлах рабочих процессов. Маскируйте всю конфиденциальную информацию, которая не GitHub является секретом, используя ::add-mask::VALUE. Это приводит к тому, что значение будет рассматриваться как секрет и отредактировано из журналов. Дополнительные сведения о маскировки данных см. в разделе Команды рабочего процесса для GitHub Actions.
• Удаление и смена предоставленных секретов
  • Редактирование секретов выполняется средствами выполнения рабочих процессов. Это означает, что секрет будет отредактирован только в том случае, если он использовался в задании и доступен средством выполнения. Если нередактируемый секрет отправляется в журнал выполнения рабочего процесса, следует удалить журнал и повернуть секрет. Сведения об удалении журналов см. в разделе Использование журналов выполнения рабочих процессов.
• Никогда не используйте структурированные данные в качестве секрета
  • Структурированные данные могут привести к сбою скрытия секрета в журналах, так как скрытие в значительной степени зависит от поиска точного соответствия для конкретного значения секрета. Например, не используйте большой двоичный объект JSON, XML или YAML (или аналогичный указанным) для инкапсуляции секретного значения, так как это значительно снижает вероятность того, что секреты будут правильно скрыты. Вместо этого создайте отдельные секреты для каждого конфиденциального значения.
• Зарегистрируйте все секреты, используемые в рабочих процессах
  • Если секрет используется для создания другого конфиденциального значения в рабочем процессе, созданное значение должно быть официально зарегистрировано как секрет, чтобы он отображался в журналах. Например, если вы используете закрытый ключ для создания подписанного JWT для доступа к веб-API, обязательно зарегистрируйте этот JWT как секрет, иначе он не будет скрыт, если он когда-либо попадет в выходные данные журнала.
  • Регистрация секретов также применяется к любому типу преобразования или кодирования. Если ваш секрет каким-либо образом преобразован (например, в кодировке Base64 или URL), обязательно зарегистрируйте новое значение в качестве секрета.
• Выполняйте аудит обработки секретов
  • Выполните аудит использования секретов, чтобы убедиться, что они обрабатываются должным образом. Это можно сделать, просмотрев исходный код репозитория, выполняющего рабочий процесс, и проверив все действия, используемые в рабочем процессе. Например, убедитесь, что они не отправляются на непредусмотренные узлы или непосредственно не печатаются для вывода журнала.
  • Просмотрите журналы выполнения для вашего рабочего процесса после проверки допустимых/недопустимых входных данных и убедитесь, что секреты правильно скрыты или не отображаются. Не всегда очевидно, как вызываемая команда или средство будет отправлять ошибки в STDOUT и STDERR, а секреты в дальнейшем могут оказаться в журналах ошибок. Поэтому рекомендуется вручную просматривать журналы рабочего процесса после проверки допустимых и недопустимых входных данных. Сведения о том, как очистить журналы рабочих процессов, которые могут непреднамеренно содержать конфиденциальные данные, см. в разделе Использование журналов выполнения рабочих процессов.
• Выполняйте аудит и смену зарегистрированных секретов
  • Периодически проверяйте зарегистрированные секреты, чтобы убедиться, что они по-прежнему необходимы. Удалите те, которые больше не нужны.
  • Периодически меняйте секреты, чтобы сократить период времени, в течение которого действителен скомпрометированный секрет.
• Рассмотрите возможность проверки доступа к секретам
  • Привлекайте необходимых рецензентов для защиты секретов среды. Задание рабочего процесса не может получить доступ к секретам окружения, пока рецензент не создаст утверждение. Дополнительные сведения о хранении секретов в средах или необходимости проверки для сред см. в разделе [AUTOTITLE и Использование секретов в GitHub Actions](/actions/deployment/targeting-different-environments/managing-environments-for-deployment).

Рекомендации по устранению атак путем внедрения сценария

Рекомендуемые подходы для устранения риска внедрения скриптов в рабочих процессах:

Использование действия вместо встроенного скрипта

Рекомендуется создать действие JavaScript, которое обрабатывает значение контекста в качестве аргумента. Этот подход не уязвим для атаки на внедрение, так как значение контекста не используется для создания скрипта оболочки, но вместо этого передается в действие в качестве аргумента:

uses: fakeaction/checktitle@v3
with:
  title: ${{ github.event.pull_request.title }}

Использование переменной промежуточной среды

Для встроенных сценариев предпочтительным подходом к обработке ненадежных входных данных является установка значения выражения в промежуточную переменную среды. В следующем примере используется Bash для обработки значения github.event.pull_request.title в качестве переменной среды:

      - name: Check PR title
        env:
          TITLE: ${{ github.event.pull_request.title }}
        run: |
          if [[ "$TITLE" =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

В этом примере попытка внедрения скрипта завершается неудачно, что отражается следующими строками в журнале:

   env:
     TITLE: a"; ls $GITHUB_WORKSPACE"
PR title did not start with 'octocat'

При таком подходе значение ${{ github.event.pull_request.title }} выражения сохраняется в памяти и используется как переменная, не взаимодействуя с процессом генерации скриптов. Кроме того, рассмотрите возможность использования переменных с двойными кавычками, чтобы избежать разбиения слова, но это одна из многих общих рекомендаций по написанию скриптов оболочек и не является специфическим для GitHub Actions.

Ограничение разрешений для токенов

Чтобы снизить риск незащищенного токена, рассмотрите возможность ограничения назначенных разрешений. Дополнительные сведения см. в разделе Использование GITHUB_TOKEN для проверки подлинности в рабочих процессах.

Устранение рисков ненадежного получения кода

Как и атаки на внедрение скриптов, ненадежное содержимое запроса на вытягивание, которое автоматически активирует обработку действий, также может представлять угрозу безопасности. pull_request_target Триггеры рабочего workflow_run процесса, используемые при извлечении ненадежного запроса на вытягивание, предоставляют репозиторию компрометации безопасности. Эти рабочие процессы являются привилегированными, что означает, что они совместно используют один кэш основной ветви с другими триггерами привилегированного рабочего процесса, а также могут иметь доступ на запись репозитория и доступ к указанным секретам. Эти уязвимости можно использовать для получения репозитория.

Дополнительные сведения об этих триггерах, их использовании и связанных рисках см. в разделе [AUTOTITLE и События, инициирующие рабочие процессы](/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflow_run).

Для дополнительных примеров и рекомендаций по рискам ненадёжной проверки кода см. раздел «Предотвращение запросов на pwn » GitHub Security Lab и документацию «Опасный рабочий процесс» из OpenSSF Scorecard.

Рекомендации

• Избегайте использования триггера pull_request_target рабочего процесса, если это не требуется. Для разделения привилегий между рабочими процессами лучше workflow_run активировать. Используйте только эти триггеры рабочего процесса, если рабочий процесс фактически нуждается в привилегированном контексте.

• Избегайте использования pull_request_target``workflow_run триггеров рабочего процесса с ненадежными запросами на вытягивание или содержимым кода. Рабочие процессы, использующие эти триггеры, не должны явно проверять ненадежный код, в том числе из вилок запроса на вытягивание или из репозиториев, которые не находятся под вашим контролем. Рабочие процессы, которые активируются, workflow_run должны обрабатывать артефакты, отправленные из других рабочих процессов с осторожностью.

• CodeQL может сканировать и обнаруживать потенциально уязвимые GitHub Actions рабочие процессы. Вы можете настроить настройки репозитория по умолчанию и убедиться, GitHub Actions что сканирование включено. Дополнительные сведения см. в разделе Настройка настройки по умолчанию для сканирования кода.

• OpenSSF Scorecards помогут выявить потенциально уязвимые рабочие процессы, а также другие риски безопасности при использовании GitHub Actions. Дополнительные сведения см. в статье об использовании систем показателей OpenSSF для защиты зависимостей рабочих процессов далее в этой статье.

Использование действий третьих лиц

Отдельные задания в рабочем процессе могут взаимодействовать c другими заданиями (и подвергать их риску). Например, задание, запрашивающее переменные среды, используемые более поздним заданием, записывающее файлы в общий каталог, который обрабатывает более позднее задание, или даже более непосредственно, взаимодействуя с сокетом Docker и проверяя другие запущенные контейнеры и выполняя в них команды.

Это означает, что компрометация одного действия в рабочем процессе может иметь очень большое значение, так как это скомпрометированное действие будет иметь доступ ко всем секретам, настроенным в вашем репозитории, и может использовать GITHUB_TOKEN для записи в репозиторий. В результате существует значительный риск при поиске действий из сторонних репозиториев.GitHub Сведения о некоторых шагах, которые может предпринять злоумышленник, см. в разделе Справочник по безопасному использованию.

Вы можете помочь снизить этот риск, выполнив следующие рекомендации:

• Закрепление действий с полной длиной фиксации SHA

  Закрепление действия к полной фиксации SHA в настоящее время является единственным способом использования действия в качестве неизменяемого выпуска. Закрепление в определенном SHA помогает снизить риск того, что злоумышленник добавит черный ход в репозиторий действия, так как ему потребуется создать коллизию SHA-1 для действительной полезной нагрузки объекта Git. При выборе SHA необходимо убедиться, что он находится в репозитории действия, а не вилке репозитория.

  Пример использования полной фиксации SHA в рабочем процессе см. в разделе Использование стандартных блоков в рабочем процессе.

GitHub предлагает политики на уровне репозитория, организации, , требующие привязки действий к полноценному коммит-SHA: * Сведения о настройке политики на уровне репозитория см. в разделе Управление настройками GitHub Actions для репозитория. * Сведения о настройке политики на уровне организации см. в разделе Отключение или ограничение GitHub Actions для вашей организации. * Сведения о настройке политики на корпоративном уровне см. в разделе Применение политик для GitHub Actions в вашем предприятии.

• Аудит исходного кода действия

  Убедитесь, что действие обрабатывает содержимое репозитория и секреты должным образом. Например, убедитесь, что секреты не отправляются на непредусмотренные узлы или не регистрируются самопроизвольно.

• Закрепляйте действия в теге только в случае доверия автору

  Хотя закрепление в фиксации SHA является наиболее безопасным вариантом, указание тега — это более удобный и широко используемый метод. Если вы хотите указать тег, убедитесь, что вы доверяете авторам действия. Значок «Проверенный создатель» на GitHub Marketplace является полезным сигналом, так как указывает на то, что действие было написано командой, чья личность была подтверждена .GitHub Обратите внимание, что в этом подходе есть риск, даже если вы доверяете автору, потому что тег может быть перемещен или удален, если злоумышленник получит доступ к репозиторию, в котором хранится действие.

Повторное использование сторонних рабочих процессов

Те же самые принципы, описанные выше для использования сторонних действий, также применимы к использованию сторонних рабочих процессов. Вы можете снизить риски, связанные с повторным использованием рабочих процессов, следуя тем же рекомендациям, которые описаны выше. Дополнительные сведения см. в разделе Повторное использование рабочих процессов.

GitHubФункции безопасности

GitHub предоставляет множество функций для повышения безопасности вашего кода. Вы можете использовать GitHubвстроенные функции для понимания действий, от которых зависят ваши рабочие процессы, уведомлять о уязвимостях в используемых вами действиях или автоматизировать процесс их актуальности. Если вы публикуете и поддерживаете действия, вы сможете использовать GitHub их для общения с вашим сообществом о уязвимостях и способах их устранения. Для получения дополнительной информации о функциях безопасности, которые GitHub предлагают, см. Функции безопасности GitHub.

Использование CODEOWNERS для отслеживания изменений

Вы можете использовать функцию CODEOWNERS для управления внесением изменений в файлы рабочего процесса. Например, если все файлы рабочего процесса хранятся.github/workflows, вы можете добавить этот каталог в список владелец кода s, чтобы любые предложенные изменения в этих файлах сначала требовали утверждения от назначенного рецензента.

Дополнительные сведения см. в разделе О владельцах кода.

Управление правами для GitHub Actions настроек в вашей организации

Вы можете практиковать принцип наименьших привилегий для CI/CD конвейера GitHub Actions вашей организации, администрируя индивидуальные организационные роли. Пользовательская роль организации — это способ предоставления отдельным лицам или команде в организации возможности управлять определенными подмножествами параметров без предоставления полного административного контроля организации и его репозиториев.

Для GitHub Actionsможно включить любое из следующих разрешений для отдельных лиц или команд в вашей организации.

• Управление политиками действий организации: доступ к управлению всеми параметрами на странице параметров "Общие действия", за исключением параметров локального запуска.
• Управление группами запуска организации и группами runner: доступ к созданию и управлению размещенными на сайте GitHub средствами выполнения, локальными группами выполнения и группами runner, а также управлять тем, где можно создавать локальные модули выполнения.
• Управление секретами действий организации: доступ к созданию секретов организации Actions и управлению ими.
• Управление переменными действий организации: доступ к созданию переменных организации Actions и управлению ими.

Дополнительные сведения см. в разделе Разрешения на кастомные организационные роли.

Использование OpenID Connect для доступа к облачным ресурсам

Если рабочим процессам GitHub Actions требуется доступ к ресурсам от поставщика облачных служб, поддерживающего OpenID Connect (OIDC), можно настроить рабочие процессы для проверки подлинности непосредственно в поставщике облачных служб. Это позволит прекратить хранение таких учетных данных в виде долгоживущих секретов и обеспечить другие преимущества безопасности. Дополнительные сведения см. в разделе OpenID Connect.

Как Dependabot version updates поддерживать актуальность действий

Вы можете использовать Dependabot для обеспечения актуальности ссылок на действия и повторно используемые рабочие процессы, используемые в репозитории. Действия часто обновляются с помощью исправлений ошибок и новых функций, чтобы сделать автоматизированные процессы более быстрыми, безопасными и более надежными. Dependabot берет на себя усилия по поддержанию зависимостей, так как это делается автоматически. Дополнительные сведения см. в разделе [AUTOTITLE и Поддержка актуальности действий с помощью Dependabot](/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates).

Разрешение рабочим процессам доступа к внутренним и частным репозиториям

Если вы делаете частный репозиторий доступным для рабочих процессов GitHub Actions в других репозиториях, внешний участник совместной работы на других репозиториях могут косвенно получить доступ к частному репозиторию, даже если у них нет прямого доступа к этим репозиториям. Внешний участник совместной работы могут просматривать журналы для рабочих процессов при использовании действий или рабочих процессов из частного репозитория. Для получения дополнительной информации см. Совместное использование действий и рабочих процессов с вашим предприятием.

Чтобы разрешить бегунам загружать эти действия, GitHub передает маркер установки в средство выполнения с заданной областью. Этот маркер имеет доступ на чтение к репозиторию и автоматически истекает через один час.

Предотвращение GitHub Actions создания или одобрения pull-запросов

Вы можете разрешить или запретить рабочим процессам GitHub Actions создавать или утверждать запросы на вытягивание. Разрешение рабочим процессам или любой другой автоматизации создавать или утверждать pull requests может представлять угрозу безопасности, если pull request объединяется без надлежащего контроля.

Для получения дополнительной информации о том, как настроить эту настановку, см. Применение политик для GitHub Actions в вашем предприятии,Disabling or Limiting GitHub Actions для вашей организации и Управление настройками GitHub Actions для репозитория.

Использование code scanning для защиты рабочих процессов

Code scanning может автоматически обнаруживать и предлагать улучшения для распространённых уязвимых паттернов, используемых в GitHub Actions рабочих процессах. Для получения дополнительной информации о том, как включить code scanning, см. Настройка настройки по умолчанию для сканирования кода.

Использование систем показателей OpenSSF для защиты зависимостей рабочего процесса

Системы показателей — это автоматизированное средство безопасности, которое выявляет рискованные действия в цепочке поставок. Вы можете использовать действие системы показателей и шаблон рабочего процесса для выполнения рекомендаций по безопасности. После настройки действие Scorecards запускается автоматически при изменениях репозитория и предупреждает разработчиков о рискованных практиках цепочки поставок, используя встроенный code scanning опыт. Проект системы показателей выполняет ряд проверок, включая атаки путем внедрения сценария, разрешения токенов и закрепленные действия.

Утвердение для GitHub-ведущих бегунов

Усиление защиты для средств выполнения тестов локального размещения

Самостоятельные раннеры GitHub не имеют гарантий работы в эфемерных чистых виртуальных машинах и могут постоянно скомпрометироваться ненадёжным кодом в рабочем процессе.

осторожны при использовании самостоятельных раннеров на приватных или внутренних репозиториях, поскольку любой, кто может форкнуть репозиторий и открыть pull request (обычно те, кто имеет доступ к репозиторию), могут скомпрометировать самостоятельную среду раннера, включая доступ к секретам, которыеGITHUB_TOKEN, в зависимости от настроек, могут предоставить доступ к записи репозитория. Хотя рабочие процессы могут контролировать доступ к секретам окружения с помощью окружений и обязательных проверок, эти рабочие процессы не запускаются в изолированном окружении и по-прежнему подвержены тем же рискам при запуске в средстве выполнения тестов локального размещения.

Владельцы предприятия и организация владельцы могут выбрать, какие репозитории разрешены для создания локальных средств выполнения на уровне репозитория.

Дополнительные сведения см. в разделе [AUTOTITLE и Применение политик для GitHub Actions в вашем предприятии](/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#limiting-the-use-of-self-hosted-runners).

Когда самостоятельный раннер определен на уровне организации или предприятия, GitHub он может планировать рабочие процессы из нескольких репозиториев на один и тот же раннер. Следовательно, нарушение безопасности этих окружений может привести к серьезным последствиям. Чтобы уменьшить масштабы компрометации, вы можете установить границы, упорядочив средства выполнения тестов локального размещения в отдельные группы. Вы можете ограничить доступ к группам раннеров к рабочим процессам, организациям и репозиториям. Дополнительные сведения см. в разделе Управление доступом к самостоятельно размещенным средствам выполнения с помощью групп.

Следует также рассмотреть окружение компьютеров средств выполнения тестов локального размещения:

• Какие конфиденциальные сведения находятся в компьютере, настроенном в качестве средства выполнения тестов локального размещения? Например, закрытые ключи SSH, маркеры доступа API и другое.
• Имеет ли компьютер сетевой доступ к конфиденциальным службам? Например, сервисы метаданных Azure или AWS. Объем конфиденциальной информации в этом окружении должен быть сведен к минимуму, и вы всегда должны помнить, что любой пользователь, способный вызывать рабочие процессы, имеет доступ к этому окружению.

Некоторые клиенты могут попытаться частично снизить эти риски, внедрив системы, которые автоматически уничтожают средство выполнения тестов локального размещения после каждого выполнения задания. Однако этот подход может быть не таким эффективным, как предполагалось, так как нет никакого способа гарантировать, что средство выполнения тестов локального размещения выполняет только одно задание. Некоторые задания будут использовать секреты в качестве аргументов командной строки, которые могут быть видны другому заданию, выполняющемся в том же средстве выполнения тестов, например ps x -w. Это может привести к утечкам секретов.

Использование JIT-командлетов

Чтобы повысить безопасность регистрации runner, можно использовать REST API для создания временных и JIT-модулей. Эти локальные средства выполнения выполняют не более одного задания, прежде чем автоматически удаляться из репозитория, организации или предприятия. Дополнительные сведения о настройке средств выполнения JIT см. в разделе Конечные точки REST API для локальных runners.

После получения файла конфигурации из ответа REST API его можно передать в средство выполнения при запуске.

./run.sh --jitconfig ${encoded_jit_config}

Планирование стратегии управления для средств выполнения тестов локального размещения

Самостоятельный раннер может быть добавлен на различные уровни вашей GitHub иерархии: на уровне предприятия, организации или репозитория. Это размещение определяет, кто сможет управлять средством выполнения тестов:

Централизованное управление:

• Если вы планируете, чтобы централизованная команда владела средствами выполнения тестов локального размещения, рекомендуется добавить свои средства выполнения тестов на самом высоком уровне взаимной организации или предприятия. Это предоставляет вашей команде единое расположение для просмотра ваших средств выполнения тестов и управления ими.
• Если в вашем распоряжении только одна организация, то добавление средств выполнения тестов на уровне организации — это фактически тот же подход, но при добавлении другой организации в будущем могут возникнуть трудности.

Децентрализованное управление:

• Если каждая команда будет управлять своими собственными средствами выполнения тестов локального размещения, то рекомендуется добавить средства выполнения тестов на самом высоком уровне владения команды. Например, если у каждой команды есть собственная организация, то будет проще, если средства выполнения тестов будут добавлены и на уровне организации.
• Вы также можете добавить средства выполнения тестов на уровне репозитория, но это добавит накладные расходы на управление, а также увеличит количество необходимых вам средств выполнения тестов, так как вы не можете делиться средствами выполнения тестов между репозиториями.

Проверка подлинности в поставщике облачных служб

Если вы используете GitHub Actions развертывание в облачном провайдере или планируете использовать HashiCorp Vault для управления секретами, рекомендуется рассмотреть возможность использования OpenID Connect для создания кратковременных, хорошо осмысленных токенов доступа для ваших рабочих процессов. Дополнительные сведения см. в разделе OpenID Connect.

Аудиторские GitHub Actions мероприятия

Вы можете использовать журнал безопасности для мониторинга активности вашей учетной записи пользователя, а журнал аудита — для мониторинга активности в вашей организации или предприятии. Журнал безопасности и аудита записывает тип действия, когда он был запущен, и который личная учетная запись выполнил действие.

Например, для отслеживания org.update_actions_secret события можно использовать журнал аудита, который отслеживает изменения секретов организации.

Полный список событий, которые можно найти в журнале аудита для каждого типа учетной записи, см. в следующих статьях:

• События журнала безопасности
• События журнала аудита для организации
• События журнала аудита для вашего предприятия

Общие сведения о зависимостях в рабочих процессах

Вы можете использовать граф зависимостей для изучения действий, используемых рабочими процессами в репозитории. Граф зависимостей представляет собой сводку файлов манифеста и блокировки, хранящихся в репозитории. Он также распознает файлы в ./github/workflows/ виде манифестов, что означает, что любые действия или рабочие процессы, на которые ссылается синтаксис jobs[*].steps[*].uses , или jobs.<job_id>.uses будут проанализированы как зависимости.

В граф зависимостей показаны следующие сведения о действиях, используемых в рабочих процессах:

• Учетная запись или организация, которая владеет действием.
• Файл рабочего процесса, ссылающийся на действие.
• Версия или SHA, на которые закреплено действие.

В граф зависимостей зависимости автоматически сортируются по серьезности уязвимостей. Если какие-либо из действий, которые вы используете, имеют рекомендации по безопасности, они будут отображаться в верхней части списка. Вы можете перейти к рекомендации из граф зависимостей и инструкции по доступу для разрешения уязвимости.

.Владельцы предприятий могут настраивать граф зависимостей для Dependabot alerts предприятия. Для получения дополнительной информации см. Включение графа зависимостей для предприятия.

Учитывая уязвимости безопасности в действиях, которые вы используете

Для действий, доступных на рынке, GitHub просматривайте связанные рекомендации по безопасности, а затем добавляйте эти уведомления в GitHub Advisory Database. Вы можете выполнить поиск в базе данных действий, используемых для поиска сведений о существующих уязвимостях и инструкциях по их устранению. Чтобы упростить поиск, используйте GitHub Actions фильтр в GitHub Advisory Database.

Вы можете настроить репозитории, чтобы вы:

• Получение оповещений, когда действия, используемые в рабочих процессах, получают отчет об уязвимостях. Дополнительные сведения см. в разделе "Мониторинг действий в рабочих процессах".
• Предупреждаются о существующих помощниках при добавлении или обновлении действия в рабочем процессе. Дополнительные сведения см. в разделе "Проверка уязвимостей" в новых или обновленных рабочих процессах.

Мониторинг действий в рабочих процессах

Вы можете отслеживать Dependabot действия в рабочих процессах и уведомлять Dependabot alerts вас о случае, когда в вашем действии обнаружена уязвимость. Dependabot выполняет сканирование стандартной ветки репозиториев, где включено обнаружение небезопасных зависимостей. Dependabot Генерируется Dependabot alerts , когда в The GitHub Advisory Database The добавляется новое предупреждение или когда обновляется используемое вами действие.

Владелец бизнеса должен сначала настроить Dependabot свой бизнес, прежде чем вы сможете управлять Dependabot alerts своим репозиторием. Для получения дополнительной информации см. Включение Dependabot для предприятия.

Вы можете просматривать все открытые, закрытые Dependabot alerts и соответствующие Dependabot security updates данные во вкладке Dependabot вашего репозитория. Для получения дополнительной информации см. Просмотр и обновление оповещений Dependabot.

Проверка действий по уязвимостям в новых или обновленных рабочих процессах

При открытии запросов на вытягивание для обновления рабочих процессов рекомендуется использовать проверку зависимостей для понимания влияния на безопасность изменений, внесенных в действия, которые вы используете. Проверка зависимостей помогает разобраться в изменениях зависимостей и понять их влияние на безопасность в каждом запросе на вытягивание. Она обеспечивает легко понятную визуализацию изменений зависимостей с широкими возможностями на вкладке "Измененные файлы" запроса на вытягивание. Функция проверки зависимостей позволяет получить следующую информацию:

• Какие зависимости были добавлены, удалены или обновлены вместе с датами выпуска
• Сколько проектов использует эти компоненты
• Данные уязвимости для этих зависимостей

Если какие-либо изменения, внесенные в рабочие процессы, помечены как уязвимые, вы можете избежать их добавления в проект или обновить их до безопасной версии.

Дополнительные сведения о проверке зависимостей см. в разделе Сведения о проверке зависимостей.

"Действие проверки зависимостей" ссылается на конкретное действие, которое может сообщать о различиях в запросе на вытягивание в контексте GitHub Actions. См. раздел dependency-review-action. Вы можете использовать переменные данных Действие проверки зависимостей в репозитории для принудительного применения проверок зависимостей в запросах на вытягивание. Это действие проверяет наличие уязвимых версий зависимостей, представленных изменениями версии пакета в запросах на вытягивание, и предупреждает о связанных с ними уязвимостях системы безопасности. Это позволяет лучше отслеживать изменения в запросе на вытягивание и предотвращать добавление уязвимостей в репозиторий. Для получения дополнительной информации см. Сведения о проверке зависимостей.

Обеспечение безопасности и актуальности действий в рабочих процессах

Вы можете использовать Dependabot для обеспечения актуальности ссылок на действия и повторно используемые рабочие процессы, используемые в репозитории. Действия часто обновляются с помощью исправлений ошибок и новых функций, чтобы сделать автоматизированные процессы более быстрыми, безопасными и более надежными. Dependabot берет на себя усилия по поддержанию зависимостей, так как это делается автоматически. Дополнительные сведения см. в разделе [AUTOTITLE и Поддержка актуальности действий с помощью Dependabot](/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates).

Следующие функции могут автоматически обновлять действия в рабочих процессах.

• **Dependabot version updates ** Открывайте pull requests для обновления действий до последней версии при выпуске новой версии.
• **Dependabot security updates ** Открывайте pull requests, чтобы обновить действия с указанными уязвимостями до минимальной пропатчённой версии.

Для получения информации о том, как настроить Dependabot version updates, см. Настройка обновлений версий Dependabot.

Для получения информации о том, как настроить Dependabot security updates, см. Настройка обновлений для системы безопасности Dependabot.