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

Найдите информацию о лучших практиках безопасности при написании рабочих процессов и использовании 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.

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

Code scanning позволяет выявлять уязвимости безопасности до их попадания в производство. GitHub предоставляет шаблоны рабочих процессов для code scanning. Вы можете использовать эти предложенные рабочие процессы для построения своих code scanning рабочих процессов, а не начинать с нуля. GitHubРабочий процесс , Рабочий процесс анализа CodeQL, работает на CodeQL. Доступны также сторонние шаблоны рабочих процессов.

Дополнительные сведения см. в разделе [AUTOTITLE и Сведения о проверке кода](/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning#configuring-code-scanning-using-third-party-actions).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Использование 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 создания или одобрения pull-запросов

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

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

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

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

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

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

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

GitHub-Размещённые бегуны принимают меры для снижения рисков безопасности.

Обзор цепочки поставок для GitHub-hosted runners

Для -hosted runners, созданных на основе изображений, GitHubподдерживаемых GitHub, вы можете посмотреть программный список материалов (SBOM), чтобы увидеть, какое программное обеспечение было предварительно установлено на раннере. Вы можете предоставить пользователям SBOM, которые они могут выполнять через сканер уязвимостей, чтобы проверить наличие уязвимостей в продукте. Если вы создаете артефакты, вы можете включить этот SBOM в ваш счет материалов для комплексного списка всех, которые пошли в создание вашего программного обеспечения.

SBOM доступны для изображений runner Ubuntu, Windows и macOS, поддерживаемых GitHub, включая раннеры на базе ARM. Вы можете найти SBOM для сборки в ресурсах https://github.com/actions/runner-images/releasesвыпуска. SBOM с именем файла в формате sbom.IMAGE-NAME.json.zip можно найти в вложениях каждого выпуска.

Запрет доступа к узлам

GitHubразмещенных в среде runners подготавливаются с etc/hosts помощью файла, который блокирует сетевой доступ к различным пулам интеллектуального анализа криптовалют и вредоносным сайтам. Узлы, такие как MiningMadness.com и cpu-pool.com, перенаправляются в localhost, чтобы они не представляют значительный риск безопасности. Для получения дополнительной информации см. Средства выполнения тестов, размещенные в GitHub.

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

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

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

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

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

Дополнительные сведения см. в разделе Применение политик для 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, на которые закреплено действие.

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

Граф зависимостей включён для публичных репозиториев, и вы можете включить его в приватных репозиториях. Для получения дополнительной информации об использовании графа зависимостей см. Изучение зависимостей репозитория

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

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

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

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

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

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

Вы можете включить 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.

Защита созданных действий

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

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

• Используйте представление зависимостей в графе зависимостей, чтобы узнать, какие проекты зависят от кода. Если вы получаете отчет об уязвимостях, вы получите представление о том, с кем нужно взаимодействовать с уязвимостью и как ее исправить. Дополнительные сведения см. в разделе Изучение зависимостей репозитория.
• Используйте рекомендации по безопасности репозитория для создания рекомендаций по безопасности, частной совместной работы для устранения уязвимости во временной закрытой вилке и публикации рекомендаций по безопасности для оповещения сообщества об уязвимости после выпуска исправления. Дополнительные сведения см. в разделе [AUTOTITLE и Настройка отчетов о частных уязвимостях для репозитория](/code-security/security-advisories/working-with-repository-security-advisories/creating-a-repository-security-advisory).