Skip to main content

Изучение вашего бизнес-испытания GitHub Code Security

Введение в функции кода и сканирования зависимостей, доступные в GitHub Code Security IN GitHub Enterprise Cloud , чтобы оценить их соответствие потребностям вашего бизнеса.

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

Введение

          Code scanning и анализ зависимостей работает аналогично в публичных репозиториях, а также в частных и внутренних репозиториях с Advanced Security включённым режимом. Кроме того, Advanced Security это позволяет создавать кампании безопасности, где специалисты по безопасности и разработчики могут совместно сотрудничество для эффективного снижения технической задолженности.

В этой статье рассматриваются способы объединения этих функций с элементами управления корпоративного уровня для стандартизации и применения процесса разработки.

Уточнение конфигураций безопасности

В отличие от Advanced Security, где одна конфигурация безопасности обычно применяется ко всем репозиториям, вам, вероятно, стоит доработать конфигурацию code scanning для разных типов репозиториев. Например, может потребоваться создать дополнительные конфигурации, чтобы:

  •         Code scanning использует раннеры с определённой меткой для подачи заявок на репозитории, требующие специализированной среды или использующие частные реестры.
    
  •         Code scanning «Не настроено» для применения репозиториев, требующих расширенной настройки или стороннего инструмента.
    

Для пробной версии проще всего создать основную конфигурацию безопасности корпоративного уровня и применить ее к репозиториям тестов. Затем можно создать дополнительные конфигурации безопасности и применить их к подмножеству репозиториев, выбранных с помощью языка кода, пользовательского свойства, видимости и других параметров фильтра. Дополнительные сведения см. в разделе [AUTOTITLE и Включение функций безопасности в пробной версии предприятия](/code-security/securing-your-organization/enabling-security-features-in-your-organization/applying-a-custom-security-configuration).

Предоставить доступ к просмотру результатов code scanning

По умолчанию только администратор репозитория и владелец организации могут просматривать все code scanning оповещения в своей области. Необходимо назначить предопределенную роль диспетчера безопасности всем командам организации и пользователям, которым требуется получить доступ к оповещениям, найденным во время пробной версии. Вы также можете предоставить владельцу учетной записи предприятия эту роль для каждой организации в пробной версии. Дополнительные сведения см. в разделе [AUTOTITLE и Управление диспетчерами безопасности в организации](/organizations/managing-peoples-access-to-your-organization-with-roles/using-organization-roles#assigning-an-organization-role).

Оценка и уточнение результатов настройки по умолчанию

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

Краткое описание результатов, найденных в организациях вашего пробного предприятия, вы можете увидеть в разделе Security «Предприятие». Существуют также отдельные представления для каждого типа оповещений системы безопасности. См . раздел AUTOTITLE.

Если вы не видите ожидаемых code scanningрезультатов , вы можете обновить настройки по умолчанию, чтобы запустить расширенный набор запросов для репозиториев, где ожидали найти больше результатов. Это управляется на уровне репозитория, см . раздел AUTOTITLE.

Совет

Если вам запрещено редактировать настройки репозитория , code scanningотредактируйте настройки безопасности, используемую репозиторием, чтобы настройки не применялись.

Если расширенный набор по-прежнему не сможет найти ожидаемые результаты, может потребоваться включить расширенную настройку, чтобы можно было полностью настроить анализ. Дополнительные сведения см. в разделе [AUTOTITLE и Используйте страницу статуса инструмента для сканирования кода](/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning).

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

Существует три различных типа автоматизированного анализа pull request, встроенных в GitHub:

  •         **
            Code scanning Анализ** использует запросы для выделения известных ошибочных шаблонов кодирования и уязвимостей безопасности. 
            Автофикс второго пилотапредлагает исправления проблем, идентифицированных .code scanning
    
  •         **Проверка** зависимостей суммирует изменения зависимостей, внесенные запросом на вытягивание, и выделяет все зависимости с известными уязвимостями или которые не соответствуют вашим стандартам разработки.
    
  •         **
            Copilot Обзор кода** использует ИИ, чтобы дать обратную связь по вашим изменениям с предложениями исправлений, где это возможно.
    

Эти автоматизированные проверки являются ценным расширением для самостоятельной проверки и упрощают для разработчиков представить более полный и безопасный запрос на вытягивание для одноранговой проверки. Кроме code scanning того, проверки зависимостей могут быть проведены для защиты безопасности и соответствия вашему кодексу.

Примечание.

          GitHub Copilot Автофикс включена в лицензию на GitHub Code Security. 
          Copilot Code review требует платного Copilot плана.

          Code scanning Анализ

Когда code scanning он включен, вы можете заблокировать слияния в важные ветки, если pull request не соответствует вашим требованиям, создав набор правил для предприятия или организации. Обычно требуется, чтобы результаты code scanning были доступны и все важные оповещения были разрешены.

  •         **Тип набора правил:** Branch.
    
  •         **Требуйте code scanning результаты:** Включите блокировку слияния до тех пор, пока результаты для коммита не будут успешно сгенерированы и не будут ссылаться на цели pull request.
    
  •         **Необходимые инструменты и пороги оповещения:** Определите, какой уровень оповещений нужно разрешить, прежде чем pull-запрос можно будет объединить для каждого code scanning используемого вами инструмента.
    

Как и во всех наборах правил, вы можете точно контролировать, какие организации (корпоративный уровень), репозитории и ветви он действует, а также определять роли или команды, которые могут обойти правило. Дополнительные сведения см. в разделе Сведения о наборе правил.

Просмотр зависимостей

Когда Advanced Security для репозитория включены граф зависимостей и зависимостей, файлы манифеста имеют расширенный дифференциальный вид, который показывает сводку зависимостей, которые они добавляют или обновляют. Это полезная сводка для рецензентов запроса на вытягивание, но не предоставляет никакого контроля над тем, какие зависимости добавляются в базу кода.

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

  1. Создайте частный репозиторий, чтобы служить центральным домом, где можно хранить повторно используемые рабочие процессы для предприятия.
  2. Измените параметры действий для репозитория, чтобы разрешить всем частным репозиториям в организации доступ к рабочим процессам в этом центральном репозитории, см . раздел "Разрешение доступа к компонентам в частном репозитории".
  3. В центральном репозитории создайте повторно используемый рабочий процесс для выполнения действия проверки зависимостей, настраивая действие в соответствии с потребностями бизнеса, см . раздел AUTOTITLE.
  4. В каждой организации создайте или обновите наборы правил ветви, чтобы добавить новый рабочий процесс в обязательная проверка состояния, см. раздел AUTOTITLE.

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

Обзор кода Copilot

Примечание.

По умолчанию пользователи запрашивают отзыв Copilot так же, как и у человеческих рецензентов. Однако вы можете обновить или создать набор правил на уровне организации, который автоматически добавляет Copilot как рецензент все pull requests, отправленные к выбранным веткам во всех или выбранных репозиториях. См. Настройка автоматического обзора кода GitHub Copilot в GitHub Enterprise Cloud документации.

          Copilot Оставляет комментарий к каждому просмотру pull request, не одобряя его и не запрашивая изменения. Это гарантирует, что его проверка является консультативной и не будет блокировать работу по разработке. Аналогично, не следует навязывать разрешение предложений, сделанных из-за Copilot известных ограничений, см. [AUTOTITLE](/enterprise-cloud@latest/copilot/responsible-use-of-github-copilot-features/responsible-use-of-github-copilot-code-review#limitations-of-github-copilot-code-review) в GitHub Enterprise Cloud документации.

Определите, где Автофикс второго пилота разрешено и включено

          Автофикс второго пилота Помогает разработчикам понять и исправить code scanning оповещения, обнаруженные в их pull-запросах. Рекомендуем включить эту функцию для всех репозиториев Advanced Security , чтобы помочь разработчикам эффективно решать оповещения и расширять понимание безопасного кодирования.

Существует два уровня управления:

  • Предприятия могут разрешать или блокировать использование Автофикс второго пилота по всему предприятию, используя политику «Advanced SecurityCode security», см.: AUTOTITLE.
  • Организации могут включать или отключать Автофикс второго пилота все репозитории, принадлежащие организации, в разделе «Глобальные настройки» организации, см. Настройка глобальных параметров безопасности для организации.

Привлечение разработчиков к исправлению безопасности

Кампании по обеспечению безопасности позволяют группам безопасности взаимодействовать с разработчиками для устранения технического долга безопасности. Они также предоставляют практический способ объединения образования в безопасном коде с примерами уязвимого кода в коде, с которыми знакомы ваши разработчики. Для получения дополнительной информации см. разделы AUTOTITLE и Проведение кампании по безопасности по исправлению оповещений в масштабах в GitHub Enterprise Cloud документации.

Обеспечение безопасной среды разработки

Среда разработки имеет множество компонентов. Некоторые из самых полезных функций для масштабирования и стандартизации защищённой среды GitHub разработки:

  •         **Конфигурации безопасности:** определите настройку функций безопасности для предприятия, организации, подмножества репозиториев организации или новых репозиториев, см. статью ["Уточнение конфигураций](#refine-your-security-configurations) безопасности".
    
  •         **Политики:** защита и управление использованием ресурсов для предприятия или организации см. в разделе [AUTOTITLE](/admin/enforcing-policies/enforcing-policies-for-your-enterprise).
    
  •         **Наборы правил:** защита и управление ветвями, тегами и отправками для организации, подмножества репозиториев организации или репозитория, см [. раздел AUTOTITLE](/organizations/managing-organization-settings/creating-rulesets-for-repositories-in-your-organization).
    
  •         **Шаблоны репозитория:** определение рабочих процессов безопасности и процессов, необходимых для каждого типа среды, см. в разделе [AUTOTITLE](/repositories/creating-and-managing-repositories/creating-a-template-repository). Например, каждый шаблон может содержать специализированный:
    
    • Файл политики безопасности, определяющий позицию безопасности компании и как сообщать о любых проблемах безопасности.
    • Рабочий процесс для Dependabot version updates менеджеров пакетов, используемых компанией.
    • Рабочий процесс, определяющий расширенную настройку для code scanning поддерживаемых языков разработки, где результаты настройки по умолчанию недостаточны.

Кроме того, когда разработчик создает репозиторий из шаблона, он должен определить значение любых обязательных настраиваемых свойств. Пользовательские свойства очень полезны для выбора подмножества репозиториев, к которым вы хотите применить конфигурации, политики или наборы правил, см. Управление настраиваемыми свойствами для репозиториев в организации в GitHub Enterprise Cloud документации.

Дальнейшие шаги

Когда вы завершите изучение этих вариантов и secret scanning функций, вы готовы проверить свои открытия с потребностями вашего бизнеса, а затем изучить их дальше.

Дополнительные материалы

  •         [AUTOTITLE](/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions)
    
  •         [AUTOTITLE](/admin/enforcing-policies/enforcing-policies-for-your-enterprise)
    
  •         [AUTOTITLE](/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-repositories-in-your-enterprise/governing-how-people-use-repositories-in-your-enterprise) В GitHub Enterprise Cloud документации
    
  •         [Применение GitHub Advanced Security в масштабах](https://wellarchitected.github.com/library/application-security/recommendations/enforce-ghas-at-scale/)